asx 3.0 lists

  • magnesium

    magnesium - 2007-02-08

    I was trying to use mplayerplug-in to replace windows media player at, and noticed that for some reason, videos with several parts only play the first one.

    I used Firebug to obtain the list [1] 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:|banda=N|isc=203833576.1170957256.151|ext.asx

    this url loads the asx file in list [2] 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 [1] ----

    <div id="videoEmbed">
    <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="">
    <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="|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;">
    <div id="iframe"/>
    <div id="debug"/>

    ---- list [2] ----

    <asx version = "3.0">
    <ref href="|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx"/>
    <ref href="|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx"/>
    <ref href="|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx"/>
    <ref href="|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx"/>
    <ref href="|ultimo=true|playListId=634332|banda=N|isc=203833576.1170957256.151|ext.asx"/>

    • Kevin DeKorte

      Kevin DeKorte - 2007-02-08

      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.

      • magnesium

        magnesium - 2007-02-08

        I 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?

    • magnesium

      magnesium - 2007-02-10

      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 [1] 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?

      --list [1]--

      #request# GET|banda=N|isc=205080729.1171071724.151|ext.asx

      GET /webmedia/GMCPlayListASX?midiaId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      #request# GET|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      #request# GET|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      #request# GET|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      #request# GET|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      #request# GET|ultimo=true|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      GET /webmedia/GMCMidiaASX?midiaId=635722|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      GET /webmedia/GMCMidiaASX?midiaId=635726|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      GET /webmedia/GMCMidiaASX?midiaId=635732|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      GET /webmedia/GMCMidiaASX?midiaId=635734|playListId=635739|banda=N|isc=205080729.1171071724.151|ext.asx

      GET /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)

      • Kevin DeKorte

        Kevin DeKorte - 2007-02-10

        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.

    • Danilo Bardusco

      Danilo Bardusco - 2007-02-15

      Hi folks,

      I work at and I'm in charge of the above site(
      So, in order to clarify some points, let me contribute as follows:

      1) About the sync/async thread:
          We do have some complex authetication/authorization mecanism that implements a time-expires based token. That's why, when you do an async call to all the entries this doesn't work. Because the token isn't valid anymore after some short period of time since the first request.   
      Actually, the 11 seconds length video is an institutional video telling the user that this stream is restricted only to authorized people. But unfortunately, mplayerplug-in can't reproduce this stream also. I think this happens because the WMS authentication plugin, changes the  original source video by this other one dynamically when the token isn't valid.
          So, going in a sync way probably will do the right job.

      2) About the Cookies:
          Currently we just use cookies as a way to control and segment our video advertising.
          At the time of Globo Video's arrival this doesn't work neither with mplayer or totem, so we completely disabled the feature to all other OSes other then Micro$oft Windows with IE6+ browser.
          But if some day, mplayer goes to implement this feature, it will be great to support it.
          The way this works in Win+IE is that some pair of cookies is written by IE and later on WMPlayer reads this IE's cookies and send together in the media's request. So our advertising system could intercept this cookies and delivery a specific video campaign targeted to this user. Currently we segment this advertisings based on four cookies: user genre, user age, user state and current requested media content.
          By the way, I don't know if it could be a security threaten to mplayerplug-in access the firefox cookies.
      Please, let me know if you have any further questions.
      Danilo Bardusco <>


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks