LAV Filters - DirectShow Media Splitter and Decoders

[Matching_Mole]

I'm trying your splitter and it is very good, thanks!

But I have the same issue which MPC internal one for VC-1 video in m2ts from my Blu-ray. If you use an external VC-1 decoder (so no the MPC internal one, because so no problem), the frame rate is badly jerky. Some renderer (EVR-CP, Madvr recently,...) use some "dirty" trick to find the correct original frame rate but not all (as EVR-Sync which is currently use). I try also your splitter with KMP and same issue, jerky frame rate again. I don't know if you already know this issue.

[nevcairiel]

What external decoder did you use?
I know it works fine with ffdshow, at least, but its pretty similar to the internal decoder.

The internal splitter can't even get it right with the internal decoder, so at least thats a improvement.

[hoborg]

@nevcairiel:

Hi.
You can close issue 5 (http://github.com/Nevcairiel/LAVFSplitter/issues/#issue/5), it was fixed already.
I updated my "tests" post (http://forum.doom9.org/showthread.php?p=1426670#post1426670) - this time i tested some *.MPG samples.

BTW, by some reason, there is no free m2ts splitter right now able to connect to "CyberLink Video Decoder (PDVD10)" to decode VC-1i using DXVA. By some reason MPC splitter fail to connect. Only working solution is to use Cyberlink CLDemuxer2 demultiplexet for m2ts files, but then there is no support for subtitles and no way to switch between multiple audio streams.
By other words - will be posiible to modify LAVF splitter to be usable with CyberLink Video Decoder (PDVD10) decoder for VC-1i DXVA playback?

[nevcairiel]

The cyberlink decoder might require a custom media type. I would have to get my hands on a copy of the splitter and decoder to see whats being send around there. I guess there are trials of PDVD10?

[hoborg]

The cyberlink decoder might require a custom media type. I would have to get my hands on a copy of the splitter and decoder to see whats being send around there. I guess there are trials of PDVD10?

I wil PM link to Cyberling demultiplexer and decoder.

[nevcairiel]

Oh also a VC-1i sample would be good, i don't think any of my blurays was actually interlaced.
BTW, i thought the gabest splitter would work, but maybe not with PDVD10 anymore.

[hoborg]

Oh also a VC-1i sample would be good, i don't think any of my blurays was actually interlaced.
BTW, i thought the gabest splitter would work, but maybe not with PDVD10 anymore.

Nope, gabest + PDVD10 doesnot work for VC-1i at all :/

I am just uploading m2ts VC-1i sample for you.

BTW, there is another problem with VC-1 files + FFDshow decoder - there is no way (at last i didnt found it) how to block FFDshow decoder to load for VC-1i and keep it for VC-1p - there is no "is/is not interlaced" condition in proflies :/

EDIT:
Here is VC-1i sample (http://hobring.ic.cz/samples/m2ts.vc-1i+dts.zip).

[Matching_Mole]

What external decoder did you use?
I know it works fine with ffdshow, at least, but its pretty similar to the internal decoder.

The internal splitter can't even get it right with the internal decoder, so at least thats a improvement.

Myself, I use Arcsoft one for interlaced file. I try also the microsoft decoder via FFdshow but I had also the issue so I don't understand why it's good for you. Which renderer are you using because the issue can be hide by the "Frame Time correction" option (in MPC-HC at least)?

For Cyberlink VC-1 and Arcsoft decoders, they are not directly usable in MPC, you need to use loaders.

[nevcairiel]

BTW, there is another problem with VC-1 files + FFDshow decoder - there is no way (at last i didnt found it) how to block FFDshow decoder to load for VC-1i and keep it for VC-1p - there is no "is/is not interlaced" condition in proflies :/

Yeah, i know. You would have to block ffdshow for all VC-1. Don't think there is a proper solution for this =/
Anyway, thanks for the sample, i'll check it out after work.

Myself, I use Arcsoft one for interlaced file. I try also the microsoft decoder via FFdshow but I had also the issue so I don't understand why it's good for you. Which renderer are you using because the issue can be hide by the "Frame Time correction" option (in MPC-HC at least)?

I was using EVR-CP, but i turned frame time correction off. I see the error with the internal splitter, but not with mine.
I'll double check again.

For Cyberlink VC-1 and Arcsoft decoders, they are not directly usable in MPC, you need to use loaders.
That might as well be another issue, and the decoder strictly limiting which splitter it connects to. In that case, i wouldn't be able to fix it, and you would have to rely on a loader.

[Matching_Mole]

I was using EVR-CP, but i turned frame time correction off. I see the error with the internal splitter, but not with mine.
I'll double check again.

I will check also from my side so. All my check are done with EVR-Sync renderer because it is the smoother on my installation.


That might as well be another issue, and the decoder strictly limiting which splitter it connects to. In that case, i wouldn't be able to fix it, and you would have to rely on a loader.

You're completely right, these decoders are "normally" not usable with other splitters than their ones and the goal of the loader is to "cheat" them. But currently it exists only loaders for MPC splitter and Haali Splitter and so maybe a specific loader should be developped / updated for LAVFSplitter but I don't know who can do this. These loaders are pretty old now :)

[Sebastiii]

Hi,

I would like to know if Mediaportal user have issue on the Splitter, we (Underground78 and me) try to find why it happen but it's a very weird bug.
On this splitter, the video doesn't start it's like the video was paused. If i hit pause/play the video start (somethimes MP freeze too).
It doesn't happen with other splitter even with XBMCSplitter.

I try on my side with no good result :(

Another thest that i i made , is to start video (bug -> we stay on the same screen -> go to graphstudio -> connect to remote graph and hit play from graphstudio -> the video start in MP).

Thanks,
Seb.

[Underground78]

Hello,

I managed to add hearing impaired DVB subtitles detection to LAVFSplitter.

The patch for ffmpeg can be found here : http://pastebin.ca/1924136 and the one for LAVFSplitter itself here : http://pastebin.ca/1924138.

I hope it will be useful ! :)

[nevcairiel]

Cool stuff, i'll look it over later!

[Underground78]

Cool stuff, i'll look it over later!

Great ! :)

What was the problem with teletext ? Was it detecting teletext subtitles against some others teletext streams or something more complicated ?

[nevcairiel]

Yeah, just the problem to detect which teletext streams are actually teletext and which are teletext subtitles.
Is there a DirectShow teletext decoder, anyway? I don't even know what mediatype to use for those.

Speaking of ffmpeg, i shall try to update my ffmpeg fork to trunk and cleanly apply all patches from XBMC and my own, right now i'm only using the XBMC version without history or a clean merge path. /me hides in shame

[Underground78]

Yeah, just the problem to detect which teletext streams are actually teletext and which are teletext subtitles.
Is there a DirectShow teletext decoder, anyway? I don't even know what mediatype to use for those.

I don't know but if it happens that such a decoder exists I think ffmpeg will need some patching. I now know how to detected the type of teletext streams but it seems ffmpeg is pretty bad at detecting the streams themselves ...

If someone need teletext subtitles and know how to decode them, I can have an look.

[nevcairiel]

I guess we'll just leave teletext missing for now, they are mighty ugly anyway :D

Although, in the samples i got from Ger, it seemed to detect the teletext streams. I had to block them to not show broken streams


On another note, from the lack of complaints i can deduce that the stuttering issue is indeed not back with 0.7?

[Underground78]

I guess we'll just leave teletext missing for now, they are mighty ugly anyway :D

Although, in the samples i got from Ger, it seemed to detect the teletext streams. I had to block them to not show broken streams

Well, in my samples I see two teletext streams in VLC (one is subtitles the other is other teletext) but ffprobe only detects one. I hexedited my sample file and it seems VLC is right, I see two teletext streams ...

[Keiyakusha]

is there support for linked mkv files?

[nevcairiel]

Well, in my samples I see two teletext streams in VLC (one is subtitles the other is other teletext) but ffprobe only detects one. I hexedited my sample file and it seems VLC is right, I see two teletext streams ...

Personally, i don't worry too much about MPEG-TS files with the current backend. VLC uses the mplayer demuxer (libmpdemux)? or something entirely different?

is there support for linked mkv files?

No, sorry. libavformat does not (yet) support these.
I would however appreciate a sample, or some info where to find one. =)

I might have some ideas for segment linking and ordered chapters for the future, its somewhat related to the plans for MPEG-TS, but it'll be quite a while.

[Underground78]

Personally, i don't worry too much about MPEG-TS files. VLC uses the mplayer demuxer (libmpdemux)? or something entirely different?

I would say entirely different, not sure how good is libmpdemux with MPEG-TS files but VLC is not so bad ...

[nevcairiel]

Well i did abstract the demuxing backend, so in theory one could use another demuxer, if its at all feasible.
libmpdemux would be a good candidate because there is a fork of it with full support for mkv segment linking and ordered chapters. Knowing how its TS compat is would be good. Only one way to find out. ;)

[Underground78]

Well i did abstract the demuxing backend, so in theory one could use another demuxer, if its at all feasible.
libmpdemux would be a good candidate because there is a fork of it with full support for mkv segment linking and ordered chapters. Knowing how its TS compat is would be good. Only one way to find out. ;)

I have just tested some of my TS samples with mplayer and it looks like it does fix some and broke others ... :rolleyes:

[nevcairiel]

VLCs own demuxers are directly VLC modules, so it would require quite some re-working to get them to integrate properly. Maybe it can be done. I need like 2 month of vacation from work to do all this stuff =P

As a bonus, i'm moving into a new place next week ;)

