On Tue, 10 Oct 2017 13:25:53 -0300 James Almer <jamr...@gmail.com> wrote:
> On 10/10/2017 1:01 PM, wm4 wrote: > > On Tue, 10 Oct 2017 12:45:59 -0300 > > James Almer <jamr...@gmail.com> wrote: > > > >> On 10/9/2017 8:17 AM, wm4 wrote: > >>> On Sun, 8 Oct 2017 13:53:13 +0200 > >>> Michael Niedermayer <mich...@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 <mich...@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... _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
