[FFmpeg-devel] FFmpeg 3.4

James Almer jamrial at gmail.com
Tue Oct 10 19:25:53 EEST 2017

On 10/10/2017 1:01 PM, wm4 wrote:
> On Tue, 10 Oct 2017 12:45:59 -0300
> James Almer <jamrial at gmail.com> wrote:
>> On 10/9/2017 8:17 AM, wm4 wrote:
>>> On Sun, 8 Oct 2017 13:53:13 +0200
>>> Michael Niedermayer <michael at niedermayer.cc> wrote:
>>>> On Sat, Oct 07, 2017 at 12:06:23AM +0200, wm4 wrote:  
>>>>> On Fri, 6 Oct 2017 16:53:17 +0200
>>>>> Michael Niedermayer <michael at niedermayer.cc> wrote:
>>>>>> Hi all
>>>>>> if there are no objections i will branch release/3.4 in the next days
>>>>>> and make the 3.4 release a few days after that
>>>>>> If people prefer a specific name, suggest one now, otherwise i will
>>>>>> pick a random one from past suggestions
>>>>>> If there are features you want in, please push them to
>>>>>> master before the release is branched
>>>>>> if there are bug fixes you want in please ensure they end in
>>>>>> release/3.4 (eiter via master before branching or backport after)    
>>>>> I want hardware decoding things in that release (frame pool info,
>>>>> cuvid). I vote the release until this has happened.    
>>>> Iam not sure what you mean by "I vote the release ..."
>>>> please clarify  
>>> "I vote to delay the release"  
>> Please, don't. It's been months since the last release, and I'm nearing
>> a point in the merges where a release needs to be branched out before i
>> can continue (Technically speaking, I'm at a commit I'd rather not have
>> in 3.4 to being with).
> But that's what I'm doing. I'm blocking the 3.4 release until cuvid is
> in, and until I get the hwframes setup API I always wanted. The latter
> is a patch that's pending in Libav.

I know you're trying to block it. And I'm asking you not to.

By trying to block the release of 3.4 until this thing can get in, which
as Timo said in another email it might not even be ready for prime time,
you're delaying the release, the merges, the major bump and all the
cleaning that comes with it for an unknown amount of time, probably months.

>> The concerns Michael explained about the opaque_ref wrapping in lavc
>> with draw_horiz_band apparently also apply to libav, so maybe talk with
>> the author of the commit you're cherry picking and see if there's a
>> different solution instead? And with Mark about the wrapped_avframe decoder.
> There's no feasible "different" solution. Yes, we can do the following:
> - get the draw_horiz_band callback called with a fixed opaque_ref field
> - fix the broken codecs that claim to support DR even though they don't
>   (I'd just add a BROKEN_DR capability)
> - fix wrapped_avframe decoder
> But I have no idea if michaelni would agree to that since he's not
> responding anymore.

I doubt he'll be against. He rarely is when a solution is found and
But even if he agreed, how long would this take? This stuff is not even
in a libav release, and some things are not even in libav git master
either as you mentioned above! Why is it so necessary to be part of 3.4,
in detriment of everything else i mentioned? I mean, you don't even care
about releases, you use git master for mpv.

ffmpeg 4.0 would be released soon after new years, with the bump and a
lot of deprecated shit cleaned from the tree plus this cuvid stuff you
want. You are one of the few people that constantly complains about old
shit still in the tree, and one of the people that mentioned how glad
you were i resumed the merges. So please, don't try to be the reason
they get stalled again.

More information about the ffmpeg-devel mailing list