[FFmpeg-devel] FFmpeg 3.2

Michael Niedermayer michael at niedermayer.cc
Mon Oct 17 17:32:52 EEST 2016


On Mon, Oct 17, 2016 at 04:12:26PM +0200, Hendrik Leppkes wrote:
> On Mon, Oct 17, 2016 at 3:47 PM, 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 documentation is hardly very enlightining on any level. Which
> time_base does it refer to, even? AVFrames can come from various
> sources, and there is various time_bases involved.

AVFrame was in libavcodec, there was just one timebase in libavcodec
when AVFrame was moved to libavutil the ambiguity of "what timebase"
was introduced


> Or why does it not
> document that its basically unused for decoding, and only used for
> encoding and filtering?
> Not to mention that the field was 99% of the time unset during
> decoding, and when it was set (by like 2 video decoders that didnt
> know any better), it was actually using the pkt timebase (ie. a clone
> of pkt_pts).

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161017/0446daaa/attachment.sig>


More information about the ffmpeg-devel mailing list