Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

https://github.com/3ll3d00d/mwcapture

latest release can be found here -> https://github.com/3ll3d00d/mwcapture/releases

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

limitations noted on the linked github inc

* only tested on my system
* multichannel audio channel layout is a ? atm (I need to test more)
* I think changing audio format is technically supported by my filter but MC (as far as I know) does not this on the fly so it's probably a moot point

code is publicly available as is the build recipe, if feeling paranoid then feel free to build it yourself

note that this is a 1st release, it does seem functional (ignore the multichannel audio bit) to me but I think anyone using it should go in expecting problems & be prepared to provide logs to explain what they see (using one of the non release builds)

[Lep334]

So does this work like videoprocessor works for Madvr?

[mattkhan]

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)

[mattkhan]

NB: the key difference being you're not pinned to a renderer with an unknown future (madvr)

[mattkhan]

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.

[Lep334]

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

[mattkhan]

It basically works now as far as I can see so you just need a card to test it out

[mattkhan]

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

[mattkhan]

Looks like https://ffmpeg.org/doxygen/trunk/spdifdec_8c_source.html#l00189 is what is needed to determine the contents of the bitstream

[mattkhan]

Managed to successfully receive ac3, now to work out how to push that through mc

[mattkhan]

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.

[eve]

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.

[mattkhan]

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)

[mattkhan]

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