[FFmpeg-devel] [PATCH 00/72] Implement support for Vulkan multiplane images and video decoding

[Lynne]

Feb 17, 2023, 16:45 by michael at niedermayer.cc:

> On Fri, Feb 17, 2023 at 12:52:21PM +0100, Lynne wrote:
>
>> Feb 17, 2023, 12:05 by kierank at obe.tv:
>>
>> > On Fri, 17 Feb 2023 at 09:09, Jean-Baptiste Kempf <jb at videolan.org> wrote:
>> >
>> >> Hello,
>> >>
>> >> On Fri, 17 Feb 2023, at 04:43, Lynne wrote:
>> >> > This small patchset mostly rewrites Vulkan to enable using multiplane
>> >> images,
>> >>
>> >> This is not small. We're talking about thousands of lines of code;
>> >>
>> >> And this changes numerous h264 and hevc headers, and adds callback to the
>> >> make AVHWAccel.
>> >>
>> >> And that is besides the full rewrite of some Vulkan files...
>> >>
>> >> This will take a long time to review.
>> >>
>> >
>> > I agree.
>> >
>>
>> The codec changes are simple and separate, so it's not that bad to read.
>> There's no more than a 100 lines or so added to the H264 parser.
>> The 72 patch figure may be scary, but that's because I didn't want to
>> squash my vulkan changes behind large rewrite commits. Otherwise,
>> this would be a 30-commit patchset.
>>
>
> some of these patches are very simple, yes. Others probably not (i only looked at
> the first few)
> That said i was never a friend of large last minute patch-sets before releases.
> I think the real deciding factor is the communities opinion and
> 3 Developers already are against this going in before the branching. So
> unless theres a shift in oppinion i think there are more people for applying
> this after branching release/6.0 than before.
>
> Is it an issue if its only in 6.1 in 6months ?
>

It's quite a long ways away, and this is by far the most complete
implementation of the spec which everyone is testing against.
This is the first vendor-independent, OS-independent and
hardware-independent video decoding API, and a lot of important
users like browsers and media players want to use it.
Not having it in this release would mean that all those users will
use Gstreamer instead, or nothing at all, instead choosing
proprietary libraries.

6.0 will still have at least a few days of testing after tagging, which
is enough to discover and fix major issues, if they're found.
A single dev so far has really suggested leaving it out of 6.0,
with a few others just saying that it'll take time to review,
but I think reviews are done by looking at code rather than
speculating, and at least one person has said they'll be able to
look at it tomorrow.