[ogg-dev] adwantages of ogg container?

[Sampo Syreeni]

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