[FFmpeg-devel] [PATCH] Delay FF_API_AVFRAME_COLORSPACE until the next libavutil soname bump
michaelni at gmx.at
Mon Jul 28 20:47:07 CEST 2014
On Mon, Jul 28, 2014 at 08:28:26PM +0200, Reimar Döffinger wrote:
> On Mon, Jul 28, 2014 at 04:30:02AM +0200, Michael Niedermayer wrote:
> > This works around ABI issues with applications which depend on libavutil
> > internal values like sizeof(AVFrame)
> > One such application is VLC 2.1.4 as well as 2.1.5
> As you said yourself, we have been and will be relying on this probably
> As a result I'm not convinced that this really is a better approach, at
> least thinking long-term,
yes, but it might help distros which deal with 2.2 -> 2.3 upgrading
its certainly not a long term solution
> than asking everyone to update to fixed versions
> of those programs...
> But apart from that, even if we keep the fields in AVFrame can't we just
> ignore them at least, to reduce the amount of changes?
> I.e. only do the frame.h change? Or am I missing something (sorry, I
> feel confused trying to read the diff, so it might be just me).
you miss something
this patch deals with 5 fields, 2 of these fields where pressent in
ffmpeg 2.2, 3 are new, accesses to them are organised together in git
for clarity and to reduce the diff to the fork.
Its neccessary to move the code that accesses the remaining 2 fields
out of the #if as otherwise they would not be set properly and we
would have regressions.
Luckly the 3 new fields seem not used by anything so this patch
in absence of further comments i might apply this patch to
master and release/2.3 in a few days. But iam not completely sure
myself yet which way is better ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel