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

[Kurtnoise]

When I play an .EVO now, my receiver doesn't detect the Audio as a Dolby Digital stream (it detects PCM). And it doesn't seem like I have surround.

Is this normal?
Well, actually I don't know but are you sure that your receiver is able to detect E-AC3 streams ? (not only AC3)

Will the transcoding to, for example Dolby Digital 5.1, fix that?

And does the transcoding work in real-time?
You mean playing and transcoding as the same time ? I'm not sure but mplayer should be able to do that I think. But I might be wrong...

[Kurtnoise]

Quick question as this is my first time using mplayer on windows: I get alot of tearing in the video (though cpu usage seems ok @ ~40%), is there a more efficient -vo device that is not compiled in your binary?
Dunno...I don't have tearing myself with the samples that I tested. Maybe it's due to your processor (less powerfull than needed).


and btw, I don't have so much experience with the different video devices available for this player. So, I can't help too much here. Maybe somebody else...

[tebasuna51]

Channelmapping analysis:

1) The uncompressed output using:
ffmpeg -i input.evo -vn -acodec pcm_s16le -ac 6 -f wav out.wav
have a wrong channelmapping order (FL-FC-FR-BL-BR-LF)

2) The ac3 output with internal encoder using:
ffmpeg -i input.evo -vn -acodec ac3 -ab 448k -ac 6 -y oint.ac3
have a correct channel mapping. And using Aften with:
ffmpeg -i input.evo -vn -acodec pcm_s16le -ac 6 -f wav - | aften -b 448 -chmap 1 - oaf1.ac3
have also correct channelmapping.

3) The aac output with internal faac encoder:
ffmpeg -i input.evo -vn -acodec libfaac -ac 6 -ab 256k -y oint.aac
have a wrong channel mapping (FC-FL-FR-LF-BL-BR).
With a external encoder like enc_aacplus:
ffmpeg -i input.evo -vn -acodec pcm_s16le -ac 6 -f wav - | enc_aacPlus - oct.aac --cbr 256000
like expected the result is like uncompressed (FL-FC-FR-BL-BR-LF).
With NeroAacEnc don't work because know problem (http://forum.doom9.org/showthread.php?p=1028932#post1028932).

[Rockas]

@kurtnoise13
thank you... i finally managed to to download it :-)

I will start testing it for my next DAudioK release... thank you so much for your work... as far as I have seen, it looks (sounds) great.
I will feedback my results.

[KpeX]

when you configure mplayer for the compilation, don't forget to disable liba52...It's enable by default. Works okay here with liba52 enabled (linux x86). Thanks for putting the patch together.

[Kurtnoise]

@tebasuna : many thanks for your tests as usual...;) If you have some free time, you can play with the channels mapping switch (-af channels=x:y:a:a:b:b:c:c:d:d:e:e). I'll change them as soon as someone will have reported the correct one.

After reading the mailing list, this seems to be the correct order for E-AC3: -af channels=6:6:0:0:1:4:2:1:3:3:4:2:5:5

According to the documentation, we have :
0 = FL
1 = C
2 = RL
3 = Surround left
4 = Surround Right
5 = LFE

@KpeX: great that you're still around there...:) Haven't tested yet on my linux distro but on windows I need to disable it to be able to play those files. So,...

[tebasuna51]

If you have some free time, you can play with the channels mapping switch (-af channels=x:y:a:a:b:b:c:c:d:d:e:e). I'll change them as soon as someone will have reported the correct one.

Sorry, but mplayer don't work in my system and -af switch don't work with ffmpeg.

After reading the mailing list, this seems to be the correct order for E-AC3: -af channels=6:6:0:0:1:4:2:1:3:3:4:2:5:5

According to the documentation, we have :
0 = FL
1 = C
2 = FR
3 = Surround left
4 = Surround Right
5 = LFE


This order is the ac3 internal order, the standar uncompressed order is:
0 = FL
1 = FR
2 = C
3 = LFE
4 = Surround left
5 = Surround Right


-If the E-AC3 order is the same than AC3 the needed remap is:
-af channels=6:6:0:0:1:2:2:1:3:4:4:5:5:3

-If you need the mentioned remap:
-af channels=6:6:0:0:1:4:2:1:3:3:4:2:5:5
to obtain the AC3 order, implies the original order is:
0 = FL
1 = Surround Right
2 = C
3 = Surround left
4 = FR
5 = LFE

