[FFmpeg-devel] [PATCH 2/2] DCA - fix downmix

[Nick Brereton]

On 28 Jul 2010, at 13:58, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Nick Brereton <nick <at> nbrereton.net> writes:
> 
>> On 28 Jul 2010, at 11:00, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
> 
>>> Could you comment on the remaining problems: 
>>> Afaict, the 4.0 sample we have
>>> (A-codecs/DTS/Edward.Scissorhands.x264.DTS-4.0-48_24.mkv on
>>> samples.mplayerhq.hu) ends up with wrong channel order if converted to wav.
>> 
>> What's the correct order? With current code converting to wav I see
>> L, R, C, S in that order. (./ffmpeg -i
>> Edward.Scissorhands.x264.DTS-4.0-48_24.mkv out.wav)
> 
> How do you "see" the order of the resulting wav file?
> What I tried is to play the wav file with ffplay, mplayer and aplay (except for
> ffplay both analogue and over hdmi) and I heard the center signal (the one with
> the sound when the egg-halfs are pulled apart after ten seconds) from the (left)
> surround box.
> 
>>> And if I convert one of the "new" seven channel samples (I mean the samples
>>> that were 6-channel before your patches) to wav, nothing plays them
>>> correctly. afaict
>> 
>> I'm not seeing problems going to .wav files - is this another case?
> 
> Before your patches, both lotr_5.1_768.dts and last_stand.mkv were identified as
> 6-channel and if converted to wav, the resulting file played "fine" (wrt channel
> order) with ffplay, mplayer and aplay (again analogue and via hdmi).
> Now the samples (at least with -acodec copy -f dts) are (correctly) identified
> as seven channel, but the resulting wav file sounds completely wrong (center
> channel missing?) with mplayer and aplay - this time only analogue, because at
> least my receiver-hdmi combination (Geforce 210 - KRF-V7300D) does not accept
> seven channel wav, only 1, 2, 4, 6 and 8).

This should be working with the last set of patches. It turns out that the MKV demuxer is forcing avctx->request_channels to 6 (even though the xch extension and 7 channels exist). Decoding less than the maximum number of channels didn't work properly and that is what the patch fixes.

It does leave a question though of how the MKV forcing the channels should be handled - I assume this data was derived and encoded into the container by the encoder?

> 
> Thank you for looking into this, Carl Eugen

Regards,

Nick

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel