[UCI-Devel] Re: [vorbis-dev] Re: UCI Project Announcement

[alex at foogod.com]

On Wed, Oct 16, 2002 at 08:40:05PM -0400, Monty wrote:
> > 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.

Heh, sounded pretty rational to me, actually..  Anyway, I'm not looking for a
flamewar, so you probably wouldn't get one out of me even if you wanted one..

Thank you for responding to Christian's inquiry, BTW.. I sent out an
announcement a while back but never got anybody to give much input on what the
Ogg/Vorbis/Theora sector of things thought about UCI..  I really would like to
work together with you guys as much as possible, as I think both projects could
benefit from compatibility with the other.

> > 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 :-)

Not I, I admit, but if it's still around somewhere I'd very much appreciate a
pointer to it, as it sounds like something worth reading..

> 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.

Well, it's the "internal codecs" thing that I think Christian was noting..  UCI
is intended to make that sort of duplicated code/interface unnecessary, and add
flexibility, for example, in the variety of codecs which could be used by your
Ogg mux/demux platform..

> 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.

Heh.. funny, that's exactly my biggest complaint about the Ogg format, but
anyway..

Actually, regarding UCI, the truth is quite the contrary.  There is an
extremely strong distinction in the UCI standard between mux layer and codec
layer.  UCI _only_ covers the codec layer, it does not handle mux/demux at all
(the distinction, therefore, couldn't get much stronger).  It is designed to be
an API which can be used by mux/demuxers to interface to codecs.

That's not to say that we haven't been giving some thought to an additional
"Universal Muxing Interface" which would work alongside/on-top-of UCI down the
line.  Muxers are outside the scope of the UCI project, but we are keeping them
in mind for future development, and obviously keeping muxer's needs in mind
during UCI development.  The current plan is to get the codec interface right
first, and then move to the next logical step of doing a good muxer interface
on top of it.  If other people out there would like to begin consideration of
what form a "UMI" interface should take, that sort of input is welcome though..

> 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.

The purpose of UCI is to support as many different codec uses (including
muxers) as possible in a standard, interchangeable way.  It is quite possible
that the API still requires some refinements in order to handle a few
peculiarities of certain formats and potential uses, but that's why we are
asking for input now from those who are most familiar with those formats to
make sure the UCI system has what everyone needs to make it useful for a wide
variety of tasks.

> 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.

This seems unlikely, actually.  The problem is that what you describe as "the
designed API ... internally exposed to the codecs" appears to mostly duplicate
UCI's intended purpose (in a presumably incompatible way).  The suggestion
being made, I believe, was that we instead work together to try to make one
interface for codecs which both works with your Ogg mux/demuxer and can be more
generally useful as part of UCI's generalized codec interface (so codec makers
don't have to write to a different interface for your one muxer than for
everything else).

> 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.

I think, instead, that you have misidentified what UCI is intending to do.

It should also be noted that UCI is intended to solve specific, identified
problems, they just may not be the same problems you're thinking they are.

> 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.

Well, it may not be Ogg's fault, but it is at least partially the fault of the
various Ogg people out there who haven't bothered to give any input to the UCI
project about how it might be changed so that Ogg could fit in it.  This is
exactly why I sent out announcements asking for participation and input from
all over the current multimedia development community, so that UCI could be
designed with the needs of a wide variety of formats/codecs/apps in mind.  The
UCI spec is still in active development, and we would very much like to hear
your input (or input from anybody else big on the whole Ogg thing) on what you
feel it would need to work well with Ogg.