really strange, and to obtain the uncompresed order for WAV or external encoders we need:
-af channels=6:6:0:0:1:5:2:2:3:4:4:1:5:3

[Alosaur]

What would the remap be to convert the eac3 to wav for encoding to flac?

[tebasuna51]

What would the remap be to convert the eac3 to wav for encoding to flac?

Flac, like Aften, NeroAacEnc, Enc_AacPlus, ... need the standard wav order:
0 = FL
1 = FR
2 = C
3 = LFE
4 = Surround left
5 = Surround Right
and the actual output from ffmpeg is:
0 = FL
1 = C
2 = FR
3 = Surround left
4 = Surround Right
5 = LFE

If the parameter -af can be applied to ffmpeg:
-af channels=6:6:0:0:1:2:2:1:3:4:4:5:5:3

[Jjeje007]

Hi,

For the gentoo users :

I just tweak a bit the patch and add it in in this ebuild which come from the berkano overlay (cf http://forums.gentoo.org/viewtopic-t-508174-highlight-berkano.html )

I tested it, and it compil fine (x86). Just need an sample to test if the decoder is really working :rolleyes:

Any way, gentoo user, decompress the tarball in, for exemple :
/usr/local/portage/
Add this :
PORTDIR_OVERLAY="/usr/local/portage/mplayer"
In your :
/etc/make.conf
And :
emerge mplayer

Have fun

Note : You have to edit /usr/share/mplayer/codecs.conf as well

Jjeje007

Edit :

mplayer -ac help | grep ffeac3
ffeac3 ffmpeg problems FFmpeg EAC3 [E-AC3]


Edit² :

Oups, I forgot the link :p

http://www.db-instable.org/misc/mplayer_eac3_ebuild.tar.gz

[tebasuna51]

I am lose in ffmpeg world.
Sometimes I reported bugs or request without any answer.

But there are some bugs really basics that I can't understand how remain without solution:

- The multichannel output is wrong mapped.

- The uncompressed STDOUT have two fields empty (RiffLength and DataLength)

Is there any way to make a eac3 decoder out of the buggy ffmpeg?

A standalone decoder, an AviSynth plugin, a foobar component, ...?

[Kurtnoise]

Is there any way to make a eac3 decoder out of the buggy ffmpeg?

A standalone decoder, an AviSynth plugin, a foobar component, ...?
That would be great indeed. Maybe backport the stuff from the GSoC and use liba52 as a model ?

[sl1pkn07]

works!!!! thanks man!!

[tebasuna51]

That would be great indeed. Maybe backport the stuff from the GSoC and use liba52 as a model ?

Where is the sourcecode if is public?

[Kurtnoise]

http://liba52.sourceforge.net/

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

[lineman]

Is there a way to have FFmpeg create a windows wave file containing six audio tracks?

[tebasuna51]

Is there a way to have FFmpeg create a windows wave file containing six audio tracks?
Of course, I say:

1) The uncompressed output using:

ffmpeg -i input.evo -vn -acodec pcm_s16le -ac 6 -f wav out.wav

have a wrong channelmapping order (FL-FC-FR-BL-BR-LF)

Now you can use different solutions depending of your desired final output format.

[nickolasemp]

I can hear the sound so I am really happy... Thanks very much.

Merci beaucoup.

:-D

[lineman]

Of course, I say:

1) The uncompressed output using:

ffmpeg -i input.evo -vn -acodec pcm_s16le -ac 6 -f wav out.wav

have a wrong channelmapping order (FL-FC-FR-BL-BR-LF)

Now you can use different solutions depending of your desired final output format.

Thanks a million for the help..

[BENtheTEN]

looks like the eac3 code is "finished"
http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2007-September/001650.html

:thanks:

[Mc Onyx]

looks like the eac3 code is "finished"
http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2007-September/001650.html

:thanks:

AWESOME, hope to see a FFDShow build with it...

[tebasuna51]

looks like the eac3 code is "finished"
http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/2007-September/001650.html

:thanks:
Of course thanks to developers, but still there are some problems:

1) The "-correct maping channels in multi-channel sound"
is only true when the internal ac3 encoder is used.
The internal faac output, the uncompressed wav format or the direct 'pipe' to flac or aac encoders are wrong mapped.

2) The DialNorm and Dynamic Range Compression are applied always. Must be optional, or at least the default must be don't apply these values: after applied we can't recover the original quality signal.

