FFmpeg/Mplayer supports E-AC-3 format now...

[jruggle]

How big do these samples need to be? Is it ok if the last frame is damaged because of the way the samples are cut?
They don't have to be big, and they can be cut arbitrarily. They just need to be big enough for me to have something to listen to in order to compare output. Many of the samples I have are only a minute or two long.

[Snowknight26]

10MB for 1536kbps and 5MB for 768kbps enough? Should be able to get about 20 samples up if that works.

[jruggle]

10MB for 1536kbps and 5MB for 768kbps enough? Should be able to get about 20 samples up if that works.

That's more than adequate. I need samples from as many different souces as I can get. Anything new is good to have just in case it does something unexpected.

Thanks!

[Snowknight26]

http://www.stfcc.org/misc/eac3samples

Total number of samples is 79 (if you see less then I'm still uploading them). All of them but 1 are from my HD DVDs; 1 of them is from my Transformers Blu-ray but I can't remember which.

[jruggle]

http://www.stfcc.org/misc/eac3samples

Total number of samples is 79 (if you see less then I'm still uploading them). All of them but 1 are from my HD DVDs; 1 of them is from my Transformers Blu-ray but I can't remember which.
Wonderful! thank you. :)

[Snowknight26]

I'll make a zip file once they're all up so you don't have to download them individually.

[Mercury_22]

Hi everyone.

Even though the E-AC-3 decoder is in FFmpeg SVN now, I'm continuing to work on it in SoC SVN. I was very fortunate to be sent a sample which uses Spectral Extension, so I have now implemented support for it in the decoder. The code will be added to FFmpeg SVN soon.

On that note, I'm still looking for E-AC-3 samples. The more I get, the better. If it fails or gives warnings with the decoder, I really really want it! The major hurdle in implementing the full spec is availability of samples which use the enhanced features. So far, the most promising samples seem to be low-bitrate.

Edit: I'm pretty sure 2 of the really good samples I have are from Warner Home Video HD DVD's. So if anyone has any of those besides Casablanca and Rio Bravo, it would be good to get E-AC-3 samples from some others.

More samples in FFDShow's thread http://forum.doom9.org/showthread.php?p=1181004#post1181004
And maybe you can help ffdshow's developers to separate AC3 from E-AC3 (if it's possible) so we can use separate filters for AC3 and E-AC3 because when using libav for AC3 it fails to decode after a few seconds :helpful::thanks:

[jruggle]

And maybe you can help ffdshow's developers to separate AC3 from E-AC3 (if it's possible) so we can use separate filters for AC3 and E-AC3 because when using libav for AC3 it fails to decode after a few seconds :helpful::thanks:
In FFmpeg, libavformat separates E-AC3 from AC3. I understand that ffdshow uses libavcodec for the decoding, but does it have a libavformat "splitter" for demuxing? If not, they can look at the code in libavformat/raw.c and libavcodec/ac3_parser.c to see how it's done.

[Mercury_22]

In FFmpeg, libavformat separates E-AC3 from AC3. I understand that ffdshow uses libavcodec for the decoding, but does it have a libavformat "splitter" for demuxing? If not, they can look at the code in libavformat/raw.c and libavcodec/ac3_parser.c to see how it's done.

Thanks :thanks:

[Inventive Software]

I have been loosely looking at implementing libavformat as a separate splitter filter to complement ffdshow, but I'm nowhere near starting this thing, as it's difficult to implement correctly.

[pcordes]

Thread necro alert! But it's on topic. I made a patch to add support for the drc_scale option in mplayer.

I use mplayer, built from the SVN source (on Ubuntu GNU/Linux). Great to see that E-AC-3 support finally made its way into the libavcodec SVN repo that mplayer's SVN includes. And I see your drc_scale patch got in, Justin, but unfortunately mplayer doesn't seem to have any way to set drc_scale.