[Underground78]

VLCs own demuxers are directly VLC modules, so it would require quite some re-working to get them to integrate properly. Maybe it can be done. I need like 2 month of vacation from work to do all this stuff =P

As a bonus, i'm moving into a new place next week ;)

Do you think it would be easier to use libmpdemux or even VLC demuxers than fixing libavformat ?

[nevcairiel]

libmpdemux should not be too hard, it seems to have a proper API and all. I've been told the avformat framework is a bit too limited for stuff like segment linking/ordered chapters, thats why the previous patch was discarded and someone else did it with libmpdemux.

For MPEG-TS, i don't know. Using VLCs stuff would be quite alot more work. We can certainly try to fix the problems in the avformat mpegts demuxer (and try to get them upstream eventually), but debugging such media problems is always really tedious. For starters it would probably help alot to compile it with MSVC to get Just-in-Time debugging capabilities.
As far as my experience goes, the issues in the demuxers are usually not caused by perfect streams, rather by streams that somehow violate the specs, or use very exotic combinations of things.

Also, i'm currently not really knowledgeable about the mpegts bitstream format, i've successfully ignored it until now. A way too complicated format! =) Sadly the official specs, at least the up-to-date version that includes the bluray variants et al, are rather expensive.
I'm learning alot as i'm writing LAVFSplitter, though.

If anyone else wants to join in on fixing media compat problems in libavformat, you're always welcome, of course!

[Matching_Mole]

I will check also from my side so. All my check are done with EVR-Sync renderer because it is the smoother on my installation.

I made some test with a VC-1 video in m2ts container using one of the last version of MPC-HC. I used first the arcsoft decoder and the Evr custom renderer with the frame time correction disabled. The result was a jerky frame rate as you can see here:
http://img827.imageshack.us/img827/1296/screenmi.th.png (http://img827.imageshack.us/i/screenmi.png/)

I made again the test but using libavcodec the situation seems better as you said but as it is not multi-threaded and my test system old (Athlon 64 3000+) sometime the frame rate was not stable. I need to check on my PCHC to be sure that this is really due to my over-loaded core or not.

