LAV Filters - DirectShow Media Splitter and Decoders

[tebasuna51]

Originally Posted by j7n

The sound is quite obvious between the words "to" and "be" on the right side (left front channel is clean).

Sorry, I listen the high frequencies at 3.905 but not the clik.
Try then GraphEdit to verify if LAV filter decoder is also affected:

[v0lt]

Originally Posted by Blight

so I've had OpenAI's O3 model try to analyze the differences and it came up with 3 important points, 2 of which should be simple to implement, please consider enhancing this functionality.

I think the main problem with AI is not that it is stupid, but that it does not understand its stupidity. That is why AI writes its answers with unperturbed confidence.
This is where another problem arises. Naive users believe the stupid AI and start writing its answers on the Internet as a good solution. This creates even more garbage on the Internet. I hope that in the future, publishing AI "answers" on many forums will be considered flooding.

[j7n]

Sure, with 32-bit from MPC-HC. https://i.imgur.com/JTSgI5T.png

A second sample, pourque.ec3, problem at 41728 right at the start. Only on the first playback. Maybe ffmpeg has processor-specific code, so it only happens sometimes?

https://pixeldrain.com/u/AFU54eoF

[tebasuna51]

I found how write wav file in avi container:

And using LAV Audio decoder 0.79.2 in first play (x0) -> error, second play (x1) -> OK

[nevcairiel]

Originally Posted by Blight

Hi Nev, I know it's not the most thrilling of issues to fix, but can you please take look at this, I believe this issue can be partially resolved with a few small tweaks:
https://github.com/Nevcairiel/LAVFilters/issues/652

None of the statements that so called "Intelligence" provides are actually correct or event remotely useful. The code it cites does not exist, the options it recommends are wrong or their meaning distorted or entirely inverted, and the correct options that would do the tasks it suggests are set by default.

As a general rule for anyone ever reading this, any AI interaction will instantly get your post dismissed and probably ridiculed. Developers should know better.

[clsid]

Originally Posted by tebasuna51

I found how write wav file in avi container:
Attachment 18945
And using LAV Audio decoder 0.79.2 in first play (x0) -> error, second play (x1) -> OK
Attachment 18946

The whole spectrogram looks a bit different, not just the broken segment.

I suggest putting the sample files on FFmpeg bug tracker.

[j7n]

I have done so.

[Blight]

Originally Posted by nevcairiel

None of the statements that so called "Intelligence" provides are actually correct or event remotely useful. The code it cites does not exist, the options it recommends are wrong or their meaning distorted or entirely inverted, and the correct options that would do the tasks it suggests are set by default.

As a general rule for anyone ever reading this, any AI interaction will instantly get your post dismissed and probably ridiculed. Developers should know better.

I sincerely apologize. I tried many different ways to understand the performance difference compared to libVLC and the answers O3 provided made sense, I should have dug deeper to verify the code exists.

The issue itself still stands. When performing a seek action on a remote Emby server or switching subtitle tracks, with libVLC the action is near-instant while in DirectShow using LAV Source, it can take 1-30 seconds. Is there any way I can help you debug this issue, taking into consideration that I limited understanding of the code itself? Is there a build that outputs a debug log that may help trace the issue?

[clsid]

A track change triggers a flush in the splitter. That is needed to acquire data packets for the new subtitle track, which can be located before current parsing position.

But perhaps an optimization could be done. If the splitter stores the end timestamp of the last processed sub packet, then it could decide if it is possible to skip the flush of audio and video queues, if last packet end time is in the past.

[max79]

@Nevcairiel

I'm noticed that LIVE-streams(HLS or MPEG-TS) that have subtitle track in it, lead a Graph Studio to crash right after trying to render a Video pin. Example(This site works only in Russia. Please use VPN):

https://rt-ural-sur-htlive.cdn.ngeni...7/variant.m3u8

Stream contain this subtitle track:
MEDIATYPE_Subtitle {E487EB08-6B26-4BE9-9DD3-993434D313FD}
MEDIASUBTYPE_UTF8 {87C0B230-03A8-4FDF-8010-B27A5848200D}
FORMAT_SubtitleInfo {A33D2F7D-96BC-4337-B23B-A8B9FBC295E9}

p.s. I have no no crash only if I render a Subtitle pin first and only then render a Video pin.

Any feedback would be appreciated.

[Blight]

Is line 21 (closed captioning) in live streams supported by LAV Filters?

There are no sub/line21 pins exposed. I verified, a CC track exists on this stream using libVLC.

[nevcairiel]

Originally Posted by Blight

Is line 21 (closed captioning) in live streams supported by LAV Filters?

