[ogg-dev] Peer review draft for the new media types/file
silviapfeiffer1 at gmail.com
Wed Oct 3 15:46:32 PDT 2007
On 10/4/07, Ivo Emanuel Gonçalves <justivo at gmail.com> wrote:
> > * references are missing
> All references are missing. I'm leaving that to the very end, when we
> are all sure what goes in the document and what doesn't.
That's a pretty poor approach - we will possibly need to write some of
the specs and by authoring the references section early, we will
identify what specs are still missing and going to provide trouble. I
usually start writing a paper or I-D with the references section for
> > - replace "video, audio, or text format" with "a/v codec or more
> > generally time-continuously sampled data" (stay generic or we will
> > have to rewrite the rfc in future again).
> That seems to suffer from the same problem, I think. Better wording is needed.
My wording is more generic - it says "time-continuously sampled data"
and mentions a/v codec data a special case of that - I don't think you
can get more generic than that. Try reading the full sentence with my
> > - replace "non-standard visual and audio material" with "generic use"
> I do not agree. This is application/ogg we are talking about. It's
> not for generic use, as far as I understood.
This is application/ogg we are talking about. Ogg is a container
format in principle ready for any generic time-continuously sampled
data, not just audio and video. I would not want to restrict us for
the future to just audio and video.
> > - I don't think the base64 encoding suggestion is correct for Ogg
> > encapsulated content; the data in packets is simply a sequence of
> > bytes that Ogg deals with; just remove "base 64 is a suitable
> > encoding"
> It's a suited encoding for e-mail and the "data:" element in HTML.
> It's also used on the MPEG, 3GPP, MPEG-4, and even our own RFC3543.
Yes, I read that and thought that RFC3534 was wrong. base64 is used
to encode binary data inside text containers. email and html are text
containers. Ogg is a binary container and thus does not need to
re-encode, FAIK. But maybe somebody can correct me.
> > - also: I have a question about the mac file type code - does it
> > make sense to call it "OggS" everywhere?
> Paging Monty. I followed RFC3534's lead here.
Monty won't know or care I think - we need to ask Arek Korbik, author of XiphQT.
> If we were more mainstream, this would be a logical demand we could
> do, but considering our situation, the less we complicate things to
> developers, the better we will be. Work around this issue somehow,
Skeleton will make the lives of developers easier, not harder.
More information about the ogg-dev