[vorbis-dev] Re: UCI Project Announcement

[Monty]

> Anybody from the Xiph team care to comment on Alex' proposal ?

I really hope this doesn't start a flamewar.  It's not meant as a
flame, just a summary of my current thinking, open to change.

> I seem to remember that Monty has stated on the theora list recently that he
> is planning to create a new API for the project.

No, I'm coding more of the original Ogg API, designed in 1996.  We
simply had no need to code the next chunk (transport mux/demux) until
now; there;s always too much to be done.  Note that this vapor design
sitting in my head is roughly fourth generation of 'Ogg Pillar III'.
I wonder who still remembers that whitepaper :-)

> Maybe worthwhile to check
> UCI before doing so, could save you guys a lot of precious time i guess, and
> would also be a big step into the right direction to help achieving a kind
> of x-platform 'standardisation' for media handling.

Um.

I'm building an Ogg mux/demux platform.  It has no other goal in mind
than turning Ogg into a framework that uses multiple internal codecs
seamlessly and presents a very easy to use encode/decode interface for
any and all Ogg transport streams and their contents.  This neither
duplicates nor works against UCI's goals.

However...

This points out the first problem with the UCI standard.  There is no
distinction I can see in any of the API docs between mux layer and
codec layer.  They're different things, handling different tasks.
What container format does UCI use?  MCF?  Ogg?  Any and all? It's
never mentioned.  To be useful and truly universal, it has to handle
AVI, QuickTIME, MPEG4 Transport, Ogg, ASF, etc.  These containers all
work differently (Ogg's division of labor is especially deviant), and
the real challenge which hasn't already been solved a thousand times
is here.

I'm going to continue working on seamless Ogg mux/demux.  The designed
API, both externally exposed to the application and internally exposed
to the codecs, is somewhat beyond what you're proposing, but it should
be perfectly useable within a well-designed UCI frame.

It's not that you don't have a large, unoccupied, useful space to code
in.  Just that the API, as I see it, has misidentified that space and
doesn't quite grasp what the real problems to be solved are.  Building
a Big Tool and solving specific identified problems are subtly
different tasks.

> Its maybe interesting to hear that the XviD team is discussing to drop VfW
> and use UCI as main API, mainly because of constant incompatibilities
> between all the supported APIs in XviD CVS.  Peter 'suxen_drol' Ross, the
> man responsible for the XviD APIs, was suggesting this lately on xvid-devel
> . There were even discussions between Alban 'albeu' Bedel and Alex about a
> mplayer wrapper for UCI ( based on libmpc i guess ), Alex wants to do the
> same for VfW.

My personal philosophy is to demonstrate it works first, then recruit
adherents.  I see a UCI API that doesn't work.  You might dispute that
conclusion until you try to use it in practice.  For one thing, Ogg
won't/can't fit in it.  That's not Ogg's fault.

> I am posting this to vorbis-devel instead of theora-devel because it would
> be a major boost for UCI if Vorbis had a UCI interface, so every Video
> enoding app ( and also audio encoding app ) being able to call UCI codecs
> could use Vorbis for the audio in the movies, same goes for theora and the
> video of course.

The problem here is that you're saying 'Theora' and 'Vorbis' while
ignoring the fact both slot into a larger framework called 'Ogg'.  The
highest level suggestion you make, that codecs should work together
seamlessly, is sound engineering.  What your proposals fail to deal
with is that Theora (or Vorbis) might be in Ogg, might be in AVI,
might be in whatever and that the exact details of inclusion in any of
these may vary.  You need to handle codecs and containers (mux/demux)
seamlessly.  I see no mux/demux plugin API, I see none of the hard
details of the encode API written down, etc. *All* of the rub is in
the details.  High-level design is easy.  Making it work in a world of
details is not.

Yes, you'll counter that Ogg currently doesn't have this API specced
either.  There's a difference here.  I'm writing it myself.  I'm
relying on no one else to do the work.  I gather input, it's true, but
Ogg is not a committee effort.  I code the first rev of every main
chunk.  It only needs to be in my head until it actually runs.

Is this a terrible, anti-community stance?  No, the first rev is meant
to be the suggested working spec.  It not only looks nice on paper, it
demostrates empirically the strengths and weaknesses of the design.  I
realize of course, you're working toward that.  But you're not there
yet.

I have no reason to work against or poo-poo the UCI project.  But I
also reserve the right to not take it seriously until it demonstrates
that it's both serious and capable of the engineering required.
Writing a good codec is a different skill that designing a good API.
Don't confuse enthusiasm with skill.  That's a caution and well meant,
not a condemnation.

Monty

<p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.