3) The internal sample format are 32 float but are geld to 16 bit int to be send to ffmpeg, please at least 32 bits int or 24, also supported by ffmpeg.

4) If the channel mapping is corrected and we want send the ffmpeg 'pipe' output to NeroAacEnc maybe is enough correct the libavformat/wav.c:
static int wav_write_header(AVFormatContext *s)
{
WAVContext *wav = s->priv_data;
ByteIOContext *pb = &s->pb;
offset_t fmt, fact;

put_tag(pb, "RIFF");
- put_le32(pb, 0); /* file length */ // always false
+ put_le32(pb, 36); // by the moment header length send
put_tag(pb, "WAVE");
...

[ACrowley]

Of course thanks to developers, but still there are some problems:

2) The DialNorm and Dynamic Range Compression are applied always. Must be optional, or at least the default must be don't apply these values: after applied we can't recover the original quality signal.


Is it possible to enable/disable DRC/Dialonorm with currecnts Build? And when not its possibel in next builds ?
I hope so

Chances for a ffmpeg based TrueHD Decoder are bad at the Moment right ?


great Work

[Kurtnoise]

The internal faac output, the uncompressed wav format or the direct 'pipe' to flac or aac encoders are wrong mapped.
did you look around the channel mapping into lavf ? Could be great to have a fix for that...:) because I assume that FFmpeg developpers don't have a 5.1 kit to fix this.


Anyway, in my last build uploaded, I added your fix for the AAC ND encodings and it seems to work fine when we decide to downmix to stereo.

[tebasuna51]

did you look around the channel mapping into lavf ? Could be great to have a fix for that...:) because I assume that FFmpeg developpers don't have a 5.1 kit
to fix this.

The channel mapping is a issue of encoders/decoders.
A encoder must accept the uncompressed data in standard wav order and a decoder must send the uncompressed data in the same order (FL-FR-FC-LFE-BL-BR...).

If all encoders/decoders follow this rule the channelmapping problem is finished.

Then is the eac3 decoder to modify, at line 1365 in eac3dec.c:
for (k = 0; k < AC3_BLOCK_SIZE; k++) {
- for (i = 0; i < avctx->channels; i++) {
- *(out_samples++) = c->int_output[i][k];
- }
+ if (c->lfeon) {
+ switch(avctx->channels){
+ case 6:
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[2][k]; // FR
+ *(out_samples++) = c->int_output[1][k]; // FC
+ *(out_samples++) = c->int_output[5][k]; // LFE
+ *(out_samples++) = c->int_output[3][k]; // BL
+ *(out_samples++) = c->int_output[4][k]; // BC
+ break;
+ case 5:
+ if (c->acmod == 5) {
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[2][k]; // FR
+ *(out_samples++) = c->int_output[1][k]; // FC
+ *(out_samples++) = c->int_output[4][k]; // LFE
+ *(out_samples++) = c->int_output[3][k]; // BC
+ } else { // acmod 6
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[1][k]; // FR
+ *(out_samples++) = c->int_output[4][k]; // LFE
+ *(out_samples++) = c->int_output[2][k]; // BL
+ *(out_samples++) = c->int_output[3][k]; // BR
+ }
+ break;
+ case 4:
+ if (c->acmod == 3) {
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[2][k]; // FR
+ *(out_samples++) = c->int_output[1][k]; // FC
+ *(out_samples++) = c->int_output[3][k]; // LFE
+ } else { // acmod 4
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[1][k]; // FR
+ *(out_samples++) = c->int_output[3][k]; // LFE
+ *(out_samples++) = c->int_output[2][k]; // BC
+ }
+ break;
+ default:
+ for (i = 0; i < avctx->channels; i++)
+ *(out_samples++) = c->int_output[i][k];
+ }
+ } else {
+ switch(avctx->channels){
+ case 5:
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[2][k]; // FR
+ *(out_samples++) = c->int_output[1][k]; // FC
+ *(out_samples++) = c->int_output[3][k]; // BL
+ *(out_samples++) = c->int_output[4][k]; // BC
+ break;
+ case 4:
+ if (c->acmod == 5) {
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[2][k]; // FR
+ *(out_samples++) = c->int_output[1][k]; // FC
+ *(out_samples++) = c->int_output[3][k]; // BC
+ } else { // acmod 6
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[1][k]; // FR
+ *(out_samples++) = c->int_output[2][k]; // BL
+ *(out_samples++) = c->int_output[3][k]; // BR
+ }
+ break;
+ case 3:
+ if (c->acmod == 3) {
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[2][k]; // FR
+ *(out_samples++) = c->int_output[1][k]; // FC
+ } else { // acmod 4
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[1][k]; // FR
+ *(out_samples++) = c->int_output[2][k]; // BC
+ }
+ break;
+ default:
+ for (i = 0; i < avctx->channels; i++)
+ *(out_samples++) = c->int_output[i][k];
+ }
+ }

Of course work only for standard 5.1 channels.

Anyway, in my last build uploaded, I added your fix for the AAC ND encodings and it seems to work fine when we decide to downmix to stereo.

Yes, work fine now adding -ignorelength parameter to NeroAacEnc.
If you put the channelmapping patch work also with multichannel.

And to avoid the DialNorm and DynamicRangeCompression loss, at line 1337 in eac3dec.c:
/* apply scaling to coefficients (dialnorm, dynrng) */
for(ch=1; ch<=c->nfchans + c->lfeon; ch++) {
float gain=2.0f;
- if(c->acmod == AC3_ACMOD_DUALMONO) {
- gain *= c->dialnorm[ch-1] * c->dynrng[ch-1];
- } else {
- gain *= c->dialnorm[0] * c->dynrng[0];
- }
for(i=0; i<c->endmant[ch]; i++) {
c->transform_coeffs[ch][i] *= gain;
}
}

[Kurtnoise]

Thank you...:)

FFmpeg build uploaded + several command lines added in my 1st post concerning Nero Digital trancodes.

[tebasuna51]

Thank you...:)

FFmpeg build uploaded

Thank to you (I don't know how compile ffmpeg to make myself any test).

But I get the same result with build 10474 than with 10469:
- Same channelmapping
- Same low volume (DialNorm + DRC applied)

Maybe we can try a more simple change to test only multichannel 5.1 forgetting unusual cases.

for (k = 0; k < AC3_BLOCK_SIZE; k++) {
+ if (avctx->channels == 6) {
+ *(out_samples++) = c->int_output[0][k]; // FL
+ *(out_samples++) = c->int_output[2][k]; // FR
+ *(out_samples++) = c->int_output[1][k]; // FC
+ *(out_samples++) = c->int_output[5][k]; // LFE
+ *(out_samples++) = c->int_output[3][k]; // BL
+ *(out_samples++) = c->int_output[4][k]; // BC
+ } else {
for (i = 0; i < avctx->channels; i++) {
*(out_samples++) = c->int_output[i][k];
}
+ }
}

[Kurtnoise]

On my stereo system, I've better result with the rev 10474 than the previous one. New build is up (http://kurtnoise.free.fr/index.php?dir=misc/&file=ffmpeg_rev10475.7z) anyway...

btw, there is a wiki here (http://arrozcru.no-ip.org/ffmpeg_wiki/tiki-index.php) to describe how to compile FFmpeg with MSYS system. That's the way I use...

[tebasuna51]

On my stereo system, I've better result with the rev 10474 than the previous one. New build is up (http://kurtnoise.free.fr/index.php?dir=misc/&file=ffmpeg_rev10475.7z) anyway...

Still don't work. Same low volume, same wrong channelmapping.
eac3_decode_frame() in eac3dec.c is not the output routine?

btw, there is a wiki here (http://arrozcru.no-ip.org/ffmpeg_wiki/tiki-index.php) to describe how to compile FFmpeg with MSYS system. That's the way I use...

I will try, but this way is dark for me.

[jruggle]

The channel mapping is a issue of encoders/decoders.
A encoder must accept the uncompressed data in standard wav order and a decoder must send the uncompressed data in the same order (FL-FR-FC-LFE-BL-BR...).

If all encoders/decoders follow this rule the channelmapping problem is finished.


There is one problem with what you propose. Not every output format uses WAVE channel order. What if someone wants to transcode AC3 to AAC, or from E-AC3 to AC3, or from AC3 to Vorbis? The decoder should not assume that the user wants their audio automatically converted to WAVE channel order...so FFmpeg leaves the channel order as it was in the original audio.

I do admit FFmpeg needs a way to reorder channels, but it should definitely not be done the way you propose. In fact, I started working on that task a few months ago, but alas I am just one person with only so much time. Of course, if you only want to use FFmpeg to decode AC3 to WAVE then you can use that patch in your local build.

I don't mean to sound too defensive...I know there are many things that could be done to improve FFmpeg when it comes to audio. I am the FFmpeg AC3 maintainer, and I do wish I had more time on my hands to make it better. Now if I could just win the lottery so I could program for fun all day instead of working. :)

I'll go ahead and try to answer some of the other questions here.

As for disabling DRC/dialnorm, I'll see if I can get that added. I don't see why not. If you want to do it yourself, the patch would be simple enough. Add a variable to the AVCodecContext in avcodec/avcodec.h such as apply_drc. Append a line to the options[] array in avcodec/utils.c to add the option to the commandline. Then use the variable in ac3dec.c and/or eac3dec.c to control whether or not the DRC multiplier is applied. I would do it now, but I'm trying to finish this post so I can go to bed.

I already mentioned that I'm working on channel reordering. I also want to mention that it's a pain in the ass. There is a big difference between a working solution and a clean solution. I have a working solution and several ideas for clean solutions, but I kinda stopped working on it when the Google SoC started. So maybe now I'll pick it back up.

Support for anything other than 16-bit signed samples has been needed for years. It will be a pretty big task though since the whole audio API is currently based around 16-bit. As far as I know, all the FFmpeg developers want this to change, so it's a matter of someone taking on the task. It probably won't be me. :)

TrueHD support...that would take some huge breakthrough. I only find reverse engineering a little bit fun, and I don't really have the patience to stick with it. Unless Dolby decides to become generous and publish the specs, I doubt open source support for the format will happen anytime soon. But you never know...someone did reverse engineer Apple Lossless...

-Justin

[ACrowley]

Can we await a ffdshow build with EAC3 decoding soon ?

[tebasuna51]

There is one problem with what you propose. Not every output format uses WAVE channel order. What if someone wants to transcode AC3 to AAC, or from E-AC3 to AC3, or from AC3 to Vorbis? The decoder should not assume that the user wants their audio automatically converted to WAVE channel order...so FFmpeg leaves the channel order as it was in the original audio.

I don't see the problem in my proposal, the problem is leave the uncompressed channel order in the internal compressed order without any indication from the origin.

I ask (to you and DarkAvenger) what is the soft than output wav's in other order than the standard. I don't know very much:

1) Audio editors (and encoder plugins): all I know work in the standard wav order.

2) Multichannel encoders:
Aften, NeroAacEnc, Enc_Aacplus, Flac, wma_encoders ..., work in the standar wav order.
Sonic Foundry SoftEncode (old soft) is not the default order but can be easy modified.
Only OggEnc2 need ac3_order or need use WAVE_FORMAT_EXTENSIBLE header and now admit standard wav order.

