[vorbis-dev] Carrying non-audio data in an Ogg/Vorbis I stream

[Svante Seleborg]

Hi,

Thanks for the fast response!

SS> I would like to "piggy-back" other data in an Ogg/Vorbis I 
>physical stream
>SS> (i.e. file) in a manner that does not conflict with specifications and
>SS> existing decoders/players/editors etc.
>If you read the OGG framing:
>http://www.xiph.org/ogg/vorbis/doc/oggstream.html
>http://www.xiph.org/ogg/vorbis/doc/framing.html
>You'll learn that Ogg is the octet stream framing spec and vorbis an
>audio compression codec. Basically, in Ogg you put a series of packets
>that contain any stream. And you can multiplex this streams. The only
>constraint is that the ogg headers of each stream must be consecutive
>and no new stream can begin until all streams have ended. So when you
>concatenate any number of valid ogg files you get another valid ogg
>file (which is breakable). So what you want is to define a different
>ogg stream, a non vorbis stream, and multiplexit. If it's very little
(snip, a little bit)

I did read it all... I might have missed something though, but I was
under the impression that "Ogg/Vorbis I" specifically meant Vorbis
encoded audio carried in an Ogg stream, under some very specific
restrictions, the major one here being that multiplexing of the Ogg
stream is not allowed - only chaining. See the "Restrictions" section
of http://www.xiph.org/ogg/vorbis/doc/vorbis-ogg.html.

The point of the excercise is to bring other data in there, without
breaking this specification or violating these constraints.

Just doing it with Ogg as such is not the issue.

>The Theora project is working specifically on this infrastructure.You
>should join their list.

Thanks for the idea - I'll check that out. Perhaps they have defined a
way to bring video in that I can use as a basic methodology, although
I'm pretty sure that they must break the "Ogg/Vorbis I" constraints
by multiplexing, at least.

I should also clarify - it's not necessarily video I want to bring
in there.

>
>SS> As far as I can see, I have some possible choices:
>
>SS> 1 - Chaining a logical bistream at the end. If this is the way to
>SS> go, two questions arise to begin with:
>You could but is not the best alternative.
>SS> q1a - How to identify this stream in a future-proof way? Just
>SS> invent a new header, beginning with 'm' 'y' 'h' 'e' 'a' 'd' 'e'
>SS> 'r' ?
>Using a different ogg header. You should actually contact the Theo
>Project.

That was what I meant, sorry if I was unclear. I meant using a 'private'
header for the chained logical bitstream. I assume you mean the 'Theora'
project when you say 'Theo' - but why should I contact them?

>SS> q1b - I have not found any specifications on how a decoder should
>SS> handle this - obviously I want a silent ignore, not an error
>SS> message or even worse, a failure to decode. Is this defined
>SS> somewhere?
>If it has a non vorbis header, it should be ignored by a vorbis player
>(by specification).

Could you please point it out to me? I can't find anywhere where the
behavior of a player upon encountering a non-vorbis stream chained
to a vorbis-stream in an Ogg formatted stream is defined.

(snip)
>SS> 4 - Can I possibly just concatenate a completely separate Ogg
>SS> stream at the end of the first one? This seems to violate the
>SS> constraints of an Ogg/Vorbis I stream though.
>No. Don't confuse vorbis and ogg. It may be a kind of solution, but
>then if I concatenate variousvorbis files (like the tracks of a CD) it
>may breack some stupid players. And if some of those files have your
>data and some don't, you get a not very clear situation.

I hope I'm not confusing it... I'm specifically looking at the
combination of Vorbis in an Ogg stream, as defined by
"Ogg Vorbis I format specification".

What you seem to be saying is that behavior is not defined for
players encountering concatenated Ogg streams. Is that is so - then
that idea certainly goes down the drain.

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