Currently the only issue I see off hand is Ogg's lack of codec-independent ways
to identify stream formats.  Please note that there are currently plans (which
haven't made it into the spec docs quite yet) to add support for codec "stream
probing" to allow codecs to identify whether they support a given format by
being passed a portion of the data stream to look at.  I believe this
mechanism, in addition to its other benefits, should be usable to address this
issue for Ogg-based decoding.  Ogg encoding should already be supported in this
regard as long as codecs include a fairly unique identifier in the "stream
metadata" they return (support of a wider range of codecs in Ogg streams would
presumably require some hacks along the lines of the whole OGM thing, which
would be left up to the multiplexer, but if there are ways that UCI can/should
make such things easier I'm open to suggestions).

If you know of other issues which present problems for using UCI from within an
Ogg muxer, please let me know, as we would very much like to try to fix them.

For the record, BTW, the UCI project is not attempting to recruit adherents
(well, Christian may be, but please note he doesn't necessarily speak for the
UCI project as a whole).  I am personally confident that if we do things right,
the value of UCI will become apparent without a great deal of evangelizing.  We
have posted a call for participation because we are looking for input and
active discussion from a wide range of sources, in an attempt to make a product
which is useful to a wide range of people (and having some additional developer
support doesn't hurt either).  Pete Ross and others have exhibited interest in
using the results, I believe, because they already see value in it.  I take
this as an encouraging sign that we are on at least some of the right tracks
with what we are doing.  I hope that we can address any Ogg issues sufficiently
that you guys might feel similarly optimistic about UCI's usefulness in your
areas of endeavor.  I do think it has the potential to be useful with Ogg as
well, if we put the thought into it now to make sure it works.

> > 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'.
[...]

I think we've gone through all of this..  You're trying to bundle muxing into
the same package as the codec interface.  The problem with this is that each
muxer then ends up with its own distinct way to interface to codecs, which
makes them all incompatible at the codec level.  This is why UCI is attempting
to define a standard interface _between_ muxers and codecs, so that a given
codec can be used by a variety of muxers and other applications, and
vice-versa, without having to write a custom interface for each.

> 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.

>From my own past experience, this is a good way to come up with a functional
specification which works well, for one limited purpose and nothing else.  This
is exactly the problem that most open source multimedia development is
suffering from (lack of code interchangeability and reusability), and is one of
the problems UCI is specifically trying to address.

Frankly, it sounds like we're both at about the same level of development (I am
currently in the process of writing the basic libuci code as well), the big
difference is that I'm presenting my current design specs and actively
soliciting comments and input from other folks early in the process, when it's
easiest to change one's ideas.

> 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.

Well, that's fair enough, but whether you take UCI seriously or not, I still
don't really see a reason why we should be deliberately reinventing the same
wheel instead of working to make things compatible..  I think it would be much
more productive to try to make the UCI design useful in an Ogg context (and
posess the features you're looking for), and thus the Ogg muxer you're working
on could use a UCI-style interface (note that you don't have to use our
implementation if you don't want to) to interface with codecs, instead of
inventing a different interface to no real advantage.  You get a codec
interface which works for your needs either way, but working with UCI you have
the potential added advantage (should UCI turn out to be more widely useful) of
the flexibility for Ogg to use other UCI-compatible codecs, and for
Theora/Vorbis to be used with other applications/formats/muxers besides just
your one Ogg muxer..

For what it's worth, I've had roughly 15 years of programming experience in
areas including operating systems, programming language design, databases,
networking (apps and protocol stacks), interface specifications, and
multimedia, and various other things, so I think I have a fairly good
understanding of what skills are required for various types of development
efforts.  Personally, based on my own experience, I'd suggest that you might
want to consider your own advice, as I've find your particular design approach
(code first, analyze later) to be often antithetical to designing
well-thought-out, useful, generalized APIs.

It should also be noted that if UCI does prove to be serious and capable (which
I'm pretty confident it will), and produces a product which gets adopted by a
fair number of other systems, it may then be too late to make sure that it
works with Ogg the way it should, and Ogg could easily get left out of the
loop.  I would rather not see that happen, which is why I would like to have
input at this stage, when it's still feasable to change things, from you guys
about what you think UCI needs to meet your requirements.

-alex
--- >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.