[FFmpeg-devel] FFmpeg 3.2

[wm4]

On Mon, 17 Oct 2016 15:47:06 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Mon, Oct 17, 2016 at 12:01:56PM +0200, wm4 wrote:
> > On Mon, 17 Oct 2016 04:24:40 +0200
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> >   
> > > On Sun, Oct 16, 2016 at 06:01:54PM -0400, Helmut K. C. Tessarek wrote:  
> > > > On 2016-09-27 09:30, Michael Niedermayer wrote:    
> > > > > Its long since FFmpeg 3.1, so its time to make 3.2
> > > > > ill branch release/3.2 off master and make 3.2 in maybe about a week or
> > > > > 2 unless something delays it    
> > > > 
> > > > What happened to 3.2?    
> > > 
> > > the AVFrame.pts field has been changed in master redefining ABI/API
> > > without soname bump.
> > > 
> > > this complicates the 3.2 release.
> > > ATM we have 3.0 and 3.1 releases with the same sonames as git master
> > > but they are not fully compatible due to the AVFrame.pts change
> > > (on top of that i was a bit more busy with random stuff than i
> > >  expected)
> > > 
> > > the obvious solution is to bump major version of all libs. (this is
> > > not wanted i belive though)
> > > 
> > > the alternative is to remove the (useless) use of AVFrame.pts from
> > > 3.0 and 3.1 and make new releases
> > > then document in release notes that the 3.2 release cannot co-exist
> > > with 3.0 or 3.1 prior to the last release and assume no other
> > > application use AVFrame.pts
> > > 
> > > Ill look at making the 3.0 and 3.1 release without AVFrame.pts use in
> > > ffmpeg ASAP. These wont do any harm either way
> > > 
> > > Maybe someone can write the release notes ?
> > > 
> > > [...]
> > >   
> > 
> > The change was backwards-compatible, as nobody should have used the pts
> > field for decoding before.  
> 
> The field was a normal public and documented field
> Documented in our public doxygen for 3.0 and 3.1
> http://ffmpeg.org/doxygen/3.0/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> http://ffmpeg.org/doxygen/3.1/structAVFrame.html#a0452833e3ab6ddd7acbf82817a7818a4
> 
> The AVFrame.pts doxy links to examples, which use the field:
> http://ffmpeg.org/doxygen/3.0/demuxing_decoding_8c-example.html#a41
> http://ffmpeg.org/doxygen/3.1/demuxing_decoding_8c-example.html#a41
> 
> 
> > The fact that ffmpeg.c couldn't use its own
> > API correctly is not of matter.  
> 
> 
> [...]

This doesn't change anything about what I said. The example merely
dumps some garbage values.

How do you expect downstream code to break with the change, and which
actual downstream projects do break?