Re: VideoPlayer.app - Some questions and a POD

[Raffael Herzog]

Hi Frederic,

On 2003-07-15 23:55:18 +0200 Frederic De Jaeger <dejaeger@free.fr> wrote:

> I haven't follow all the previous discussion.  I may say silly
> things.

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

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,
  Raffi

--
 The difference between theory and practice is that in theory, there is
                no difference, but in practice, there is.

Raffael Herzog - herzog@raffael.ch - http://www.raffael.ch - ICQ #67961355