[FFmpeg-devel] [PATCH] Make av_set_pts_info keep previous time base if new one is invalid.
Ronald S. Bultje
Mon Feb 7 02:15:21 CET 2011
On Sun, Feb 6, 2011 at 4:51 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, Feb 06, 2011 at 10:20:30PM +0100, Reimar D?ffinger wrote:
>> On Sun, Feb 06, 2011 at 04:14:07PM -0500, Ronald S. Bultje wrote:
>> > >> A return value is useful, so that callers can detect failures to set a
>> > >> timebase, and error out in read_header() instead of parsing garbage.
>> > >> If you know of any use case where this doesn't apply (i.e. the output
>> > >> is not garbage), I'd love to hear it.
>> > >
>> > > A single-bit error in the time base? Highly unlikely normally but
>> > > I don't see what you would win by refusing a file because of a hint
>> > > there might be only garbage instead of continuing until you actually know.
>> > > And I am not saying that a return value is certainly useless, but I
>> > > dislike uglifying the API for "might-be".
>> > > If it wasn't a public API function I'd have added a return value right
>> > > away.
>> > I'll leave it as-is for now, if others agree
>> > a-return-value-so-demuxers-can-error-out would be nice, I can pick it
>> > up from here and introduce av_set_pts_info2() or so.
>> You could start with an internal symbol, we can still pollute
>> the public API when it's proven some value...
>> I guess we could also just have it change with a major bump,
>> ABI compatibility does not matter then and API is compatible
>> for most uses.
>> Just the ifdefs to do that are rather ugly.
> btw is changing a void to int really a ABI breakage on any supported platform?
Apps compiled against old FFmpeg will need to be recompiled on x86
because eax is not set on return...
More information about the ffmpeg-devel