Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jason Tackaberry <tack <at> urandom.ca>
Subject: Re: 1.2 no longer exporting _x_vo_new_port and _x_ao_new_port
Newsgroups: gmane.comp.video.xine.devel
Date: Sunday 9th March 2008 14:45:09 UTC (over 9 years ago)
Hi,

Last May, I started this thread (see my most recent email quoted
entirely below for context).  I see that _x_vo_new_port is still not
exported.  I realize these are internal calls, but I can only reiterate
what I said last year: their existence lets us extend Xine in ways that
might not be anticipated by xinelib developers.

If an alternative approach could be suggested to achieve the same thing
(see explanation of our usage below), I'd be keen to hear it.  But I
suspect just adding _x_[av]o_new_port back in would be the path of least
resistance.

Thanks.

On Fri, 2007-05-11 at 08:13 -0400, Jason Tackaberry wrote:
> Diego 'Flameeyes' Pettenò wrote:
> > Are you sure? As far as I can see, these two functions should be used
> > internally only; the public way to handle this should be
> > xine_open_audio_driver and xine_open_video_driver.
> 
> The problem with xine_open_*_driver is that they (IIRC) spawn new
> threads.  In Freevo, we have created a custom vo driver that acts as a
> passthrough to a real vo driver (such as Xv).  Our vo driver does
> certain things we need (such as alpha blend a RGB32 OSD buffer or send
> the frame to some shmem location to be handled by another process), and
> then ultimately mhands the frame off to one of xine's actual vo drivers.
> 
> So while we call xine_open_video_driver on our custom vo driver, we
> don't want to call xine_open_video_driver to create the final vo (Xv in
> this example).  We call _x_load_video_output_plugin instead.  (Note that
> this function still exists in libxine.so.)  _x_vo_new_port is used to
> get the vo port from a driver created with _x_load_video_output_plugin.
> 
> I do realize these are internal functions, but their existence lets us
> extend Xine in ways that might not be anticipated by the xinelib
> developers.  I'm happy to handle API changes in these functions, but I
> do hope they don't disappear altogether.  Though I suppose making some
> of them public functions would be a fair compromise.
> 
> Cheers,
> Jason.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel
 
CD: 17ms