Thanks for the comments. Based on the comments below the following things have
been addressed and are fixed in CVS
1. Media Files without extensions
Actually, the problem was that the correct URL was not being passed to
mplayer. There was a problem with scanning the embed tag that caused the
first item to be skipped. In this case it was "src" which is the URL where
the media was coming from. Don't know how we have had this error for so long.
Also, fixed it where in WriteReady the url was being overwritten. Still need
to test this more fully before a release.
2. I think the miniskin in the noembed=1 case is kinda weird. I would NOT
recommend having these to options in the config file
# bad example
this could lead to the skin floating around in an undetermined spot.
So install the code from CVS and see if these problems are fixed for you. In
my testing I found that it worked pretty good. But now I have to retest
On Monday 17 February 2003 12:03 pm, Benno Senoner wrote:
> Hi (I'm new)
> first kudos for this very nice plugin.
> I'd like to point out some problems I encountered so that they
> can be hopefully sorted out soon.
> I'm using RedHat 8.0, MPlayer 0.90rc4 and mplayerplug-in 0.40 (tarball).
> 1) problems with windows media files without extension:
> For example I tested the plugin on an italian webradio that uses Windows
> Media (for audio streaming but they offer video streams too) and it did not
> work because the streams do not have an file extension.
> The page that contains the stream:
> The embedded audio stream contained in the page:
> if I pass this url to mplayer I can hear the audio stream without problems,
> but the mplayerplug-in ignores that stream problably because the lack of a
> file extension.
> looking at the plugin's source I see this definition in
> Source/mplayerplug-in.c within the function NPP_GetMIMEDescription()
> "video/x-ms-asf-plugin:asf,asx:Windows Media;"
> I'm not an expert in mime types etc, but I guess that the presence of
> asf,asx in this line prevents the plugin to call mplayer when the
> "video/x-ms-asf-plugin" mime type is found.
> So I guess you should change the plugin's behaviour to always call mplayer
> regardless of an asf,asx extension being present.
> Is this possible ?
> 2) problems with the mini skin disappearing when using embed=yes
> For example if you go to http://www.zdf.de , select ZDF Mediathek (on the left
> menu) select windows media, and then click on play, the video appears,
> the navbar.
> Only play/stop works, seeking via navbar does not seem
> supported while in streaming mode but this seems to be an mplayer issue.
> The strange thing is that if you click on the navbar (within the timeseek
> bar) it disappears from the window.
> An additional issue with the mini theme is that it does IMHO offer too
> little visual control to the user for seeing what is currently going on
> with the stream.
> On the other hand if you do not select mini skin, mplayerplug-in does not
> show mplayer's GUI (eg default skin) while in embed=yes mode. This means
> that the user cannot figure out what's going on in case of problems with
> the audio/video stream (eg connection stalled etc).
> So I think one of the most comfortable way to run mplayerplug-in is to
> set embed=on and use-guy=yes so that the default mplayer skin appears.
> This is particularly useful when listening to webradio where no video
> window is present.
> Perhaps it would be even better to have a mini skin (that doesn't
> disappear) with a time indicator so that the user can see if the stream is
> advancing or is stalled.
> While testing I discovered an additional problem with mplayer freezing
> after playing a streaming WMV file (mms://.. ).
> This happens in both cases when mplayer is called from the commandline and
> when it is called through the plugin.
> For example try to play a WMV stream from zdf.de with embed=no,use-gui=yes
> The playback works ok, you can for example close gmplayer in the middle of
> the stream (by closing the video windows) causing it to exit in the correct
> manner. But if you wait until the video is finished then the gmplayer GUI
> freezes and you are unable to close the application (neither by trying to
> close the video windows, the GUI window).
> When you close the webpage that contains the video object then it closes
> gmplayer but this is probably due to a kill signal sent by mplayerplug-in.
> But as said this is an mplayer problem since it happens too when
> calling the player from the commandline (with the mms://.. video stream as
> Today I posted about this problem on the mplayer-users list, let's see
> what they say.
> PS: If you want me to perform more tests with mplayerplug-in, let me know
> I think once these small problems will go away, mplayerplug-in and mplayer
> will really improve the multimedia web experience on the Linux.
> Linux sul tuo Desktop
> This mail sent through http://www.gardena.net
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Mplayerplug-in-devel mailing list