[FFmpeg-cvslog] r15043 - trunk/libavformat/utils.c

[Ronald S. Bultje]

Hi,

On Fri, Aug 29, 2008 at 8:19 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Aug 29, 2008 at 07:04:08PM -0400, Ronald S. Bultje wrote:
>> On Fri, Aug 29, 2008 at 6:50 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Fri, Aug 29, 2008 at 06:35:53PM -0400, Ronald S. Bultje wrote:
>> >> On Fri, Aug 29, 2008 at 6:31 PM, Baptiste Coudurier
>> >> <baptiste.coudurier at smartjog.com> wrote:
>> >> > Ronald S. Bultje wrote:
>> >> >> On Fri, Aug 29, 2008 at 6:13 PM, bcoudurier <subversion at mplayerhq.hu> wrote:
>> >> >>> make has_codec_parameters not returning true when sample_fmt is not set
>> >> >> [..]
>> >> >>> @@ -1842,7 +1842,7 @@ static int has_codec_parameters(AVCodecC
>> >> >>>     int val;
>> >> >>>     switch(enc->codec_type) {
>> >> >>>     case CODEC_TYPE_AUDIO:
>> >> >>> -        val = enc->sample_rate && enc->channels;
>> >> >>> +        val = enc->sample_rate && enc->channels && enc->sample_fmt != SAMPLE_FMT_NONE;
>> >> >>>         if(!enc->frame_size &&
>> >> >>>            (enc->codec_id == CODEC_ID_VORBIS ||
>> >> >>>             enc->codec_id == CODEC_ID_AAC))
>> >> >>
>> >> >> Doesn't this mean, since s_fmt is codec-dependent (and can thus only
>> >> >> be set by the codec) that we always have to open the codec and that
>> >> >> demuxer header parsing is never sufficient to pass find_stream_info()?
>> >> >> If so, I would guess that this is bad.
>> >> >>
>> >> >
>> >> > Video already does that ... see pix_fmt.
>> >>
>> >> Once I test video, I would probably have complained about that... :-).
>> >>
>> >> More in a broader context, is this wanted (that we always need to open
>> >> a codec to know this kind of stuff) and what would be an acceptable
>> >> way to work around it in case of network-streams such as MMS/RTSP?
>> >
>> > It should be possible for AVParsers to set it
>>
>> But that still requires incoming data, right?
>
> only if the parser cannot decide it without such data
>
>
>> Here, for all unselected
>> streams, no data ever comes in. Only that AVStream to which we
>
> it should be rather simple to add a check for AVStream.discard in there

If that's acceptable then I'll submit a patch doing that whenever I next hit it.

Thanks,
Ronald