[vlc-devel] libvlc status?

[Pierre d'Herbemont]

On Mar 26, 2008, at 5:57 PM, Tanguy Krotoff wrote:
> On Wed, Mar 26, 2008 at 4:19 PM, Pierre d'Herbemont <pdherbemont at free.fr 
> > wrote:
>>> http://wiki.videolan.org/LibVLC_Media_List_Management -> does not
>>> compile
>>
>> Could you fix it?
>
> Yes, but I prefer another approach: creating a example1.c inside the
> unit test system and then from the wiki put a link.
> Otherwise code examples will be always broken. If I correct it, I
> guess somebody else will have to do it again in 6 months or so...

Cool. I hope I'll see a patch soon ;)

> libvlc_media_instance_set_drawable() opens me another window
> I use Windows XP SP2
> I will try my VLC Phonon backend under Linux to see...

This is tricky. The drawable really depends on the vout used. I have  
never used it on Windows, soI can't tell.

> This way, it is simple for Windows devs to use and debug libvlc:
> libvlc get more users/developers and less forum messages like: "I
> can't compile vlc under Windows".
>
> I have almost 1000 lines of code because of this... cf
> http://smplayer.svn.sourceforge.net/viewvc/smplayer/experimental/phonon-vlc/vlc_symbols.h?revision=1020&view=markup
> and others
>
> It's a matter of
> "ok, I want users to use my work and I make everything possible so
> that it is easy for them" vs "I don't care, I code for my own"

  Do you think you could provide that?

>
>>> * found it strange that qtvlc does not use libvlc + Qt4 is compiled
>>> statically, but this is another subject.. :p
>>
>> Don't get it. libvlc is only used by external application. That's why
>> it is so poor and untested.
>
> The traditional way to do it:
> - create a lib
> - call this lib from a gui
> qtvlc don't do this. Xine for example does this: libxine + xine-ui
> Well this is history now

Yeah, definitely. VLC was conceived a bit differently for reason that  
I don't know.

Basically there is a real libvlc.so, that vlc uses.

But basically libvlc.so is unusable for most applications, as vlc  
loads modules for interface.

(Here we are talking about libvlc-control.so)

>>> The libvlc API is quite confusing (ok this is only my opinion): a  
>>> lot
>>> of stuffs: media_list, media_list_player, media_list_view +
>>> depreceated API...
>>
>> Why is this confusing? Don't use the media_list stuff if you don't
>> need it.
>
> Of course. I mean the API is confusing because you have different way
> of doing things.
> Java style: only one way to do things
> That's why people don't like to read Perl code :p
> If you have several way to do things, following Murphy's law you will
> mix everything or take the wrong path -> BOOM!
> For the creator it is always obvious, for the user it is always  
> obscure.

No, there is one way to read a media and one way to read a media_list.  
The naming makes clearly understand this to me. (Once we'll have  
media_descriptor->media and media_instance->media_player).

Of course we could have some sort of libvlc_player that reads both a  
media and a media_list, but then you have a bunch of problem IMO.  
Reading a media and reading a media_list are two different problems.  
(Or we don't have solved it yet).

>>> About events, you have to attach each category to a callback. I  
>>> think
>>> a simple switch() from the user side would have been ok + one and  
>>> only
>>> one callback registration and all events going to the same callback.
>>
>> This is a nice idea.
>
> tsss. Philosophically it is wrong to put everything in one.

Yeah. Depends on what you want. But what you are asking is trivial to  
implement in your app. See after.

> I might be wrong on this one, I question myself about all this code.
> My goal is to do everything in few lines of code that is easy to read.

I got your points, but, after reflection. We could pretty trivially  
set a small wrapper for:

events[] = { ... }
for (i = 0; i < count; i++) {
	libvlc_media_instance_attach( p_mi, events[i], function, user_data );
}

Hence you attach your multiples events to "function". None has said  
you need one function for one event.

>> However to ease the understanding of the API, we may want to change
>> the media_descriptor name to media, and media_instance to
>> media_player. (That's the original name I wanted). Would that be less
>> confusing to you? Basically we would expose:
>>
>> - libvlc_media
>> - libvlc_media_player
>
> I didn't found the name media_descriptor confusing.

Well, that save a couple of characters too. So I guess it's welcomed.  
I'll sed the tree eventually.

>> And we need to find a way to properly integrate the old:
>> - libvlc_video_*
>> - libvlc_audio_ *
>
> libvlc_media_instance_audio_set_volume()
> libvlc_media_instance_audio_set_mute()
> libvlc_media_instance_video_set_drawable()
> libvlc_media_instance_video_set_fullscreen() -> 2 media_instance in  
> fullscreen?

Yeah, the name becomes a little bit long.

>
>> That's nice to have an external point of view.
>
> nice to chat rather than fighting libvlc.h alone :p

:)

Pierre.