LAV Filters - DirectShow Media Splitter and Decoders

[VipZ]

That version doesn't help either, the build I did 2 days ago also had this issue. I don't recall which revision it was, but it was maybe d1a6c61.

I am not sure how to roll back changes to compile an older build in git, if you could give me a tip of this, I can do some testing to try find which one broke the sync.

This issue isn't to all DTS in MKV though it seems to be somewhat to this file only and maybe others, though 0.25 worked perfectly for this file. Decoded DTS doesn't have the sync issue with this file either.

I mostly found bitstreaming to have better sync than decoding, especially so for the build 2 days ago.

[nevcairiel]

I have no issues whatsoever, so i claim your file is broken.
With the latest version, and the A/V sync thing enabled, it'll always match against the timestamps of the incoming data, and make sure it fits.

Edit: Try with this older version; http://files.1f0.de/lavf/LAVFilters-...2-g9f7db6b.zip

[VipZ]

Nope, that is also out of sync

[nevcairiel]

You're out of luck then, get rid of the broken file.
Or give me a sample to reproduce the problem.

I could revert some of those changes, and when bitstreaming, just trust whatever timestamps the source gives me (like 0.25 did), so if they are messed up, its clearly the files fault.
Except, the audio jitter is horrible then, and the graph of EVR-CP looks like crap because the audio timings jitter so much, so its clearly not good.

However, with A/V sync thing enabled, i really do not see how there could be sync issues, ever. It'll compare all timings to the input time of the data, and if there is a too bad drift, it'll adjust to that. Its just impossible that my calculated timings cause a 2-3 second desync. Its just not possible.
It uses the same timing the decoding would use, it reads the data, and figures out how long it would be - and then increments the clock by that. Thats a perfect match to the source timings, minus the jitter of DTS in MKV, of course.

[noee]

Originally Posted by VipZ

I am not sure how to roll back changes to compile an older build in git, if you could give me a tip of this, I can do some testing to try find which one broke the sync.

fyi, you can go to the github for LAVFsplitter, choose "History" link on the right, just above the file listing,then you can browse the commits and select a commit, then with the "Download" option you can extract that "branch" and build it.

[nevcairiel]

So i have a new theory, maybe its the ffmpeg parser that somehow causes something funny.

Please try this:
http://files.1f0.de/lavf/LAVAudio-0.25-15-g19442af.zip

This version already includes the ffmpeg parsers, but still the old timing logic.

[VipZ]

Originally Posted by noee

fyi, you can go to the github for LAVFsplitter, choose "History" link on the right, just above the file listing,then you can browse the commits and select a commit, then with the "Download" option you can extract that "branch" and build it.

Thanks

Originally Posted by nevcairiel

So i have a new theory, maybe its the ffmpeg parser that somehow causes something funny.

Please try this:
http://files.1f0.de/lavf/LAVAudio-0.25-15-g19442af.zip

This version already includes the ffmpeg parsers, but still the old timing logic.

Which build should I drop this AX in, or it doesn't matter?

[nevcairiel]

The latest one i posted earlier should work, maybe all other 0.25 builds too.

[VipZ]

Originally Posted by nevcairiel

The latest one i posted earlier should work, maybe all other 0.25 builds too.

Yep, LAVFilters-0.25-55-g31d0dd6 with the AX from LAVAudio-0.25-15-g19442af fixes the issue

[madshi]

Originally Posted by nevcairiel

Thats where that extra stream switching filter comes in, basically a multiplexer that takes all decoders, and forwards only the active one to the renderer.

Ah, I see, I missed that part, makes sense to me now.

Originally Posted by nevcairiel

But yeah, its not a viable solution, unless a player fully supports this mode.

If you support IAMStreamSelect in one of the filters involved shouldn't that make stream switching work with most players? Maybe you'll have to make LAV Splitter support IAMStreamSelect and then forward that to the switching filter, cause it might be possible that players expect IAMStreamSelect only from the splitter.

[nevcairiel]

Originally Posted by madshi

If you support IAMStreamSelect in one of the filters involved shouldn't that make stream switching work with most players? Maybe you'll have to make LAV Splitter support IAMStreamSelect and then forward that to the switching filter, cause it might be possible that players expect IAMStreamSelect only from the splitter.

That would be possible. Maybe i'll build such a multiplexer in due time. Of course it'll look a bit weird in the graph list, say you have 6 audio tracks, you suddenly have 6 decoders in there...

I'll draft up a full concept, and post it for commenting somewhere.

Originally Posted by VipZ

Yep, LAVFilters-0.25-55-g31d0dd6 with the AX from LAVAudio-0.25-15-g19442af fixes the issue

I properly fixed the issue now. Thanks for the sample.
The calculation for the DTS durations was off for that file, not sure why. But i changed it, and it should work better now.
I would've kinda hoped that my A/V sync code would've taken care of this, but the timings were drifting apart so fast, that it couldn't keep up.

http://files.1f0.de/lavf/LAVFilters-...6-g41ca5a7.zip

[VipZ]

Originally Posted by nevcairiel

