[FFmpeg-devel] [RFC] FFmpeg 3.3

James Almer jamrial at gmail.com
Sat Apr 1 02:04:46 EEST 2017

On 3/31/2017 6:42 PM, James Almer wrote:
> On 3/31/2017 3:19 PM, Michael Niedermayer wrote:
>> On Fri, Mar 31, 2017 at 03:07:15PM +0200, Michael Niedermayer wrote:
>>> On Fri, Mar 31, 2017 at 01:31:51PM +0200, Michael Niedermayer wrote:
>>>> On Tue, Mar 14, 2017 at 12:29:52PM +0100, Michael Niedermayer wrote:
>>>>> Hi all
>>>>> are there any issues/tickets that block making 3.3 ?
>>>>> What about the spherical API size_t / uint32_t issue ?
>>>>> we can change it before the release but not after it
>>>> Ive finally branched release/3.3 off
>>>> feel free to backport anything
>>>> we also need release notes and all that stuff
>>>> once we all agree ill make 3.3 from it
>>> wm4 and ubitux stated on irc that now is a bad time to release due to
>>> the many recent merges
>>> so what shall we do ?
>>> should we release now (as in a few days) anyway ?
>>> should we wait till the merge rate slows down ? (no idea when that will
>>> be or in what condition the tree will then be)
>>> should we make a 3.3 release from 0bab78f7e729a76ea7a8cbec7f1de033c52494e8
>>> that is 3 weeks ago with backports ?
>> heres 0bab78f7e729a76ea7a8cbec7f1de033c52494e8 with commits backported
>> till master of today ommiting merges, anything changing version (cant be
>> backported due to conflicting version numbers)

Right, forgot the thing about version bumps.

I guess it's always possible to revert the commits that bumped library
version in release/3.3 after recutting it at the point i mentioned below.
Afaik the only one so far (outside of the post release bump) is one that
added two functions to spherical.h, so it should be harmless.

>> , most hwaccel stuff
>> (as likely related to merges), most cherry picks from libav and
>> anything that didnt apply / depended on ommited commits
>> https://github.com/michaelni/FFmpeg/tree/alternative-3.3
>> fate of course passes
>> do people prefer this over what is in release/3.3 ?
> IMO, this is not ideal. It will make the release/3.3 branch wildly
> different than master (and libav master) at the alleged point where it
> branched out from it.
> Now, regarding merges, we're like 10 commits away from the massive
> bitstream reader batch, which is more or less the only thing committed
> to libav for a whole week. So how about we re-cut from master (should be
> a matter of merging master into release/3.3, which will be
> straight-forward as nothing has been cherry-picked) once we have reached
> that exact point?.
> Give Google and Kierank a couple days to make sure h264 fuzzing didn't
> find anything outstanding, and go ahead with tagging the release.
> However, if the merges really put the tree in an unstable state, as it's
> apparently been argued, then i guess what you suggested above is better
> than waiting another month to release 3.3.

More information about the ffmpeg-devel mailing list