Re: [Gnash-dev] Re: Free codecs support (was: release criteria ?

[Martin Guy]

> > > On Sun, Apr 08, 2007 at 03:54:08PM +0200, Tomas Groth wrote:
> > > > We can just using a non-flv file (ogm,
> > > > avi, etc), which is already supported by at least the ffmpeg-backend, and
> > > > for some filetypes also for the gstreamer-backend.

Exactly, the same as every other free video player.

> > > > The other options is to continue to use the FLV-format, but use the free
> > > > codecs instead of mp3 and H.263, and this will require an extension of
> > > > the SWF-specs.

2007/4/10, Tomas Groth <address@hidden>:
> I think we should just re-use the existing AS classes.

Absolutely, if at all possible.

> --- Klaus Rechert <address@hidden> skrev:
> > Defining new CodecIDs for free codecs and free players is unavoidable imho.
> I agree, so I guess we should choose some open codecs and some proper IDs.

CodecIDs have nothing to do with it - are we confusing terms here?
There are three issues in a video strea (as Tomas knows too well!):
- container format (avi, ogg, flv) that wraps and interleaves the
audio and video
- video encoding format (ogg theora, mpeg2, mpeg4)
- audio coding format (mp3, ogg vorbis)
while a codec is a piece of code that decodes (or encodes) a specific
format. An application may contain several decoders (codecs) that
decode the same encoded format, and is free to choose one at runtime
if it wishes - embedding the *codec* choices in FLV format sounds like
a gross way to avoid doing format detection. That information is
already available in the header of the container/audio/video stream.

Note that here "decoder" may mean a member of a suite of decoders such
as something from ffmpeg, as well as an individual decoder such as the
Xiph ogg theora decoder, which complicates matters, since Gnash needs
to choose between alternative and independent codecs, not just have
GST or FFMPEG as a compile-time choice and choose one of the limited
set of decoders it offers... unless you want to implement ogg theora,
FLV, mad and everything else within the FFMPEG framework.

In this context, FLV video is a container format, not a video format,
and the Flash Video extras can be preserved if you treat it as such.
The fact that it contains MP3-coded audio and AMR-coded video is a
side issue - the decoder selection code would be the same as for other
containers, and the special FLV-related information ("cue points" for
long videos?) can be extracted by the FLV container code.

It's not an easy problem but there are already several sets of free
code that do it: mplayer and transcode for sure, vlc, xine and friends
probably do the same thing.
Embedding some magic number in the Flash file format to tell Gnash
which specific *codec* to select seems like a lame Gnash wart to avoid
coding the format detection properly.

I guess Gnash's codec framework is currently too simplistic to do
this. In that case, since ffmpeg can manage the existing FLV format,
it seems better to get a working version of that out to people before
uprooting the existing audio/video/container code to enlarge it to
support many separate codecs and codec suites.

Or am I missing something?

   M