<html><head></head><body>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.<br><br><div class="gmail_quote">Le 13 novembre 2019 09:05:15 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 2019-11-12 16:10, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le tiistaina 12. marraskuuta 2019, 8.50.21 EET Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 2019-11-09 2:17, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Le vendredi 8 novembre 2019, 16:12:42 EET Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">On 2019-11-08 14:54, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;">This works to create a device out of nothing, but presumably the goal is<br>to create a device out of an encoder, not nothing. So this does in fact<br>not work.<br></blockquote> No, the goal is to create an encoder out of a hardware device when<br> possible (unfortunately named "decoder device") and fall back to<br> software if it doesn't work.<br><br></blockquote>   From an architectural point of view, both options are possible, and I<br>   don't<br><br> personally mind either way. But people use the (sout-transcode-)venc<br> option, and it will get nasty if we need two agreeing options to select<br> the encoder.<br></blockquote>This doesn't change anything for the encoder. What it will change is<br>that the user can use --dec-dev and the encoder might use it if it can<br>(for example the QSV with D3D11 I did).<br></blockquote>That's self-contradictory. If it changes nothing, then there's no interaction<br>with dev-dec. And that's exactly the problem: now the user needs to set not<br>one (venc) but two parameters to select the encoder. Currently, you can select<br>QSV with just venc.<br></blockquote><br>Maybe I wasn't clear enough. The QSV+D3D11 work I did is not in master <br>because it's a dirty hack on the 3.0 codebase. There is currently no way <br>for encoders to use hardware/GPU chromas/surfaces.<br><br>As for the options, there is still only one parameter to select the <br>encoder and will always be. The --dec-dev is to force a certain hardware <br>to be used. Encoders are free to use it or not. If they do use a decoder <br>device, they will use the default one if --dec-dev is not set. Just like <br>for normal playback.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>