ogg dev - Aug 2010 - adwantages of ogg container?

On 2010-08-27, Ralph Giles wrote:
>> My question to you, What advantages has ogg vs matroska.
>
> They're both free containers, and there isn't a significant 
> performance difference, so either one works from a free media 
> perspective. [...]
Personally I would add the following points/bullets:

* Ogg has a lesser semantic burden, so that e.g. embedded
   implementations which necessarily have to be minimal are easier and
   cheaper to build; this of course means that a conforming Ogg
   implementation might not be as feature-rich as a Matroska one
* Ogg is a pure streaming protocol, whereas, IMO, Matroska tries to go a
   bit beyond that; so I'd argue Ogg is a bit better at "doing just one
   thing and doing it well"; I'd say it's "cleaner"
* Ogg goes more with the traditional single-use paradigm than Matroska,
   with its EBML and whatnot; it is still extensible in the IETF sense of
   the word, but more centralized control is effected; IMO that is a good
   thing -- or would you really like such an infrastructure oriented
   protocol to be extended willy-nilly? (think what would happen if
   people did that to IP? :)
* OTOH, the centralized decision process of Xiph/Ogg is much more open
   than Matroska's
* Because it's a stream protocol, Ogg decidedly isn't fit for
   bit-for-bit file storage; I tend to dislike the idea that an Ogg
   stream is stored as an Ogg file upon transmission
* For one reason or another -- which I'd really like somebody to
   research and document -- there are huge differences in the kind of
   content that is being disseminated using the two formats; I'm
   reasonably sure at least part of the difference has to have something
   to do with the specific needs of the communities using the protocols,
   instead of just adoption discrepancies
* There might just be a bit more coupling between the multiplexing and
   codec design within Ogg than there is with Matroska, which then of
   course means better layer separation/win for the latter; from what is
   seen in the wild Matroska is certainly used to multiplex a far wider
   set of codecs and whatnot than Ogg; but then Xiph/Ogg has its open
   source political aspirations as well, which severely limit what
   is/can be offered
* As a more centralized and "committee-bound" thingy, Matroska was
much
   more tighly engineered at its inception than Ogg, and it also seems
   a bit better geared to handle today's
   piece-of-media-over-stream-of-media preferences; I'm thinking this
   could explain much of its current market value

I'm certain I've left out a *ton* of points, so do continue with the 
topic. I mean, the reason I responded in the first place is that I 
personally have the tendency to *really* overengineer stuff, which would 
make me a Matroska lover, yet then I have a persistent bad feeling about 
that tendency because that's "not the internet way". I would
*love* to
learn about some further/finer points, and of course counterpoint.
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Am Freitag, den 27.08.2010, 20:51 +0300 schrieb Sampo
Syreeni:
> On 2010-08-27, Ralph Giles wrote:
> 
> >> My question to you, What advantages has ogg vs matroska.
> >
> > They're both free containers, and there isn't a significant 
> > performance difference, so either one works from a free media 
> > perspective. [...]
> 
> Personally I would add the following points/bullets:
> 
> * Ogg has a lesser semantic burden, so that e.g. embedded
>    implementations which necessarily have to be minimal are easier and
>    cheaper to build; this of course means that a conforming Ogg
>    implementation might not be as feature-rich as a Matroska one
> * Ogg is a pure streaming protocol, whereas, IMO, Matroska tries to go a
>    bit beyond that; so I'd argue Ogg is a bit better at "doing
just one
>    thing and doing it well"; I'd say it's "cleaner"
Doing one thing seem to be good reason. User normally see just file name
say bla.ogg or bla.mkv . Matroska may contain mp3+x264, this mix will
not work out of the box on really GPLed linux. By ogg you normally know
what it contain. Other thing is reduced matroska -> webm. This container
do one thing too.

Are there any good reason why ogg do not do frame timestamps (or
variable frame rate)? Or your first point, easy/embeded systems, is the
answer?

