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/ezcapture

This thread is about a variant of https://yabb.jriver.com/interact/index.php/topic,140134.msg972062.html which uses the decklink api to support blackmagic capture cards

it's in testing state atm but seems stable enough to try to use it, feedback welcome

current testing version can be found at https://github.com/3ll3d00d/ezcapture/releases/tag/0.7.0-alpha.9

pls use this variant for testing -> bmcapture-0.7.0-alpha.9-release-trace-logging.zip

as then logs are available

installation instructions, basically admin cmd and then regsvr32 the ax file (NB: rename it bmcapture-trace.ax if using trace)

a few things to note if you try it

* I only have a decklink mini 4k here so testing is a bit limited
* it converts everything to 8 bit RGB internally right now because it's the only format natively supported by jrvr (better transformations will come later)

[Hendrik]

ok thanks, is there a post somewhere that explains how to interpret the jrvr video timing log?

No, the log is basically designed for me. Although with the headers you can sort of make sense of it, i guess.
Note that its layout changes based on presentation mode.

[jmone]

Sounds good, I'll give it a try and report back!

[jmone]

Here is a quick test from my Camera (and I'll be away till the easter weekend).  I tried with both UHD/50fps 709 and HLG signals (see attached pics).  Here are some notes:
- Audio was just static that came and went (note: I was just sending 2ch from the Camera and the filter was saying 8ch)
- The filter seems to be "persistent" and holds the device till you close both MC and MC Server (otherwise you get a black screen in MC if the input signal changes between playbacks)
- 709:  Just worked and looked good
- HLG:  Just worked and looked good, I see that the Colour Format was 2020, but the Transfer function was 709 not HLG

Overall, nice work!  I'll try with a PC next.

[jmone]

Did a test from a Laptop playing and HDR Test Clip using MC so I could see that it was outputting HDR correctly.  The input was only seen as SDR.

[jmone]

Couple of other things:
 - the audio "static" thing, is actually over the top of any other audio, I even get it when the video is paused.
 - it is all a bit "fragile", in that if you get any signal mismatch you end up with a black screen (eg everything needs to be in the same FPS, and the BMD device seems to get stuck in a particular FPS).

[mattkhan]

thanks for testing, tbf I wasn't expecting stability at this point

can someone fork these posts to a new thread on a public board? I guess they're better there as they are about decklink devices specifically

- Audio was just static that came and went (note: I was just sending 2ch from the Camera and the filter was saying 8ch)

I was surprised by this also, the SDK reports the card has 8 channels so that's what I set the output format as but I thought capture was 2 channel only

- The filter seems to be "persistent" and holds the device till you close both MC and MC Server (otherwise you get a black screen in MC if the input signal changes between playbacks)

as far as I can see, MC never destroys the filter once it's loaded it until server shutdown which, to my mind, seems a bit odd. I would think the filter would be destroyed after playback stops (and hence the filter graph is torn down) but that's not how MC works as far as I can see. It seems a bug to me.

- HLG:  Just worked and looked good, I see that the Colour Format was 2020, but the Transfer function was 709 not HLG

will check it, I hadn't thought about HLG tbh (don't have any such sources)

Did a test from a Laptop playing and HDR Test Clip using MC so I could see that it was outputting HDR correctly.  The input was only seen as SDR.

for this case, it will be really helpful if you can use the trace filter and post the log it generates

[JimH]

CEO-Elect is Back:  https://yabb.jriver.com/interact/index.php/topic,141053.0.html

[mattkhan]

@jmone updated 1st post, there's a new build which hopefully fixes many of the issues you noted

[jmone]

Thanks mate, I'll give it a go when back home later this weekend!

[mattkhan]

just to note, the thing I haven't spent any time on yet is audio

[claw]

HDR input not processed as such.

Trace log attached.

DeckLink 4K Mini Recorder.   
Apple TV 4K sending 4K23 4:2:2 12-bit BT2020 HDR10

[mattkhan]

thanks, looks like a simple bug in propagating the hdr metadata

Should be fixed in https://github.com/3ll3d00d/ezcapture/releases/tag/0.7.0-alpha.9

[claw]

