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

[madshi]

I've been working feverishly to get eac-3 decoding to work in windows
How about "eac3to source.eac3 dest.ac3 -libav"? It doesn't get much easier than that.

[Gannjunior]

exactly phhangover.

jruggle, tonight i will check my decoder version but i think i have used the last one.

ciao!

[sl1pkn07]

one noob question..

Which compiles before? ffmpeg, mplayer or is indifferent (I suppose that compiles the ffmpeg)

in case update ffmpeg... is needed recompile mplayer? or mplayer adds automatically changes on ffmpeg

sorry my bad english

greetings

[pbjr]

Hello, another noob here!

I can svn eac3 and compile ffmpeg no problem.

Whats the next step to get this version of ffmpeg with eac3 working with mplayer svn? Just copy the libav* directories over the ones that come with mplayer and compile? It looks like the svn ffmpeg is newer than the one that svn mplayer grabs.

How do I combine the two?

I'm grateful for anyones help. I've just blow 4 hours on trying to figure this out. Any chance of a new patch? :)

Thanks,
-PBjr.

[Blue_MiSfit]

How nice would it be to have eac3 decoding patched into ffdshow or AC3Filter :D

~MiSfit

[jruggle]

How nice would it be to have eac3 decoding patched into ffdshow or AC3Filter :D

That will probably be more likely once it is in the main FFmpeg branch, which is proving slower than expected. 7.1ch decoding is a bit difficult to fit into FFmpeg's current AC3 frame parsing framework. But it will happen eventually.

[zonyl]

I was able to assemble a working rev of ffmpeg for Kurtnoise's MLP patch and it compiled, however, I cannot get a clean rev of mplayer at the specified revision (external HEAD reference to libavcodec causes patch to fail).

Does someone have a tarball they can share of mplayer with MLP TrueHD support?

[Kurtnoise]

just wait...Here is an extract from the FFmpeg svn log:

rev 12896 - part 1 of EAC3 support - by Michael Niedermayer.
rev 12897 - Part 2 of EAC3 support, this is still disabled as it breaks regressions due to bugs elsewhere - by Michael Niedermayer.


concerning MLP, what is the problem exactly ?

[Taktaal]

Hello. I linked to this thread from a guide and people are complaining that there's no more Windows version to download. Did you remove that?

[Kurtnoise]

FFmpeg or mplayer ?

Most FFmpeg related stuff are included in the eac3to tool now. So...

About mplayer, yes I'm lazy to build every day/week a new build. Just hoping that all this stuff will be included soon in the svn tree...

[madshi]

That will probably be more likely once it is in the main FFmpeg branch, which is proving slower than expected. 7.1ch decoding is a bit difficult to fit into FFmpeg's current AC3 frame parsing framework. But it will happen eventually.
Hi Justin,

any news? :) Sorry, don't want to put any pressure on you. Just wondering...

Maybe it would make sense to skip 7.1 decoding for now and get 5.1 decoding into SVN first? I mean there's no real E-AC3 7.1 content available, anyway. All movies are only 5.1. The only 7.1 samples we have are from a Dolby demo disc... ;) And now with the death of HD DVD I don't think we'll see real 7.1 E-AC3 content anytime soon. It seems to me that Blu-Ray studios don't plan to ever make serious use of E-AC3. The consumers are crying too loud for lossless audio. So while 7.1 decoding would be nice to have, all we really need right now IMHO is 5.1 decoding...

[jruggle]

any news? :) Sorry, don't want to put any pressure on you. Just wondering...


Hi Madshi,

I've been somewhat busy with mentoring for this year's GSoC, among other things. Since it seems that Bartek has also moved on to working on his project for this summer, I'll go ahead and get back to finishing up E-AC3. Your suggestion makes sense. I'll get 5.1 into SVN first, then try to get those 7.1 samples working later.

[madshi]

Thank you for the heads up - and for your continued work on libav. It's much appreciated... :)

[ACrowley]

Is there any already Patched (EAC3, THD)mplayer Build ?

[jruggle]