I don't understand why the frame rate is so jerky with the Arcsoft decoder because it works perfectly with H.264 codec. It's sad because this one is multi-threaded and accept interlaced stream.

[nevcairiel]

Its so jerky because VC-1 sucks. Somehow MS designed a "brilliant" format that doesn't have timestamps. The splitter trys to generate the timestamps, but its not working properly. So what i did was use the DTS timestamps (Decoding Time). While it seemed to work somewhat fine with ffmpeg based decoders, it produces problems with others. With the MS decoder, audio/video is out of sync. And with your decoder, its still jerky, apparently.

Hate VC-1. If someone knows how to reconstruct proper timestamps for the samples, please, do tell!

[Matching_Mole]

Ok I can understand better the issue so. Its seems that to solve this issue Halli splitter makes a kind of guessing and MPC-HC one lets the renderer makes the guessing if it has the functionality. Do you know if VLC team uses the same method than you?

Nevertheless, thank you very much for your answers and your splitter! I hope you will find a solution because it seems that to use Arcosft VC-1 decoder with your splitter, no loader is needed. So it will be a good solution to have a multi-threaded decoder which accept interlaced stream.

[nevcairiel]

Haali + loader works fine with the Arcsoft decoder?
I can hook up a debug filter to haali and see how his timestamps look, maybe that will tell me how to fix them, or something.
I always thought haali didnt do VC-1 in mpegts properly either.

[Matching_Mole]

I made quickly the test and you're right, Haali do not works correctly also for VC-1. Sorry for the bad info.

[naomatrix]

I don't understand why lavfsplitter shows FOURCC - "FMP4 ffmpeg decoder" in normal Avi files, when mediainfo shows FOURCC - "XVID". Because of this error ?? :confused: Potplayer can't connect the decoder XVID. DScaler Mpeg2 Video Decoder now connects to mpeg2 4:2:2 video, thanks. But is not connected decoder "WMVideo decoder DMO" for FOURCC - "WVC-1". It would be good to incorporate into splitter loader(tweak) for Cyberlink decoder in containers .mkv and .M2ts(.ts) with VC-1 video, is it possible also for Arсsoft Video decoder( tweak also exists).Here - http://depositfiles.com/ru/files/duzd3phid are all known to me tweakers for Cyberlink decoder.
In Haali is one option "Autoload VSFilter" - yes/no, is useful to work with subtitles in madvr.
Sorry for the many wishes, but I hope that the lavfsplitter will be the main splitter on my computer and I will not use Haali :).
Thanks

[nevcairiel]

I'll not add hacks like that, if you want to use decoders that strictly limit what they connect to, you need to use the seperate loaders, or use their demuxers as well.

[nevcairiel]

Debugging with CyberLink demuxer didn't shed any more light on the timestamp issue. It delivers completly screwed up data that their decoder probably fixes. meh.
At least you can watch VC-1i with the wmv9 option in ffdshow. I'll try to get this to work eventually with other decoders, but my time is going to be severly limited the next month.

0.7 seems stable enough to keep around for the time being, mostly while i move into the new apartment ;)

If there is any non-commercial demuxer that can demux VC-1 in TS without the jerky playback problem, please tell me about it, so i can compare its timestamp generation to mine, and maybe figure out the algorithm to fix it. The commercial demuxers usually only work with their own decoders, and that doesn't really help much.

PS:
The 25fps sample i got from hoborg does not seem to suffer from the problem at all. It appears only NTSC-timestamped samples suffer, possibly due to a accuracy problem with their wonky framerate of 24000/1001. Sadly i didn't bring a sample with me on the laptop and can't test it right now to compare values.

[Matching_Mole]

