[FFmpeg-devel] TrueHD track in EVO not playable/testable with ffplay
Fri Jul 10 02:38:34 CEST 2009
2009/7/9 M?ns Rullg?rd <mans at mansr.com>:
> Michael Niedermayer <michaelni at gmx.at> writes:
>> On Wed, Jul 08, 2009 at 11:01:57PM -0700, Baptiste Coudurier wrote:
>>> On 07/08/2009 07:47 PM, Michael Niedermayer wrote:
>>>> my tired mind says we need a
>>>> coded_channels representing the number of channels stored in the stream
>>>> and a seperate field that represents the decoder output channels
>>> I suggest to keep ->channels as the coded channels and to use another field
>>> like output_channels.
Wouldn't this break API? Programs currently check avctx->channels to
know how much data there is. If we make them check
avctx->output_channels we'd need to bump major (and break something
else so people know they need to update and we hope they stumble upon
a place that explains this change too).
>> I wouldnt mind, if we wouldnt have
>> coded_width & coded_height in there
> This is different. ?Unless I am mistaken, coded_width and coded_height
> indicate the encoded width/height of a video including any padding
> (e.g. mod-16) required by the codec but never meant to be displayed.
> In the case at hand, we have a number of audio channels, all of which
> are meaningful, but which may be downmixed before output.
By looking at the doxy in avcodec.h I don't think coded_ is the best too.
I attached a patch to see if this is what you mean by adding a new
field (I named it coded_channels like michael suggested but I don't
really like the name as I pointed out).
Now would this mean that all decoders should be changed to
"avctx->coded_channels = avctx->channels = <number of channels>"? Or
only the decoders that support downmixing (and the documentation
should be updated to say this field only has meaning if it's != 0)?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1928 bytes
Desc: not available
More information about the ffmpeg-devel