LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Well, there isn't an actual problem right now to fix, its all theoretical at this point.
I'll probably create some broken ts file and see what happens. I'm also not sure how the timestamps of TrueHD in m2ts look, as the TS timebase of 1/90000 is still too coarse to perfectly timestamp audio of 0.833ms each sample. (still alot better then 1/1000 MKV timestamps)

Playback right now is fine, its just the handling of corrupted streams that needs some work - and if its just broken samples, i can detect those and re-sync against the container timestamps after such a decoding failure. Now if there is frames completely missing, thats another deal entirely.

There is another aspect to consider. Internally i buffer PCM samples until i reach a certain buffer length, because some post-processors are not particularly happy when they get samples of 0.8333ms each - so what i do is collect samples until i have at least 16ms (and in addition try to collect enough samples so the duration can be expressed as an integer), and during buffering my internal time tracking does not advance.

But like i said, playback right now is perfect, and just from my personal opinion: screw DVB recordings, TV is just crap anyway.

[Casshern]

If you basically throw the original time stamps away, I tend to agree with madshi. There needs to be a mechanism to ensure that audio and video stays in sync. Its a shame that in some cases the timestamps are unreliable. Its the same with video where everybody invents their own way of deriving the real frame rate from the stream. For audio this would mean averaging over a large enough amount of samples and occasional resyncing with video. One would hope this would increase error resilience.

Originally Posted by nevcairiel

20ms is not enough, especially when you're dealing with a stream from a MKV file, the timestamps are so coarse that they deviate quite alot - especially on TrueHD, which has a sample size of 0.83ms, i have seen deviations of 300ms, then a few samples later its -300ms, and it just swaps around like that all the time - 100% constant and predictable. At first i thought there would be a problem, but with the very constant pattern, i just attributed it to too coarse timestamping.

[madshi]

Originally Posted by nevcairiel

Well, there isn't an actual problem right now to fix, its all theoretical at this point.
I'll probably create some broken ts file and see what happens. I'm also not sure how the timestamps of TrueHD in m2ts look, as the TS timebase of 1/90000 is still too coarse to perfectly timestamp audio of 0.833ms each sample. (still alot better then 1/1000 MKV timestamps)

Playback right now is fine, its just the handling of corrupted streams that needs some work - and if its just broken samples, i can detect those and re-sync against the container timestamps after such a decoding failure. Now if there is frames completely missing, thats another deal entirely.

I don't think it's so theoretical. From my own broadcast recordings, about 1 out of 5 is in some way corrupted. Corruption can be just a couple of wrong bits, or larger blocks of random data. Depending on the type of corruption, anything can happen. E.g. when the AC3 decoder receives a frame to decode and the header signature isn't correct, the decoder (or parser) will likely skip the damaged data and simply wait for the next proper frame. The net effect is an audio gap. For video the probability of a missing frame is smaller cause the data/header ratio is different. Also, even if video and audio frames are both damaged, there's still a high chance that they will run out of sync because 1 video frame has a different runtime compared to 1 audio frame. Sure, if you resync after every problem, that might fix the majority of problems. But since the corruption is random, I would be afraid that in some cases you might not detect the corruption, but still there could be an audio gap/overlap.

For m2ts the Blu-Ray spec defines how big TrueHD data blocks should be, IIRC. I think the blocks are defined in such a way that they match the timestamps somehow, but I'm not 100% sure right now. Should be easy to double check. IMHO, the best solution would be for you to check how reliable TS/m2ts timestamps are. If they are as reliable as I think they are, the easiest and best solution would be to use the TS/m2ts timestamps as they are instead of using your own timestamps. Of course for MKV I would keep the current logic, but maybe add some kind of safety net.

Just my 2 cents, of course. Feel free to ignore...

[nevcairiel]

Only TS should suffer from this high corruption probability, right?
Even m2ts on Blu-rays should be mostly fine again, as i would hope they are muxed somewhat sanely, and all non-mpeg formats are typically written by "offline" muxers, and not dumping broadcasts onto disc.

I can of course detect if the source filter claims to have opened a .ts file, and if it did, sync against the source timestamps every time i deliver a PCM sample, or something to that effect.

Edit: A quick test with some m2ts look good, the timestamps appear to be perfect. But i do not have a TrueHD sample right now, only checked AC3 and DTS. More testing this afternoon or over the weekend. My sample collection on the work laptop is quite limited.

[madshi]

Yes, only TS should suffer from high corruption probability, I'd say. However, some of the freeware muxers allow converting TS files to m2ts, so a TS->m2ts file could be corrupted, too. Also, if the timestamps are perfect, there's little reason to not use them. So you could simply use the container timestamps for TS and m2ts, while using your own calculated timestamps for other containers. Alternatively you could also choose the timestamps based on the container + audio format. E.g. you could use the container timestamps only for TS + AC3/E-AC3/DTS/MP2, but not for TrueHD or DTS-HD. Broadcasts never use TrueHD or DTS-HD, so TrueHD and DTS-HD have a rather low probability of being damaged.

[ontherocks]

Is there a Readme or tutorial on this?

My goal is just bitstreaming no more no less.
So I installed just the Audio Decoder (install_audio.bat).
I went to MPC-HC View-->Options-->External Filters-->Add Filter and selected "LAV Audio Decoder". Then set it to "Prefer".



