[Ffmpeg-devel] dts decoding broken?

[Andreas Öman]

Uoti Urpala wrote:
> On Fri, 2007-02-09 at 19:19 +0200, Uoti Urpala wrote:
>> On Fri, 2007-02-09 at 17:52 +0100, mail at kraymer.de wrote:
>>> same with 5.1 dts. Now, I only get 2 out of 6 channels without downmix,
>>> even with -channels 2 and/or -af channels=2. What I get is mainly music
>>> and background sounds, voices are missing.
>>> I did some regression testing and it turned out that a change in ffmpeg,
>>> namely commit -r 7839, introduced that behavior. Using recent mplayer svn
>> That commit changes the decoder to output the full number of channels by
>> default. Unfortunately it also seems to completely remove the ability to
>> use the libdts downmixing functionality.
>>
>> The rest of the channels are there and you can access them by explicitly
>> specifying some conversion to 2 channels with "-af pan" for example.
>> However having a way to use the libdts downmixing would be better.
> 
> Does anyone intend to restore support for the downmixing functionality?
> Can anything sanely use the current 6-channel output? Is the channel
> order even documented anywhere in FFmpeg (outside libdts)?
> 

No. i don't think so, aac 5.1 and ac3 5.1 output channels in different
order.

On top of that, "avctx->channels" is a bit misused, atleast in the
current ac3-decoder. (It's used both for hinting the decoder of how
many channels we'd like and as a result for how many we got).
This causes issues when streams switches no. of channels during
playback.

Here are some ideas from the top of my head.

* avctx->channels should be replaced with an enum much like PixelFormat
for video, or we collide with formats having the same amount of channels
(such DTS_3F1R and DTS_2F2R). These enumerations implicitly specifies
the number of channels, the channel locations (front, back, side, 
center, etc) and channel order (interleave offset in output data).
Call it 'ChannelFormat' / 'ChannelLayout' or somthing.

* For presentation purposes we should always keep the original
channellayout stored in the codeccontext.

* It might also be worth pondering a way of letting the application say
'hey, i can handle these formats, give it your best downmix'. One way of
doing this is by letting the application specify a bitmask of the
soundformats it is willing to accept. This of course limits us to 32 (or
64 maybe) different channelformats, which might be a bad thing :/

Once this is in place we could start to work on some kind of standard
post processor (IIRC Michael has mentioned such a thing here before)
that could to stuff like format conversion, resampling and additional
channel matrixing.

I'm willing to give the channel-layout-code a try (assuming people
think it's a wise thing to do)