A new release of Gnash, version 0.8.9, is due in the near future. Plenty of bugs have been fixed, but some users are still going to have problems playing YouTube videos. Here's a short explanation.
At some point last year, YouTube started setting HTTP cookies in your web browser, to keep track of which of their video servers is nearest to your machine. This lets them provide a better experience for you (I guess). Here's a diagram of what goes on in your browser:
As of Gnash 0.8.8, a workaround was added, calling an NPAPI function NPN_GetValueForURL to ask the web browser for the relevant cookies. New diagram:
The downside is that this function was only added in NPAPI version 1.9. This means:
What does Adobe's plugin do? I imagine it's something like the following:
So, the good news is, this problem should almost certainly get fixed over the coming Debian release cycle, if only because all the browsers will get updated. In the meantime, disabling cookies (and removing stale ones from YouTube) is a workaround.
Posted: 12 Feb 2011 23:45 |
Mwahahahaa, just a few moments ago, my local copy of gnash actually got past the RTMP handshake, and got a response from iPlayer. I need to be at work in around 8 hours, though, so no time to push this until tomorrow... and it needs some cleanup.
Obviously, no audio has yet been played. Don't be silly.
Posted: 19 Nov 2010 01:04 |
Having studied librtmp over the weekend, it doesn't drop into gnash as neatly as I'd hoped. Gnash already has classes to implement NetConnection and NetStream, which it makes sense to use - but librtmp is designed to replace the need for such classes to exist. So it implements certain higher-level responses to various calls from the server, that are necessary when downloading a stream. Gnash probably needs to hook in instead, and let the flash application decide what to do in these cases.
So more work required, and possibly changes to librtmp in future - but I've started fixing up Gnash's RTMP code instead, for now, and have sent a couple of initial patches to Savannah. I don't think YouTube exercises these code paths, so they're a little rusty - I hope to make more progress through the week.
Posted: 15 Nov 2010 13:27 |
So I studied the SWF 8 iPlayer a little - there are some simple rendering issues with Gnash that I'd like to come back to, but the biggest problem is obviously the media not playing. Looking at the network requests, wireshark says something about malformed packets - Gnash is getting as far as making RTMP requests, but the connection dies pretty quickly.
My working theory is that there is a bug in the Gnash RTMP client code. This code was forked from rtmpdump, and has since been converted from C to C++, and a whole bunch of other stuff. It's quite possible that there is some change deep in the code which hasn't been copied back into Gnash - therefore, it makes sense to get Gnash building against librtmp properly, which is now a separate library.
This, of course, means actually writing code. Eurgh. I try to avoid that when I can, but sometimes it is inevitable. :)
When writing larger changes, I find it takes me longer to get acquainted with the existing code base - in this case, two code bases, since I have to understand librtmp at some level, as well. I'm not expecting to produce anything before the weekend, which is frustrating. It is also risky to write about stuff before you have completed it, because it can be a very public failure if you don't manage it!
Posted: 10 Nov 2010 22:38 |
There exist several different versions of BBC iPlayer. (Even if you don't care about the main iPlayer site, perhaps you might want to watch videos on BBC News one day, which uses the same code.)
a = glow.embed.Flash.version(); f = ""; f = a.major>=10 ? "10player.swf" : a.major<8 ? "7player.swf" : a.major==9 && (a.minor>0 || a.release>=115) ? "9player.swf" : "player.swf";
It is clear that Flash 9.0.115 holds special significance; this was the version that introduced SWF Verification support. The 7player.swf file seems to have disappeared entirely - I get a "404 not found" error. That means there is still one version of the iPlayer which hopefully should not require implementing SWF Verification.
Navigating around the site with Gnash declaring itself as version 8 (with a patch applied to fix Glow compatibility), only radio programmes attempt to play using this version, and even then not the live streams. (No, gnash still doesn't play anything, don't panic.)
So it would seem to me that fixing Gnash's support for this SWF 8 iPlayer would be a good place to start.
Posted: 08 Nov 2010 00:14 |
So, with the GNASH_OPTIONS=writelauncher hint from last time, you have got a script which runs gnash. It is still running a remote SWF file, though - you want to modify that file to isolate a test case, and for that it will need to be on the local filesystem.
First, look in the gnash-debug-1.sh script to find the URL for the SWF, and download it. It's the last option passed to gnash.
In order to convince the file that it's still being served from the web server, you now need to swap the '-U' option in the gnash command line for a '-u'. This is enough for gnash 0.8.8 to play the file.
Unfortunately, if you are running current git master, this does not work. You also need to feed the SWF from standard input to gnash - i.e. use '-' as the last option, and redirect the SWF file to the gnash command:
/path/to/gtk-gnash -u http://some/url [more options] '-' < downloaded.swf
If any of this is documented, I'm buggered if I can find it.
Posted: 07 Nov 2010 20:30 |
Gnash has moved from bzr to git, at least for the moment - Savannah's bzr setup is slow and unlikely to improve, so the choice is git or Launchpad, apparently. (Thinking selfishly, I'm a lot more familiar with git than with bzr, so I hope it stays this way.) My instructions from July have changed only slightly:
git clone git://git.sv.gnu.org/git/gnash cd gnash ./autogen.sh ./configure --enable-renderer=agg \ --enable-media=GST \ --enable-gui=gtk \ --with-plugins-install=system make sudo make install sudo make install-plugins
Buried near the end of the bug reports wiki page is a useful tip for debugging - export GNASH_OPTIONS=writelauncher before starting the browser, and gnash will write out the instructions for starting a local copy.
In practise, these instructions seem to appear as a file called /tmp/gnash-debug-1.sh, and that will reference a file matching /tmp/gnash-cookies.* - so don't bother trying to dig through the debug log.
With this tip, it's possible to get the browser out of the loop, and focus on debugging gnash (which should be enough for most problems). At least, that's what I hope - I've spent the last hour or so just figuring this stuff out. Hmpf.
Posted: 03 Nov 2010 22:38 |
One thing I noticed having started to use gnash is that the BBC's iPlayer website (UK-only, I believe) gives a message like "You do not have Flash player installed" - not merely complaining about the version, but actually not recognising gnash as a Flash player at all.
The bottom line is, glow uses this regex:
var regexFLASH_VERSION = /^Shockwave Flash\s*(\d+)\.(\d+)\s*\w(\d+)$/;
and gnash uses a description like this:
Shockwave Flash 10.1 r999. Gnash trunk, the GNU SWF Player. Copyright (C) 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc. Gnash comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of Gnash under the terms of the GNU General Public License. For more information about Gnash, see http://www.gnu.org/software/gnash. Compatible Shockwave Flash 10.1 r999.
Note the dollar sign at the end of the regex. Indeed, rebuilding gnash without all the notices at the end of the description lets you see the iPlayer UI. (It doesn't actually play anything, don't get your hopes up.)
Interestingly, different parts of iPlayer require different minimum versions of Flash. Clips of radio programmes tend to be more liberal with what they will accept - right down to version 7. Most TV streams and clips require at least version "9.0 r115", and I've heard they use SWF verification. I'm not sure how legal it is to implement that, although apparently code exists.
Posted: 19 Jul 2010 22:34 |
Adobe aren't supporting their flash player on amd64 right now. The cognitive dissonance gets a little draining, anyway, and I've seen the hoops I'd have to jump through to get the 32-bit version running. So I'm going to try tracking gnash trunk for a while.
First impressions: gnash seems easier to build than it used to be (or maybe I just read the instructions this time). I chose the AGG graphics backend, with gstreamer and gtk. I also chose to install the browser plugins system-wide. The bzr repository ships copies of the necessary Mozilla libraries, which I'd usually frown upon as a packager, but it did mean I didn't have to worry about them.
So the whole process looked like:
bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk cd trunk ./autogen.sh ./configure --enable-renderer=agg \ --enable-media=GST \ --enable-gui=gtk \ --with-plugins-install=system make sudo make install sudo make install-plugins
The README file was very helpful, as was the configure script output.
So, off to youtube... "An error has occurred, please try again later." Hmpf. Off to read the mailing list... there was a problem discussed a while ago about cookies that YouTube has started sending. I checked the patch discussed at the time, and a version of it seems to be in trunk, but the symptoms are still happening for me. But... disable all cookies in the browser, and it starts working. (There's a chance that libcurl might not be configured properly.) I'll have to report the problem or track it down further, but for now, I'm sitting back and declaring success.
Co-incidentally, the video was discussing another cookie problem. ("Put pinky down. Down pinky. Good.")
Posted: 17 Jul 2010 19:39 |