[FFmpeg-devel] FFmpeg 3.4

[James Almer]

On 10/10/2017 1:40 PM, wm4 wrote:
> On Tue, 10 Oct 2017 13:25:53 -0300
> James Almer <jamrial at gmail.com> wrote:
> 
>> 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
>> suggested.
>> 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.
> 
> mpv always supports the latest FFmpeg release (though not the latest
> Libav release, as these are way too old). I guess that changes now.

It would change once this cuvid stuff is applied and not before, in any
case, which given the above checklist could take a bit. And by then it
will be ready for 4.0

> 
>> 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.
> 
> Fine, if there'll be a new release within 3 months...

Doubt it will take more than three or four months.