> So, I've spent a while thinking about the problem and the proposed solution.
Thank you! > First of all, I think the solution is not very good, for 2 reasons: a > lack of understanding of multimedia from the person writing it up and > the second is that such a huge list doesn't make it easy for the > application developer to decide which format to use. Should someone > that wants to use some format really have to check audio codec, video > codec and container format? Where does it put Ogg Skeleton support for > the subtitles? We'd love to make a complicated thing easy for the app developer (I guess the app developer is the Internet Archive, in this example?). If you know a way to make it easy, please, tell us! Otherwise we can only simplify it "as much as possible, but no more". Here's the problem we're trying to solve. A large repository of video, the Internet Archive, cares about freedom. They are also a public library, and care about easy access by everyone, not just free software fans. They offer free downloads of all their videos in the original uploaded format, and in a variety of transcoded formats. But they discovered that public uptake and convenience was much higher when they added a Flash-based player on the same page, which allowed people to merely click the player and see the video (rather than slowly downloading the large files and then struggling with codecs and media players). See, for example: http://www.archive.org/details/the_talking_magpies They have 130,000 more videos like that one -- and growing, including a new collection of NASA movies: http://www.archive.org/index.php They, and I, would like to extend this easy-play experience to free software fans. Currently, those fans must install proprietary codecs (FLV, in particular) to see the Flash-based player. They also must install proprietary codecs to see most of the downloadable videos, since most are in proprietary formats. The second issue can be addressed merely by transcoding all the downloadable videos into Ogg Theora (or other free codecs as they arrive). They are prepared to do that. I thought that the first issue could most easily be resolved by allowing the Flash-based streaming player to select an Ogg stream rather than an FLV stream. Gnash already supports playing an Ogg Theora stream from a .swf Flash movie. But gnash, and flash in general, provide no transparency about what kinds of video will actually play locally, versus which will fail. Trying to play an Ogg stream on the proprietary Adobe Windows Flash player will fail. Trying to play an FLV stream on Gnash will often fail. > But most of all, I think extending the supported video formats of > Flash is not very useful. I can see two reasons for this. The first is > promoting the Flash format, which still is the last thing I want. The > second is to allow videos with features that aren't available today. > And the only feature that Flash video formats don't give you yet is > Freedom. But if you care about Freedom, you don't use Flash, you use > HTML5 and <video> with Ogg Theora. So the proper solution for the Free > video problem is Firefox 3.1 and a little Javascript. > Or am I missing something? Flash is not quite a proprietary format any more. Like .DOC, its dominance in its niche has resulted in reverse-engineering, and compatable software is available from several different places. You may wish to discourage people from using Flash, but that isn't the job of the Gnash project. We are doing what we can to make Flash usable and friendly for free software users. Adobe's control of Flash, and its dominance of the web video niche, are both based on the ubiquity of its proprietary FLV codec. If we can show web sites that care about freedom how to provide the same experience with non-proprietary codecs and a non-proprietary flash player, the free world will move forward a notch, further lessening Adobe's control. Have you actually tried to play a large library of video with <video>? I can see two or three immediate problems. First, <video> in Firefox is full of bugs; check Bugzilla. It's so full of bugs, they aren't shipping it yet; it's only in the nightly builds, not in the releases. (Try the test page here: http://www.double.co.nz/video_test/ . It certainly doesn't play in my Firefox 3.0.1, downloaded last month directly from Mozilla.) Second, it's not easy for an HTML page to tell whether <video> is supported by its browser or not. Third, the presence of <video> does not guarantee that an Ogg Theora decoder is present. (It happens to be there in Firefox, but of course Apple and Microsoft and Nokia will throw a wrench into the works by shipping <video> without Ogg.) So even if you use <video>, you're back to having to decide which video URL to provide as the <video src=>, based on the locally supported decoders. As yet, HTML5 provides no way to discover those. The Archive's programmers think it's acceptable for their server to provide a list of the available streams to their Flash application, and annotate each one with appropriate metadata so that the application can choose which stream to play. My proposed improvement in Gnash would provide the basic information needed for the Flash application to make that choice. Yes, there are dozens of corner cases in which this will fail -- such as wanting closed captioning, or files that use a codec at a bizarre sample rate or bit rate. Would you advocate making the metadata more generic, e.g. merely providing a set of properties, rather than dividing them into file formats, audio encoders, video encoders, audio decoders, and video decoders? I prefer more generality when it doesn't get in the way. Thus a given video might only be selected if the "decode container Ogg", "decode video Theora", and "decode audio Speex" properties are all locally supported. How would you mix in closed captioning? Would you decline to select a captioned video stream if the captioning support is locally missing? But wasn't the captioning designed to fall back to non-captioned output by default, in players that don't support it? How would you represent supported sample rates and bit-rates? I was trying to keep it simple enough to work for >90% of movies, rather than making it ten times as complex in order to work for >99% of movies. A challenge will be in coming up with unique names for all these properties; already, gstreamer and ffmpeg use different names for the same codecs -- and ffmpeg sometimes uses different names for the encoder and the decoder! We'll have to regularize these for presentation to the Flash layer, and ideally standardize them upstream in gstreamer and ffmpeg as well, if their developers are willing. John Gilmore _______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev
