LAV Filters - DirectShow Media Splitter and Decoders

[leeperry]

I support this just fine, the problem he has is with ffdshow profiles, which are only based on the initial connection, so he needs that to be correct.
ffdshow video can switch profiles on the fly, but ffdshow audio can't, it's picked once and for all at the DS graph initialization...I wish it could http://forum-images.hardware.fr/icones/ohwell.gif

PS: It seems to be due to HMS indeed, everything's recognized as it should using your splitter :)

PPS: You don't provide any option to change the "input buffer size" like in HMS? When seeking within a MKV on a DVD-R, it can be jerky...I can even completely lose the audio for a few secs.

Also, HMS has good error resilience when seeking in broken MKV's..does yours too?

Anyway, PotPlayer has a lot of options to have the audio/video bitrate/bitdepth/number of channels displayed on the skin...and very often all HMS had to tell PotP was "0", duh. Now I get my magic numbers each time, too cool :)

[nevcairiel]

Input Buffer doesn't really help that much when seeking on a slow medium. Once the seek request finishes, LAV Splitter will immediately start demuxing again, and run the demuxer constantly until the buffer is filled again (around 100 packets), while another thread starts dispatching those packets to the decoders while the demuxer is still powering through the file to fill the buffer. I don't see how any buffer changes can reduce that latency.

I'm always open to improving seeking, as its usually one of the things a splitter either shines at, or is total crap. LAV Splitter supports key-frame/index seeking as used by MPC-HC, which greatly improved seeking performance in MKV (and some other formats).
I've also got some feedback that seeking is really working well, at least with MKV. MPEG-TS seeking is always a bit weird, but it feels "ok" to me, at least on BluRay media, which is usually "good" MPEG-TS. DVB captures are most of the time just broken, because the capture apps have incomplete or broken muxing tools. :/

For the error resilience, thats all in the hands of ffmpeg. Feel free to throw some corrupted files at it, and see what happens.

[leeperry]

I'm always open to improving seeking, as its usually one of the things a splitter either shines at, or is total crap. LAV Splitter supports key-frame/index seeking as used by MPC-HC, which greatly improved seeking performance in MKV (and some other formats).
I've enabled keyframe seeking in PotPlayer, it works like a charm w/ HMS and the built-in MKV splitter. Very fast seeking, no hiccup and I never lose audio. Lemme know if there's any way I could provide you w/ logs or something? I've encountered the problem when reading MKV(h264+1.5mbit DTS) from DVD-R, and I was using CDBremse to slow down the 16X Liteon XJ-HD166S drive to 6X(it becomes hardly audible).

[nevcairiel]

I can burn some MKV to a DVD-R and test with that, i guess. AnyDVD offers a slow-down option, i'll run it on the slow & quiet preset, not sure what speed that is effectively.

I should also add some logging for users to see, right now all logging is only with a proper debugger *shrug*

[leeperry]

So as I said, PotPlayer has an option for keyframe seeking: http://thumbnails36.imagebam.com/12264/3e2573122636717.jpg (http://www.imagebam.com/image/3e2573122636717)

Seeking in MKV(h264+448kbit AC3) w/ this option checked, I've got the exact same problems as when seeking from a DVD-R...I lose the audio for a few secs after seeking, it also stutters and sometimes stalls for a second or two.

If I uncheck the option, I can easily get it to freeze PotPlayer completely. HMS works fine w/ both options, but seeking is slower if it's unchecked.


I run XPSP3, and here's my active filter list:
[Used Filter List]
(1) LAV Splitter
(2) CoreAVC Video Decoder (CUDA in use)
(3) ffdshow Video Decoder
(4) Madshi Video Renderer
(5) ffdshow Audio Decoder
(6) ReClock Audio Renderer

I'll be glad to run any debug version, and if you wanna try to recreate the problem, you can find PotPlayer here (http://www.dvbsupport.net/download/index.php?act=view&id=230)(I'd advise to use 7-Zip and only extract PotPlayerMini.exe & PotPlayer.dll...the rest is just bloat).

I mentioned error resilience because HMS copes a lot better w/ broken MKV's than the built-in PotPlayer/KMP MKV splitters...the latters usually freeze the player when encountering broken frames, OTOH HMS allows you to reseek easily.

[nevcairiel]

Seeking in MKV(h264+448kbit AC3) w/ this option checked, I've got the exact same problems as when seeking from a DVD-R...I lose the audio for a few secs after seeking, it also stutters and sometimes stalls for a second or two.

On a file from HDD, seeking in MPC-HC with Key-Frame seeking is always instant for me, without its not instant, but audio resumes right away, video is a bit jerky until the decoder gets the next keyframe .. but thats the same with any splitter i tried.
As i mentioned earlier, alot of people confirmed these findings with MPC-HC. Not sure if its really a player thing.

I'll test from a slow optical medium, and try that PotPlayer.

[madshi]

Just a thought: Any splitter can issue a seek command through the graph interface methods. Maybe it would be a nice trick for the splitter to "fine tune" any user seek request by issuing a correction seek command to the nearest video key frame? The net effect should be similar to seeking in MPC-HC with Key-Frame seeking enabled. However, it should work with any media player.

[nevcairiel]

I actually had something like that planned for the future, but as MPC-HC is my main target, i didn't give it any high priority.

[madshi]

Nice. :)

[nevcairiel]

In theory it shouldn't even be needed to issue another seek request. The IMediaSeeking::SetPosition call is not guaranteed to end up on that spot exactly, i could just change the target position before doing the actual seek, and the player would then receive the new current position either through the argument it put in (its a pointer for a reason), or by calling GetCurrentPosition afterwards.

I hope the filter graph is smart enough to fix the reference clock in this case. Something to test.

This of course depends on the player being developed sanely.

[madshi]

In theory it shouldn't even be needed to issue another seek request. The IMediaSeeking::SetPosition call is not guaranteed to end up on that spot exactly, i could just change the target position before doing the actual seek, and the player would then receive the new current position either through the argument it put in (its a pointer for a reason), or by calling GetCurrentPosition afterwards.
As far as I understand the MS documentation, your SetPositions implementation should only modify the position value if the "AM_SEEKING_ReturnTime" is set.

I hope the filter graph is smart enough to fix the reference clock in this case. Something to test.

This of course depends on the player being developed sanely.
What does the player have to do with it? The true playback position is maintained by the graph, not by the media player. The media player doesn't call SetPositions on your filter directly, instead it calls SetPositions on the graph's IMediaSeeking interface. The graph will then as a result loop through all filters in the graph and call their IMediaSeeking::SetPosition methods. Which means that it probably doesn't matter how the media player is written. You returning a different seek position in your SetPositions implementation will require the graph to accept the change - not the media player. So whether your idea will work should not depend on the media player, but on the OS.

FWIW, I rather doubt it will work, but it might be worth a try. If it does work, I would recommend to test it in all OSs, just to be safe... :p

[nevcairiel]

As far as I understand the MS documentation, your SetPositions implementation should only modify the position value if the "AM_SEEKING_ReturnTime" is set.


I understand AM_SEEKING_ReturnTime somewhat differently. To me it sounds like that when its set, the return value should always be converted to REFERENCE_TIME, no matter what the time format of the stream currently is.

In any case, dispatching a new seek request would work as well.

[madshi]

I understand AM_SEEKING_ReturnTime somewhat differently. To me it sounds like that when its set, the return value should always be converted to REFERENCE_TIME, no matter what the time format of the stream currently is.
Yes yes, that's correct. What I meant to say is that AM_SEEKING_ReturnTime is the only thing in the documentation that mentions modifying the position values. When AM_SEEKING_ReturnTime is not set, the doc does not mention that you could/should change the position values.

[nevcairiel]

You're right, its not really documented like that.
Oh well, i'll just do it with another seek request, just have to be careful to not create a loop there. :)

[pankov]

guys,
I might be guessing here but would this change from "precise seek" to "key frame seek" break the frame by frame stepping that ZoomPlayer and other players have?
Excuse my ignorance if this has nothing to do with your conversation.

[nevcairiel]

guys,
I might be guessing here but would this change from "precise seek" to "key frame seek" break the frame by frame stepping that ZoomPlayer and other players have?


Yes it would. But i wouldn't have it always on, but offer an option to enable/disable it.

[madshi]

Frame by frame *forward* stepping is realized in a different way, without seeking, I believe (at least in MPC-HC). To be honest, I'm not sure how stepping backwards is done, though.

[leeperry]