thanks, looks like a simple bug in propagating the hdr metadata

Should be fixed in https://github.com/3ll3d00d/ezcapture/releases/tag/0.7.0-alpha.9

I will test later today.

Another issue I did not mention is that motion is not smooth, especially with the trace version of the capture filter.  Switching to the non-trace version helped but still not good enough.   Using the same JRiver and JRVR options that I use with the Magewell card.

[mattkhan]

Is it dropping frames?

[claw]

No.

[claw]

thanks, looks like a simple bug in propagating the hdr metadata

Should be fixed in https://github.com/3ll3d00d/ezcapture/releases/tag/0.7.0-alpha.9

Getting unable to lock status in log.

User error.

[mattkhan]

I have found it flaky in that regard too, not sure why

unfortunately the decklink api docs are poor and support is basically non existent so it's a bit tricky to work with

[claw]

I have found it flaky in that regard too, not sure why

unfortunately the decklink api docs are poor and support is basically non existent so it's a bit tricky to work with

This looks better. Log and screenshot:

[mattkhan]

interesting that it reports HDR10, never seen that before

@Hendrik what triggers JRVR to show that?

[mattkhan]

your log is dotted with lines like this

Code: [Select]

19:31:39.674156592 [7632] bmcapture.cpp:779            LOG_WARNING   filter       [BlackmagicCaptureFilter] Video capture discontinuity detected, 1 frames missed at frame 292

I suspect it explains the motion problem, it's a function of the need to convert the format of every single frame received. I didn't expect to need to do this & for it to be so slow so I'm doing it in the wrong place atm. A subsequent release should fix this (but that is a bit more involved so will take some days to get done)

[claw]

your log is dotted with lines like this

Code: [Select]

19:31:39.674156592 [7632] bmcapture.cpp:779            LOG_WARNING   filter       [BlackmagicCaptureFilter] Video capture discontinuity detected, 1 frames missed at frame 292

I suspect it explains the motion problem, it's a function of the need to convert the format of every single frame received. I didn't expect to need to do this & for it to be so slow so I'm doing it in the wrong place atm. A subsequent release should fix this (but that is a bit more involved so will take some days to get done)

Yes, still have the motion issue.    Also maybe related is that I have to set 450 ms audio delay in my AVR.     Audio is split out by HDfury VRROOM before sending to capture card.

Good progress, though.

[mattkhan]

Yes, still have the motion issue.    Also maybe related is that I have to set 450 ms audio delay in my AVR.     Audio is split out by HDfury VRROOM before sending to capture card.

fwiw, based on what I've seen, I'd expect a decklink card to be delayed somewhat relative to a magewell card in the same system for 2 reasons.... 1) the magewell sdk provides a low latency mode which means it should take less time to capture a frame, 2) decklink supports a v limited set of formats which require conversion (done on the cpu) before handing them to the renderer

overall i would think it means higher cpu usage & need to handle a somewhat larger delay vs a magewell card (but they're generally a fair bit cheaper so....)

[claw]

fwiw, based on what I've seen, I'd expect a decklink card to be delayed somewhat relative to a magewell card in the same system for 2 reasons.... 1) the magewell sdk provides a low latency mode which means it should take less time to capture a frame, 2) decklink supports a v limited set of formats which require conversion (done on the cpu) before handing them to the renderer

