[vlc-devel] [PATCHv3 03/12] libvlc: add renderer module list option

[Steve Lhomme]

On Thu, Mar 31, 2016 at 2:20 PM, Steve Lhomme <robux4 at gmail.com> wrote:
> On Thu, Mar 31, 2016 at 12:43 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
>> Le 2016-03-31 10:18, Steve Lhomme a écrit :
>>>
>>> On Wed, Mar 30, 2016 at 8:26 PM, Rémi Denis-Courmont <remi at remlab.net>
>>> wrote:
>>>>
>>>> Bad idea IMHO. It will probably break VLM and stream output unexpectedly.
>>>
>>>
>>> It seems using VLM with a renderer output (push model vs pull model)
>>> doesn't make much sense.
>>
>>
>> That's the whole point.
>>
>> I don't see why you need yet another output type anyway. AFAICT, either
>> existing output paradigms (es_out, aout, vout and/or sout) are enough for
>> your use case, or you probably shouldn't be using the input thread at all.
>
> In the case of Chromecast (dunno about the others) it's because the
> receiver is a renderer that has no control of its own. It needs to be
> controlled by the API. That's what we do in VLC, since it's the UI
> that controls the playback on a particular output. I don't know VLM
> enough so I don't know if it's possible to launch it while playing a
> file and issuing remote commands that way.

Another reason is that we need to be able to decide the "sout" string
to use for each file of the playlist we're trying to play as the
device only supports some codec and containers. The "input-prepare"
string callback was refused, partly because it could be called in
chains and in any order and thus possibly breaking badly. With this
renderer we have a single one that is designed just for that.

>> --
>> Rémi Denis-Courmont
>> http://www.remlab.net/
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel