LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

I also haven't seen those on a live BD, all secondary audio tracks i found are DTS Express.

[jakmal]

Originally Posted by nevcairiel

That looks like one of those rare DD+ on Blu-ray files. You wouldn't happen to have gotten that from the Dolby Demo Blu-ray?
Looks alot like a demo file, tbh.

I haven't actually seen a real BD with E-AC3. Like i said, E-AC3 on Blu-rays is special, and may or may not be supported when bitstreaming. I don't really plan to invest much time into this, as its a practically non-existent format.

Yes, it is from the BD demo disc.

The OTT services like Netflix and Vudu are using DD+ for their streams in some cases, so maybe it will start gaining traction for physical media ?

I thought you mentioned that one of the advantages of LAV Audio over ffdshow is the fact that LAV Audio actually bitstreams EAC3

Btw, IIRC, that demo file bitstreamed perfectly with 0.25 and started giving issues only in 0.26 .

[madshi]

I have seen quite a few Blu-Rays with E-AC3 PiP tracks. E.g. Transformers 1, IIRC.

[madshi]

Originally Posted by jakmal

Yes, it is from the BD demo disc.

I wish that stupid BD demo disc would never have seen the light of day. Do you really want nevcairiel to spend hours of his time supporting a format which has only ever been used on exactly 1 demo BD disc world wide? There's not a single movie studio which has *ever* used this format.

IMHO every user who posts a sample from that BD demo disc should be banned for a week. Just kidding, of course...

Originally Posted by jakmal

The OTT services like Netflix and Vudu are using DD+ for their streams in some cases

I doubt they're going to use the stupid Blu-Ray 7.1 E-AC3 logic, though. They're most probably using the HD DVD 5.1 + 7.1 E-AC3 logic which is supported by LAV Splitter / Audio Decoder just fine.

[CruNcher]

Ahh about the encoding issue the same happens @ fastforward in MPC-HC @ 2x i get only 30 fps max not 50 fps as you would expect from that 25fps .ts (Mainconcept Decoder) so something is locking cyberlink demuxer and lav splitter up to 30 fps seems to only happen with them.

[SamuriHL]

There is NO WAY that broadcasts and other streaming services are going to use BD's implementation. Seriously, I agree here....not useful to spend time on this. If anything, I'd prefer to see the effort spent on getting the Dolby decoder dll's from ArcSoft working if you're going to even bother.

[Andy o]

Is there even a 7.1 E-AC3 in existence using HD-DVD's method?

[SamuriHL]

Not that I've ever seen. And broadcasts are never going to use it, either. They'll stick to 5.1. At least for the forseeable future.

[jakmal]

Originally Posted by madshi

I wish that stupid BD demo disc would never have seen the light of day. Do you really want nevcairiel to spend hours of his time supporting a format which has only ever been used on exactly 1 demo BD disc world wide?

Originally Posted by SamuriHL

There is NO WAY that broadcasts and other streaming services are going to use BD's implementation. Seriously, I agree here....not useful to spend time on this. If anything, I'd prefer to see the effort spent on getting the Dolby decoder dll's from ArcSoft working if you're going to even bother.

Sorry guys Being a verification engineer IRL, I always try to find corner cases where the design doesn't work.. My main concern with respect to filing that issue was that it used to work previously..

[CruNcher]

No go it always locks to 30 fps no difference what you set, it seems like a hard coded parser force, it happens also with other decoder so it seems to be a lav splitter issue it's interesting that Cyberlinks Demuxer has the same problem, many others don't have this issue so it seems avoidable, it also makes fast forward 2x in MPC-HC impossible

[SamuriHL]

Originally Posted by jakmal

Sorry guys Being a verification engineer IRL, I always try to find corner cases where the design doesn't work.. My main concern with respect to filing that issue was that it used to work previously..

Understood, but, the real world issue is that Nev's time is limited and if he's screwing around with something that we'll never encounter outside of a demo disc, it takes away from real functionality that we can really use. So yes, it's a nice edge case and as a software engineer myself I appreciate those things, it's just not something that's worth giving time to. I'm sure Nev will feel the same way.

[whurlston]

Originally Posted by madshi

I've not seen 6.1 E-AC3. But 6.1 TrueHD should exist. You can create 6.1 WAV and FLAC files by decoding DTS with eac3to, of course.

If I remember correctly, the DVE HD DVD has 6.1 DD+ and TrueHD samples. I would need to find my copy though.

[Mark_A_W]

Originally Posted by nevcairiel

There is no code whatsoever that forces any decoder. Blame ZoomPlayer, its "smart play" is usually not so smart.

nevcairiel

Pankov has done some testing for me, and he figured out that ZP is using the Filter Profile for E-AC3 instead of the Filter Profile for FLAC (for FLAC audio). I had LAV Audio chosen in the E-AC3 Profile - which is why it appeared to be forced to me.

It sounds like a Zoom Player issue. But it only happens with the LAV Splitter - it's a bit murky.

Here's what Pankov said to me:

"I've just tried the file and I do think that there is something wrong in ZoomPlayer.
Even though the media subtype is one that's specified in the FLAC profile it insists on loading the filter configured in the E-AC3 profile (added in v8.00 RC2 on my request) which has a totally different media subtype ({AFBC2343-3DCB-4047-9655-E1E62A61B1C5}). If you press "I" while playing the file you'll see the Media Information window and there at the bottom ZP states that it's E-AC3 !?!?"


