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

[Jjeje007]

Hi,

Here is the updated patch which compil ok against the latest mplayer svn

http://www.db-instable.org/misc/eac3v4.patch

Jjeje007

[skygod]

Originally Posted by Jjeje007

Here is the updated patch which compil ok against the latest mplayer svn

http://www.db-instable.org/misc/eac3v4.patch

Jjeje007

Thanks a million Both patch apply and mplayer compile was clean. Quick 'n dirty 2channel downmix testing on "sample-matrix2.evo" worked.

[Jjeje007]

Hi,

Just to let we know, i removed all the hacks regarding channel mapping done by tebasuna51. It look like that the devs started to rearrange channel mapping output in mplayer (i just check the log quickly).

Any way, the others hacks :

- Dialog Normalization attenuation disabled
- Dynamic Range Compression disabled
- Frames with "transient pre-noise processing" accepted and no more error (remove the fprint )

Are always done

Jjeje007

[jruggle]

Originally Posted by Jjeje007

Hi,
Any way, the others hacks :

- Dialog Normalization attenuation disabled
- Dynamic Range Compression disabled
- Frames with "transient pre-noise processing" accepted and no more error (remove the fprint )

Do you have any E-AC3 samples which use transient pre-noise processing? If so, could you send a small snippet to ftp://upload.mplayerhq.hu/MPlayer/incoming ? It would help in implementing the missing feature.

Thanks,
Justin

[madshi]

@Justin, is there a central place somewhere where we can always get the latest version of the E-AC3 decoder patches? That would be very helpful, as long as the decoder is not in the ffmpeg source tree yet. Thanks!

[tebasuna51]

Originally Posted by jruggle

Do you have any E-AC3 samples which use transient pre-noise processing? If so, could you send a small snippet to ftp://upload.mplayerhq.hu/MPlayer/incoming ? It would help in implementing the missing feature.

I use the sample-matrix2.evo from this Jjeje007 post

[jruggle]

Originally Posted by madshi

@Justin, is there a central place somewhere where we can always get the latest version of the E-AC3 decoder patches? That would be very helpful, as long as the decoder is not in the ffmpeg source tree yet. Thanks!

svn://svn.mplayerhq.hu/soc/eac3

I will routinely update it to current SVN until it is included in FFmpeg. Right now it's updated to work with FFmpeg-SVN r11200.

The checkout.sh script will always show what revision the patch should be applied against.

[madshi]

Originally Posted by jruggle

svn://svn.mplayerhq.hu/soc/eac3

I will routinely update it to current SVN until it is included in FFmpeg. Right now it's updated to work with FFmpeg-SVN r11200.

The checkout.sh script will always show what revision the patch should be applied against.

Great - thanks!

[baudi]

Could you implement a new functionality in ffmpeg_evo so that one can transform a DD+ or DTS-HD track inside an .EVO file applying PAL speedup (from 24fps to 25fps) over the target sound file on the fly?

Similar to eac3to.exe -speedup parameter.

Thanks.

[jruggle]

Originally Posted by Jjeje007

Any way, the others hacks :

- Dialog Normalization attenuation disabled
- Dynamic Range Compression disabled

I'm working on a fix for this for FFmpeg. Dynamic range compression will not be disabled because the specification requires that it not be ignored. But the user will be given the option to adjust how much to apply, from 0% to 100%.

As far as dialog normalization, it will not be applied in the decoder, but simply transmitted to the user level.

- Frames with "transient pre-noise processing" accepted and no more error (remove the fprint )

This one is now fixed in FFmpeg-SoC SVN.

Thanks,
Justin

[madshi]

Originally Posted by jruggle

Dynamic range compression will not be disabled because the specification requires that it not be ignored. But the user will be given the option to adjust how much to apply, from 0% to 100%.

How can my program (which uses avcodec.dll) switch DRC on/off? Is there an API/function for that?

Originally Posted by jruggle

As far as dialog normalization, it will not be applied in the decoder, but simply transmitted to the user level.

I've just checked the latest SVN of the E-AC3 decoder and the output level is too low compared to the reference decoder (Nero). Is this DRC? Can't really be dialnorm cause the track I was testing had dialnorm set to 0.

Thanks!

[jruggle]

Originally Posted by madshi

How can my program (which uses avcodec.dll) switch DRC on/off? Is there an API/function for that?

Not yet. Although I am FFmpeg AC3 maintainer, adding a parameter to the public API adds changes to files which I do not maintain. My patch is currently pending review. It will probably be something like AVCodecContext->drc_scale with values of 0.0 to 1.0 to apply a percentage of DRC during decoding.

I've just checked the latest SVN of the E-AC3 decoder and the output level is too low compared to the reference decoder (Nero). Is this DRC? Can't really be dialnorm cause the track I was testing had dialnorm set to 0.

It's probably the DRC. I hope it's the DRC. Are you referring to 5.1 decoding, stereo, or both?

[madshi]

Originally Posted by jruggle

Not yet. Although I am FFmpeg AC3 maintainer, adding a parameter to the public API adds changes to files which I do not maintain. My patch is currently pending review. It will probably be something like AVCodecContext->drc_scale with values of 0.0 to 1.0 to apply a percentage of DRC during decoding.

Don't know how long "pending review" takes. But if it takes a bit longer, wouldn't it make sense to disable DRC temporarily - as long as there's no way to disable it manually? At least for my purposes (eac3to = audio transcoding) DRC is really bad. For transcoding I need the audio to be totally unprocessed.

Originally Posted by jruggle

