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".