[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VideoPlayer.app - Some questions and a POD
Re: VideoPlayer.app - Some questions and a POD
Wed, 16 Jul 2003 17:26:00 +0200
On 2003-07-15 23:55:18 +0200 Frederic De Jaeger <address@hidden> wrote:
I haven't follow all the previous discussion. I may say silly
You didn't. But to let you all know what exactly I'm working on, here's a
short description of the current architecture:
VideoPlayer.app is based on Gorm. It has two subprojects:
- libVideoView provides an NSView that displays the movie. This library also
defines the protocols for talking to the engine (currently, these are
VideoEngine and VideoStream), provides some utilities for locating and loading
the engine, and some utility classes for implementing new engines.
- XineX11.engine is a dynamically loaded bundle, it implements VideoEngine and
VideoStream using libxine and libxine's X11 visual.
This is how you can play a movie with libVideoView:
// VideoView is assumed to be initialized and visible
[VideoView attachDefaultEngineToView: videoView];
// or: [VideoView attachEngineNamed: @"MyEngine"
// toView: videoView]
stream = [[videoView engine] streamWithMRL: @"file:/path/to/movie"];
This is still subject to change because everything's so terribly experimental
right now and constantly changing... :)
You should have a look at core/back/Source/x11/XGGLContext.m
In this file, I wrote a class (that could be reused). Its goal is to
attach an X-window to any NSView, provided it is not rotated from it's
OK, it seems like I have to live with this restriction (no scaling/rotating).
At least, your code showed me how I can check that the restrictions are met
and fail gracefully (hmmm... "fail gracefully" - an oxymoron? :)
I don't know how libxine works. But according to the screenshots, it
looks like the libxine doesn't have its own X-window.
That's one of the main reasons why I prefer Xine over Mplayer: libxine is just
an API and you're free to do with it whatever you want to do. It provides you
with direct access to all of Xine's functionallity without any NSTask/IPC
Maybe if you
use a subwindow, properly placed, just to display the movie, it would
solve the repaint bug, and, the synchronisation bug (just have
a separate X connection for libxine).
Didn't work. I tried your Subwindow code, with both a shared and a separate X
connection. I also tried to use no subwindow but a separate connection. The
only effect was that it took a bit longer until Xlib failed with "unexpected
async reply" at some point (or could this message also be caused by not having
an event loop for the new connection? - this is not only my first GNUstep
program, it's also my first X11 program). If I use NSTask for the Xine engine,
it should work, though. But if I think of all that programming and performance
overhead this would cause... ugly!
IMHO, it would make much more sense to insert those X(Un)LockDisplay() calls
into the backend. It doesn't cause much of a performance loss (if it does at
all), it's just some one-time work and a bit of complexity added to future
maintenance, but it would properly solve the problem at its root - maybe,
doing it properly would also solve the repaint bug, who knows...
Your code will most probably be used later, because Mplayer.engine is already
planned (I had a short mail discussion with Fabien Vallon, who did
By the way, having your own window probably enables the possibility to
use some X extensions, like XVideo (but I really don't know the
subject, maybe libxine already do the job)
In my current implementation libxine is already using whatever driver you tell
it to use (it's XV on the screenshots).
And finally, doing all this dirty stuff, you are not far away to have
implemented the backend part of the NSMovie and NSMovieView, from
I took a short look at the API. I think it's doable, but it won't be easy,
because it's done quite differently to what Xine and Mplayer do. I think, I'll
stick with the current architecture of libVideoView and when it's working, me
or someone else could write a wrapper to implement NSMovie and NSMovieView.
libVideoView will probably allow to switch the engine whenever you like,
because Xine and Mplayer both have their strengths and weaknesses depending on
what exactly you're playing (Xine is better for long movies and DVDs, Mplayer
is better for playing M$ streams). This is why I think that it makes sense to
stick with the current architecture and wrapping it later into NSMovie and
It would be great, if this is compatible with the licence of your code
of course, that you write a bundle for the X backend that contains
all your code, in such way that the gui can trivially use it to
implement the two previous classes.
Yes, when it's working, we can think about incorporating it into the backend,
implement NSMovie, whatever. Licencing is OK.
BTW, I'll probably soon move to sf or something (recommendations about what to
Comments, critics and tips are always welcome... :)
cu & thanks,
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.
Raffael Herzog - address@hidden - http://www.raffael.ch - ICQ #67961355