Get a temporary patch here (http://forum.doom9.org/attachment.php?attachmentid=7899&stc=1&d=1198108057). This is for soc/eac3 SVN-r1607.

Then you can set the libavcodec or ffmpeg option, drc_scale, to 0.0 to disable DRC.

Is dialog normalization a separate thing, and is there any code I'd need to change to disable it? i.e. is

eac3dec.c:246 skip_bits(gbc, 5); // skip dialog normalization

actually skipping it, or just because that function isn't interested in that part of the frame.

It's pretty freaky that DRC is the default behaviour, for mplayer's liba52 as well. My s/pdif-input speakers (logitech Z-5500) don't default to "night mode" for AC-3, you have to turn that on in a menu.

I'll just change the default for drc_scale in my local SVN checkout (nice speakers in a quiet room). I wish mplayer/ffmpeg used git; it's much easier to keep local patches around across upstream updates with git; you can commit them to your own repo, and git has nicer conflict-resolution than just having to resolve conflicts per-file when svn tells you to in the middle of the svn update.


What do other people do? Use eac3to to strip the drc/dialognorm info when remuxing?


I tried to find where in mplayer I could add support for setting drc_scale in avctx, but -lavdopts is only used by libmpcodecs/vd_ffmpeg.c, which is for ffmpeg video decoders, not audio. I don't know mplayer's code paths, but I think each codec gets its own avctx, so setting drc_scale in the video context would have no effect on the eac3 code. All that's needed is support for parsing drc_scale=xx in whatever calls the .init function for ffmpeg audio codecs, but probably the right thing to do is pull the lavdopts parsing code out of vd_ffmpeg.c, so audio and video contexts can use it.

I got stuck trying to find where the .init functions are called from (in mplayer). libavcodec/ac3dec.c defines the AVCodec eac3_decoder struct, but I don't see any other references to that symbol! Is there some preprocessor magic that's hiding the other usage in a table of codecs or something? Oh, I think I found it, in allcodecs.c. grep eac3_decoder didn't find it because of the preprocessor magic.

Ok, and that leads back to ad_ffmpeg.c. Duh, should have guessed that such a file existed after seeing vd_ffmpeg.c for video. Ok, wow that's easy to add a config option. patch attached: drc_scale.c. made against mplayer SVN r29972. Obviously this isn't the standard channel for submitting patches to mplayer. I submitted it to mplayer's bugzilla (http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1607), too. Obviously it's a bit of an ugly hack, and splitting const m_option_t lavc_decode_opts_conf[] and the static variable it points to out into a file by itself would be the way to go. Maybe lavdopts.c/.h.


I also made a patch to libavcodec to log when it activates eac3 support, since I wanted to know that it wasn't just taking the AC-3 core of an E-AC-3 stream (if they even have that.) ac3-log-eac3-mode.txt does that, and changes the libavcodec default value for drc_scale to 0.

Share and enjoy.

[tebasuna51]

I made a patch to add support for the drc_scale option in mplayer.

Good luck!

[jruggle]

Is dialog normalization a separate thing, and is there any code I'd need to change to disable it? i.e. is

eac3dec.c:246 skip_bits(gbc, 5); // skip dialog normalization

actually skipping it, or just because that function isn't interested in that part of the frame.

The decoder skips it currently. One option we're considering is providing a way to export the value to the user, but the dialogue normalization gain is not and will not be applied within the decoder.

It's pretty freaky that DRC is the default behaviour, for mplayer's liba52 as well. My s/pdif-input speakers (logitech Z-5500) don't default to "night mode" for AC-3, you have to turn that on in a menu.

I'll just change the default for drc_scale in my local SVN checkout (nice speakers in a quiet room).

There might be something in the spec about the default behavior. I'll check when I get home from work. If not, I can probably get the default changed to zero in libavcodec.

I wish mplayer/ffmpeg used git; it's much easier to keep local patches around across upstream updates with git; you can commit them to your own repo, and git has nicer conflict-resolution than just having to resolve conflicts per-file when svn tells you to in the middle of the svn update.

FFmpeg does at least have a git mirror at git.ffmpeg.org that tracks the svn repo. I essentially do all my FFmpeg development in my local git repo. I just use svn when I need to commit something.

What do other people do? Use eac3to to strip the drc/dialognorm info when remuxing?
For simple remuxing (vs. decode/encode), FFmpeg does not remove drc/dialnorm. Although someone could implement a bitstream filter to do that if they wanted to.

[jruggle]

There might be something in the spec about the default behavior. I'll check when I get home from work. If not, I can probably get the default changed to zero in libavcodec.

Indeed, the spec does say that applying drc should be default behavior. From the AC-3 spec (A/52B 7.1.1.1):
Broadcasters must be confident that the compression characteristic that they introduce into AC-3 will, by default, be heard by the listeners. Therefore, the AC-3 decoder shall, by default, implement the compression characteristic indicated by the dynrng values in the data stream.

[madshi]

Indeed, the spec does say that applying drc should be default behavior. From the AC-3 spec (A/52B 7.1.1.1)
AFAIK DRC is mandatory if there's no option to enable/disable it. But AFAIK as long as the user can turn in on/off, Dolby allows the default to be turned off, at least in the latest version of their license policy. I know that Dolby even considered (based on user requests) to allow Dialnorm to be turned off in the receiver. Older versions of their license didn't allow that. Not sure if they do allow it now or not.

But even if Dolby does state that DRC should always be enabled by default, I'd still say that this is a funny decision on their part and should not really be considered part of the spec. We don't have to follow their recommendations to the letter, if there are bad things in it, do we? E.g. if the Dolby spec stated that the decoder should always convert true 5.1 decodings to 2.0 Dolby ProLogic by default, would you follow that advice, too, just because the spec says that?