[FFmpeg-devel] [RFC] stream parsing

Benjamin Larsson banan
Mon Sep 27 16:53:05 CEST 2010


On 09/27/2010 02:04 PM, Michael Niedermayer wrote:
> On Mon, Sep 27, 2010 at 12:59:27PM +0200, Benjamin Larsson wrote:
>   
>> On 09/27/2010 12:39 PM, Michael Niedermayer wrote:
>>     
>>>>> Please tell me if this works:
>>>>> @@ -2000,6 +2000,8 @@
>>>>>      int val;
>>>>>      switch(enc->codec_type) {
>>>>>      case AVMEDIA_TYPE_AUDIO:
>>>>> +        if(!enc->channel_layout && (!enc->codec || (enc->codec->capabilities & CODEC_CAP_CHANNEL_CONF)))
>>>>> +            return 0;
>>>>>          val = enc->sample_rate && enc->channels && enc->sample_fmt != SAMPLE_FMT_NONE;
>>>>>          if(!enc->frame_size &&
>>>>>             (enc->codec_id == CODEC_ID_VORBIS ||
>>>>>
>>>>> if not, please tell me why it fails, ill fix it
>>>>>   
>>>>>       
>>>>>           
>>>> Well it works if the container does not populate the channel_layout
>>>> (riff based ones do that if the field is there). So in that case the
>>>>     
>>>>         
>>> and is it wrong in the riff case?
>>> (if its wrong this could be argued to be a bug in the riff demuxer)
>>>
>>>       
>> Well I wanted the  CODEC_CAP_CHANNEL_CONF flag to mean that whatever
>> channel configuration info is stored in the container, it should be
>> overridden by the codec info (ie sample_rate, channels, channel_layout).
>> It has nothing to do with if the riff demuxer is buggy or not.
>>     
> well it matters because this flag is not stored per demuxer but codec
> we only need a single case where the demuxer is more accurate for this to
> break down
> or to see it differntly, if demuxer information is inaccurate this is a demuxer
> thing, its not a codec feature that the demuxer is wrong, its a codec feature
> if this information is stored in the codec.
>
>
>   
>> In the riff case if the is a wavefmt_extensible header and the stored
>> codec is pcm then there is no other info then in the container, ie we
>> have to use that. But if the stored codec is dca we should use the info
>> from the codec as it is more reliable. Your patch does not cover that
>> scenario. I think that we should cover this scenario. My original patch
>> does cover this scanario and the same technique is used for AAC.
>>     
> we could put the code in riff under !(capabilities & CODEC_CAP_CHANNEL_CONF)
>
> that said i dont mind if we set things to 0 in av_find_stream_info() if it
> works better but your implementation of that is too convoluted for my taste
>


Is this too convoluted also ? Missing is a comment describing what it
does and how it works.

MvH
Benjamin Larsson


Index: libavformat/utils.c
===================================================================
--- libavformat/utils.c    (revision 25147)
+++ libavformat/utils.c    (working copy)
@@ -2171,6 +2171,7 @@
     } info[MAX_STREAMS] = {{0}};
 
     for(i=0;i<ic->nb_streams;i++) {
+        AVCodec *codec;
         st = ic->streams[i];
         if (st->codec->codec_id == CODEC_ID_AAC) {
             st->codec->sample_rate = 0;
@@ -2191,9 +2192,12 @@
             }
         }
         assert(!st->codec->codec);
+        codec = avcodec_find_decoder(st->codec->codec_id);
+        if (codec && codec->capabilities & CODEC_CAP_CHANNEL_CONF)
+            st->codec->channels = 0;
+
         //try to just open decoders, in case this is enough to get
parameters
         if(!has_codec_parameters(st->codec)){
-            AVCodec *codec = avcodec_find_decoder(st->codec->codec_id);
             if (codec)
                 avcodec_open(st->codec, codec);
         }




More information about the ffmpeg-devel mailing list