[vlc-devel] [PATCH 01/11] decoder: use an object to create the decoder device

[Steve Lhomme]

On 2019-11-12 16:10, Rémi Denis-Courmont wrote:
> Le tiistaina 12. marraskuuta 2019, 8.50.21 EET Steve Lhomme a écrit :
>> On 2019-11-09 2:17, Rémi Denis-Courmont wrote:
>>> Le vendredi 8 novembre 2019, 16:12:42 EET Steve Lhomme a écrit :
>>>> On 2019-11-08 14:54, Rémi Denis-Courmont wrote:
>>>>> This works to create a device out of nothing, but presumably the goal is
>>>>> to create a device out of an encoder, not nothing. So this does in fact
>>>>> not work.
>>>>
>>>> No, the goal is to create an encoder out of a hardware device when
>>>> possible (unfortunately named "decoder device") and fall back to
>>>> software if it doesn't work.
>>>>
>>>   From an architectural point of view, both options are possible, and I
>>>   don't
>>>
>>> personally mind either way. But people use the (sout-transcode-)venc
>>> option, and it will get nasty if we need two agreeing options to select
>>> the encoder.
>> This doesn't change anything for the encoder. What it will change is
>> that the user can use --dec-dev and the encoder might use it if it can
>> (for example the QSV with D3D11 I did).
> 
> That's self-contradictory. If it changes nothing, then there's no interaction
> with dev-dec. And that's exactly the problem: now the user needs to set not
> one (venc) but two parameters to select the encoder. Currently, you can select
> QSV with just venc.

Maybe I wasn't clear enough. The QSV+D3D11 work I did is not in master 
because it's a dirty hack on the 3.0 codebase. There is currently no way 
for encoders to use hardware/GPU chromas/surfaces.

As for the options, there is still only one parameter to select the 
encoder and will always be. The --dec-dev is to force a certain hardware 
to be used. Encoders are free to use it or not. If they do use a decoder 
device, they will use the default one if --dec-dev is not set. Just like 
for normal playback.