On 17.08.2015 16:45, Michael Niedermayer wrote: > On Mon, Aug 17, 2015 at 04:36:52PM +0200, Nicolas George wrote: >> Le decadi 30 thermidor, an CCXXIII, Michael Niedermayer a écrit : >>> From: Michael Niedermayer <mich...@niedermayer.cc> >>> >>> Move field to internal part of AVStream and struct to internal.h >>> >>> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >>> --- >>> libavformat/avformat.h | 2 ++ >>> libavformat/internal.h | 12 ++++++++++++ >>> libavformat/mux.c | 22 ++++++++++++++-------- >>> libavformat/utils.c | 6 +++++- >>> 4 files changed, 33 insertions(+), 9 deletions(-) >> >> I see there are very few uses of this structure: why not simply replace it >> by stand-alone fields? >> >> int64_t pts_int, pts_num, pts_den; >> >> The only use of frac_init() can be inlined: >> >> st->pts_int = 0; >> st->pts_num = 0; >> st->pts_den = den; >> >> And frac_add() is used only twice, both times directly on &st->pts, it could >> become: >> >> void pts_add(AVStream *st, int64_t incr) >> >> Or maybe I am missing something obvious? > > at least on the demuxer side we have a timestamp rounding accumulation > bug that looks like it can be fixed by using *Frac. I dont know if > other places exist but the usecase seems somewhat generic so i > wouldnt be surprised to find more places that could use it. > If we cut the API down to the bare minimum actually used ATM then > using it elsewhere may no longer be possible as other uses > might require the removed parts. > So i think we first should investigate where potetial uses exist > that would become more exact with it and only afterwards cut the > API down if theres something that is nowhere used
Meanwhile applying this patch would be good, I think, so that disabling FF_API_LAVF_FRAC doesn't break the build anymore. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
