Print

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

[mattkhan]

OK, will be great if it can be done in an open manner that lets a user provided filter give the info required to drive it

[JimH]

Matt,
I think you know that we don't intend for JRVR to be used by other applications.  I hope you understand.

[mattkhan]

You misunderstand as it's not another application

I'm talking about a directshow capture filter to use as channel within MC television. I can already use the microsoft provided one for the card but that only supports stereo audio and doesn't expose the colourspace in a way that lets a renderer understand it, you have to use the api provided by the card manufacturer to do all that. Hence write one and then be able to use MC to fully access the card capabilities.

Put simply, it's exactly what Yaobing is doing for the blackmagic cards (which I don't use because they have limited support for the resolution/frame rate output by my cable box. I can't imagine why you'd want to restrict support to a particular card but obviously it's your software so that's your choice.

[mattkhan]

We are working on HDR metadata.  It is still not clear how we are approaching it.

regardless of whether you make it public api or not, I'm curious what are the downsides of the method of packing data into IMediaSideData (https://github.com/Nevcairiel/LAVFilters/blob/81c5676cb99d0acfb1457b8165a0becf5601cae3/include/IMediaSideData.h) are? it seems commonly used and pretty straightforward

[mattkhan]

FWIW I have my filter functional now and it seems to at least play in MC & I can see that JRVR is tonemapping without changing settings when fed with appropriate data so not sure you need to do anything other than simply integrate their API as a capture filter?

I haven't tackled attempting to handle changing format yet, e.g. my cable box (a virgin 360 aka LG horizon) will switch from sdr to hdr when I go from normal tv to something like apple+, atm I just plan to use its function to overlay an image as OSD to say "restart playback" but would JRVR cope with this? e.g. does it support https://learn.microsoft.com/en-us/windows/win32/directshow/dynamic-format-changes ?

[Hendrik]

JRVR is fine with dynamic format changes, if you need to change the allocator due to frame size or format changes, you may need to flush though (so all frames are returned to the allocator). Feel free to refer to LAV Videos format change logic https://github.com/Nevcairiel/LAVFilters/blob/master/decoder/LAVVideo/LAVVideo.cpp#L1500-L1589

[mattkhan]

thanks for the link, will try to adapt/copy

[jmone]

I still think an encoder is going to be needed if you want to pause, record etc.  That uncompressed video stream bitrate is too high to write out to disc effectively and the resultant file is full of dropped frames.

[Yaobing]

What you are saying is that the hard disk is the limiting factor here.  A compressor and a decompressor shift load to CPU. That is what I thought too, as time-shifting writes many files to disk and then reads them back for displaying.

[Yaobing]

Regarding HDR metadata, I posted the following a few days ago:

BMDDeckLinkSupportsHDRMetadata is 1
BMDDeckLinkSupportedDynamicRange is 1610612736 (HDRStaticPQ, HDRStaticHLG)
Found IDeckLinkHDMIInputEDID interface
bmdDeckLinkHDMIInputEDIDDynamicRange is 536870912 (HDRStaticPQ)
Found IDeckLinkStatus interface
bmdDeckLinkStatusDetectedVideoInputDynamicRange is 0 (SDR)


These are the static info that I found from API, and the result was for jmone's device. What I did not know was whether we need to deal with metadata for each frame. As far as I know, the WDM capture filter does not carry the metadata, so how do we pass the metadata? I suppose we need to synchronize the video frames that go to the renderer via DirectShow filters with what we find with the API?  That is why I thought a complete re-writing of the system (not using their WDM capture filter, like mattkhan is doing) is necessay?

[mattkhan]

It is transmitted per frame though clearly it changes rarely so I guess you could write a transform filter to sit on top of the provided capture filter (though in my experience, dealing with the media type and the filter negotiation is where all the work actually is, capturing the frame is simple in comparison)

[jmone]

What you are saying is that the hard disk is the limiting factor here.  A compressor and a decompressor shift load to CPU. That is what I thought too, as time-shifting writes many files to disk and then reads them back for displaying.

Kinda.  We are capturing uncompressed Video (RGB) and the data rates (see table) will be in many cases well over 10 Gbps Vs playing "normal" compressed Video (HEVC, AVC, MPEG, AV1 compressed files, discs, streams) which is normally well under 1 Gbps.  These uncompressed data rates:
- Can be too large to write out to a file in real time (eg dropped frames)
- Are too large to then be later played over a std 1Gbps network connection
- Takes up far too much disc space

My suggestion would be to write the uncompressed video stream via an encoder to a file (say MP4 using HEVC, AVC, whatever) and then play that as with any other "normal" compressed video file.