On 10/10/2017 1:40 PM, wm4 wrote: > 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.
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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
