[FFmpeg-devel] TrueHD track in EVO not playable/testable with ffplay
Fri Jul 10 03:28:46 CEST 2009
On Thu, Jul 09, 2009 at 09:11:09PM -0400, Justin Ruggles wrote:
> Ramiro Polla wrote:
> > 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)?
> This would affect demuxers as well if they rely on a parser.
> av_find_stream_info() expects the parser to set avctx->channels or else
> it will start trying to decode frames.
yes av_find_stream_info() would also need to be fixed.
It really seems theres no way to avoid 2 channel fields, as "in bitstream"
and "decoder output" can differ, whats left is bikeshed about the naming ;)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
GMX, the mailprovider that uses RBL lists to reject mails from your friends
running their own mailserver at home. The mailprovider that obscures the
origin of mails (mis)identified as viruses. The mailprovider that improves
security my disallowing more secure forms of authentication.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel