[FFmpeg-devel] [PATCH 14/18] lavf: move AVStream.{need_parsing, parser} to AVStreamInternal

James Almer jamrial at gmail.com
Sun Oct 11 16:29:12 EEST 2020


On 10/11/2020 9:12 AM, Anton Khirnov wrote:
> Quoting Andreas Rheinhardt (2020-10-09 16:36:27)
>> Anton Khirnov:
>>> Those are private fields, no reason to have them exposed in a public
>>> header.
>>> ---
>>>  libavdevice/v4l2.c           |   2 +-
>>
>> This is a problem: There is no requirement to update libavdevice at the
>> same time as libavformat; one might use a newer version of libavformat
>> together with an older version of libavdevice. This effectively makes
>> the offsets of all the fields accessed by libavdevice avpriv, regardless
>> of whether they are in AVStream or AVStreamInternal.
> 
> Right. I wish avdevice was either purged from earth or merged into lavf,
> in that order of preference.
> Shall I postpone this patch until the bump then?

That depends on if we plan to make a last release before the bump or
not. If we do then you should apply it after the branch is cut, and if
not then doing it now is fine, since it will make no difference whatsoever.

> 
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index 9c0b25d37b..b1aab0c8ea 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -1053,12 +1053,10 @@ typedef struct AVStream {
>>>       */
>>>      int codec_info_nb_frames;
>>>  
>>> -    /* av_read_frame() support */
>>> -    enum AVStreamParseType need_parsing;
>>
>> sizeof enum types is compiler-specific IIRC. Compilers may choose a type
>> smaller than int if all the constants fit into a smaller type. Could
>> this cause a problem here?
> 
> Theoretically, I guess. In practice, probably no.
> But changed the type of unused8 to enum AVStreamParseType, just in case.
> 
>>
>> There is no need to keep the superfluous whitespace here and in the
>> other places.
> 
> Ok, fixed locally.
> 



More information about the ffmpeg-devel mailing list