On 10/9/2020 6:55 PM, Michael Niedermayer wrote:
> On Fri, Oct 09, 2020 at 03:04:30PM +0200, Anton Khirnov wrote:
>> Specifically: pts_wrap_bits, first_dts, cur_dts.
>> They are supposed to be private and are located in the private section
>> of AVStream, but ffmpeg.c currently accesses them regardless. They
>> should be moved to AVStreamInternal once that bug is fixed.
>>
>> Remove the marker for the private AVStream section, as there are no
>> other accessible fields left there. It has proven highly confusing and
>> people kept adding supposedly-public fields into the private section.
>> New private per-stream fields should be added to AVStreamInternal.
>> ---
>>  libavformat/avformat.h | 20 +++++++++-----------
>>  1 file changed, 9 insertions(+), 11 deletions(-)
>>
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index a01912d654..612791a2eb 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -1013,22 +1013,16 @@ typedef struct AVStream {
>>       */
>>      AVCodecParameters *codecpar;
>>  
>> -    /*****************************************************************
>> -     * All fields below this line are not part of the public API. They
>> -     * may not be used outside of libavformat and can be changed and
>> -     * removed at will.
>> -     * Internal note: be aware that physically removing these fields
>> -     * will break ABI. Replace removed fields with dummy fields, and
>> -     * add new fields to AVStreamInternal.
>> -     *****************************************************************
>> -     */
>> -
>>  #if LIBAVFORMAT_VERSION_MAJOR < 59
>>      // kept for ABI compatibility only, do not access in any way
>>      void *unused;
>>  #endif
>>  
> 
>> -    int pts_wrap_bits; /**< number of bits in pts (used for wrapping 
>> control) */
>> +    /**
>> +     * number of bits in pts (used for wrapping control)
>> +     * private, do not access from outside libavformat.
>> +     */
>> +    int pts_wrap_bits;
> 
> This is maybe a really bad way to export "pts_wrap_bits" but i think
> User applications could quite reasonably need to know at which point pts wrap.
> Or whats the max duration for a timebase where pts are still unique or valid.
> 
> Based on this a user app might warn the user at the begin of transcoding that
> timestamps will wrap and that with non streaming output, wrap might equal 
> fail.
> 
> so maybe this should not be declared private without replacement.

It already is private. This commit doesn't change that.

> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to