INTERACT FORUM
Windows => Third Party Plug-ins, Programs, and Skins => Topic started by: mattkhan on December 03, 2024, 01:50:05 pm
-
https://github.com/3ll3d00d/ezcapture
latest release can be found here -> https://github.com/3ll3d00d/ezcapture/releases/latest
this is a directshow filter that enables use of a magewell pro card (https://www.magewell.com/products/pro-capture-hdmi-4k-plus) in MC (and other directshow apps)
you can use such cards in MC without this filter so the differentiation comes from
* will automatically try to handle signal changes, mainly this means from SDR to HDR and back (NB: actual support depends on the renderer, JRVR does support this so all good for MC)
* can handle multichannel audio
code is publicly available as is the build recipe, if feeling paranoid then feel free to build it yourself :)
refer to the readme in the repo for installation instructions & how to debug/diagnose problems
-
So does this work like videoprocessor works for Madvr?
-
So does this work like videoprocessor works for Madvr?
Yes you could use it that way (though this is driven by the metadata in the stream rather than user choice)
-
NB: the key difference being you're not pinned to a renderer with an unknown future (madvr)
-
Now that video seems done, continuing to work on multichannel pcm, and audio format negotiation. I eventually realised that the channel mapping in cea-861 is different to usual output formats so I need to add some logic to handle whatever is in the audio hdmi infoframe.
-
NB: the key difference being you're not pinned to a renderer with an unknown future (madvr)
That is definitely exciting. Will keep an eye on this for sure
-
It basically works now as far as I can see so you just need a card to test it out
-
for audio, I found https://learn.microsoft.com/en-us/windows/win32/coreaudio/representing-formats-for-iec-61937-transmissions which looks like it corresponds to the info in 6.6.1 of https://ia903006.us.archive.org/11/items/CEA-861-E/CEA-861-E.pdf (HDMI audioframe) so I guess I should be able to try to send such encoded content from my filter in the right format, whether it works or not is probably something that's going to take a bit of time to test out
-
Looks like https://ffmpeg.org/doxygen/trunk/spdifdec_8c_source.html#l00189 is what is needed to determine the contents of the bitstream
-
Managed to successfully receive ac3, now to work out how to push that through mc
-
as far as I can tell, https://github.com/3ll3d00d/mwcapture/releases/tag/0.3.0-beta.5 works from a software point of view and is compatible with LAV & can handle multi channel PCM as well as a bitstream correctly and switch between HDR and SDR (as much as I've been able to test).
For video, this seems fairly straightforward and seems to work ok.
For audio, PCM seems fine, AC3 seems fine, anything beyond AC3 (EAC3, truehd, dtshd) seems much much more brittle and whether it works or not seems entirely source dependent. i.e. I've tested a few different source devices, each one has behaved differently and, as far as I can tell, these are not software problems at my end.
-
This is chill. Also a nice confirmation that those Magewell cards do handle multichannel properly :)
Thanks.
Say you were to be splitting out your video *before* the magewell using it only for audio, any clue about the latency coming out of the directshow filter? If I was utilizing the direct show filter in GStreamer or something.
https://www.magewell.com/developer/14/detail is interesting. Will need to investigate this more.
-
there's some more detail in https://www.magewell.com/developer/26/detail inc some measurements they provide, I am using the low latency with partial notification mode (min 64 lines chunks) because why not :)
might be stating the obvious but.... the actual latency will be heavily dependent on the host hardware, what you capture & what you do with it so not sure measurements from elsewhere will be terribly useful and I'd guess the latency is commonly going to be dominated by what you do with the frame.
In this case, the entire frame has to be received before it can pass downstream and latency is going to be dictated by what the renderer does with it (and timestamps on the audio stream).
I'm not a directshow expert but I don't see how that (frame/sample based) api could fully benefit from partial notification, i.e. you'd need to be able to feed the lines into some buffer that a renderer can operate as and when it arrives in order to reduce latency further but since that's going to be done on the gpu then I imagine you want to be writing fewer times in smaller chunks (assuming a usual windows setup with a discrete gpu that has its own ram which is relatively costly to write to)
-
fwiw https://github.com/3ll3d00d/mwcapture/releases/tag/0.3.1 seems to be fully functional to me, supports switching between HDR and SDR and between different codecs (PCM to AC3 to EAC3 etc)....
... however the card, in my setup at least, cannot handle 192kHz audio without loss which prohibits use with anything beyond AC3 (or non HD DTS but I don't think that is used basically anywhere these days) for encoded audio
also depends on https://yabb.jriver.com/interact/index.php/topic,140304.0.html to be used with MC
-
https://github.com/3ll3d00d/mwcapture/releases/tag/0.4.5 fixes some remaining glitches in PCM audio handling, seems stable to me at least
video has been fine/untouched for ages so still switches between hdr and sdr automatically without issues
I added support for magewell usb devices as well so they should work ok (my own testing is a bit lighter but seems ok)
-
robin49,
You have a new thread here: https://yabb.jriver.com/interact/index.php/topic,140722.0.html
-
next release will include a property page showing the important bits about the signal so you don't have to rely on logs
examples attached including how that relates to what JRVR shows
(there is some bug in the HDR bit means it's not being cleared out correctly for SDR, will fix that)
-
and one to show what happens when there is no signal
-
available at https://github.com/3ll3d00d/mwcapture/releases/tag/0.5.2
will need to register the filter again to pick up the property page
-
available at https://github.com/3ll3d00d/mwcapture/releases/tag/0.5.2
will need to register the filter again to pick up the property page
I am talking to you @ AVS? Just found the project here and can't believe I was sleeping on this amazing development!!!!
-
Working well for me now with a Magewell Pro Capture HDMI 4K capture card, model 11153.
4K23 HDR10 streaming input with JRVR tone mapping to SDR BT2020 output. (Audio is handled separately by a Denon AVR in order to retain Atmos compatibility.)
All I have left to do is to automate the start of the channel.
-
Hello from France!
I’ve just discovered your plugin that looks great.
Would it work with a decklink 4k recorder?
Thank you
Fred
-
there's a version in https://yabb.jriver.com/interact/index.php/topic,141053.0.html under testing but it doesn't entirely work atm
-
Thank you.
Does it work fine with Usb models (pro or plus) like PCI Magewell?
-
it's been tested with 4k pro and plus models and seems to work ok (NB: the feature set of those cards is not exactly the same as the pro models)
-
There are a lot of pci cards models. What is the minimum requiered for 4k TM?
-
the 4k plus is the model with a hdmi 2.0 input
-
One more question about audio:
Is it better to use the loop through of the card, or let Jrvr treat the sound and let it go out through the audio output of the Pc?
-
it really depends on what you need, many people want immersive formats so route audio separately to a decoder (i.e. an AVR/AVP)
-
it's been tested with 4k pro and plus models and seems to work ok (NB: the feature set of those cards is not exactly the same as the pro models)
What would be the difference between pci and usb in use with jrvr? Speed? Drivers?…
-
the difference is the hardware capabilities of the card, you need to compare specs from their site vs how you intend to use it
-
Thank you.
Does it work fine with Usb models (pro or plus) like PCI Magewell?
The Magewell USB Capture HDMI 4K Plus is limited to 4K30 or less. Inputs with 4:4:4 or 4:2:2 color sampling are automatically converted to 4:2:0 for capture in the NV12 or I420 color space format, in order to fit within the 5Gbps bandwidth available in the USB 3.0 standard. 4K30 4:2:0 8-bit is 4.46 Gbps.
The USB Capture HDMI 4K Pro has a USB 3.2 2x2 20Gbps interface that allows it to capture 4K60 HDR, as long as the PC also has a USB 3.2 20Gbps interface.
-
Thank you very much for these helpful answers!