Well, to me the point of using your splitter is rather clear...here I get the AC3 bitrate right on the PotPlayer transport bar(as I've always dreamed about): http://thumbnails37.imagebam.com/12269/d06a41122686139.jpg (http://www.imagebam.com/image/d06a41122686139)

HMS simply says "0": http://thumbnails31.imagebam.com/12269/74d86c122686134.jpg (http://www.imagebam.com/image/74d86c122686134)

I've spoken to Haali about those problematic samples (http://forum.doom9.org/showpost.php?p=1482783&postcount=75), and his splitter simply repeats verbatim what's written in the MKV itself. If I demux/remux those 2 samples using mkvtoolnix 4.0, then they're both properly detected as 5.1 :confused:

These 2 samples were muxed by 2 different ppl using different versions of mkvmerge, so I dunno wth is going on(even MediaInfo sees them as stereo)....anyway, it's only a side effect of the fact that HMS simply repeats what's written in the container header, when OTOH your splitter actually checks for the bitrate/number of channels of the streams...which provides all the right infos about bitrate/number of channels to the DS graph filters. I would very much appreciate if you could bring the seeking operations(using PotPlayer) to the foolproof status of HMS. :thanks:

PS: HMS tells the bitrate of FLAC soundtracks(using madFlac), but your splitter simply says "0". I can make a sample.

PPS: humm yeah, I've seeked in a MKV(h264+20bit 7.1 FLAC, authored w/ mkvtoolnix 4.0) a few times, and then seeking didn't work anymore...no picture/no sound. PotPlayer hadn't locked up, though.

[nevcairiel]

Bitrate info is purely cosmetic and not really my main concern. Some ffmpeg codecs don't export bitrates, maybe flac is one of those. I can check if it somewhere stores the container supplied bitrate value, though.

[nevcairiel]

Okay, i tried alot of my files with PotPlayer (all from local HDD or my network storage), and seeking is as smooth as it is in MPC-HC, no issues whatsoever.
This was with ReClock, madVR, ffdshow audio and video. Switching to CoreAVC for decoding, its still fast, but takes maybe half a second after seek to produce an image - does not matter if i have ffdshow raw video processor in there, or not. I would guess flushing the hardware pipeline could possible be slightly slower.

Vanilla PotPlayer settings, except filter choices (decoders mostly set to system default instead of internal, renderers to reclock and madvr respectively)

I could not produce any freezes, or anything of that sort. Seeking was a pleasure as i know it from MPC-HC. I can try from an optical media on the weekend, but seeking in BluRays was working just fine the last times i tried.

[leeperry]

OK, thanks for testing on your end. Did you try on XPSP3?

I can easily get this sample to freeze PotPlayer completely(in D3D excusive mode), read from a fairly fast HDD: http://www.mediafire.com/?86bj8hpgilgy242

Filter list:
[Used Filter List]
(1) LAV Splitter (0.17)
(2) CoreAVC Video Decoder 2.0 (CUDA active, using the 257.21 drivers and latest DX9.0c update)
(3) ffdshow Video Decoder (ffdshow_rev3771_20110307_xhmikosr_icl12.exe)
(4) Madshi Video Renderer (0.43)
(5) ffdshow Audio Decoder
(6) ReClock Audio Renderer (1.8.7.3)

I've disabled all internal filters in PotPlayer, using the latest PotPlayer beta(from a few days ago), and my own TMT3 modded skin: http://www.mediafire.com/?w9owhawg7a7jyav

Sometimes I lose the audio for a few secs, sometimes it locks up for one second, sometimes it stutters, and finally sometimes it locks up PotPlayer completely(very easy to reproduce). HMS works like a charm, and I do have "move by keyframe" checked in PotP.

[nevcairiel]

I'm only testing on Win7, i don't feel like supporting a legacy version of the OS. :P .. not that i have any box thats still left on XP (and capable of running madVR). My Work laptop is XP, i can try running it there, but no madVR or ReClock there.

I'll test with that sample, see if its anything special.

I'll also add some more logging and make it log to a file, maybe for the next version, we'll see how my free time goes.

Edit:
Sample is just fine.

[leeperry]

Legacy? XPSP3 is still fully supported by m$, and all the stats in the world prove that there are still billions of ppl using XP...one random example: http://www.w3schools.com/browsers/browsers_os.asp
Windows XP is the most popular operating system

XP gets the job done. Ignoring XP users is pretty drastic...for what we know atm, the problem might come from something else too. HMS works wonderfully, never a single hiccup or lockup. I'm sorry to rub it in, and I realize that your product is not in competition w/ HMS.

[nevcairiel]

I don't care about statistics. I also don't care about anyones opinion, use whatever OS you want. I'll use the one i like.
I just don't have any real XP box to work on, and i do not have the time (nor motivation) to set one up, or run all tests on multiple systems. If it comes down to being a XP problem, well, bad to be a XP user, i guess. Its all open source though, so if any coder is using XP, or feels strongly about XP support, i welcome any contributions.

Personally, i doubt its a XP issue, or more people would've complained already.

Also, HMS is nearly as old as XP, of course it had alot more time to mature, and yet, its still full of bugs, and every version adds new ones.

[leeperry]

oh yah, the good ole' "patches are welcome" :D

I'll be on the lookout for any update then, :thanks:

[nevcairiel]

I just tried your starwars sample from above on my XP work Laptop, like mentioned without madVR or ReClock, EVR Custom and default DirectSound instead. Works like a charm. I cannot run more extensive tests, because, well, i should be working. :P

Did you try changing decoders, or renderers, to see if the problem persists?

In other news, i implemented automatic detection for VC-1 timestamp correction, so when the (new) configuration is set to "Auto" (default), it'll turn off the timestamp correction if the cyberlink decoder is detected.

Anyone using the ArcSoft decoder for VC-1? I remember people saying that they had the same timing issues that people reported for Cyberlink.
If so, please try http://files.1f0.de/lavf/LAVSplitter-0.17-vc1-test2.zip and see if its running smooth with the ArcSoft decoder.

[Mercury_22]

I've register ArcSoft video decoder (TMT3) and set it as preferred and on the top of MPC-HC's External Filters list but I can't connect to it using either LAVSplitter or MPC-HC's Splitter. What am I missing here ?

[nevcairiel]

Try adding this GUID as a new subtype to the arcsoft decoder in the external filter list "{D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53}". I'm not sure if it works like this, though. Sadly i forgot to add the ArcSoft Media Type to the splitter .. i'll do that when i get to my development system.

[leeperry]

I just tried your starwars sample from above on my XP work Laptop, like mentioned without madVR or ReClock, EVR Custom and default DirectSound instead. Works like a charm. [..]
Did you try changing decoders, or renderers, to see if the problem persists?
Just did yeah, using VMR9/DS/CoreAVC(CUDA disabled), I even disabled my Avisynth/winamp DSP plugins. Very often everything's frozen for a fews secs when I seek(even the mouse pointer)...and I also got it to lockup PotP completely.

I use an o/c Q9450 and it would appear that there's a thread deadlock or something...I dunno.

[Mercury_22]

Try adding this GUID as a new subtype to the arcsoft decoder in the external filter list "{D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53}". I'm not sure if it works like this, though. Sadly i forgot to add the ArcSoft Media Type to the splitter .. i'll do that when i get to my development system.

Not working :confused:

P.S. I have TMT 3.0.1.185

[nevcairiel]

Don't worry about it, i'll add the proper media type in the code and test when i have the time.

[nevcairiel]

Not working :confused:

P.S. I have TMT 3.0.1.185

If you care to use it, here is a guide how to get the codec working outside of TMT3

http://www.avsforum.com/avs-vb/showthread.php?p=19420488#post19420488

The next version will have proper VC-1 support in conjunction with both the Cyberlink and the ArcSoft decoders.

[Mercury_22]

If you care to use it, here is a guide how to get the codec working outside of TMT3

http://www.avsforum.com/avs-vb/showthread.php?p=19420488#post19420488

The next version will have proper VC-1 support in conjunction with both the Cyberlink and the ArcSoft decoders.

:thanks: Working now !

P.S. I knew about that guide but I thought that's just for the audio decoder
I'll compile the latest version of LAV later and do more tests

Edit: Compiled and did a few test and it's working great !
A small bug: it seems that the splitter can't identify the language in the PGS subs from m2ts stream it shows "S:stream#4" instead of "eng"
Also the word grey (for Auto) in the VC-1 tool-tip it's not quite accurate :) (it's more a blue)

