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

[madshi]

Last time I checked the ffmpeg E-AC3 decoder it gave out slightly distorted sound for me. So IMHO it's too early to replace Nero's E-AC3 decoder right now. However, the next eac3to version will include the ffmpeg TrueHD/MLP decoder which seems to work well.

[madshi]

Just released the latest eac3to version with experimental support for libav/ffmpeg TrueHD and E-AC3 decoding. Download link and more details see eac3to thread.

[Blue_MiSfit]

interesting! I hope this decoder matures a bit. It would be a VERY clean solution to have this all integrated into a single app!

~MiSfit

[nightcity]

I added Kurtnoise's eac3 code into ffdshow on my pc, it works, but there is noise in left channel, the other 4 channels are all ok(I tested it on 2 HD-DVD discs), does any one has any idea with the problem?

[Jjeje007]

Hi,

Here is the new eac3 patch which compil and hopefully work (hope i don't mess something) fine with the latest mplayer's svn :

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

Jjeje007

[sl1pkn07]

thanks!

sl1pkn07@SpinFlo:~/aplicaciones/mplayer-svn$ cat eac3v3.patch | patch -p0 --dry-run
patching file libavcodec/ac3.c
patching file libavcodec/ac3.h
patching file libavcodec/ac3dec.c
patching file libavcodec/ac3dec.h
patching file libavcodec/ac3tab.c
patching file libavcodec/ac3tab.h
Hunk #2 succeeded at 40 with fuzz 2.
patching file libavcodec/eac3dec.c
patching file libavcodec/eac3.h
patching file libavcodec/aac_ac3_parser.c
Hunk #1 succeeded at 50 with fuzz 2 (offset 2 lines).
Hunk #2 succeeded at 61 with fuzz 1 (offset 2 lines).
patching file libavcodec/aac_ac3_parser.h
patching file libavcodec/aac_parser.c
patching file libavcodec/ac3_parser.c
Hunk #3 succeeded at 159 (offset 3 lines).
patching file libavcodec/allcodecs.c
Hunk #1 succeeded at 178 with fuzz 1 (offset 6 lines).
Hunk #2 succeeded at 286 (offset 19 lines).
patching file libavcodec/avcodec.h
Hunk #1 succeeded at 269 (offset 11 lines).
patching file libavcodec/Makefile
Hunk #1 succeeded at 67 (offset 4 lines).
patching file libavcodec/ac3enc.c
patching file libavformat/wav.c
Reversed (or previously applied) patch detected! Assume -R? [n] y
sl1pkn07@SpinFlo:~/aplicaciones/mplayer-svn$

its normal?

[Jjeje007]

Hi,

I just modify the patch for the ac3dec.c file which was changed.
So, you should remove your "mplayer-svn" folder and do an clean checkout.

Jjeje007

[Kurtnoise]

I added Kurtnoise's eac3 code into ffdshow on my pc, it works, but there is noise in left channel, the other 4 channels are all ok(I tested it on 2 HD-DVD discs), does any one has any idea with the problem?

it's not my code...:) You should contact the developper who has coded this part. Check the headers of the files, there is a mail I believe.

anyway, I'll be interested by your ffdshow patch...:p

[clsid]

Yep, that ffdshow patch would be interesting for those who don't use mplayer.

[Mc Onyx]

Yep, that ffdshow patch would be interesting for those who don't use mplayer.

+1 :)

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

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 :thanks: 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 :D)

Are always done :rolleyes:

Jjeje007

[jruggle]

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 :D)


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]

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 (http://forum.doom9.org/showthread.php?p=1047681#post1047681)

[jruggle]

@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]

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]

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 :D)


This one is now fixed in FFmpeg-SoC SVN.

Thanks,
Justin

[madshi]

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?

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]

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]

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.

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]

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]

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]

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 (http://forum.doom9.org/attachment.php?attachmentid=7899&stc=1&d=1198108057). 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... :o Sorry about that. But I thought asking wouldn't harm. You can still simply say "no", of course! ;)

[jruggle]

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]

It works fine for me. Did you use "configure --enable-gpl" ?
Nope. Didn't know about that switch. Thank you... :)

No. :)
:D

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]

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...

[madshi]

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...
No no, that's good to know. Thanks for the information!

Personally, I'm not really using ffmpeg, but only libavcodec. Because of that I just didn't see the problem. But now after reading your explanation I understand. Anyway, I've decided that the best solution for me is to just modify libavcodec for my needs. Wasn't difficult to do. Thankfully the (E-)AC3 decoder code is documented well... :)

[jruggle]

Update: current svn of both ffmpeg (r11346) and ffmpeg-soc-eac3 (r1677) ignore dialnorm and allow for scaling of drc using the "drc_scale" option.