I've been somewhat busy with mentoring for this year's GSoC, among other things. Since it seems that Bartek has also moved on to working on his project for this summer, I'll go ahead and get back to finishing up E-AC3. Your suggestion makes sense. I'll get 5.1 into SVN first, then try to get those 7.1 samples working later.
Update: The version in svn.mplayerhq.hu/soc/eac3 should be pretty close to the final version which will be in FFmpeg svn. I might find something during the merging process, and I will probably have to make some changes during the final devel review as well.

Hopefully this should all be within the next few days.

Since the last post, the only major thing I've added is error concealment. The goal was to prevent sync loss as much as possible with damaged streams. It's also updated to current FFmpeg svn (r13613).

[madshi]

Thanks... :)

[compunett]

thx justin, your work is much appreciated :)

Just for curiosity how is going to be the SoC 2008 :)

[jruggle]

thx justin, your work is much appreciated :)
thank you.
Just for curiosity how is going to be the SoC 2008 :)
Wondeful, I hope! You can see FFmpeg's projects at
http://code.google.com/soc/2008/ffmpeg/about.html
I am mentoring an MLP encoder and an ALAC encoder.

[compunett]

hehe nice then :)

I only knew about multimedia.cx wiki site. Btw isn't it difficult to mentor students around the world (for student or for you) ?

[jruggle]

...
Btw isn't it difficult to mentor students around the world (for student or for you) ?
There are some obstacles, but it's not too bad. One student is in Brazil, and therefore only 1 hour ahead of me. The other student is in India, so we have to adapt a bit.

Email is fine for reviewing patches. For more involved discussions, IRC works well. For communicating with the student in India, there is 9 hours between us, so I just have to stay up a little later, and he has to get up a little earlier.

[compunett]

OK then, don't forget to rest a bit :)

[compunett]

As you are all waiting, I followed the process this weekend, so far 2 third of the patches have been applied, some patches are still being reviewed, for Q&A, etc.

That's my 2 cent on the progress being made. Greats to all the commiters ;)

[Mercury_22]

Any progress ? :helpful:

[jruggle]

Any progress ? :helpful:
The final patches have been reviewed, so it is now only a matter of me finding the time to make the necessary changes. I'm hoping to do so before I go out-of-town next Tuesday.

[Mercury_22]

The final patches have been reviewed, so it is now only a matter of me finding the time to make the necessary changes. I'm hoping to do so before I go out-of-town next Tuesday.

Great news ! I can barely wait for this! :thanks:

[iamlindoro]

Well, I noticed that the MLP decoder has been merged into ffmpeg SVN, so that's good news. MLP now more or less works out of the box in mplayer and ffmpeg. Any news on E-AC3 being merged in the near future?

Also, it appears the demuxers for EVO and m2ts might need some work as one still needs to specify the audio codec and demuxer for these formats. Any move towards a solution to pick up the default audio track from the container, and use the correct demuxer and codec so I don't need to determine the individual command line for each HD rip?

Thanks so much for your hard work on this, Justin.

[jruggle]

Well, I noticed that the MLP decoder has been merged into ffmpeg SVN, so that's good news. MLP now more or less works out of the box in mplayer and ffmpeg. Any news on E-AC3 being merged in the near future?

Thanks so much for your hard work on this, Justin.
Getting the MLP decoder merged was all due to the hard work of Ramiro and of the original author Ian.

As for E-AC3, the last sticking point was the 6-pt IDCT used in E-AC3's Adaptive Hybrid Transform. The version in SoC SVN is a really slow brute-force approach. I finally got an optimized version of the function working a couple days ago, which is about 6x faster. Now I just have to submit a final set patches.

[compunett]

Great news

I was following the newsgroup on gmane, and commiters are really active in a lot of area, thx to them :)

[jruggle]

Update: I made quite a lot of commits today to update the SoC SVN repo. I'll be submitting another round of patches for review tomorrow.

[lnt4069]

Thanks Justin for all your work! This update has finally let me get sound working on my evo and m2ts files again in mplayer. I had it working with an earlier version of the SoC patch, but updating broke it and I was never able to get it working again, until now. Thanks again!

[Mercury_22]

Yes Thanks Justin ! :D :thanks:

So tomorrow's patches will be the last one , (for now) ?

[madshi]

