[FFmpeg-devel] [PATCH 18/18] lavf: document some AVStream fields as private
James Almer
jamrial at gmail.com
Sat Oct 10 00:57:30 EEST 2020
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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>
More information about the ffmpeg-devel
mailing list