[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VideoPlayer.app - Some questions and a POD

From: Raffael Herzog
Subject: Re: VideoPlayer.app - Some questions and a POD
Date: Wed, 16 Jul 2003 17:26:00 +0200

Hi Frederic,

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"];
 [stream play];

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

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 Mplayer.app).

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
MacOSX's AppKit...

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

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 use?).

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]