Not yet. Although I am FFmpeg AC3 maintainer, adding a parameter to the public API adds changes to files which I do not maintain. My patch is currently pending review. It will probably be something like AVCodecContext->drc_scale with values of 0.0 to 1.0 to apply a percentage of DRC during decoding.

It's probably the DRC. I hope it's the DRC. Are you referring to 5.1 decoding, stereo, or both?

5.1 decoding. Didn't check anything else yet. If you want I can send you a WAV comparison sample between ffmpeg and Nero.

[jruggle]

Originally Posted by madshi

Don't know how long "pending review" takes. But if it takes a bit longer, wouldn't it make sense to disable DRC temporarily - as long as there's no way to disable it manually? At least for my purposes (eac3to = audio transcoding) DRC is really bad. For transcoding I need the audio to be totally unprocessed.

It won't take long. and committing something temporarily is not an option. but I can throw together a quick patch that can be applied on top of the E-AC3 patch.

5.1 decoding. Didn't check anything else yet. If you want I can send you a WAV comparison sample between ffmpeg and Nero.

That would be helpful, yes.

[madshi]

Originally Posted by jruggle

It won't take long. and committing something temporarily is not an option. but I can throw together a quick patch that can be applied on top of the E-AC3 patch.

A quick patch would be welcome, but if your real DRC patch won't take long to be accepted then I could also wait. Thanks.

[jruggle]

Originally Posted by madshi

A quick patch would be welcome, but if your real DRC patch won't take long to be accepted then I could also wait. Thanks.

Get a temporary patch here. This is for soc/eac3 SVN-r1607.

svn co svn://svn.mplayerhq.hu/soc/eac3 -r 1607
cd eac3
./checkout.sh
cd ffmpeg
patch -p0 <ffmpeg_eac3_drc_scale.patch.txt
./configure --enable-gpl
make

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

[madshi]

Thanks much for the DRC patch!

-------

Is it intentional that when using ffmpeg SVN plus E-AC3 soc SVN the AC3 decoder stops working?

C:\msys\local\bin>ffmpeg -i channeltest.ac3 test.wav
FFmpeg version SVN-r11260, Copyright (c) 2000-2007 Fabrice Bellard, et al.
  configuration: --enable-shared --disable-static --enable-memalign-hack
  libavutil version: 49.6.0
  libavcodec version: 51.49.0
  libavformat version: 52.2.0
  built on Dec 18 2007 15:52:49, gcc: 4.2.1-sjlj (mingw32-2)
Input #0, ac3, from 'channeltest.ac3':
  Duration: 00:01:00.0, bitrate: 448 kb/s
    Stream #0.0: Audio: 0x0000, 48000 Hz, 5:1, 448 kb/s
Output #0, wav, to 'test.wav':
    Stream #0.0: Audio: pcm_s16le, 48000 Hz, 5:1, 4608 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Unsupported codec (id=86020) for input stream #0.0

Another question: Is there any chance to support the "USE_HIGHPRECISION" or "CONFIG_AUDIO_NONSHORT" flag to support 32bit output? The new TrueHD/MLP decoder does that and it works just fine. I know that ffmpeg officially doesn't support anything other than 16bit audio yet. But offering a special switch like the TrueHD decoder does shouldn't harm, right?

Ok, I know, I'm getting gready... Sorry about that. But I thought asking wouldn't harm. You can still simply say "no", of course!

[jruggle]

Originally Posted by madshi

Is it intentional that when using ffmpeg SVN plus E-AC3 soc SVN the AC3 decoder stops working?

It works fine for me. Did you use "configure --enable-gpl" ?

Another question: Is there any chance to support the "USE_HIGHPRECISION" or "CONFIG_AUDIO_NONSHORT" flag to support 32bit output? ... You can still simply say "no", of course!

No. FFmpeg doesn't support 32-bit because the API is currently setup for only 16-bit audio. The audio API will have to be changed to support other sample formats. This will happen eventually, just don't know when...

[madshi]

Originally Posted by jruggle

It works fine for me. Did you use "configure --enable-gpl" ?

Nope. Didn't know about that switch. Thank you...

Originally Posted by jruggle

No.

Originally Posted by jruggle

FFmpeg doesn't support 32-bit because the API is currently setup for only 16-bit audio. The audio API will have to be changed to support other sample formats. This will happen eventually, just don't know when...

I see. So the TrueHD decoder optionally outputting 32bit is probably an extremely ugly hack then? Works just fine for my needs, though... <shrug>

[jruggle]

Originally Posted by madshi

I see. So the TrueHD decoder optionally outputting 32bit is probably an extremely ugly hack then? Works just fine for my needs, though... <shrug>

It's a hack, but it's not extremely ugly...it just won't work within FFmpeg, only in libavcodec. The function for audio decoding is:
int avcodec_decode_audio2(AVCodecContext *avctx, int16_t *samples, int *frame_size_ptr, uint8_t *buf, int buf_size);

As you can see, the output samples are presumed to be an array of 16-bit signed integers. The MLP decoder just treats the output as a void * and then casts to either int16_t or int32_t depending on the source. This works just fine when using libavcodec alone because the user can look at AVCodecContext.sample_fmt to decide what to cast the array as.

But it's really supposed to be int16_t. And internally, FFmpeg assumes that is the case. The exception is an ugly hack within ffmpeg.c that allows for only raw pcm to be encoded using formats other than 16-bit.

The most likely fix to this will be to change the audio encoders and decoders to use an AVFrame instead of a sample array, which is how the video codecs work.

Anyway, that's probably more than you wanted to know...