[nevcairiel]

A small bug: it seems that the splitter can't identify the language in the PGS subs from m2ts stream it shows "S:stream#4" instead of "eng"

Thats most likely a BluRay, yes? BluRays don't have languages in their m2ts files, you need to parse the playlist for that. Thats my next big thing on the TODO.


Also the word grey (for Auto) in the VC-1 tool-tip it's not quite accurate :) (it's more a blue)

Yeah.. naming it any color is really not that great. How do you call the third state of a checkbox?

[fastplayer]

Yeah.. naming it any color is really not that great. How do you call the third state of a checkbox?
Try "Indeterminate".

[nevcairiel]

Would a user know what i mean with that? :P
I could just name it "Auto" and hope they figure it out. Its the default, too!

[fastplayer]

Would a user know what i mean with that? :P
I could just name it "Auto" and hope they figure it out. Its the default, too!
I think it's safe to assume that users who deal with VC-1 timestamp stuff, know about three-state checkboxes. :p

[Mercury_22]

1 Yes it's a Blu-ray
2 Try "Full" or "Square mark"
3 Now there is an audio delay / out of sync when opening an mkv file but NOT from the beginning and using Arcsoft video decoder! When using MPC-HC's internal splitter or using other video decoder with LAVSplitter or using other container (e,g, m2ts) ther is no more audio delay / out of sync ! The audio delay / out of sync disappear after a small seek

