On Mon, Oct 17, 2016 at 04:12:26PM +0200, Hendrik Leppkes wrote: > On Mon, Oct 17, 2016 at 3:47 PM, Michael Niedermayer > <mich...@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 <mich...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