3) Multichannel decoders:
Faad, NeroAacDec, Tranzcode, OggDec, NicAudio-AviSynth, BeLight-BeSweet, Foobar2000, ..., the output is always in standard wav order (yes also OggDec).
Azid with -d3/2 -L0 -l1 -ol,r,c,lfe,sl,sr can output standard wav order.

Of course the internal transcode ac3->ac3 or ac3<->ogg work fine now, but ac3<->aac don't work at all. If the uncompressed output is the standard wav order all external compliants encoders can be used.

Then my opinion is: the decoder must assume that the user wants their uncompressed audio automatically converted to WAVE channel order.

I do admit FFmpeg needs a way to reorder channels, but it should definitely not be done the way you propose. In fact, I started working on that task a few months ago, but alas I am just one person with only so much time. Of course, if you only want to use FFmpeg to decode AC3 to WAVE then you can use that patch in your local build.

Really I don't need ffmpeg to decode anything, I only want improve the free software with my very little input.
And can't accept "it should definitely not be done the way you propose", without any reason.

I don't mean to sound too defensive...I know there are many things that could be done to improve FFmpeg when it comes to audio. I am the FFmpeg AC3 maintainer, and I do wish I had more time on my hands to make it better. Now if I could just win the lottery so I could program for fun all day instead of working. :)

Of course I accept that. But let me propose a complete solution for multichannel ac3 ffmpeg encoder/decoder.

As for disabling DRC/dialnorm, I'll see if I can get that added. I don't see why not. If you want to do it yourself, the patch would be simple enough. Add a variable to the AVCodecContext in avcodec/avcodec.h such as apply_drc. Append a line to the options[] array in avcodec/utils.c to add the option to the commandline. Then use the variable in ac3dec.c and/or eac3dec.c to control whether or not the DRC multiplier is applied. I would do it now, but I'm trying to finish this post so I can go to bed.

