[FFmpeg-devel] [PATCH 0/1] ffmpeg: Switch cuvid to generic hwaccel

[Timo Rothenpieler]

Am 17.06.2017 um 21:35 schrieb Hendrik Leppkes:
> On Sat, Jun 17, 2017 at 9:29 PM, Timo Rothenpieler
> <timo at rothenpieler.org> wrote:
>> Am 17.06.2017 um 00:11 schrieb Philip Langdale:
>>>
>>> On Fri, 16 Jun 2017 21:53:22 +0200
>>> wm4 <nfxjfg at googlemail.com> wrote:
>>>
>>>> On Fri, 16 Jun 2017 20:31:14 +0200
>>>> Timo Rothenpieler <timo at rothenpieler.org> wrote:
>>>>
>>>>> Am 16.06.2017 um 16:41 schrieb Philip Langdale:
>>>>>>
>>>>>> This is mechanically simple, but does the fact that additional
>>>>>> command line arguments have to be used to get the same results
>>>>>> count as a compatibility break? Do we need to fix that before we
>>>>>> can actually make this change?
>>>>>
>>>>>
>>>>> I'd consider that as a breaking change, even though things don't
>>>>> "break", it results in unexpected behavior that is not obvious.
>>>>
>>>>
>>>> Probably, but it's also slightly saner in general if you consider that
>>>> a user could add video filters. Currently, hwaccel filters and normal
>>>> filters are completely different beasts, so the user needs to be aware
>>>> of the difference, and select the appropriate mode. So depending on
>>>> whether you output hw surfaces by default, you'll break hw filters or
>>>> sw filters by default. Making sure sw filters work by default seems
>>>> like the better choice.
>>>>
>>>> But yes, maybe we could rename the hwaccel just so that users of the
>>>> old hwaccel become aware of the change. You could even keep the old
>>>> hwaccel name, and make it somehow override the -hwaccel_output_format
>>>> option and print a warning, in case you care enough for compatibility
>>>> in this case.
>>>
>>>
>>> We could use it as an opportunity to rename it to 'cuda' which is more
>>> accurate.
>>>
>>> Keeping the old specialised code for 'cuvid' would also ensure
>>> compatibility :-)
>>
>>
>> One thing to keep in mind is that cuvid is vastly different from other
>> hwaccels.
>> While for example for vaapi, specifying -hwaccel vaapi makes the h264
>> decoder use vaapi. But for cuvid, the h264_cuvid decoder always uses
>> hardware, and the -hwaccel cuvid flag is essentially used to switch its
>> output mode to cuda frames.
>> With the new approach, there is no apparent difference from using cuvid with
>> or without -hwaccel cuvid.
>> That situation would seem kinda weird and confusing to me.
>>
> 
> The situation right now is weird and confusing, specifically because
> -hwaccel cuvid is different from all the others.
> To rectify that, it should probably be changed to behave just like
> -hwaccel vaapi or similar
> 
> So basically, -hwaccel cuvid should instruct ffmpeg.c to use the
> cuvid-based decoders, without needing to manually specify them on top
> of that, and thats all it should do - ie. it behaves just like
> -hwaccel vaapi/dxva2, just with a different logic in the background.

That would indeed be ideal, but I'm not sure how easy realistic it is to 
achieve it.