[nevcairiel]

LAV DirectShow Filters 0.18
LAV Splitter
- Improved compatibility when decoding VC-1 with the ArcSoft and Cyberlink Decoders
- Increased the splitters merit
- Fixed an issue that caused the splitter to deadlock when changing streams with madVR

LAV Audio Decoder
- Fixed a bug that caused sample durations to be calculated wrong, causing playback glitches

Download: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.18.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.18-x64.zip)

Thanks to the guys over at the MediaPortal forum for testing and confirming that the fix for the Cyberlink and ArcSoft decoders works.

If no more bugs come up that i have to fix urgently, i'll be working on BluRay support next, so stay tuned.

[SamuriHL]

Excellent progress! Thanks for your hard work!!

[nevcairiel]

3 Now there is an audio delay / out of sync when opening an mkv file but NOT from the beginning and using Arcsoft video decoder! When using MPC-HC's internal splitter or using other video decoder with LAVSplitter or using other container (e,g, m2ts) ther is no more audio delay / out of sync ! The audio delay / out of sync disappear after a small seek
Yeah it looks like the ArcSoft decoder is still not working perfectly with it.
But Cyberlink is perfect for me, and the decoder is basically "free", you can get it from the PDVD Trial version without any modifications, just register it and it works - and it does DXVA with interlaced material, which is the main reason people seem to be using it.

One thing i noticed, though. In Software decoding mode its perfect, in Hardware mode i still have to turn on "Enable Frame Time Correction" in MPC-HC, but when thats on, its just perfect.

[SamuriHL]

Yeah it looks like the ArcSoft decoder is still not working perfectly with it.
But Cyberlink is perfect for me, and the decoder is basically "free", you can get it from the PDVD Trial version without any modifications, just register it and it works - and it does DXVA with interlaced material, which is the main reason people seem to be using it.

Sorry, maybe I'm a little thick here...if I add the PDVD decoder to my external filters in MPC-HC, it will do DXVA? Hmm. That has some serious potential on my bedroom HTPC that doesn't have a lot of native power but has an nVidia 450 in it. I may have to check that out. Thanks!

[nevcairiel]

Yes, it does. The one from PDVD10 anyway, dunno about others. You have to enable DXVA in the decoders property page though!

[Mercury_22]

I'm using nero and it does DXVA with interlaced material too and also you just register it and nero (9)'s audio does dts-hd 7.1 and just needs registering But not with trial

[SamuriHL]

Yes, it does. The one from PDVD10 anyway, dunno about others. You have to enable DXVA in the decoders property page though!

When I tried that before the DXVA setting never "stuck". And never seemed to work. Guess I'll have to try it again.

[nevcairiel]

I just enabled DXVA for testing, and the setting seems to stick, and MPC-HC claims i'm using DXVA too.

[Sebastiii]

Thanks Nevcairiel :) will test new filter quickly.
Seb.

[SamuriHL]

I just enabled DXVA for testing, and the setting seems to stick, and MPC-HC claims i'm using DXVA too.

Alright, I'll test that again when I get a chance. I'd really like for that to work. The PDVD codecs are pretty decent quality so that'd be nice.

[robpdotcom]

To get DXVA in Cyberlink to stick, I have to do this:

Open MPC-HC > go to external filters and double-click Cyberlink Decoder > change decoding to DXVA. Then, without closing MPC-HC, drag a VC-1 encoded file into it.

You may also need to add GUID {31435657-0000-0010-8000-00AA00389B71} as a media subtype to MEDIATYPE_Video of CyberLink Video Decoder in MPC-HC's external filter page.

The bad thing about Cyberlink's decoder though: it doesn't seem to work well for VC-1 inside an mkv. For that, Arcsoft's decoder seems best when dealing with interlaced VC-1 (ironically, at least on my system, I get stuttering on progressive VC-1 inside mkv with Arcsoft :confused:).

[nevcairiel]

I have a VC-1 MKV of my Dark Knight BluRay that i created some time back for testing, and its working fine with Cyberlink. (of course thats progressive content)

The GUID thing shouldn't be needed with LAV Splitter.

With hardware decoding, i have to turn on MPC-HCs Frame Time Correction, though.