On 20-08-08 17:22, Bernd Petrovitsch wrote:
On Mon, 2008-08-11 at 11:31 +0200, Rene Herman wrote:
On 11-08-08 10:02, Rohit Sharma wrote:
What all possible use cases are there for multiple data stream? (
apart from spy wares and other destructive uses )
As in filesystem forks? The most convincing one I feel is video, or
more specifically A/V interleaving. Without forks you end up
solving the same problem a few hundred times in container formats
(matroska, ogg, avi and so on) with specialized tools needed for
each. With filesystem forks the
Define a generic API and provide a compatibility lib until all but
one died. Problem solved.
Hurray! Well, except for the problem that by this time you're dead as well.
Don't get me wrong please. I formulated it as "the most convincing one"
implying that anything else is even less convincing. I am not suggesting
everyone run out and implement kernel level forks.
It's just sad reality that everything you leave non-central just always
invites a hundred different and diverging implementations with different
and diverging bugs, together destroying useability of it all. A more
central implementation than kernel based isn't available.
Ofcourse, with A/V being generally very cross-platform, a linux kernel
based implementation isn't in fact very central anyway but this was just
about the idea of things.
The huge, incredible A/V mess -- and especially so on Linux -- has been
annoying the crap out of me for a few years now so it was an example
close to heart. I'm using ogg exclusively for audio (vorbis), but when
video enters the picture, run for cover.
It's not like you can actually stick an mpeg inside an ogg for example.
You need a slightly tweaked ogm format to do that. An obsolete and
probably non-compiling format and set of tools by now ofcourse. Or put
it in avi, after you've found and mastered the tools for that, or
matroska, with yet another set of not so shiny tools, or DVD format, with...
I pee on video people!
interleaving implementation is provided and lets you for example very
easily extract the soundtrack; or the multiple soundtracks for multiple
languages. And the subtitles. And ...
The problem with that idea is that no problem is solved. The video and
audio streams need additional meta-data like codec and perhaps
codec-specific parameters, sample rates, language of the sound stream
and subtitles and font/encoding of the subtitles[0] (and God knows what
else).
What's the problem? Every stream can have its own header just fine.
Not going to go into the rest. As said, note how it was formulated. I'm
not suggesting that forks are generally wonderful and in fact, the
central interleaving implementation is also just about the _only_
advantage that I see.
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
