On 31 Jan 2003, Miguel Freitas wrote:
> On Thu, 2003-01-30 at 22:09, Bill Fink wrote:
> > I first tried:
> > http://www.bernclare.com/movie/mvcdsmpl.mpg
> > First off, I had the impression that this would be embedded in the
> > web page but it actually opened a new window.
> there are two ways xine-plugin can be called from mozilla: embedded or
> not. embedded happens when you have a page using the embed tag:
> <embed src="mvcdmpl.mpg" width=... height=..... >
> this will be presented on web page, using the specified width/height and
> mime type.
> the other way is what you tried, pasting the stream url directly into
> mozilla. this is the non-embedded mode and therefore it opens it's own
> window (not the best solution, read below)
Well I just clicked on the link on the web page, but I get what you
are saying, namely that the referenced URL was the actual MPEG clip,
and not a web page using the embed tag.
> > If I used the X in
> > the right corner of this window to close it, it closed the entire
> > mozilla application. I found out I needed to use the Back button
> > to safely close the video window (which then disappeared on its own).
> sure. this problem is documented on source and TODO file.
> in fact, i see no reason to reimplement a frontend here. so my idea is
> that non-embedded streams should just open a helper application (either
> xine-ui or gxine).
And hopefully reuses any existing instance of xine, rather than
spawning a new xine for each URL.
> > The MPEG clip played (both video and audio) but in fits and starts.
> > Is there any way (configuration option) to increase the amount of
> > buffering it does before it starts playing to try and minimize this
> > (gxine has the same issue)?
> currently no. Thibaut did some experiments with net control code so he
> can probably give a better comment here.
> ideally the buffer should be about the double of the network jitter to
> have no pauses.
I think a configuration object would be a good idea, and more buffering
is probably generally better. It's probably very difficult to try and
estimate the necessary amount of buffering up front. The MacOS QuickTime
plugin for netscape had a configuration option to attempt to buffer the
entire video clip into memory (up to the limit of the browser cache size)
first before starting playing and this would be a really nice option to
also have for the xine mozilla plugin.
> > Also it didn't play the very end of the
> > clip (the "chicken" in "nobody calls me chicken" isn't played).
> no idea. we must investigate..
> > I then tried:
> > http://xinehq.de/images/gallery/xine_about.avi
> > This actually played fine, which was better than the gxine 0.2.1
> > plugin which just got stuck at 0% buffering the last time I tried
> > it. But it brought up a possible issue with the previous MPEG clip.
> > I noticed that the AVI clip actually updated the progress bar on the
> > bottom of the main mozilla window, whereas the MPEG clip had not.
> funny you mention it...
> this is exactly the intended behaviour i added to xine-plugin. first it
> tries to open the url directly from libxine. this works for mpg but
> fails for avi, because http is not seekable. in case of error, it will
> ask mozilla to download the stream and hand it to plugin as a local
> file, so this is why you see the progress bar going.
Hmmm, so could _this_ be used to save a directly unplayable stream
(such as QuickTime movie trailers on my PPC system) to disk at this
point, sort of an auto-wget fallback feature (based on a config
setting of course)?
> as local file (in mozilla cache) libxine can open the avi and play it. i
> guess gxine code isn't that smart... ;)
> > All in all, this is great progress on mozilla xine plugin support
> > (both xine-plugin and gxine are now semi usable for web based media
> > playing and neither crashes mozilla any more (knocking on wood as
> > I'm typing this)).
> and you haven't tested neither the embeded mode or the reference streams
> support (asx/ram)! ;)
Which I guess wouldn't work on my PPC system. :-(
Actually I could play RealPlayer videos using the RealPlayer8 plugin.
Which now brings up another question. If two plugins, such as xine
and real, both register to handle the same type of file, which takes
precedence, and how do you set that (in my case I'd probably want
the real plugin to take precedence).
Argghh. I just checked and they did conflict, and I couldn't watch
RealPlayer movie trailers anymore without first removing the xine
plugin. So I guess I need a facility to tell the xine plugin not
to register itself for specified types of files (for now I guess
I can just hack the source code to remove rpm files from the list
since that's the only file type that actually conflicts).