[vlc-devel] [PATCH] Add a libvlc_set_video_output function

[Hugo Beauzée-Luyssen]

On Thu, Feb 13, 2014 at 12:06 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le mercredi 12 février 2014, 23:10:10 Hugo Beauzée-Luyssen a écrit :
>> I beg to differ since there's no way to do what I want right now
>
> Your patch does not work either since it makes unwarranted assumptions about
> the dummy vout...
>
>> (without rendering to a hidden widget, or into some ephemeral buffers)
>> It might be seen as a hack, though using vmem as a way to disable any
>> kind of rendering to a window/widget also is.
>
> ...unlike vmem. Yes, using vmem to discard the video signal is a hack and I
> would hate it in my code. Likewise, setting vout to dummy is a hack and I
> would dislike it in LibVLC code.
>

Looks to me like vout is built in the same way vmem is, so I'm not
sure what you mean by "unwarranted assumptions"

>> Yes it does things unrelated to a media player, that's because I'm not
>> writing a media player.
>
> The libvlc_media_player_t is not meant to snapshot a video. It is meant to
> play it, and optionally generate snapshots as it plays.
>
>> Quoting https://wiki.videolan.org/LibVLC/,
>> «The libVLC (VLC SDK) media framework can be embedded into an
>> application to get multimedia capabilities.». Those capabilities being
>> getting some video informations such as width/height/fps, grabbing a
>> snapshot, among other things.
>
> It is a media PLAYBACK framework so far. If you want to extend it cleanly, you
> can, but I fail to see how this fits with the media player part.
>

This time I'll quote http://www.videolan.org/vlc/libvlc.html  and
argue that what I want to do still fits inside the "wide range of
multimedia applications using the VLC features."

>> > No. LibVLC is enough bloated and confusing as it is, I do not want that
>> > kind of hacks. There has to be a sanity limit somewhere and this would be
>> > an absolutely terrible precedent.
>>
>> So what about the alternative from the original propose? Providing a
>> way to "disable" video output (so actually using the dummy one
>> instead)
>
> I fail to see how disabling video explicitly would be a hack. Selecting a
> video output instead of disabling video is a hack, but that is quite different
> in terms of API design.
>

To clarify, by "disabling video" you mean --no-video or equivalent right?

Regards,

-- 
Hugo Beauzée-Luyssen
mail: hugo at beauzee.fr
skype: beauze.h