I properly fixed the issue now. Thanks for the sample.
The calculation for the DTS durations was off for that file, not sure why. But i changed it, and it should work better now.
I would've kinda hoped that my A/V sync code would've taken care of this, but the timings were drifting apart so fast, that it couldn't keep up.

http://files.1f0.de/lavf/LAVFilters-...6-g41ca5a7.zip

No problem. Thanks, its working good now

[madshi]

Originally Posted by Mark_A_W

Is there any reason *not* to use LAV Audio for FLAC?

madFlac uses the official FLAC library / source code and has been working for years with perfect A/V sync, no stability problems and bit perfect output, with all kinds of channel configurations, bitdepths and samplerates. AFAIK, the LAV FLAC decoder uses a different code base (not the "official"/original one) and has not been extensively tested yet. Why would you even consider going away from a pretty much perfectly working decoder? I don't really understand that. There's nothing to gain, from what I can see. From my experience, everytime a different FLAC decoder was (accidently) activated on my PC, I ran into all kinds of playback problems. That also includes LAV Audio Decoder, although it was an older version, the problem might be fixed in the latest version.

[nevcairiel]

Yea, ffmpeg implemented their own FLAC decoder, and i'm not sure if its working perfectly.
There was a problem that caused sync issues in earlier LAV Audio versions, but that was fixed a long while ago, and everything is working good now. Since its a lossless codec, we could compare the PCM output, couldn't we?
Anyhow, i don't use FLAC that much, and i have other things to do.

[nevcairiel]

LAV Filters 0.26

General
- The VC2010 runtime is no longer required to be installed

LAV Splitter
- Further VC-1 in MKV improvements
- Added a separate "mpegvideo" (m2v files) option to the Format section
- Added a flag for secondary audio streams
- Changed the default DTS media type (better compatibility)

LAV Audio
- Added the ability to use the ArcSoft DTS decoder directly through LAV Audio
- Added an automatic algorithm to keep A/V sync stable
- Improved Bitstreaming with splitters other then LAV Splitter
- Improved timestamp generation when bitstreaming
- Fixed LPCM 24-bit Media Types

Download: Installer (both x86/x64) -- Zips: 32-bit & 64-bit

Using the ArcSoft DTS decoder
LAV Audio can now directly interface with the ArcSoft DTS decoder. You do no longer need any complicated setup or installation.
To use the ArcSoft decoder in LAV Audio, simply get the "dtsdecoderdll.dll" from your TMT3/5 Codecs directory, and put it in the same directory as LAV Audio.
Thats all you need to do, no configuration, no hacked checkactivate.dll, no extra filter to be used.

When playing a file, you can see if its being used on the "Status" page of the LAV Audio propertys sheet. "dca" is the ffmpeg based decoder, "dts" (and any variations of that) is the ArcSoft decoder.

This will allow you full decoding of DTS-HD MA and all other variations of DTS.

One thing, though.
Do NOT ask where to get the ArcSoft decoder. If you own TMT3 or TMT5, it will be in the TMT Codecs folder. If you do not own it, you should buy it. I respect their work, and so should you!

Bitstreaming Improvements
Bitstreaming should now work much better with other splitters. Note that there is still one limitation however, TrueHD only works properly if its actually flagged as TrueHD, and the interleaved AC3 was removed. Therefor, it will most likely not work with Haali and the MPC-HC/Gabest splitters.


As always, please report any regressions or still persistent bugs directly here, with all the relevant details, and if possible a sample file.

[SamuriHL]

Just an FYI...I tested last night's code with MC16 build 160090 and Star Trek 2009 off the disc. I have LAV Audio decoding everything to PCM. I'm using ReClock at the moment for exclusive mode (plan on playing with MC16's exclusive mode at some point, but, in testing I had sync issues). Star Trek was rock solid. That's a good thing as that's always been one of the "trouble" discs for TrueHD. I'm very pleased! Building 0.26 now and will test it out at some point. Thanks, Nev!!

[Gleb Egorych]

Originally Posted by nevcairiel

How about that avi crash?

This testing took a bit more time because the bug appeared pretty random. Seems it is fixed . Tested 0.25-53 and slightly 0.26.

I'll also watch if player hang bug is also fixed with those patches.

Thanks, nevcairiel!

[madshi]

Originally Posted by nevcairiel

Since its a lossless codec, we could compare the PCM output, couldn't we?

Yes, but you'd have to test all bitdepths, channel configurations and samplerates. Furthermore you'd have to test whether the decoder works with all containers (that support FLAC) and all splitters and produces perfect A/V sync with all splitters, including seeking etc. Then, there are also extra tricks to support non-standard channel configurations which I'd bet ffmpeg does not implement by itself. Finally, since ffmpeg is constantly being worked on, with FLAC only being one of the less important small parts of ffmpeg, there's always a chance that some future ffmpeg revision might accidently break something without being noticed. FATE tests don't cover everything.

[CruNcher]

Crazy we can do DTS-HD MA transcoding live now, i guess madshi helped you here with where to hook into thx

[nevcairiel]

Originally Posted by CruNcher

i guess madshi helped you here with where to hook into

Nope, thats all my doing. It actually wasn't that hard to figure out. Just some leg-work, testing and debugging to figure out the arguments.