Also, thanks to madshi, I now have a sample which uses enhanced coupling. So hopefully I will be able to get that feature working soon.

[madshi]

Sounds good, thanks... :)

[LAj]

Hi all,
after 5 days maybe it's better for you all I'll continue to not post in this forum being to the "Hall of Fame" of the forums.

I've compiled mplayer on Gentoo and finally I've seen my first HD-DVD.
:thanks:I've to thanks you a lot ...but now I'm ill so only go on with the first request :)

How to passthrough E-AC3 stream ?


libavformat file format detected.
[lavf] Video stream found, -vid 0
[lavf] Audio stream found, -aid 1
[lavf] Audio stream found, -aid 2
[lavf] Audio stream found, -aid 3
[lavf] Audio stream found, -aid 4
VIDEO: [WVC1] 1920x1080 0bpp 29.970 fps 0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Requested video codec family [wmvvc1dmo] (vfm=dmo) not available.
Enable it at compilation.
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffvc1] vfm: ffmpeg (FFmpeg WVC1)
==========================================================================
==========================================================================
Trying to force audio codec driver family hwac3...
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 48000 Hz, 6 ch, s16le, 640.0 kbit/13.89% (ratio: 80000->576000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)


I know:
AC3 through S/PDIF 0x2000/0x74656E64 - -
DTS through S/PDIF 0x2001 - -
as reported here http://www.mplayerhq.hu/DOCS/codecs-status.html#ac

So, How to passthrough Uncompressed PCM?

Why AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
if iec958 is unmuted and selected as output device?
I think it can be passthrough at this level also.

P.S.: please correct my bed English :)

[madshi]

I now have a sample which uses enhanced coupling. So hopefully I will be able to get that feature working soon.
Just for my interest: Is enhanced coupling the last missing feature in the E-AC3 decoder? In other words: Will the decoder be "complete" when you get enhanced coupling to work? Or are there any other features you still need samples for?

Thnx.

[jruggle]

Just for my interest: Is enhanced coupling the last missing feature in the E-AC3 decoder? In other words: Will the decoder be "complete" when you get enhanced coupling to work? Or are there any other features you still need samples for?
Well, not quite. Here is the current TODO list:
http://svn.mplayerhq.hu/soc/eac3/TODO?view=co

[madshi]

Well, not quite. Here is the current TODO list:
http://svn.mplayerhq.hu/soc/eac3/TODO?view=co
Thanks!

[jruggle]

Just for my interest: Is enhanced coupling the last missing feature in the E-AC3 decoder? In other words: Will the decoder be "complete" when you get enhanced coupling to work? Or are there any other features you still need samples for?
Update: I still need a sample for enhanced coupling. It turns out that the sample I had did not use enhanced coupling...it was just a bug in the decoder.

So basically, I need samples for enhanced coupling, spectral extension, and dependent streams (i.e. 7.1-channel). More samples with AHT would be nice too since I only have 1 right now.

[nautilus7]

How we non-programmers can find out if an e-ac3 track is what you need?

[jruggle]

How we non-programmers can find out if an e-ac3 track is what you need?
If you try to play it with the latest version of the FFmpeg E-AC3 decoder, it will spit out a long error message about how we need samples.

[nautilus7]

Ok, i see. I'll check some of my tracks on weekend.

[madshi]

Update: I still need a sample for enhanced coupling. It turns out that the sample I had did not use enhanced coupling...it was just a bug in the decoder.

So basically, I need samples for enhanced coupling, spectral extension, and dependent streams (i.e. 7.1-channel). More samples with AHT would be nice too since I only have 1 right now.
Is the decoder bug fixed in SVN? Probably it would make sense if I updated eac3to with the latest SVN and asked eac3to users to run their eac3 tracks through eac3to to find useful samples?

I don't think there is any way to get a "dependent streams" sample today. Isn't this only used for Blu-Ray E-AC3 tracks? I'm not aware of any Blu-Ray disc with E-AC3. Also I'm not aware of any HD DVD disc with an E-AC3 track with 7.1, unfortunately.

What is "AHT"? Hopefully the decoder outputs a "sample warning" message for AHT, too, so that the eac3to users will know when to send a sample?

[jruggle]

Is the decoder bug fixed in SVN? Probably it would make sense if I updated eac3to with the latest SVN and asked eac3to users to run their eac3 tracks through eac3to to find useful samples?
One bug fixed, but still buggy for AHT (see below). One problematic thing is that it is hard to tell whether the error message is due to a bug or if it really has the advanced feature until I dig into it quite thoroughly. So basically I just need samples which give error messages and I'll try to figure it out from there.

What is "AHT"? Hopefully the decoder outputs a "sample warning" message for AHT, too, so that the eac3to users will know when to send a sample?
It is the Adaptive Hybrid Transform. Essentially, this is one of the biggest features in E-AC3. It does a DCT (type 2 I think) on all 6 blocks, then uses completely different quantization for the mantissas (Gain Adaptive Quantization and Vector Quantization). I only have 2 samples currently which use this. One is a mono track which decodes perfectly. The other is a 5.1 track which is buggy.

The decoder does not currently give any kind of indication of whether the E-AC3 stream uses AHT. Later today I'll add some debugging printouts which tell what features are being used.

[madshi]

It is the Adaptive Hybrid Transform. Essentially, this is one of the biggest features in E-AC3. It does a DCT (type 2 I think) on all 6 blocks, then uses completely different quantization for the mantissas (Gain Adaptive Quantization and Vector Quantization). I only have 2 samples currently which use this. One is a mono track which decodes perfectly. The other is a 5.1 track which is buggy.

The decoder does not currently give any kind of indication of whether the E-AC3 stream uses AHT. Later today I'll add some debugging printouts which tell what features are being used.
Maybe you could output the usual "please send a sample" text whenever the decoder finds AHT? Of course only temporarily as long as you have enough samples with AHT. Afterwards you could remove that output. That would make it easier for us to collect samples.

[madshi]

@Justin,

just tried the latest eac3 svn and the sample I uploaded is still reported as "enhanced coupling" and fails to decode. Now I'm wondering: Should I wait for a new svn before asking the "eac3to" users to look for samples? I'm fearing that with the current svn we might get lots of such "enhanced coupling" samples which are not really enhanced coupling, but just cause the decoder to stumble. What do you think?

Btw, I noticed that you already merged some parts of the AC3/E-AC3 decoders. That's nice! :)

[jruggle]

@Justin,
just tried the latest eac3 svn and the sample I uploaded is still reported as "enhanced coupling" and fails to decode. Now I'm wondering: Should I wait for a new svn before asking the "eac3to" users to look for samples? I'm fearing that with the current svn we might get lots of such "enhanced coupling" samples which are not really enhanced coupling, but just cause the decoder to stumble. What do you think?
Well, there is no way to tell right away whether a sample really uses enhanced coupling. I have to basically isolate the frame and study it using debugging output. I still would love to have any samples which report errors. If it gets to the point where I am getting too many samples, I'll shout. But for now anything that will help improve the decoder is a good thing, whether it be to implement a new feature or fix bugs.

Btw, I noticed that you already merged some parts of the AC3/E-AC3 decoders. That's nice! :)
Thanks. I'm really hoping to finish up this weekend and get the decoder into main FFmpeg SVN.

[madshi]

Well, there is no way to tell right away whether a sample really uses enhanced coupling. I have to basically isolate the frame and study it using debugging output. I still would love to have any samples which report errors. If it gets to the point where I am getting too many samples, I'll shout. But for now anything that will help improve the decoder is a good thing, whether it be to implement a new feature or fix bugs.
Ok. Prepare to get a bunch of samples then... :)

Thanks. I'm really hoping to finish up this weekend and get the decoder into main FFmpeg SVN.
That would be great!

[jruggle]

just tried the latest eac3 svn and the sample I uploaded is still reported as "enhanced coupling" and fails to decode.
fixed. :) and unfortunately it really doesn't use enhanced coupling...

[uberjay]

Hey everyone. I spent quite some time playing around with the EAC3 patches and mplayer. I have been trying to play King Kong (from an HD-DVD, using the XBox 360 HD-DVD drive), but haven't been able to play 5.1 audio over S/PDIF.

As I understand it, S/PDIF is not high enough bitrate to directly pass through the EAC3 audio, so some transcoding is required. (am I off base here?) Should I be able to use something like mplayer's ac3 encoder audio filter to do what I want?

When I play the video files using mplayer+eac3 patches, I get only stereo audio output. Using ffmpeg to extract/transcode the eac3 audio to ac3, and then playing the resulting file works perfectly, but I'm trying to figure out how to do this all in real time.

I tried:

mplayer -channels 6 -af lavcac3enc=1 -demuxer lavf -ac ffeac3 -fps 24000/1001 <filename> -aid <streamid>

and mplayer segfaulted. Perhaps I ought to send a backtrace to the mplayer team, but I thought I'd check first if this is the right strategy to be using.

Thanks in advance for any help!

(EDIT: not sure if it helps any, but I get the exact same behavior with the TrueHD/MLP decode patch--only stereo output, and a segfault when trying to re-encode to 6 channel ac3...)

[skygod]

As I understand it, S/PDIF is not high enough bitrate to directly pass through the EAC3 audio, so some transcoding is required. (am I off base here?)

Yes and me too. The new audio formats require way more bandwidth than spdif. I'm considering getting an a USB sound card with individual 5.1 output - I have an old receiver without HDMI. 1080 is already asking alot (too much) from my system.