[vlc-devel] libvlc status?

[Tanguy Krotoff]

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...

>  > + getting the volume should of course not depend from a
>  > libvlc_media_instance_t
>
>  Of course it should depend on a media_instance.

oupss you are right, I though about the general volume

>  > * libvlc_media_instance_set_drawable()
>  > does not work, I have to use libvlc_video_set_parent()
>
>  Works here. What is your system?

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...

>  > * no libvlc.lib and libvlc.pdb
>  > There is no SDK, so I load the libvlc.dll at runtime
>  > I already sent an email about this to vlc-devel
>  > code is here if it can help somebody:
>  > http://smplayer.svn.sourceforge.net/viewvc/smplayer/experimental/phonon-vlc/vlc_symbols.h?view=markup
>  > problem is that without the .pdb file I cannot go debug inside
>  > libvlc code.
>
>  That's windows, I don't know.

Idea is to ease the use libvlc for developers.
Compiling vlc under Windows is difficult. To use libvlc, Windows
developers need vlc*.dll, vlc*.lib and vlc*.pdb.
Currently, only the vlc*.dll are present inside win-snapshots. Idea is
to modify the buildbot scripts (or create another target) and add to
the snapshots, the vlc*.lib and the vlc*.pdb so you get a proper SDK
under Windows.
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"

>  > * There is no event like libvlc_BufferStatus with a %
>  > this is really minor
>
>  I don't see what would be the use of that, could you elaborate?
>  libvlc_MediaInstancePositionChanged is what you need I think.

Forget about it, I don't know why I need this :p

>  > * 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

>  > 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.

>  > 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.

In practice I have 100 lines of code just for event registration cf
connectToAllVLCEvents()
http://smplayer.svn.sourceforge.net/viewvc/smplayer/experimental/phonon-vlc/vlcmediaobject.cpp?view=markup

+ I found some strange things too:
* there is no libvlc_media_list_player_event_manager()
* libvlc_media_discoverer_event_manager() +
libvlc_media_list_view_event_manager() don't take a libvlc_exception_t
param
--> API is not symmetric

Of course code is here so it won't change. Still, is all this really
necessary compare to a simple:
callback(mid, event) {
  switch(event) {
  case i_want_this_event:
    do_my_things()
  }
}
??
What is the added value?
it's a "register the events I want via event_attach" vs "deal only
with the events I want via switch()"
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 have a concern about merging media_descriptor and media_instance. I
>  am not sure the separation is that confusing, especially when using
>  bindings with object oriented languages. Also, the media instance
>  allow you to register the event you like once, set up the playing
>  environment once, and plays all the media descriptor you want in it.
>  Which is I think the more practical cases (From the vlc_app rewrite).

I agree with that.

>  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.

>  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?

>  That's nice to have an external point of view.

nice to chat rather than fighting libvlc.h alone :p

-- 
Tanguy Krotoff <tkrotoff at gmail.com>
+33 6 68 42 70 24