Thanks, I will try.

I already mentioned that I'm working on channel reordering. I also want to mention that it's a pain in the ass. There is a big difference between a working solution and a clean solution. I have a working solution and several ideas for clean solutions, but I kinda stopped working on it when the Google SoC started. So maybe now I'll pick it back up.

Really I think the best solution is manage the uncompressed audio in a unique order (and the standard is MS wav, to play and to file output).

But maybe you have other ideas. I'm not a MS defender but I think is more easy accept the MS wav order than try to impose any other.

Support for anything other than 16-bit signed samples has been needed for years. It will be a pretty big task though since the whole audio API is currently based around 16-bit. As far as I know, all the FFmpeg developers want this to change, so it's a matter of someone taking on the task. It probably won't be me. :)

Ok.

[tebasuna51]

On my stereo system, I've better result with the rev 10474 than the previous one. New build is up (http://kurtnoise.free.fr/index.php?dir=misc/&file=ffmpeg_rev10475.7z) anyway...

Yes, the disable DialNorm-DRC can work, but seems my only eac3 to test have DialNorm -31 and DRC 'none' and I can't detect any difference. But the same change with standard ac3 works fine.

btw, there is a wiki here (http://arrozcru.no-ip.org/ffmpeg_wiki/tiki-index.php) to describe how to compile FFmpeg with MSYS system. That's the way I use...

Yes!. My first ffmpeg compiled.
I use your ffmpeg.patch because with the sources downloaded initially from http://svn.mplayerhq.hu/soc/eac3/ don't work for me (Unsupported codec (id=86020) for input stream #0.1)

I correct the problem and the wav order is now correct, in your
ffmpeg.patch at line 3646:
+ for (k = 0; k < AC3_BLOCK_SIZE; k++) {
+ for (i = 0; i < avctx->channels; i++) {
+ *(out_samples++) = c->int_output[i][k];
+ }
+ }
+ if (c->lfeon) {
+ switch(avctx->channels){
+ case 6:
...

must be:

+ for (k = 0; k < AC3_BLOCK_SIZE; k++) {
+ if (c->lfeon) {
+ switch(avctx->channels){
+ case 6:
...
+ }
My If {} replace the for (i ...) {}

The same changes can be made for regular ac3 (ac3dec.c).

Now I want change the ac3enc.c to permit work the internal encoder.

[Mc Onyx]

Can we await a ffdshow build with EAC3 decoding soon ?

Well i've asked a few times, but haven't got an answer! Damn, i wish i knew how to compile stuff, like libavcodec, etc.

[ACrowley]

Well i've asked a few times, but haven't got an answer! Damn, i wish i knew how to compile stuff, like libavcodec, etc.

ok thx..i dont know how to compile too

a ffdhow Build with EAC3 support would be extremly usefull for EAC3 Playback. So far we can disable DRC, as like as for AC3.

[Kurtnoise]

The AC3 decoder build in FFdshow uses liba52 not lavc...



@tebasuna : 10x...I'll look at this later. :)

[Mc Onyx]

The AC3 decoder build in FFdshow uses liba52 not lavc...

I forgot about that, so there's no way to get this decoder into FFDShow, unless somebody ports it?

[Kurtnoise]

yep...

[damngod]

I'm still getting this error when trying to encode E-AC3 to AAC-LC :

ffmpeg : unrecognized option '-aid'

I'm missing something but... what ?

If i omit -aid x, i'm getting a "output file does not contain any stream".

[Kurtnoise]

try this cmd ffmpeg -i input.evo and copy & paste the stdout here...

[damngod]

Here is it :

F:\>ffmpeg -i video.evo
FFmpeg version SVN-r10475, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --enable-gpl --enable-memalign-hack --enable-avisynth --enable-
libfaac --enable-libfaad --enable-libogg --enable-libvorbis --enable-libmp3lame
--enable-libx264 --enable-pp
libavutil version: 49.5.0
libavcodec version: 51.43.0
libavformat version: 51.12.3
built on Sep 11 2007 11:45:37, gcc: 4.2.1-dw2 (mingw32-2)
Input #0, mpeg, from 'video.evo':
Duration: N/A, start: 0.038556, bitrate: N/A
Stream #0.0[0xfd55]: Video: vc1, yuv420p, 1920x1080, 29.97 fps(r)
Must supply at least one output file

F:\>

[Kurtnoise]

no audio stream in your input file...that's why you have this message.

[jruggle]

Really I don't need ffmpeg to decode anything, I only want improve the free software with my very little input.
And can't accept "it should definitely not be done the way you propose", without any reason.

[...]

Really I think the best solution is manage the uncompressed audio in a unique order (and the standard is MS wav, to play and to file output).

But maybe you have other ideas. I'm not a MS defender but I think is more easy accept the MS wav order than try to impose any other.


I'm sorry, I'll explain a little more. FFmpeg is made up of several separate libraries, the biggest 2 being libavcodec and libavformat. Channel ordering is complex because sometimes it is dependent on the codec and sometimes on the format. There also needs to be a way for the user to specify the order. Some containers support 1 channel order, some support many orders, etc... We can't design the solution based on raw audio in WAVE order without taking other possibilities into account.

A form of your proposed solution was actually discussed. We decided that the decoder should not modify the channel order, but could modify the number of channels (i.e. downmixing). The most recent solution I was working on went something like this:

Input side (source channel layout)
1. The user can optionally specify the source channel layout.
2. The input format (container), if present, can optionally specify the channel layout when initialized.
3. The decoder can optionally specify the channel layout when initialized.
4. If none of the above occur, revert to a default channel layout.

Output side (destination channel layout)
5. The user can optionally request the output channel layout. If the encoder or container do not support it, give error message.
6. The encoder, when initialized, can optionally specify a channel layout.
7. The output format (container), when initialized, can optionally specify a channel layout.
8. If none of the above occur, revert to a default channel layout.

Take the example of AC3 source and WAVE output.
1. The user could override the source layout if they wanted to.
2. source container: raw AC3, no preferred layout
3. source codec: AC3, standard AC3 channel layout
4. skip, the input layout has been set to AC3 order with layout based on number of channels and acmod value.
5. The user can request a different output channel layout. For example, downmixed from 5.1 to stereo.
6. The encoder, raw pcm, doesn't care about the channel order
7. The output container, WAVE, needs to be in WAVE order.

All this is pretty straight-forward except for figuring out which options take precedence, and in what situations. The tricky part comes in deciding where the actual conversion should take place. In addition to reordering, there is also potential for downmixing when converting channel layouts. I implemented a solution which worked at the user level, which is also where sample rate conversion is done. This works, but has some drawbacks. AC3 and DTS both have specifically defined ways of doing downmixing. We thought of having the decoder pass along downmixing coefficients, but that could get really messy. The FFmpeg developers want a solution which would support downmixing and reordering at both the encoder/decoder level and at the user-level. This is certainly possible, but not simple to implement.

Let's look at 2 examples. Please note that when I say "user" I'm not talking about the actual program user, but the library user. The FFmpeg program is the user-level in this case since it uses libavcodec and libavformat.

AC3 5.1 to 6-channel WAVE:
*at initialization:
- AC3 decoder chooses 6 channels in AC3 order based on source stream and/or user request
- WAVE output format chooses 6 channels in WAVE order based on format default and/or user request
*during decode/encode:
- The input format doesn't do anything except split the frames (raw AC3 parser)
- AC3 decoder outputs a raw audio frame with 6 channels in AC3 order
- The user-level knows the source and output layouts and does the necessary reordering.
- The encoder doesn't do anything (raw pcm)
- The output format (WAVE) accepts the packet without warning or error since it has already been converted it to a supported channel layout.

AC3 5.1 to stereo WAVE:
*at initialization:
- AC3 decoder chooses 2 channels based solely on user request
- WAVE output format chooses 2 channels based on format default and user request
*during decode/encode:
- The input format doesn't do anything except split the frames (raw AC3 parser)
- AC3 decoder does the downmixing, and outputs a raw audio frame with 2 channels.
- The user-level knows the source and output layouts and doesn't have to do any reordering (it's just stereo)
- The encoder doesn't do anything (raw pcm)
- The output format (WAVE) accepts the packet without warning or error since it is in a supported channel layout.

Sorry for the really long post... I just want to make sure I'm explaining my thought process well enough.

[damngod]

Thanks Kurtnoise13 ! Too many file in the same dir with strange names, i was working on the wrong one. Just tried this morning with the correct .evo and it worked perfectly. Great tool. :)

[tebasuna51]

@Justin
Thanks for your long post and detailed explanations.

The most interesting for me is:
"A form of your proposed solution was actually discussed. We decided that the decoder should not modify the channel order,..."

Well, I'm not agree with you but I can't do nothing with this.

I think is more easy (and clean) each encoder/decoder uses like input/output the same order (maybe WAV or other), bitdepth (seems 32 float is more adequate instead 16 int) and so on.

With a unique format the user-level can do any process (TimeStretch, SampleRateChange, Upmix, Downmix, ...) much more easy.
BTW, I think the downmix process don't be a job for decoders, can suggest coefficients like pressent in BSI-AC3, but is a job for the user-level.

Then if:
"- AC3 decoder outputs a raw audio frame with 6 channels in AC3 order
- The user-level knows the source and output layouts and does the necessary reordering.
..."
we only can wait until ffmpeg developers implement the user-level. I know is not easy.

At least is not so easy than my solution implemented in less than a week by a unexperienced C programmer and without any knowledge of ffmpeg: I have a functional ffmpeg with correct channel mapping for wav, ac3, eac3 input and wav, ac3 output.

Of course others internal multichannels encoders/decoders like ogg and aac must need changed. But actually the aac output is wrong mapped also and multichannel ogg not allowable.

Maybe the official ffmpeg can accept at least the apply_drc command line parameter with the values:

0 Don't apply Dialog Normalization and Dynamic Range Compression (default, preserve the audio quality)
1 Apply only DRC (suggested for ac3 encoded with Aften with DialNorm included)
2 Apply only Dialog Normalization (I don't know for what)
3 Apply both (Dolby compliant equipments in noise ambience)

And the little patch to wav.c for stdout (http://forum.doom9.org/showthread.php?p=1043284#post1043284) to be accepted for NeroAacEnc:

put_tag(pb, "RIFF");
- put_le32(pb, 0); /* file length */ // always false
+ put_le32(pb, 36); // by the moment header length send
put_tag(pb, "WAVE");


Thanks.

[damngod]

Mmh, i was able to encode one E-AC3 this morning but i didn't have specified the stream number so it encoded the first one by default. Anyway i want to encode the second one and i'm still experiencing problems with -aid option. Wherever i put "-aid 2", it gets me :

ffmpeg : unrecognized option '-aid'

[damngod]

I tried :

ffmpeg -i rebuilt.evo -vn -acodec libfaac -ac 2 -ab 128k -aid 2 -y audio.fr.aac
ffmpeg -i rebuilt.evo -ac 2 -vn -acodec libfaac -ab 128k -aid 2 -y audio.fr.aac
ffmpeg -i rebuilt.evo -vn -acodec libfaac -ac 2 -ab 128k -ac 2 -aid 2 -y audio.fr.aac

And so on.

[yonta]

Mmh, i was able to encode one E-AC3 this morning but i didn't have specified the stream number so it encoded the first one by default. Anyway i want to encode the second one and i'm still experiencing problems with -aid option. Wherever i put "-aid 2", it gets me :

ffmpeg : unrecognized option '-aid'

as far as I know '-aid' is a mplayer/mencoder option.

if you just execute something like this;
ffmpeg.exe -i source.evo

output will be something like this;
Stream #0.0[0x1e2]: Video: mpeg2video, 90000.00 fps(r)
Stream #0.1[0xb1]: Audio: 0x0000
Stream #0.2[0xc0]: Audio: E-AC3, 48000 Hz, 5:1, 1536 kb/s
Stream #0.3[0xc3]: Audio: E-AC3, 48000 Hz, 5:1, 768 kb/s
Stream #0.4[0xc2]: Audio: E-AC3, 48000 Hz, 5:1, 640 kb/s
Stream #0.5[0x20]: Subtitle: dvdsub

now, if you want to transcode Stream #0.3(768k) to ac3 448k;
ffmpeg.exe -map 0:3 -i source.evo -vn -acodec ac3 -ab 448k -ac 6 stream03.ac3

[Kurtnoise]

my fault...sorry.

try this :
ffmpeg -i rebuilt.evo -vn -acodec libfaac -ac 2 -ab 128k -map 0:2 -y audio.fr.aac

the key is -map 0:x where x is the stream # desired...



edit/ yonta beats me. ^^

[damngod]

Thanks guys :)

I got a "noobie" question : do ffmpeg use an external decoder such as Nero or Sonic to decode the E-AC3 or is it able to encode E-AC3 by itself ? Because I have plenty decoders/splitters installed, I just want to know what is really needed (the minimum) to do E-AC3 to AAC. Thanks in advance, I hope I'm clear enough.