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

Steve Lhomme robux4 at ycbcr.xyz
Wed Nov 13 13:24:59 CET 2019


On 2019-11-13 12:14, Rémi Denis-Courmont wrote:
> That won't work. Encoders cannot just use the default decoder device. 
> Typically, they can only use device of a single given type. That's 
> exactly the problem.

Just like *every* other decoder device user, the encoder has to check 
the "dec_device->type" matches what it can handle or fallback to 
software (or refuse encoding).

> Le 13 novembre 2019 09:05:15 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> 
> a écrit :
> 
>     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.
>     ------------------------------------------------------------------------
>     vlc-devel mailing list
>     To unsubscribe or modify your subscription options:
>     https://mailman.videolan.org/listinfo/vlc-devel
> 
> 
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser 
> ma brièveté.
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
> 


More information about the vlc-devel mailing list