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/mwcapture
latest release can be found here -> https://github.com/3ll3d00d/mwcapture/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