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

[ChristianHJW]

"Monty" <xiphmont at xiph.org> wrote in message
news:20021017004005.GB16021 at xiph.org...
> > 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.

Not at all Monty, not at all ! In fact i am happy you took the time to
answer in such a detailled form. Estimating your time shedule every day, i
was positively surprised.

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

So i misunderstood you here. What you are thinking about right now is more
like  UFI  ( Universal Format Interface ) , something the MCF team was
requesting also from Alex as we need it desperately to complement UCI for
interfacing to other formats. However, Alex made clear to us that he will
first finish UCI ( caring about codec interfacing only ) , before he will
start to even think about making UFI ( makes sense ).

Codec recognition is a big issue for us, as we dont only have to deal with
the brilliant Xiph codecs, but also with all existing VfW, Realmedia,
Quicktime, etc. codecs, so our work is ressembling here. Honestly speaking,
we havent been able to come up with a good, striking solution for the time
being, it seems using GUIDs was the best compromise for all platforms, we'll
discuss this further.

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

UCI doesnt care at all about formats. As i understand it its meant to be a
light, easy to understand and implement codec interface, giving every codec
developer the chance to integrate an interface into his codec that would
allow using it with many other applications, given they can use the UCI
interface. XviD is currently the only codec project that has real interest
to do this, i am personally talking to people who could be adding UCI
support to Virtualdub for Windows ( not whith AVI output of course ),
mplayer people consider a UCI wrapper for mencoder and mplayer.

> 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

I apologize if my mail was not perfectly clear here, i am using english
language a lot, but still i am not a native speaker. I had 2 intentions with
my mail :

1. Possible positive input from UCI to Theora API

2. UCI interface in Vorbis

In detail :

1. I understand you are not looking at theora as a codec now, but at the Ogg
bitstream and framework in general. Although i am not a coder even i can
understand this API has to be very Ogg specific, and UCI doesnt cover any of
its tasks. UFI might be a valuable source one day, but its not even started
yet ( maybe in Alex' brains ). UCI could probably be of help if you do
design the interface to the theora codec one day, not sure here.

2. In any case i'd love to see a UCI interface in Vorbis CVS ( and maybe
even theora later ? ) one day, because this would boos the idea behind UCI a
lot, baring in mind that Vorbis is the most successful opensource codec
ever, and its still at its very beginning. I dont understand enough of it to
know if this interface required a different compilation, or could be
integrated in normal vorbis, but in any case it would be acceptable.

Thanks for you answers Monty, lets fight together for the success of open
source ... irrespective of the platform its used on  :-)   !

Christian

Sites : http://mcf.sourceforge.net
http://sf.net/projects/mcf
MCF mailing lists : news://news.gmane.org
gmane.comp.video.mcf.general
gmane.comp.video.mcf.devel
gmane.comp.video.mcf.mplayer
gmane.comp.video.mcf.announce
gmane.comp.video.mcf.mpc
Soon :  www.corecodec.com

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