Its so jerky because VC-1 sucks. Somehow MS designed a "brilliant" format that doesn't have timestamps. The splitter trys to generate the timestamps, but its not working properly. So what i did was use the DTS timestamps (Decoding Time). While it seemed to work somewhat fine with ffmpeg based decoders, it produces problems with others. With the MS decoder, audio/video is out of sync. And with your decoder, its still jerky, apparently.

It's weird because this link seems to say that you have implemented the right method :
http://books.google.fr/books?id=MKhbLPHRb78C&pg=PA69&lpg=PA69&dq=vc1+PTS&source=bl&ots=hkUTqf4BLA&sig=Bs67nEZJrkPfxf_3RJIdQhk8UYs&hl=fr&ei=uL10TKTfF4qPswbBpfzlBQ&sa=X&oi=book_result&ct=result&resnum=5&ved=0CC4Q6AEwBDgK#v=onepage&q&f=false

But I don't have a great knowledge on his subject so may be I'm wrong.

Anyway, if I find something I will let you know. Thank you very much for your help!

[nevcairiel]

I cannot access that page, but yes, its what my research revealed as well. It works with ffdshow, so it cant be all wrong. I'll still try to fix it up with at least the MS decoder, no promises on the locked proprietary decoders.

[nevcairiel]

Well i figured out why its out of sync with the MS decoder. Turns out it doesn't respect timing flags like it should be doing, and just plays a frame once it receives it.
The file i was testing with had a few milliseconds of audio before the first video frame was sent. Not sure if thats common on media files or just a fluke with my sample. Anyway, due to that behaviour, it instantly started playing the movie, while ffdshow waits for the proper timing of the sample, and thus, with the DMO decoder, its out of sync.

What i can try to do is basically look for the first video sample in the stream, take its timing information, and drop all audio frames before this time. If it works properly, i don't know. But i'll test it.

[Matching_Mole]

For the link I have also sometime the same issue than you. but I reclick again on it and it works :)

This is coming from the book "The VC-1 and H.264 Video Compression Standards for Broadband Video" which seems interesting. If you can't access to it I can maybe provide to you the chapter information "VC-1 Encapsulation in MPEG-2 Systems".

[Virtual_ManPL]

https://forum.doom9.org/showthread.php?p=1427707#post1427707
Thanks for fast fixing bugs #1 & #2, and adding OGG splitter :)

But bug #3 still exist, can someone confirm it ?


Also I find that seeking seems broken, because it hangs whole player... or it's just me... ? :D

[Underground78]

Also I find that seeking seems broken, because it hangs whole player... or it's just me... ? :D

No it's not just you but for me it does not happen each time I seek, it seems to happen quite randomly.

[Ger]

I've been busy the last week, but I'm trying to get back to some testing now. Haven't signed up at github yet, but I'll try to get there eventually. For now I'm posting my findings regarding a couple of crash/freeze issues here.

I have been trying to figure out when this freeze-on-seek issue started, and I'm kind of relieved to see in the last two posts that I'm not the only one with the problem. I was starting to wonder if there was something unique about my system.

Anyway, my findings about freeze-on-seek:
- Present only in v0.6 and v0.7. v0.5 and earlier are not affected.
- Happens with all containers (I assume, since I know for sure it happens with avi, mkv, ts).
- Seems a bit random, but is certainly easy to reproduce on my system if you click on different places on the seek bar in quick succession. A normal avi/xvid is fine for testing this.
- Happens often enough that I can't really keep 0.6-0.7 registered for everyday use (the freezing becomes too annoying). I'm back to 0.5 for that reason.

So I'm pretty sure we can conclude that this is caused by one of the changes between 0.5 and 0.6 that affects all containers.