overall i would think it means higher cpu usage & need to handle a somewhat larger delay vs a magewell card (but they're generally a fair bit cheaper so....)

I am using a less powerful PC for the DeckLink installation.   An i5 instead of i7, and an RTX2080Ti instead of a 3080Ti.

[Hendrik]

interesting that it reports HDR10, never seen that before

@Hendrik what triggers JRVR to show that?

Its just the PQ transfer. 0 nits means a lack of static metadata.

[claw]

I don't use the Presentation queue.   But if I enable it, the output video locks up.

[jmone]

interesting that it reports HDR10, never seen that before

FWIW I see JRVR report "HDR10 0 nits" (note the space between 10 and 0) if I don't set "HDR Metadata" on my encodes in Resolve. 

[claw]

I see these metadata related traces with version 8, but not in version 9 of the capture filter.   I would expect to see HDR10 1000 nits based on the MaxDML value in this trace.


03:14:30.379812819 [4720] capture.h:107                LOG_INFO      filter       [BlackmagicCaptureFilter] HDR metadata is now present
03:14:30.379813208 [4720] capture.h:115                LOG_INFO      filter       [BlackmagicCaptureFilter] Primaries RGB 0.6800 x 0.3200 0.2650 x 0.6900 0.1500 x 0.0600
03:14:30.379813247 [4720] capture.h:120                LOG_INFO      filter       [BlackmagicCaptureFilter] Whitepoint 0.3127 x 0.3290
03:14:30.379813284 [4720] capture.h:125                LOG_INFO      filter       [BlackmagicCaptureFilter] DML/MaxCLL/MaxFALL 0.0050 / 1000.0000 585 162

[jmone]

WOW!  Alpha 9 is looking really good.  Did some HDR test from my laptop with MC --> UltraStudio --> Desktop with MC.
- Great looking picture
- Nice and stable
- Quick startup
- Buzzing sound is gone
- HDR worked

Here are some of the things that I could not figure out (it may also be all the combinations of settings in the tool path)
- Audio Channel Mapping: Missing Center & wrong Sub Channel.  The UltraStudio is seen by my laptop as a "normal" HDMI connection supporting up to 8ch.  If I pick any of the 5.1 / 7.1 config options I don't get any center channel, and the sub is mixed to the center channel on my Desktop.  It seems like a channel mapping issue but I'm not sure if it is in the capture code or with the config of either/and/or the Laptop / Ultrastudio
- HDR 10 0 nits:  Something is stripping out the static HDR Meta Data as I only get "HDR 10 0 nits" on the HDR Test Clips through this chain, but when played natively it is "HDR10 1000 nits"

Let me know what logs you want (and with what filter).

[jmone]

I've also only been testing the Audio being decoded, I'd need to test if Bit streaming works?

[mattkhan]

thanks for testing

- HDR 10 0 nits:  Something is stripping out the static HDR Meta Data as I only get "HDR 10 0 nits" on the HDR Test Clips through this chain, but when played natively it is "HDR10 1000 nits"

this one is a small bug on my side but, to the best of my knowledge, it's only impacting the OSD (as JRVR ignores this when tone mapping as far as I know

- Audio Channel Mapping: Missing Center & wrong Sub Channel.  The UltraStudio is seen by my laptop as a "normal" HDMI connection supporting up to 8ch.  If I pick any of the 5.1 / 7.1 config options I don't get any center channel, and the sub is mixed to the center channel on my Desktop.  It seems like a channel mapping issue but I'm not sure if it is in the capture code or with the config of either/and/or the Laptop / Ultrastudio

in my magewell filter, I have full support for all possible channel mappings because I have access to the HDMI infoframe that contains this info. The Blackmagic SDK doesn't provide any such info so I probably have to pick what look like the most sensible default option and use that? If you have a better idea, do lmk!

you can see all the possible mappings from CEA-861-E Table 28 in https://github.com/3ll3d00d/ezcapture/blob/main/mwcapture/mwcapture.cpp#L1614 (I guess the comments should make it clear what's what)

probably the one marked as KSAUDIO_SPEAKER_7POINT1_SURROUND is the only one that really makes sense (NB: you can see that C and LFE are swapped on the wire but not sure if blackmagic sdk remaps this or passes it through)

[jmone]

- Audio: Does not look like the UltraStudio supports bitstreaming.  Windows does not report that it has any compressed format support.
- Display Rate Change:  Not unexpected (given the filter is already built) but changing the frame rate (eg MC's Display Rate change option) does not work, you have the frame rate that the filter was created sticking, even though the UltraStudio itself dynamically changes to the new frame rate.

[mattkhan]

I've also only been testing the Audio being decoded, I'd need to test if Bit streaming works?

the decklink sdk says it only supports PCM, I asked about it on https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=218498 but seems like they don't really answer Qs so no clue what would get passed through if you send encoded audio

all the code to support this (detection of the codec in the bitstream, extraction of the databurst, negotiation of audio formats with MC) is present in my magewell filter so can give it a try once I get everything else working

for a pure bitstream passthrough, I believe MC would need to support this (not sure if it does, I don't think so but Hendrik would have to comment)

[mattkhan]

- Display Rate Change:  Not unexpected (given the filter is already built) but changing the frame rate (eg MC's Display Rate change option) does not work, you have the frame rate that the filter was created sticking, even though the UltraStudio itself dynamically changes to the new frame rate.

it's an MC limitation, refresh rate switching does not work for capture cards so you have to do it manually until MC supports that

[jmone]

- On the Audio, I've just been testing with the Windows Audio Config, where you click on different speakers to see where it goes.  I tried it with both the 5.1 mapping option in the UltraStudio on and off (see pic).  That looks like the only option from their GUI.  Apart from that I don't really have any insight to what would work best, as the BMD device are just designed to pass through audio eg take Ch1 --> Ch1 etc as the cameras let you map the Mics to any Audio Channel, and you then assign them in the editing SW to the layout you want.

- Bitstreaming: I just don't think it supports it as compressed audio not really a "thing" in their space.  It would be interesting to see what it does if you did force though a Bitstream.  It would be kind of irrelevant however, as most devices would only see what the UltraStudio is advertising, and it is blank for Bitstreaming so that would need to be spoofed in the driver?

- Frame Rate Switching:  Yup, I remember the convo many years ago about this limitation (discussion having gapless playback of multiple video files like you can with audio)

- HDR 10 0 nits:  Nice.  I don't see any obvious differences anyway in my testing

[jmone]

it's an MC limitation, refresh rate switching does not work for capture cards so you have to do it manually until MC supports that

FWIW - I do see MC (Client) change the display rate and the UltraStudio change as well.  Not having the capture side change is a small thing, as I'm guessing most wanting this filter would have it all presetup for the correct frame rate anyway.

[mattkhan]

FWIW - I do see MC (Client) change the display rate and the UltraStudio change as well.  Not having the capture side change is a small thing, as I'm guessing most wanting this filter would have it all presetup for the correct frame rate anyway.

not sure if I'm telling you something you already know but..... the capture card will (should) change automatically & JRVR will see this, MC doesn't trigger a change in the actual output though and this needs to be fixed (people generally want this, e.g. if you feed an appletv in then it will change refresh rates and you want the whole chain to honour it). Note that it's not just a gapless playback issue, it's not even like you can restart playback and it will be in the rate frame rate (as this is based on library info and there's no library item to drive it)

[jmone]

Yes, I think we are saying the same thing.

[Expectingtofly]

Many thanks for creating this. 

For info, I'm getting incorrect black levels on standard 1080p sdr content.   For reference, I do get correct black levels if I use the blackmagic WDM capture device in JRVR or when using video processor + madvr.
My workflow is ybcr->Full (JRVR)->Full
I presume from the properties, the wdm device is converting the ybcr to full RGB and so is the bmcapture, but JRVR is seeing it as limited.

I've attached screenshots showing the incorrect black levels through JRVR bmcapture, and the correct levels through JRVR wdm and through VP
Let me know if you need any logs



 

[mattkhan]

the decklink SDK does not provide any way to determine what the nominal range of the signal is, I can change it to signal unknown to the renderer though I'm not sure how JRVR will behave in this case, a Q for Hendrik to answer

[Expectingtofly]

the decklink SDK does not provide any way to determine what the nominal range of the signal is, I can change it to signal unknown to the renderer though I'm not sure how JRVR will behave in this case, a Q for Hendrik to answer

As far as I can tell, all 3 input signal types (Ycbcr, RGB Limited, RGB Full Range) result in a conversion to RGB Full Range in the capture filter, but the renderer being told it is RGB Limited.
Making it impossible to get correct black levels, unless I'm mistaken?

[mattkhan]

It's just a setting in the filter, I can change it for next release. This is just a version for testing purposes so bugs are expected

[Expectingtofly]

It's just a setting in the filter, I can change it for next release. This is just a version for testing purposes so bugs are expected

That's great, thanks. I realise this is in early test release.  I just wasn't sure I had described the problem well enough.