Sat 07 Jun 2008 04:48:43 PM UTC, comment #12:
Closing.
|
Mon 05 May 2008 09:49:19 PM UTC, comment #11:
works for me too (gstreamer)
|
Mon 05 May 2008 09:32:44 PM UTC, comment #10:
The embedded player works now with gtk, and the redirect problem should also have been fixed. Please test with klash.
It seems that http://kcat.strangesoft.net/youtube_test.html was included in this bug as a test.
|
Sun 30 Mar 2008 03:52:38 PM UTC, comment #9:
Isn't this a duplicate of #20608 ?
|
Tue 18 Sep 2007 08:52:36 AM UTC, comment #8:
Bastiaan, I guess this is for you. Thanks Chris !
|
Tue 18 Sep 2007 08:50:22 AM UTC, comment #7:
Here's what I've come up with. It does contain a few other unrelated changes I was working on (namely removing the apparently unneeded m_src_url var, fixing a couple unused variable warnings, using KProcess::kill to cleanly send a SIGTERM to the spawned Gnash process, removing the unnecessary action buttons, not using the temp file for http(s) files..).
The important changes are in KlashPart::openURL and the new KlashPart::responseHeaderReceived, and related changes in klash_part.h. It retrieves the header for a given http(s) url, and when encountering a 3xx response, rebuilds the URL with the new location. An enhancement would be to do it recursively until getting a non-3xx response, but this should be good enough for now.
(file #13978)
|
Mon 17 Sep 2007 08:36:59 PM UTC, comment #6:
This is the command line generated by nsapi plugin:
Starting process: /home/strk/src/gnash/build/head/allgui_agg_ffmpeg/gui/gtk-gnash -v -x 58725084 -j 425 -k 350 -u http://www.youtube.com/jp.swf?video_id=XCo0R_DEE3w&eurl=http%3A//kcat.strangesoft.net/youtube_test.html&iurl=http%3A//img.youtube.com/vi/XCo0R_DEE3w/default.jpg&t=OEgsToPDskKKryjQ9uboAXDnN7iCzfSi -U http://kcat.strangesoft.net/youtube_test.html -P height=350 -P src=http://www.youtube.com/v/XCo0R_DEE3w -P type=application/x-shockwave-flash -P width=425 -P wmode=transparent -
So it seems the nsapi is taking care of the redirect here...
Good to know you're the one sending the patch for fixing kparts before as maybe you can fix this one too ? :)
PS: rob, we'd need plugin-nsapi and plugin-kparts categories for the bug tracker...
|
Mon 17 Sep 2007 07:45:18 PM UTC, comment #5:
Yeah, I'm the one that sent in the patch for it. :) That patch fixed the problem of not sending the page options set via javascript with -P.
The problem here is that remote embedded videos don't use javascript, and instead are embedded objects given the "short" source url http://www.youtube.com/v/<video id> which redirects to the actual swf with a dynamic query string. The kpart gets the original source url before it's processed, I guess assuming the kpart will do all the processing necessary for the url, and gives it to Gnash as the "real" url (via -u).
A more detailed explanation of what happens is this:
KlashPart::openURL is called with the given unprocessed source url (as specified in the webpage/adress bar/wherever) and hands it off to KParts::ReadOnlyPart::openURL.
KParts::ReadOnlyPart::openURL copies the name into m_url, and for remote files, creates a temp file, stores its name in m_file, sets m_bTemp to true, and downloads the source into the temp file (local files just copy m_url to m_file, removing the given protocol handler (eg. file:///foo/file.swf -> /foo/file.swf), and leaves m_bTemp false).
Then KlashPart::openFile is called to open m_file (which is copied to KlashPart::m_src_url and used for the actual loaded file) by calling play(), which passes m_url as the "real" url with -u, and ultimately generating a command like this:
/usr/local/bin/kde-gnash -x 29361184 -j 425 -k 350 -u 'http://www.youtube.com/v/XCo0R_DEE3w' -U 'http://kcat.strangesoft.net/youtube_test.html' -P 'movie=http://www.youtube.com/v/XCo0R_DEE3w' -P 'wmode=transparent' -P '__khtml__pluginembed=YES' -P '__khtml__pluginbaseurl=http://kcat.strangesoft.net/youtube_test.html' -P '__khtml__classid=' -P '__khtml__codebase=' -P 'width=425' -P 'height=350' '/tmp/kde-kitty/konquerorBuMvjb.tmp'
Gnash sees the original source url, misses the query string from the redirected url, doesn't set the required flashvars, and doesn't play the video. Replacing the given "real" url with the actual redirected url (with the query string) lets Gnash set the flashvars which makes it work.
|
Mon 17 Sep 2007 05:50:21 PM UTC, comment #4:
kparts plugin had a bug up to 0.8.1, should be fixed in head.
|
Mon 17 Sep 2007 04:28:22 PM UTC, comment #3:
(This is the original poster, I've decided to make an account)
Perhaps it's a difference between NSAPI and KParts::BrowserExtension (the former being given the real URL, the latter getting the page-defined one). I'd think as long as Gnash itself can handle http addresses for input, it also needs to be able to handle redirects too, IMO.
If I'm reading the source correctly, the Player::_url member is the only one that needs to look for and follow redirects, regardless if it was explicitly set or copied from the infile, before load_movie is called (or somewhere within load_movie before the URL's query string is parsed).
Unfortunately I don't know how to make flash files, let alone how to have them read the query string/flashvars, or to make a webpage redirect..
|
Mon 17 Sep 2007 03:43:13 PM UTC, comment #2:
mm, Actually, I just tested with current head (nsapi plugin) and works fine.
|
Mon 17 Sep 2007 03:36:13 PM UTC, comment #1:
Auch...
Do you think the _url member of the top-level movie should actually also be affected by redirects ?
Feeling like providing a full-open testcase for this ? (not involving foreign sites)
|
Sun 16 Sep 2007 03:55:41 AM UTC, original submission:
Youtube videos that are embedded in other sites (eg. a youtube video embedded in a livejournal page) don't seem to work. A test page for one such movie is here: http://kcat.strangesoft.net/youtube_test.html
In this case, the url http://www.youtube.com/v/XCo0R_DEE3w gets passed to gnash. The player comes up, but clicking play doesn't play the movie. Looking at the verbose output, it attempts to load http://www.youtube.com/get_video?video_id=undefined&t=undefined&eurl= which, obviously, doesn't exist.
Going on a hunch, I tried to wget http://www.youtube.com/v/XCo0R_DEE3w. Doing so revealed:
HTTP request sent, awaiting response... 303 See Other
Location: /jp.swf?video_id=XCo0R_DEE3w&eurl=&iurl=http%3A//img.youtube.com/vi/XCo0R_DEE3w/default.jpg&t=OEgsToPDskIewXWtLZi8j-U8Zwqm-U-F [following]
Following that, I tried running:
gnash 'http://www.youtube.com/jp.swf?video_id=XCo0R_DEE3w&eurl=&iurl=http%3A//img.youtube.com/vi/XCo0R_DEE3w/default.jpg&t=OEgsToPDskIewXWtLZi8j-U8Zwqm-U-F'
which brings up a playable movie. I also get a playable movie from running:
gnash -u 'http://www.youtube.com/jp.swf?video_id=XCo0R_DEE3w&eurl=&iurl=http%3A//img.youtube.com/vi/XCo0R_DEE3w/default.jpg&t=OEgsToPDskIewXWtLZi8j-U8Zwqm-U-F' 'http://www.youtube.com/v/XCo0R_DEE3w'
So it appears as though Gnash should look for redirect-type responses from the "real" URL, and modify it accordingly.
|