I've also been doing some more testing on my crash-on-seek issue:
- I'm now pretty sure it's not related to the freeze-on-seek described above, since this also happens with v0.5.
- I'm fairly sure now that this is a crash in libmpeg2 or at least ffdshow's version of libmpeg2 (libmpeg2_ff.dll). Crash dialogs seemingly randomly reports ntdll.dll or mpc-hc.exe as the problem module, but at least once it identified libmpeg2_ff.dll.
- I can't say for sure if the MPC-HC internal libmpeg2 based decoder is also affected (I suspect it's not since it tended to freeze rather than crash with limited testing), since the freeze prevents reliable testing in 0.6-0.7 and 0.5 only connects to ffdshow for MPEG2 and 0.4 and earlier have duration/seek problems.
- When I set ffdshow to use libavcodec for MPEG-2 I can seek freely in my Henry IV sample (http://forum.doom9.org/showthread.php?p=1426598#post1426598) with LAVFSplitter 0.5 with no issues at all. Setting it back to libmpeg2 and the crash-on-seek is back.
- AFAIK the ffdshow libmpeg2 crash only happens with LAVFSplitter. I haven't been able to reproduce it with Gabest/Haali splitters.

I have an MPEG2 channel/sample that the libavcodec implementation in ffdshow can't handle. Apparently works in ffplay but Haruhiko couldn't figure out how to fix it in ffdshow when I reported it way back, so I hope the crash-on-seek with ffdshow/libmpeg2 + LAVFSplitter can be fixed.

BTW, I use recent svn builds for both MPC-HC and ffdshow. Always 32-bit versions of all splitters/decoders/players on Win7 x64. EVR Sync. ATI 5770.

PS. Thanks Underground78 for the patches and of course to nev as always.

[nevcairiel]

I don't get the freeze on seek at all =(
Anyone that can reproduce it and is comfortable with Git and building lavfsplitter yourself want to bisect it? :D

[Underground78]

I don't get the freeze on seek at all =(
Anyone that can reproduce it and is comfortable with Git and building lavfsplitter yourself want to bisect it? :D

I could try.

[nevcairiel]

I ran into the error once when trying now, and saw a deadlock on the demuxer worker thread. It happend when too many flush events occur, or two threads try to flush at the same time. Anyhow, i applied a fix.

Since i can't really test it myself reliably, please test this version and see if its gone:
Download (http://files.1f0.de/lavf/LAVFSplitter-0.7-seeking-fix.zip)
(Its just the .ax, take the dlls from 0.7 - also only 32-bit)

[Underground78]

I ran into the error once when trying now, and saw a deadlock on the demuxer worker thread. It happend when too many flush events occur, or two threads try to flush at the same time. Anyhow, i applied a fix.

Since i can't really test it myself reliably, please test this version and see if its gone:
Download (http://files.1f0.de/lavf/LAVFSplitter-0.7-seeking-fix.zip)
(Its just the .ax, take the dlls from 0.7 - also only 32-bit)

Still crashing here. Can you update your repository so I can test the fixed version in the debugger ?

[nevcairiel]

Its crashing? No-one said anything about crashes. I was meaning to fix the freeze :P
Oh, on that note, i had some crashes when seeking wildly, but thats reclock. Disable it, and its fine. At least was for me. (Those crashes usually blame evr.dll)

[Underground78]

Its crashing? No-one said anything about crashes. I was meaning to fix the freeze :P

There was two issues when seeking, ramdom freezes and sometime crashes. In fact, it's still freezing here and I don't use Reclock.

[nevcairiel]

Yeah i didn't even try to fix, or even reproduce that yet...... :)
But as i understand, its only with libmpeg2 in ffdshow?

[Underground78]

Yeah i didn't even try to fix, or even reproduce that yet...... :)

Sorry, I edited ... In fact, freezes are not gone. I see you update your repository, I will try again with debugger.

[nevcairiel]

I updated the repository, if you can reproduce the freeze then look at the stack traces of the "CLAFVSplitter Demux" thread and the "Main Thread", and see which was the last piece of code running inside LAVFSplitter (don't care about what comes after it)

For me the main thread was sitting on CallWorker in SetPositions, and the demuxer was sitting on m_eEndFlush.Wait() in the ThreadProc. This shouldn't happen anymore, i hope.