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.