Then double clicked "LAV Audio Decoder" to bring up the options. Selected all bistreaming options.



Then deselected all the internal filters in MPC-HC.



Now if I play any DTS stream (DTS, DTS-HD) it bistreams fine to my Onkyo HT-R380.
But if I play any DD HD stream (DD-THD, DD+) it doesn't bitstream them. The receiver seems to go in a loop trying to find the input via HDMI.
The files I am trying to play are from http://www.demo-world.eu/trailers/hi...n-trailers.php

Am I missing something? Is there anything else I need to install/do?

[nevcairiel]

Are you using LAV Splitter as well, or another splitter, like Haali?

TrueHD bitstreaming currently only works reliably with LAV Splitter, especially out of mpeg-ts files (.ts, .m2ts)

I should probably write some more extensive guide or something. Anyone else want to do this maybe?

[sneaker_ger]

Originally Posted by madshi

Maybe you should treat MKV different to TS/m2ts? Because MKV is pretty much guaranteed to have no audio gaps/overlaps (unless the muxer totally crapped out)

There are lots of mkvs with gaps in audio. It can easily happen, for example on appending files.
I don't think just assuming that files don't have gaps is a good idea (just like assuming files run with a constant framerate).

[madshi]

Originally Posted by sneaker_ger

There are lots of mkvs with gaps in audio. It can easily happen, for example on appending files.

So some kind of audio/video sync safety net is necessary, it seems.

[nevcairiel]

IMHO, if some tool merges two mkv files, it should make sure the stream is continuous at the merge point.

Anyway.
I changed my timestamp difference detection to detect the actual jitter of the decoded audio, and so far results look pretty good, even on MKV. I'll run some extensive tests on all kinds of formats later, and post my findings, in case you're interested.

[Thunderbolt8]

Originally Posted by Portioli

it does something more than simple Decoding TrueHD (both .m2ts .mkv)

[PICS]

Im wondering, how can it says bit perfect output, while reclock is actually slowing down or speeding up in that moment you played those files? (its not set to speed: original & locked)

[sneaker_ger]

Originally Posted by nevcairiel

IMHO, if some tool merges two mkv files, it should make sure the stream is continuous at the merge point.

Although I agree that it may be desirable, e.g. mkvmerge can't do it (without destroying sync) and that's pretty much the mkv muxer.

[Jasch]

Hi i have a little Problem mit the MKV Splitter, it is reporting very often the wrong Framerate to my Player(DVBViewer).
Most of the Time it is reporting 23.97FPS ,but it should be 25FPS. If i use Reclock , in Reclock it is detected as 25, MPC Splitter is also working correct and is reporting 25.
The strange thing is, with some Files it is working some not.
Since i am using a little Plugin in DVBViewer wich is switching Refreshrate according to inputmaterial, this goes wrong.

If you need more things, sampels...please let me now.
(Sorry for my spelling)

[madshi]

Originally Posted by nevcairiel

I'll run some extensive tests on all kinds of formats later, and post my findings, in case you're interested.

Sure we are...

[ontherocks]

Originally Posted by nevcairiel

Are you using LAV Splitter as well, or another splitter, like Haali?

TrueHD bitstreaming currently only works reliably with LAV Splitter, especially out of mpeg-ts files (.ts, .m2ts)

I should probably write some more extensive guide or something. Anyone else want to do this maybe?

No, I don't have anything else on my computer. No other splitter, no other player (other than default WMP). Just MPC-HC and LAV Audio Decoder.
Do I need to install the splitter (install_splitter.bat) as well along with the decoder?
or
just the filter is enough ? But then I guess with just the splitter I won't get the options to bitstream.

If I am able to figure out how to go about it correctly I will write the guide myself.

[nevcairiel]

You'll need both.
Add LAV Splitter to the external list as well, and it should hopefully work.

In the future, LAV Audio should eventually also work with the default MPC-HC splitter, but then again, there is no really good reason to still use it anyway.

[madshi]

Originally Posted by nevcairiel

In the future, LAV Audio should eventually also work with the default MPC-HC splitter, but then again, there is no really good reason to still use it anyway.

There is one: There's a patch available for the MPC-HC splitter, enabling it to output 3D content. There's no such patch available for the LAV splitter yet. There are no 3D decoders and renderers available yet, but that can change quickly these days.

[nevcairiel]

Originally Posted by madshi

There is one: There's a patch available for the MPC-HC splitter, enabling it to output 3D content. There's no such patch available for the LAV splitter yet. There are no 3D decoders and renderers available yet, but that can change quickly these days.

If it does change, i'll look into it.

Do you know how thats used in a player anyway?
Does the player open a second instance of the splitter for the second stream on the Blu-ray?

Thats how i figured it would work, after reading the patch, but i never really investigated.

I also wonder how 3D in Matroska will work..

[ontherocks]

Originally Posted by nevcairiel

You'll need both.
Add LAV Splitter to the external list as well, and it should hopefully work.

In the future, LAV Audio should eventually also work with the default MPC-HC splitter, but then again, there is no really good reason to still use it anyway.

Ok. Now I can see the following in External Filters.
Should I Add both of them?

LAV Splitter
LAV Splitter Source

[nevcairiel]

Doesn't hurt to add both, but you'll most likely only need "LAV Splitter".