[FFmpeg-devel] [PATCH] avformat: Remove use of AVFrac and AVStream->pts
andreas.cadhalpun at googlemail.com
Sat Aug 22 18:06:59 CEST 2015
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 <michael at niedermayer.cc>
>>> Move field to internal part of AVStream and struct to internal.h
>>> Signed-off-by: Michael Niedermayer <michael at 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
>> 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.
More information about the ffmpeg-devel