There are no sub/line21 pins exposed. I verified, a CC track exists on this stream using libVLC.

https://github.com/Nevcairiel/LAVFil...ettings.h#L405

[Blight]

Originally Posted by nevcairiel

https://github.com/Nevcairiel/LAVFil...ettings.h#L405

Thank you 🙏

Is there any downside to always enabling the CC output pin creation?

[Blight]

Originally Posted by nevcairiel

https://github.com/Nevcairiel/LAVFil...ettings.h#L405

I enabled the pin, found a stream that is verified to support closed captions, but trying to connect the line21 pin to the Microsoft's "Line 21 Decoder 2" filter results in an error #0x80040207 (VFW_E_NO_ACCEPTABLE_TYPES).

I noticed the output pin on LAV Video decoder exposes "MEDIATYPE_DTVCCData" instead of the expected "MEDIATYPE_AUXLine21Data" which may be the cause.

Is there something I'm not taking into consideration?

[nevcairiel]

Its designed to be CEA 708 DTV CC data, not the older Line 21 data.

[Blight]

Originally Posted by nevcairiel

Its designed to be CEA 708 DTV CC data, not the older Line 21 data.

I tried DirectVobSub/xySubFilter and neither one supports this format.

I even tried passing it through the SAMI (CC) Parser filter with no success (error 0x80004002)
https://learn.microsoft.com/en-us/wi...-parser-filter

Can it be used with any existing DirectShow components? I searched but it's not very clear.

[Sunspark]

You could try MPC-BE's decoder with EVR-CP to verify whether or not it works with the media you're working with and go from there. "Line 21 Decoder - enabled for Microsoft DTV-DVD Video Decoder and EVR-CP". Not sure if you also need to check on the line 21 checkbox in the DVD settings (present in both HC and BE) for streams, or if the checkbox is only for DVD.

[Blight]

Originally Posted by Sunspark

You could try MPC-BE's decoder with EVR-CP to verify whether or not it works with the media you're working with and go from there. "Line 21 Decoder - enabled for Microsoft DTV-DVD Video Decoder and EVR-CP". Not sure if you also need to check on the line 21 checkbox in the DVD settings (present in both HC and BE) for streams, or if the checkbox is only for DVD.

Nev wrote earlier that he's translating the line 21 data to another format, that's why I'm unable to get it to work, it's incompatible with Microsoft's line 21 decoder.

I tried to see if MPC-BE works any better, it doesn't detect the closed captions at all.

For reference, I'm not playing a DVD, this is a live stream.

[nevcairiel]

The data is not being translated, its exposed as-is from the video bitstream if present (typically from SEI NALs). Basically the data FFmpeg exposes as AV_FRAME_DATA_A53_CC (eg. "ATSC A53 Part 4 Closed Captions.", also known as CTA-708 (formerly EIA-708 and CEA-708))
The data format consists of a number of cc_data_pkt (definition of which can be seen in the CTA-708 specification), the number can be obtained from buffer size / 3 (as each cc_data_pkt is 3 bytes, one control byte and two CC data bytes).

I have no idea if any existing filter exists that can handle it - make your own if needed. I know for a fact that the LAV data is being used for subtitles successfully with custom filters.
Microsoft abandoned DirectShow a long time ago. The Microsoft provided filters are stuck in a state from 15 years ago or so.

This format is the digital successor to Line21 data, which is also mandatory in US broadcasts, so should always be available.

[Blight]

Originally Posted by nevcairiel

The data is not being translated, its exposed as-is from the video bitstream if present (typically from SEI NALs). Basically the data FFmpeg exposes as AV_FRAME_DATA_A53_CC (eg. "ATSC A53 Part 4 Closed Captions.", also known as CTA-708 (formerly EIA-708 and CEA-708))
The data format consists of a number of cc_data_pkt (definition of which can be seen in the CTA-708 specification), the number can be obtained from buffer size / 3 (as each cc_data_pkt is 3 bytes, one control byte and two CC data bytes).

I have no idea if any existing filter exists that can handle it - make your own if needed. I know for a fact that the LAV data is being used for subtitles successfully with custom filters.
Microsoft abandoned DirectShow a long time ago. The Microsoft provided filters are stuck in a state from 15 years ago or so.

This format is the digital successor to Line21 data, which is also mandatory in US broadcasts, so should always be available.

Thank you for the detailed information,

Unfortunately, my expertise lies in user interfaces and less so in filter development, which is why I hoped for something off the shelf I could integrate rather than telling people to switch to the libVLC engine.

Would it be possible to translate this format to a subtitle format on the output pin?