[FFmpeg-devel] FFmpeg 3.4

[wm4]

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.

> 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...