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_magpiesThey have 130,000 more videos like that one -- and growing, including
a new collection of NASA movies:
http://www.archive.org/index.phpThey, 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