[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