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. 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
