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