[vlc-devel] VLC.framework Changes/Modifications

Enrique Osuna enrique.osuna at gmail.com
Tue Oct 9 01:14:51 CEST 2007


Yet another attempt.  This time I took some of your suggestions and advice
and implemented it.  See files for full framework and patches for each
individual file. Main thing to notice is that I changed up the directory
structure.  And the same notes as before apply (e.g. only compiles under
debug configurations) also a new note to add the included Makefile doesn't
compile -- I used straight xcode project for compilation.

Also, I had to do a quick hack to the core's media_descriptor struct.  I
added a p_user_data field so that I could store, from within Cocoa, a
pointer referencing back the VLCMedia object it's associated with.
Otherwise, we'd have to recreate that object every time we wanted to
manipulate a media_descriptor -- or we would have to maintain a local copy
of generated media descriptors.

With VLCMediaControl, I was trying to follow the MediaControlAPI
> Architecture ( http://wiki.videolan.org/MediaControlAPI ).  Although the
> class implementation doesn't actually use any of the mediacontrol APIs.  It
> does try to mimic the way it works.
>
>
> Ok. I don't really like the fact of being able to do the same thing using
> a different API. What about some shortcut in existing classes?
>

Not implemented in this rendition of changes.  But I will add to the TODO
list.

Your comment about MVC, I'm not sure if I quite understand.  I thought I was
> implementing the class in an MVC fashion, can you point out a clearer
> example so that it may help me out.
>
>
> I was a bit lost with the MediaControl thing.
>
> Tell me if I am wrong?
>
> Model is VLCMedia
> View is VLCVideoView
> Control is VLCMediaPlayer
>
> In libvlc we do have:
> Model libvlc_media_t
> View libvlc_drawable_t
> Control libvlc_media_instance_t
>

You're right.

My initial thoughts were to do that, however, I wanted to create a mechanism
> that allowed for other programmers to use this framework and use the
> VLCMediaPlayer instance for playback strictly.  I know there are a few
> projects out there ( e.g. centerstageproject.com) that have their own
> playlist manager if you will and would want to use VLC just as a playback
> engine versus a playlist manipulation one.
>
>
> True enough. Isn't
>
> [aMediaPlayer initWithMedia: aMedia];
> [aMediaPlayer setVideoView: aVideoView];
> [aMediaPlayer play];
>
> Simple enough?
>

Yeah it is.  But if we want to go that simplistic, wouldn't we just
integrate the VLCMediaPlayer's methods into VLCMedia it self?

[aMedia initWithURL:@"~/Movies/test.avi"];
[aMedia setVideoView:aVideoView];
[aMedia play]

> libvlc_media_instance_stop should be implemented in core.
>
> It should but what would it do?  Other than pausing the playback and
> setting it's state to STOPPED.
>
>
> it should STOP the input (close the vout and such...), not pause... Not a
> big deal though.
>

On TODO list.

> do we need all this classes?
>
> No, I don't think we need all the classes.  However, I wanted to try to
> stay true to your original implementation.
>
> We can get rid of things like VLCPlaylist.  I think the core
> implementation, such as Library, MediaList, MediaInstance and
> MediaDescriptors are a definite.
>
>
> Ok. I got your point. I was a bit septical about introducing too much
> complexity in the framework, but it seems to work fine. Yet we now need the
> VLCMediaListPlayer class.
>
> VLCMediaListPlayer would be a subclass of the VLCMediaPlayer;
>
> [aMediaListPlayer initWithMediaList: aMediaList];
> [aMediaListPlayer setVideoView: aVideoView];
> [aMediaPlayer play];
>

I know we talked about this the other night, but how much different would
this implementation be as compared to VLCMediaControl?  If I remember
correctly, VLCMediaListPlayer should just be a wrapper around the core's
implementation?

> I would suggest you to send (small) patches with your modification.
> I'll work on that this afternoon and resubmit.
>
> One of the major changes that I did make was a structural change to how
> the headers are stored in the framework.  Instead of VLC.framework/Headers/VLC/VLC*.h
> it's VLC.framework/Headers/VLC*.h
>
>
> I missed that one... Headers/VLC/*.h are the exported headers. Header in
> Headers/*.h are the private one. So I think this one is not valid.
>

Private headers are stored in Headers/Internal and public are stored in
Headers/Public.  Also, I need to fix the some of the private binding
categories.  The interfaces are declared in the same spot that they are
implemented.  We should implement a VLCInternal header file or something of
the sort.  We need to declare the interfaces (like [VLCMedia setLength]) but
implement them in a public place.

- Enrique
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071009/fbb77181/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: framework-update-media_descriptor-user_data-hack.patch
Type: application/octet-stream
Size: 2969 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071009/fbb77181/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Framework-Update-Patches.zip
Type: application/zip
Size: 51825 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071009/fbb77181/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VLC.framework.zip
Type: application/zip
Size: 136372 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071009/fbb77181/attachment-0001.zip>


More information about the vlc-devel mailing list