> Are there any good reason why ogg do not do frame timestamps (or
It does...
The mapping for Theora to Ogg does not, though, which is probably what
you were thinking about.

Ogg pages have a timestamp. It also allows you to stuff more than one
packet per page, if packets can have a deduced timestamp. If they have
each their own individual timestamp that's arbitrary, then you place
each in a page, and place your particular timestamps there. You get
more 'compression' from stuffing more packets per page though, so as
usual it's a tradeoff.

On 2010-08-27, Alexey Fisher wrote:
> Doing one thing seem to be good reason. User normally see just file 
> name say bla.ogg or bla.mkv . [...]
Yes, that might be a benefit as well. But an unexpected one: in 
well-designed and matched protocol environments, if you expect to see 
some array of differing protocols, you will also see an easy way of 
discerning those protocols from each other. Before engaging in any sort 
of decoding endeavor.

File names, resource fork types or IFF/RIFF block types do not seem to 
be working quite like that, so you shouldn't be relying on them. They 
just do not disambiguate the content fully. Something else is needed. 
That else is usually, and sadly, contained within the file/stream, and 
it can be quite complex to decode. The worst part of course is that the 
lower level semantics of a TCP stream or a common OS file is just a 
stream of bytes, which means that there is no fully predictable type 
designator for the stuff at all. Ogg makes it simpler by limiting 
options, but even it can be rather difficult to deal with.

For some strange reason the network engineers always include a type 
field in the lower level protocol which refers to a formal specification 
of how the higher level protocol is supposed to deal with/interpret the 
data that it's given. AFAIK no file system does the same, eventhough 
they too store and retransmit data. (Even Apple seems to have typing 
only for resource forks, not the primary datafile.)
> By ogg you normally know what it contain.
Normally, yes. But not always. That then kills interoperability. A 
*real* "one-aim, one protocol" architecture would simply need no 
options. Even the usual IETF way of doing things would dictate options 
have to be fully backwards compatible, in all regards. The IETF has 
broken the principle quite a number of times, implicitly, but the design 
criterion stays the same: once you define a protocol, in principle 
everything from here to the end of time should be decodable, and with 
minimum changes even efficiency-wise. That's not happening with most 
extensible protocols, like Ogg or Matroska, because their extensibility 
architecture works by superceding packet types, and not by compatibly 
extending them so that further versions are enhanced without dropping 
support for earlier version receivers.
> Are there any good reason why ogg do not do frame timestamps (or 
> variable frame rate)? Or your first point, easy/embeded systems, is 
> the answer?
AFAIK Ogg actually does do timestamps, only at a low resolution and in a 
form whose precise format is upto the multiplexed protocol. That is, if 
you want to get relative time information out of an Ogg stream, you will 
have to understand each of the multiplexed protocols within it in order 
to properly decode the granule timing. Then, there is no absolute timing 
requirement that I'm aware of; just the fact that each of the commonly 
Ogg multiplexed formats has one, and the silent assumption that the kind 
of real-time streamed content that Ogg primarily supports would properly 
have that as well.

Whether or not handling timing (and searching by time; a very big debate 
in early Ogg development) this way is a layer violation is a source of 
considerable contention. It's not clear this sort of protocol should 
even care about time, and quite certainly Ogg's treatment of time is 
adequate, as designed, for mostly-reliable stream transports. Files, 
there the reasoning goes haywire, serious loss over the transport path, 
it kills ogg, editing operations on the stream and/or the resultant file 
after saving the stream an sich, certainly very inefficient. But then 
based on the original design and implementation documentation, that 
shoudln't have been a surprise, because it was an implementation choice 
to the contrary, very simple and low overhead, minimum latency, 
streaming multimedia multiplexing end of the spectrum.

Personally, I think Ogg is a multiplexing framework which is right now 
dead, and perhaps should be resuscitated when IPv6 multicast finally 
covers some ground. As a file format, I wouldn't go with it -- but then 
I'd seriously consider reimplementing all of its unique features, 
because as an architecture, it's *extremely* well thought out, and has 
some unique benefits. Typing of flows and other data -- a particular 
concern of mine -- I'd say most protocols do that well, but when 
multiple combinations of inner protocols are enabled using extension 
mechanisms, not enough care is taken with layer separation.

I'd probably have pages worth of pet peeves to share, but let me share 
the final one: what precisely stopped the developers of these protocols 
from a) first putting up an implementation as a proof of concept, and b) 
then relinguishing the development of the precise protocol to IETF, for 
development as an Internet Standard? That way it's *certain* that all of 
the format issues I've raised, and the also the bandwidth, vendor 
compatibility, deprecation, whoknowswhat issues would eventually have 
been aggressively vetted out. Had that happened, perchance we could now 
have a single multiplexing standard with more overall support and 
balance, or if two, at least a better architecture for them both.

I would hate to relinguish a standard I originated if it ever came to 
that. But this sort of situation really does tell you that you should do 
it for the common internet welfare.
-- 
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Sampo Syreeni wrote:
> * Because it's a stream protocol, Ogg decidedly isn't fit for
>    bit-for-bit file storage;
What about Ogg/PCM. Its probably not well supported, but it is
out there.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/