So either is a ZP issue, and I apologise, or something about LAV Splitter is sending the wrong media type to ZP or something like that...(I've also posted this in the testing section on the inmatrix forum).

Anyway I'm glad Pankov was able to duplicate my issue, therefore I'm not insane (well, maybe a little...)


Sorry to give you and madshi the run-around.

Mark

[nevcairiel]

Originally Posted by CruNcher

it also makes fast forward 2x in MPC-HC impossible

LAV Splitter does not support adjusting the playback rate. 1x, or get out!

Originally Posted by jakmal

My main concern with respect to filing that issue was that it used to work previously..

It most likely broke because i added the ffmpeg parsers to re-assemble frames, it may not know how to do that with the dependent E-AC3 substream. Otherwise there are no changes that would affect EAC3, it does not use the new timing logic.

Note that E-AC3 will not work with the MPC-HC splitter, as it claims that its AC-3.

I can run some quick tests on that.

[tetsuo55]

Originally Posted by SamuriHL

Understood, but, the real world issue is that Nev's time is limited and if he's screwing around with something that we'll never encounter outside of a demo disc, it takes away from real functionality that we can really use. So yes, it's a nice edge case and as a software engineer myself I appreciate those things, it's just not something that's worth giving time to. I'm sure Nev will feel the same way.

FYI this was exactly ATI's opinion when they decided not to support any streams beyond the strictest L4.1 specs for DXVA h264, look where that brought us.

Other than that, i agree.

[nevcairiel]

Except, there really are no Blu-rays with their main audio in E-AC3 - with the one exception of the Dolby Demo Blu-ray, where they had to show-off their features - and i don't think there are free tools available to create such streams, unlike H264, which has x264 with which you can encode to any level.

Its also not like this is a strict limitation in some hardware chip or something, if there ever surface those discs, for whatever reason, i can still try to fix it.

Originally Posted by tetsuo55

look where that brought us.

To NVIDIA.

[madshi]

Originally Posted by tetsuo55

FYI this was exactly ATI's opinion when they decided not to support any streams beyond the strictest L4.1 specs for DXVA h264, look where that brought us.

The difference is that high spec h264 files were already widely used when ATI made that decision. Furthermore using higher spec h264 encoding can actually be useful sometimes. Both facts don't apply to Blu-Ray style E-AC3 tracks. They're junk, not useful, have never been used in real life yet and most likely never will be.

[tetsuo55]

I think thats a good benchmark.

Give us a commercial or homebrew sample and work on it can be started.
Imho EAC3 is a bad idea anyway.

[nevcairiel]

EAC3 itself is fine, it basically just extends AC3 from 5.1 to 7.1 and allows higher bitrates, no magic involved. Its similar enough to AC3 for decoders to adapt quickly, better then inventing a new format. Its basically the Dolby variant to the DTS-ES extensions or certain DTS-HD HRA profiles.

What they did to Blu-ray style E-AC3 tracks is another matter. To keep the tracks backwards compatible to AC3 decoders, they invented this stupid way of only using this 4 channel E-AC3 to replace the AC3 side channels, and add back channels.

[pankov]

Originally Posted by Mark_A_W

nevcairiel

Pankov has done some testing for me, and he figured out that ZP is using the Filter Profile for E-AC3 instead of the Filter Profile for FLAC (for FLAC audio). I had LAV Audio chosen in the E-AC3 Profile - which is why it appeared to be forced to me.

It sounds like a Zoom Player issue. But it only happens with the LAV Splitter - it's a bit murky.

Here's what Pankov said to me:

"I've just tried the file and I do think that there is something wrong in ZoomPlayer.
Even though the media subtype is one that's specified in the FLAC profile it insists on loading the filter configured in the E-AC3 profile (added in v8.00 RC2 on my request) which has a totally different media subtype ({AFBC2343-3DCB-4047-9655-E1E62A61B1C5}). If you press "I" while playing the file you'll see the Media Information window and there at the bottom ZP states that it's E-AC3 !?!?"


So either is a ZP issue, and I apologise, or something about LAV Splitter is sending the wrong media type to ZP or something like that...(I've also posted this in the testing section on the inmatrix forum).

Anyway I'm glad Pankov was able to duplicate my issue, therefore I'm not insane (well, maybe a little...)


Sorry to give you and madshi the run-around.

Mark

Mark, Nev,
the problem turned out to be not in ZoomPlayer itself but in the E-AC3 profile that I've created and spread around.
I've used the incorrect media subtype (the one stated above) instead of the real MEDIASUBTYPE_DOLBY_DDPLUS.
After fixing it everything is working OK.

Nonetheless, it's strange why it happens only with LAV Splitter. At the Inmatrix forum Gleb Egorych noticed that LAV Splitter initially sends MEDIASUBTYPE_FFMPEG_AUDIO ({AFBC2343-3DCB-4047-9655-E1E62A61B1C5}) and then switches to the correct one. Is this intentional?
If there are other affected ZoomPlayer users here is the discussion and the correct E-AC3 profile
http://forum.inmatrix.com/index.php?showtopic=13088