GNOME Bugzilla – Bug 426773
Does not parse asx playlist trees like WMP
Last modified: 2019-03-20 10:38:38 UTC
Please describe the problem: Totem 2.18.0 in Ubuntu Feisty Beta (using today's repository, xine-lib 1.1.4 and today's GStreamer 0.10.12) only plays the *first* video in a master-playlist containing nested asx sub-playlists (in a playlist tree with arbitrary depth). Microsoft media player iterates over all sub-playlists (the nodes/leaves of the tree) correctly and plays *all* the videos in the nested playlist. The master asx playlist (the root of the tree, listed below) contains further references to other nested asx sub-playlists as in a tree of playlists. Each sub-playlist leaf contains only one mms: video stream element each which should be played. Each sub-playlist is successfully played by totem if started manually, but totem fails to iterate over all of them if given the master playlist to play. Steps to reproduce: totem "http://mrc.gran.googlepages.com/example-nested-playlist.asx" (the asx contents of this url can be seen below.) Actual results: - only the first item of the master-playlist above is shown. - each item can be played successfully if manually started using the sub-playlist urls (see list of urls below). - *sometimes*, totem can be made to iterate over some of the master playlist items if the 'next item' button is pressed repeatedly without stopping. Expected results: totem should play *all* videostreams in the leaves of the playlist tree, just like Microsoft Media Player does. Does this happen every time? yes Other information: - Microsoft media player fetches/plays each asx sub-playlists and mms: streams inside them synchronously (depth-first, blocking the iteration that fetches the next asx sub-playlist contents until the current videostream is over or cancelled). - maybe totem is doing this asynchronously (breadth-first, fetching the contents of all asx sub-playlists before starting to play the first videostream)? The master playlist in the root of the tree (pointing to nested sub-playlists) given as example: <asx version = "3.0"> <entry> <ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=654705|banda=N|ext.asx"/> </entry> <entry> <ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=660298|banda=N|ext.asx"/> </entry> <entry> <ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=660285|banda=N|ext.asx"/> </entry> <entry> <ref href="http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=659836|banda=N|ext.asx"/> </entry> </asx>
Works fine here. What's the output of "test-parser -d" on that playlist on your system? $ ./test-parser http://mrc.gran.googlepages.com/example-nested-playlist.asx ###################### parsing ################ added URI 'mms://windowsmedia.globo.com/_fechado/globocom/jornalismo/1/em_cima_da_hora/2007/03/21/EFCGJ_T_654705_wmbl.wmv?url=0200040922000730693JPvNrNXkoin1e6JtRcOXSA%3D%3D&WMContentBitrate=200000' added URI 'mms://windowsmedia.globo.com/_fechado/globocom/jornalismo/2/bom_dia_brasil/2007/04/03/EFCGJ_T_660298_wmbl.wmv?url=0200012123501212636iWdRvd8Cs0n1VxIVr6zTDw%3D%3D&WMContentBitrate=200000' added URI 'mms://windowsmedia.globo.com/_fechado/globocom/jornalismo/2/bom_dia_brasil/2007/04/03/EFCGJ_T_660285_wmbl.wmv?url=0200040562340711563GG4QClzYOjoyqir9yovWYg%3D%3D&WMContentBitrate=200000' added URI 'mms://windowsmedia.globo.com/_fechado/globocom/jornalismo/2/bom_dia_brasil/2007/04/02/EFCGJ_T_659836_wmbl.wmv?url=0200011697382201622zp2N2G5gRtWfQGx5rJ75ZQ%3D%3D&WMContentBitrate=200000'
hi, i'm having problems compiling test-parser, if you could attach it (x86) i will have a look at its output. but i believe the problem is more subtle than just being able to load all items. totem seems to try to play all 4 streams, but the *order* in which it is processing the elements of the nested asx tree seems to be wrong. to make it more precise: imagine a master asx playlist asx0, whose items point to further nested asx urls/playlists asx0.0, asx0.1, asx0.2, asx0.3. each one of these nested lists contain one mms item: mms0.0.0, mms0.1.0, mms0.2.0, mms0.3.0. (this is the abstract structure of the initial example url i provided) now, it seems that totem goes breadth-first in this tree, fetching the urls in this order: asx0,asx0.0,asx0.1,asx0.2,asx0.3 and only then fetching mms0.0.0 (and blocking further processing of the tree until mms0.0.0 video ends),then fetching mms0.1.0(and blocking until it ends),mms0.2.0 and so on. windows media player, instead, uses a depth-first strategy, fetching the urls in this order: asx0,asx0.0,mms0.0.0 (and blocking further fetching of the tree url-nodes until mms0.0.0 video ends), then fetching asx0.1,mms0.1.0(and blocking further fetching until mms0.1.0 video ends), then fetching asx0.2,mms0.2.0(and blocking), then finally fetching asx0.3,asx0.3.0. some sites rely on the depth-first order to authenticate/ping the client while it is fetching the asx0.x nodes, just before authorizing the transference of the mms stream mms0.x.0. if the breadth-first strategy is used, they will not authenticate/ping the client just before the transference of the mms streams: the mms streams will not play or they will show up a error video stream. that's why I think that windows media player plays the above url http://mrc.gran.googlepages.com/example-nested-playlist.asx and totem does not, and that's why the bug is so subtle. to see this bug, just point totem to this url above and wait 5min for it to go through the items. it will just play the first (or at most the second item) before returning invalid videos for the last items of the playlist. do the same in windows media player and it will play all items.
I think I understand the problem, but it would mean quite some changes to totem, the totem-playlist and the parser to be able to act like that, although I guess it would be possible to work-around it in the playlist itself (set recursion level to one, and ask the playlist to parse the second item when it gets to it, rather than when parsing the first level).
I can't actually play the second stream because I get the complaint: "Audio codec 'ACELP.net' is not handled. You might need to install additional plugins to be able to play some types of movies" Are you sure that this isn't the problem you're seeing?
hi ya, this happened exactly because of the bug described (wrong parse order in asx playlist trees): if you play the second stream directly, it will play correctly: totem "http://playervideo.globo.com/webmedia/GMCMidiaASX?midiaId=660298|banda=N|ext.asx" because it only has one wmv item inside it, so the order doesn't matter. Now, if you try to play the root asx playlist (the one at "http://mrc.gran.googlepages.com/example-nested-playlist.asx"), which contains four asx items, totem will not play from the second on. The complaint you observed is the result of totem doing a breadth-first walk in the elements of the asx tree (instead of doing a depth-first walk, as in microsoft media mplayer (msmm)): since the implementation of video.globo.com depends on the msmm way of walking to authenticate the wmv streams, it fails on totem. (the authentication, in this case, depends on msmm fetching asx-i just before it fetches wmv-i: asx-0, wmv-0, asx-1, wmv-1, asx-2, wmv-2, asx-3, wmv-3. This doesn't occur with totem, which fetches all asx-0,asx-1,asx-2,asx-3, and only then it fetches wmv-0,wmv-1,wmv-2,wmv-3. therefore, only wmv-0 will be directly preceded by an asx-i, and thus wmv-1,-2,-3 will fail (btw, wmv-1 is the one that failed with you.)) if you play the second stream directly (as I suggested above), totem will play asx-1,wmv-1, therefore wmv-1 will play correctly. The 'codec ACELP' error is because video.globo.com implementation sends a weird warning video in a strange format when the authentication is unsuccessful, but this is a different problem.
Hello, Bastien, did you have any progress in the solution of this bug? []s,
hi, I have problems playing video channels at www.iran.tv website. I suspect it is a playlist parsing problem. Basically what happens when playing it in windows is that an ad is played before the main stream is opened. In totem, there are two different scenarios depending on which channel is chosen. Scanrio 1: accessing http://www.iran.tv/jamejam2.htm causes the ad to played but totem fails at opening the main stream Scenario 2: accessing http://www.iran.tv/tapesh.htm neither the ad nor the main stream is opened. I am not a technical person on this issue but suspect that there might be non-standard features used. Having totem follow the same behavior as WMP makes a lot of sites designed for windows media work in linux too.
Amin, please file separate bugs for those problems.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/totem-pl-parser/issues/8.