Update: I made quite a lot of commits today to update the SoC SVN repo. I'll be submitting another round of patches for review tomorrow.
Sounds great!

The one thing I'm waiting for is the license change from GPL to LGPL. Is that still in the cards?

Thanks! :)

[jruggle]

So tomorrow's patches will be the last one , (for now) ?
I can only hope.

The one thing I'm waiting for is the license change from GPL to LGPL. Is that still in the cards?
That depends on the liba52 maintainer. He has expressed willingness in the past to allow relicensing of FFmpeg's AC-3 decoder as LGPL once E-AC-3 support is added. I will not ask him again until the code is in FFmpeg SVN.

[Mercury_22]

So, is it done ? :thanks:

[jruggle]

So, is it done ? :thanks:
it is now pending review. i still have not gotten a full review at this point, so it may take more work to get it committed. i'll post here when it is.

[Mercury_22]

it is now pending review. i still have not gotten a full review at this point, so it may take more work to get it committed. i'll post here when it is.

Ok ! :thanks: I can't wait :p :)

[madshi]

There's a lot happening right now at libavcodec. The E-AC3 decoder, an AAC decoder + encoder and an MLP encoder. All very exciting projects! :)

[jruggle]

FFmpeg now supports E-AC-3 decoding as of SVN revision 15103. :)

[Snowknight26]

24-bit?

[madshi]

FFmpeg now supports E-AC-3 decoding as of SVN revision 15103. :)
Congrats - well done! :)

Sorry for going on your nerves, but has the time come to ask about that other AC3 guy about LGPL now? :o

[Mercury_22]

FFmpeg now supports E-AC-3 decoding as of SVN revision 15103. :)

YES ! Thanks !
:thanks:

[liels]

FFmpeg now supports E-AC-3 decoding as of SVN revision 15103. :)

w00t!!! Thanks!!!

[Mercury_22]

@ Jruggle

Ok maybe this is too much BUT... :)

PLEASE CAN YOU HELP WITH IMPLEMENTATION OF FFmpeg's E-AC-3 IN FFDshow since nobody can / know and I have no idea how to... (http://forum.doom9.org/showthread.php?p=1177585#post1177585)? :helpful::stupid:

P.S. Because if the end user CAN'T BENEFIT from your work ..... :(

[madshi]

PLEASE CAN YOU HELP WITH IMPLEMENTATION OF FFmpeg's E-AC-3 IN FFDshow
Why are you shouting? That's not very polite...

As far as I can see ffdshow uses libav for many audio codecs (FLAC, WMA and Vorbis, just to name a few) - but for whatever strange reason not for AC3. The only thing they'd have to do is to add an option to use libav for AC3 decoding, too. Shouldn't be hard to do, and it should automatically make E-AC3 decoding work, too, with the latest libav SVN. But this is a request you should make in the ffdshow thread... ;)

[Inventive Software]

24 bit decoding AFAIK doesn't work properly in ffdshow, and more work in the underlying layer needs to be done.

[Mercury_22]

Why are you shouting? That's not very polite...

As far as I can see ffdshow uses libav for many audio codecs (FLAC, WMA and Vorbis, just to name a few) - but for whatever strange reason not for AC3. The only thing they'd have to do is to add an option to use libav for AC3 decoding, too. Shouldn't be hard to do, and it should automatically make E-AC3 decoding work, too, with the latest libav SVN. But this is a request you should make in the ffdshow thread... ;)

Sorry if it seems like I'm shouting ! :p But I've already made a "request in the ffdshow thread" (http://forum.doom9.org/showthread.php?p=1177551#post1177551) and they make it sound like a very hard thing to do So....! ? !:confused::helpful::thanks:

[jruggle]

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.

[nautilus7]

Nice to hear, but what exactly is Spectral Extension?

[jruggle]

Nice to hear, but what exactly is Spectral Extension?
It is a tool which an E-AC-3 encoder can use to only encode minimal information about upper bandwidth frequencies. Then the decoder basically copies the lower frequency data to the upper bandwidth area, and applies scaling and noise blending using that small amount of information provided in the bitstream.

[Snowknight26]

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.

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?

[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?