Difference between revisions of "Talk:MediaControlAPI"

From VideoLAN Wiki
Jump to navigation Jump to search
Line 5: Line 5:
 
The generic part is actually very worrying to me. I think we anyway should ''definitely'' have "VLC" in the symbol names, to avoid any clashes. "mediacontrol" is far too generic to me.
 
The generic part is actually very worrying to me. I think we anyway should ''definitely'' have "VLC" in the symbol names, to avoid any clashes. "mediacontrol" is far too generic to me.
  
[[Littlejohn]] At the moment the opportunity an external developer has to use this interface is very little. There are coding issues making the interface usable only within the VLC tree. See [[http://bugzilla.videolan.org/cgi-bin/bugzilla/show_bug.cgi?id=2189 this] bug I filed.
+
[[Littlejohn]] At the moment the opportunity an external developer has to use this interface is very little. There are coding issues making the interface usable only within the VLC tree. See [http://bugzilla.videolan.org/cgi-bin/bugzilla/show_bug.cgi?id=2189 this] bug I filed.
  
 
== API Design ==
 
== API Design ==

Revision as of 12:12, 13 December 2005

Discussion about API

OlivierAubert And isn't that too VLC-specific ? The rest of the API (minus suggested VLM, which is clearly identified) is fairly generic. We could move vlc specific features in an 'extra' module.

The generic part is actually very worrying to me. I think we anyway should definitely have "VLC" in the symbol names, to avoid any clashes. "mediacontrol" is far too generic to me.

Littlejohn At the moment the opportunity an external developer has to use this interface is very little. There are coding issues making the interface usable only within the VLC tree. See this bug I filed.

API Design

OlivierAubert For me, the mediacontrol API is a generic API, independent from the player. If the player does not support some feature (like position parameter to pause and resume), then the API should try its best to have a coherent behaviour.

Littlejohn Well, I think even if the interface is generic it has to call functions contained in the player. For example the position parameter for pause and resume should be implemented in the player and then called by the mediacontrol interface. In this way we have to opportunity to enrich the player and ease maintainance of the interface (otherwise features in the interface could overlap with those in the player or changes in the player could break the interface).

Stream Information

  • mediacontrol_get_stream_information Return synthetized information (position, url, status), so that applications can quickly get it (Advene for instance calls this method every 100ms)
  • mediacontrol_get_video_information Return misc. information about the video (aspect ratio, dimensions, bitrate, codec, author, etc). The output could be transmitted in some generic format (XML?)

Zorglub: I'm not too keen on introducing some XML or stuff like that in the API. IMHO, information should be returned in structured programmatic way. The caller can then generate XML if it wants too. I also think we should integrate these, probably using the Stream and Media Information facility. This needs some polishing

Playlist

OlivierAubert Could be transformed into a Playlist object (returned by MediaControl.playlist), that would feature the corresponding methods: add, clear, next, prev, play, sort...


Littlejohn This is ok for me. Maybe we could apply this abstraction to other parts of the interface, ie having a Stream object and so on.

Video