[FFmpeg-devel] [PATCH 0/5] Cuvid/videotoolbox preparations
Thilo Borgmann
thilo.borgmann at mail.de
Fri Oct 27 21:46:03 EEST 2017
Am 27.10.17 um 19:00 schrieb James Almer:
> On 10/13/2017 1:59 PM, wm4 wrote:
>> These commits are required to merge Libav's cuvid hwaccel, and to
>> fix videotoolbox operation if frame threading is enabled.
>>
>> Anton Khirnov (4):
>> decode: avoid leaks on failure in ff_get_buffer()
>> decode: add a method for attaching lavc-internal data to frames
>> decode: add a mechanism for performing delayed processing on the
>> decoded frames
>> decode: add a per-frame private data for hwaccel use
>>
>> wm4 (1):
>> lavc/avrndec: remove AV_CODEC_CAP_DR1, as it's broken
>>
>> libavcodec/avrndec.c | 1 -
>> libavcodec/decode.c | 113 ++++++++++++++++++++++++++++++++++++++++++-
>> libavcodec/decode.h | 40 +++++++++++++++
>> libavcodec/h264dec.c | 5 +-
>> libavcodec/huffyuvdec.c | 3 +-
>> libavcodec/mpegutils.c | 4 +-
>> libavcodec/vp3.c | 3 +-
>> libavcodec/wrapped_avframe.c | 7 +++
>> 8 files changed, 167 insertions(+), 9 deletions(-)
>
> Can we please find a way to get this thing moving instead of keeping it
> blocked indefinitely? I'll eventually reach this point in the merge
> queue and i don't want to find myself stuck again because two devs can't
> find a common ground.
>
> We have dozens of devs, many knowledgeable enough in this subject to
> chime in and tip the scales. So far one dev is against it (Michael) and
> two in favor (wm4 and Thilo). This needs the attention of more people.
I'm not in favor of anything and never claimed to do so. Instead, I already said
that I am not as familiar with that part of the code to dive into the discussion.
I just offered to do the codemonkey on whatever shall finally be implemented -
for the case it actually stalls for nobody willing to do so.
> If a vote is needed then so be it, but for fucks sake, we really need to
> find solutions for this kind of discussions in a more timely manner.
Yes.
-Thilo
More information about the ffmpeg-devel
mailing list