Hello, I'm moving over here the discussion on this thread: https://sourceforge.net/forum/forum.php?thread_id=1668761&forum_id=242727
Just for reference, a copy of the initial discussion is at the end of this post.
I tried to find a more detailed specification of how asx playlists and asx entries work (see below), and I believe my theory of synchronous execution of asx entries is right. I put the relevant bit of the specification in bold/italics: according to it, the next ENTRY element should be processed only *after* the current piece of (mms) content is done playing.
That portal video.globo.com depends on this sync of the asx specification in order to issue synched http-request + mms-requests. Why this sync is required for this specific portal is beyond me, but maybe it tries to force the users to use a browser (and see the ads...) or it is just a weird implementation.
Anyway, I'll look at the source file you told me and try to make it work in my case. I really don't want to use wmp anymore.
REF: This element specifies a URL for a piece of media content. The URL can point to any media type supported, using any protocol supported by the WMP control. The most common use of this element is for URL rollover. If the WMP control is unable to open a piece of media defined in a REF element, it tries the URL in the next REF element. Once the WMP control opens media content from a URL defined within the scope of one ENTRY element, it ignores subsequent REF tags within that ENTRY element. After the piece of content is done playing, the WMP control moves on to the next ENTRY element, if any.
Once the WMP control establishes a connection to a referenced piece of content, it ignores all other REF elements in that ENTRY, whether the connection terminates normally or abnormally.
<REF HREF="mms://example.microsoft.com/selection1.asf" />
<REF HREF="mms://example.microsoft.com/mirror/selection1.asf" />
mg12) - 2007-02-08 10:06By: magnesium (
was trying to use mplayerplug-in to replace windows media player at
video.globo.com, and noticed that for some reason, videos with several
parts only play the first one.
I used Firebug to obtain the list  below, showing the html code used by the portal to show up the embedded video: the internal iframe loads a frame containing a object+embed tags containing a src pointing to the following url:
this url loads the asx file in list  below. Notice that it contains a list of entries, each one a part of the video. Only the first entry plays inside mplayerplug-in. The others do not show up.
I would like to know if ASX 3.0 lists are supported at all. If so, I'll try to dig deeper to find out what might be going on. If not, I would like to suggest adding it to the next version, and of course I would be glad to test it.
---- list  ----
<iframe id="gmc_embed_iframe_1170956064591" scrolling="no" frameborder="0" marginwidth="0" marginheight="0" style="width: 320px; height: 288px;" name="gmc_embed_iframe_1170956064591" src=" http://playervideo.globo.com/webmedia/GMCAbrePlayer?midiaId=634332&autoStart=true&sessaoId=7822&embedInterno=true&corFonte=73899D&corLink=4F4F4E&requisitos=true&nocache=1170956064622">
<div id="player_embed" class="">
<div id="player" style="display: block;">
<embed id="gmcPlayer_1170956072681" width="320" height="250" stretchtofit="1" showstatusbar="1" type="application/x-mplayer2" src=" http://playervideo.globo.com/webmedia/GMCPlayListASX?midiaId=634332|banda=N|isc=203833576.1170957256.151|ext.asx"/>
<div id="videoAtual" style="display: none;">
<div id="enviar" style="display: none;"/>
<ul id="base_video" style="display: none;">
<div id="videoBarra" style="display: block;">
---- list  ----
<asx version = "3.0">
<ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=634318|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx "/>
<ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=634319|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx "/>
<ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=634320|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx "/>
<ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=634322|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx "/>
<ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=634324|ultimo=true|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx "/>
kdekorte ) - 2007-02-08 11:32By: Kevin DeKorte (
You don't say which version of mplayerplug-in you are using, but version 3.35 or CVS should be able to handle thos files.
mg12) - 2007-02-08 13:48By: magnesium (
downloaded, make-compiled and make-installed version 3.35, and
'about:plugins' in my firefox 2.0 says I'm using 3.35. Is there any
modification pos-3.35 which could have improved handling asx lists?
As an addendum to the previous post:
1) when I manually type the urls of each part/entry of the asx list above in firefox, mozillaplug-in plays the individual video part correctly (so the plugin is capable of loading and playing each part individually).
2) if I let mozillaplug-in to handle the asx list automatically (as expected), iterating through the video parts of the list on its own, only the first video plays correctly. from the second video part on, the plugin shows a video length of only 0:11 seconds on its status bar while showing the updated mms:// url for the part (probably indicating that the mms:// video part wasn't loaded correctly for some reason.) maybe cookies are not being sent when iterating the list?
mg12) - 2007-02-09 18:08By: magnesium (
I debugged mplayerplug-in and I believe I found two bugs in its behaviour when processing asx lists:
1) I saw the trace of http requests in list  before mplayerplug-in started buffering the first mms:// video part. Notice the behavior: mplayerplug-in reads the asx list asynchronously, going through ALL the entries of the list (pinging the http get request/responses), BEFORE the first mms:// video part even starts executing! The MMS server only accepts serving the mms stream for the video part if it has just been pinged by some http request. Therefore, after the first video part finishes, there is no more http pings and the MMS server refuses to provide the subsequent video parts.
I believe the correct behavior for asx lists processing should be synchronous: read one asx entry, do the http request, obtain the mms:// url in the http response and then *block* further processing of the asx list until the mms stream stops, and only then process the next asx entry until there is no entry left. This should work recursively in case the asx list entries point recursively to further asx lists.
That's why typing manually the http address of each entry in the address bar would always work: it does a synchronous http-request + mms-request to the server.
2) I noticed that the http response headers during the processing of each asx list entry sometimes included some Set-Cookie: items, but the http request header for the next entry would not contain the previously received cookie values in the Cookie: data. I injected manually these new values in the request headers, but they didn't seem to affect the result in my case. Anyway, this doesn't seem to be correct.
Have these behaviors being observed before? Are they expected? Which functions in the source code of mplayerplug-in I should look at in order to modify them?
#request# GET http://playervideo.globo.com/webmedia/GMCPlayListASX?midiaId=635739|banda=N|isc=205080729.1171071724.151|ext.asx
#request# GET http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=635722|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx
#request# GET http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=635726|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx
#request# GET http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=635732|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx
#request# GET http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=635734|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx
#request# GET http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=635736|ultimo=true|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx
(only now the first mms:// request is sent to server)
kdekorte ) - 2007-02-10 07:27By: Kevin DeKorte (
Can we take this discussion to the mplayerplug-in-devel mailing list. So that others will read it..
I do think you might be on to something and I'll tell you that I am not an expert in ASX playlists. I usually just do what I can to make them work.
The way I have made the ASX playlist and in fact all other play lists work is by doing this.
Ask the site for the file I'm given. Open that file and see it if is a playlist (buildPlaylist in plugin-list.cpp does this). For ASX files I get the list of every item in the playlist and put it on the internal list, processing each file recursively to see if they contain playlists themselves. I then request each file in the list and play them one after another. If the file is determined to be a streaming file (mms then the file is passed directly to mplayer for processing and mplayer is run with the -cookies option, so it should be passing cookie data).
I really don't see anything wrong with gathering up all my data and then starting the play. mplayerplug-in is async by nature since files are requested and may or may not come back to the plugin and also may come back in a different order than requested, so any type of request must be done and handled in an async manner.
I'm not sure your theory about an mms stream working only if it has been requested as http first is a rule. I have several sites I use that work fine by requesting the mms stream only. It might be something that site is doing, but I don't know of any other sites that do that. We could do an http "knock" on mms sites. In that we request an http version of the file, but don't do anything with it. I know there are sites that send an mms url, but if you request the data over http, you actually get clearer video. I tried implementing a url protocol rotation with http first, but found that it broke a lot of sites. I found that I had to go back to mms, mmst and http in the rotation as there are some sites that give a mms:// protocol but actually want to serve the data over mmst or http
Please feel free to look at the code an implement any changes that you think might be helpful. I'm always willing to consider a patch.