search

mikio-honmura / gnome-mplayer

Automatically exported from code.google.com/p/gnome-mplayer
GNU General Public License v2.0
0 stars 0 forks source link

Playlist entries are not recursivelly evaluated as playlists #222

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
How to reproduce:

1. Create playlist with some items being playlist itself:
$ cat > playlist 
rtsp://ctrm.visual.cz/ctupload/reklama/sazka2_high.rm
http://master.nacevi.cz/ram/ct24liveRH1.ram

2. $ gnome-mplayer --playlist playlist

First playlist entry is final URL and is played very good (it's a silly
advertisement).

However next entry is type of playlist and the gnome-mplayer tries to play
it instead to resolve it first. Thus the second entry can not be played. 

The second entry points to another RTSP live stream URL
<rtsp://stream2.visual.cz/broadcast/CT24-High1.rm>. Running "gnome-mplayer
--playlist http://master.nacevi.cz/ram/ct24liveRH1.ram" works fine.

I suggest: whenever a playlist is given to gnome-mplayer, gnome-mplayer
should at first try to resolve any playlist entry as playlist and then try
to play the result or, in case of resolution failure, play the entry.
However be careful and prevent cycling (which happens on some servers).

Plain MPlayer works in this manner and it can play all entries in main
playlist.

Note: It's possible these concrete streams are geographically restricted.
Note2: This weird playlist is real live example (I get it through
gecko-mediaplayer on web site
<http://www.ceskatelevize.cz/ivysilani/ct24-zive/?streamtype=RL2>. So it
would be nice to overcome this problem.

Original issue reported on code.google.com by petr.pi...@atlas.cz on 2 Jul 2009 at 3:29

GoogleCodeExporter commented 8 years ago 
Ok, I can't test this with your example, cause it is geography bound... but 
give SVN
a try. I found that for the url the time it played was very short (ie 0 
seconds) and
so in this case I retry with the playlist flag.

Hopefully this will fix this issue. The http add some complication to this 
since http
urls are normally streaming media and can also be mmshttp or http and can also 
be
recursive as in the case of ASX files.

Original comment by kdeko...@gmail.com on 2 Jul 2009 at 4:30

GoogleCodeExporter commented 8 years ago 
Thank you for very quick response.

I did some tests and I think I put bad advice in my first comment. Actually 
there are
two problems:

(1) The gnome-mediaplayer (which is Netscape plugin wrapping gnome-mplayer) 
parses
the playlist on its own and than instructs gnome-mplayer to add an item into 
playlist
and play it (I think at least, maybe I'm wrong in it). The plugin tells to 
player to
play not-a-playlist. Thus your patch does not fix it probably. (I tested trunk
version and it causes Firefox to freeze. I should recompile the plugin against 
newer
player probably. I will try it someday.)

(2) Gnome-mediaplayer behaves differently on playlist fetch from HTTP and 
playlist
load from local file. This fooled me and I did not catch the first (1) problem
previously. If I run "gnome-mediaplayer --playlist http://host/playlist", it 
will
download the playlist and it will try to recurse the entries as playlists. This 
is
true even for stable 0.9.6 version. However if I run "gnome-mediaplayer 
--playlist
playlist", it will not get the "-playlist" parameter to mplayer.

I prepared some test cases with public globally accessible NASA TV. Look inside
<http://xpisar.wz.cz/gnome-mplayer/>. The nasa.playlist.ram is indirect playlist
(playlist entry point to another playlist), the other nasa.ram file are direct
playlist (its entry is RTSP URL). The XHTML files are objects pointing to 
appropriate
playlist.

My results are: nasa.playlist.xhtml does not work, nasa.xhtml works, 
"gnome-mplayer
--playlist http://xpisar.wz.cz/gnome-mplayer/*.ram" works, copied nasa.ram to 
local
file system as "gnome-mplayer --playlist nasa.ram" works, but "gnome-mplayer
--playlist nasa.playlist.ram" does not work.

I will try to contact gnome-mediaplayer plugin developers to ask them about 
this problem.

Original comment by petr.pi...@atlas.cz on 2 Jul 2009 at 8:01

GoogleCodeExporter commented 8 years ago 
Gecko-mediaplayer is authored by me as well... I will try the sites you set up.

Original comment by kdeko...@gmail.com on 2 Jul 2009 at 8:22

GoogleCodeExporter commented 8 years ago 
None of your examples work for me, mainly since I can't connect to those sites 
in the
playlists for some reason. It just times out. 

However, the SVN code does try the link without playlist and then retries it 
with the
-playlist option. So I think SVN should work correctly for you.

Original comment by kdeko...@gmail.com on 2 Jul 2009 at 8:28

GoogleCodeExporter commented 8 years ago 
Regarding NASA TV: Download its official playlist
<http://www.nasa.gov/ram/35037main_portal.ram> and substitute address from 
there.
Akamai has some regional restrictions probably.

Original comment by petr.pi...@atlas.cz on 2 Jul 2009 at 9:23

GoogleCodeExporter commented 8 years ago 
gnome-mplayer http://www.nasa.gov/ram/35037main_portal.ram

works fine for me from SVN..

Original comment by kdeko...@gmail.com on 2 Jul 2009 at 9:46

GoogleCodeExporter commented 8 years ago 
It works because it's just one-level playlist. I thought to make a local copy 
of my
testcases and move content of <http://www.nasa.gov/ram/35037main_portal.ram> 
into
nasa.ram.

Never mind. I adapted <http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram>. 
Now you
should be able to reproduce the bug with
<http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.xhtml>.

Original comment by petr.pi...@atlas.cz on 3 Jul 2009 at 8:18

GoogleCodeExporter commented 8 years ago 
Still appears to be doing what it is supposed to... I do think that mplayer 
does have
issues with some of those rtsp streams,..

This is the log I am getting... you'll notice it does get to the akamai 
streams..

src/gnome-mplayer http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
GNOME MPlayer v0.9.7
vo = x11 ao = pulse
Running with GIO support
Master,0 Range is 0 to 65536 
Master,0 Current Volume 51036, multiplier = 0.001526
Scaled Volume is 77.874756
Using volume of 77.87
Using pulse audio in non-flat volume mode, setting volume to max (will be 
limited by
mixer 100% of 77%)
opening http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
is block 0
is character 0
is reg 0
is dir 0
playlist 0
embedded in window id 0x0
playlist detection = 0
adding http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram to playlist (cancel 
= 0)
playing - mmshttp://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
is playlist 0
mplayer -profile gnome-mplayer -quiet -slave -identify -volume 100 -vf-pre
yadif,softskip,scale -noconsolecontrols -osdlevel 0 -nomouseinput -cache 2048 
-wid
0x8800057 -ass -noembeddedfonts -ass-font-scale 1.00 -ass-color fffb0000 
-channels 4
-vf-add pp=ac/tn:a -autoq 3 -vf-add screenshot -af-add
export=/tmp/mplayer-af_exportlytehp:512
mmshttp://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram 
Using match: type='signal',interface='com.gnome.mplayer'
Using match: type='signal',interface='org.gnome.SettingsDaemon'
Using match: type='signal',interface='org.gnome.SettingsDaemon.MediaKeys'
Proxy connections and Command connected
Spawn succeeded for filename 
mmshttp://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
Changing window size to 0 x 0 visible = 1
MPlayer SVN-r29409-4.4.0 (C) 2000-2009 MPlayer Team
ERROR: Couldn't resolve name for AF_INET6: xpisar.wz.cz

Playing mmshttp://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram.
STREAM_ASF, URL: mmshttp://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
Resolving xpisar.wz.cz for AF_INET6...
Resolving xpisar.wz.cz for AF_INET...
Connecting to server xpisar.wz.cz[88.86.113.136]: 80...

Exiting... (End of file)
Thread completing
playing - http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
is playlist 0
mplayer -profile gnome-mplayer -quiet -slave -identify -volume 100 -vf-pre
yadif,softskip,scale -noconsolecontrols -osdlevel 0 -nomouseinput -cache 2048 
-wid
0x88000c1 -ass -noembeddedfonts -ass-font-scale 1.00 -ass-color fffb0000 
-channels 4
-vf-add pp=ac/tn:a -autoq 3 -vf-add screenshot -af-add
export=/tmp/mplayer-af_exporticqbin:512
http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram 
Spawn succeeded for filename http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
Changing window size to 0 x 0 visible = 1
MPlayer SVN-r29409-4.4.0 (C) 2000-2009 MPlayer Team
ERROR: Couldn't resolve name for AF_INET6: xpisar.wz.cz

Playing http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram.
Resolving xpisar.wz.cz for AF_INET6...
Resolving xpisar.wz.cz for AF_INET...
Connecting to server xpisar.wz.cz[88.86.113.136]: 80...
shutting down threadquery for 
mmshttp://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
since threaddata->done is TRUE
Cache size set to 2048 KBytes
Cache fill:  0.00% (45 bytes)   

Exiting... (End of file)
Thread completing
playing - http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
is playlist 1
mplayer -profile gnome-mplayer -quiet -slave -identify -volume 100 -vf-pre
yadif,softskip,scale -noconsolecontrols -osdlevel 0 -nomouseinput -cache 2048 
-wid
0x88000f0 -ass -noembeddedfonts -ass-font-scale 1.00 -ass-color fffb0000 
-channels 4
-vf-add pp=ac/tn:a -autoq 3 -vf-add screenshot -af-add
export=/tmp/mplayer-af_exportjvolee:512 -playlist
http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram 
Spawn succeeded for filename http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
Changing window size to 0 x 0 visible = 1
Resolving xpisar.wz.cz for AF_INET6...
ERROR: Couldn't resolve name for AF_INET6: xpisar.wz.cz
Resolving xpisar.wz.cz for AF_INET...
Connecting to server xpisar.wz.cz[88.86.113.136]: 80...
Cache size set to 2048 KBytes
Resolving www.nasa.gov for AF_INET6...
ERROR: Couldn't resolve name for AF_INET6: www.nasa.gov
Resolving www.nasa.gov for AF_INET...
Connecting to server www.nasa.gov[208.19.38.49]: 80...
shutting down threadquery for 
http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram
since threaddata->done is TRUE
Cache size set to 2048 KBytes
MPlayer SVN-r29409-4.4.0 (C) 2000-2009 MPlayer Team

Playing
rtsp://a1400.l1856741624.c18567.g.lr.akamaistream.net/live/D/1400/18567/v0001/re
flector:41624.
Resolving a1400.l1856741624.c18567.g.lr.akamaistream.net for AF_INET6...
ERROR: Couldn't resolve name for AF_INET6: 
a1400.l1856741624.c18567.g.lr.akamaistream.net
Resolving a1400.l1856741624.c18567.g.lr.akamaistream.net for AF_INET...
Connecting to server 
a1400.l1856741624.c18567.g.lr.akamaistream.net[207.138.82.174]:
554...
librtsp: server responds: ''
Cache size set to 2048 KBytes
Cache fill:  0.02% (411 bytes)   
ERROR: realrtsp: rdt chunk not recognized: got 0x53
ERROR: realrtsp: rdt chunk not recognized: got 0x4d
REAL file format detected.
ERROR: No stream found.
Stream description: Video Stream
Stream mimetype: video/x-pn-realvideo
ID_VIDEO_ID=0
[real] Video stream found, -vid 0
Stream description: Audio Stream
Stream mimetype: audio/x-pn-realaudio
ID_AUDIO_ID=1
[real] Audio stream found, -aid 1
RM: No video stream found.
RM: No audio stream found -> no sound.

Playing
rtsp://a1747.l1856745839.c18567.g.lr.akamaistream.net/live/D/1747/18567/v0001/re
flector:45839.
Resolving a1747.l1856745839.c18567.g.lr.akamaistream.net for AF_INET6...
Resolving a1747.l1856745839.c18567.g.lr.akamaistream.net for AF_INET...
ERROR: Couldn't resolve name for AF_INET6: 
a1747.l1856745839.c18567.g.lr.akamaistream.net
Connecting to server 
a1747.l1856745839.c18567.g.lr.akamaistream.net[64.215.170.113]:
554...

Original comment by kdeko...@gmail.com on 3 Jul 2009 at 1:28

GoogleCodeExporter commented 8 years ago

Original comment by kdeko...@gmail.com on 4 Jul 2009 at 1:46

GoogleCodeExporter commented 8 years ago 
My current status is "gnome-mplayer --playlist
http://xpisar.wz.cz/gnome-mplayer/nasa.playlist.ram" works. Launching the same
playlist as embedded video through gecko-mediaplayer does not. I will submit 
new bug
for particular project.

Original comment by petr.pi...@atlas.cz on 6 Jul 2009 at 5:24

GoogleCodeExporter commented 8 years ago 
Regarding post #10: the SVN trunk of gnome-mplayer works only playlist 
specified as
HTTP URL. Loading the playlist from local file system suffers from the this 
problem yet.

Original comment by petr.pi...@atlas.cz on 6 Jul 2009 at 6:44