<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_03_03_1913246</id>
	<title>Technical Objections To the Ogg Container Format</title>
	<author>timothy</author>
	<datestamp>1267644300000</datestamp>
	<htmltext>E1ven writes <i>"The Ogg container format is being promoted by the Xiph Foundation for use with its Vorbis and Theora codecs. Unfortunately, a number of <a href="http://hardwarebug.org/2010/03/03/ogg-objections/">technical shortcomings in the format</a> render it ill-suited to most, if not all, use cases. This article examines the most severe of these flaws."</i></htmltext>
<tokenext>E1ven writes " The Ogg container format is being promoted by the Xiph Foundation for use with its Vorbis and Theora codecs .
Unfortunately , a number of technical shortcomings in the format render it ill-suited to most , if not all , use cases .
This article examines the most severe of these flaws .
"</tokentext>
<sentencetext>E1ven writes "The Ogg container format is being promoted by the Xiph Foundation for use with its Vorbis and Theora codecs.
Unfortunately, a number of technical shortcomings in the format render it ill-suited to most, if not all, use cases.
This article examines the most severe of these flaws.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382</id>
	<title>Technical Objections by Armchair Engineer?</title>
	<author>guruevi</author>
	<datestamp>1267610700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>His complaints:</p><p> <i>On top of this we have the 27-byte page header which, although paling in comparison to the packet size encoding, is still much larger than necessary.</i> <br>Ok, it's a container format, nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing. And if you're complaining because it needs to go in the intertubes, gz compression on the server does a very good job of extracting and compressing plain non-random text like page headers but again, MBits are cheap and unless you're living in the US they are plenty.</p><p> <i>The version field could be disposed of, a single-bit marker being adequate to separate this first version from hypothetical future versions. One of the unused positions in the flags field could be used for this purpose</i> <br>It's kind of important to keep track of versions. If your player can't play the next version or an older version it should be able to detect that so it doesn't try-and-fail. It might also want to suggest what version of the player is required.</p><p> <i>A 64-bit granule\_position is completely overkill. 32 bits would be more than enough for the vast majority of use cases. In extreme cases, a one-bit flag could be used to signal an extended timestamp field.</i> <br>That's what they said about our memory too back in the early 90's. 32-bit addressing is enough, nobody will ever have more than 4G of RAM. Again, these open formats tend to be scalable across time because they need to fulfill a certain mission. Look at ZFS, they have 128-bit addressing but nobody (currently) needs that amount of storage.</p><p> <i>32-bit elementary stream number? Are they anticipating files with four billion elementary streams? An eight-bit field, if not smaller, would seem more appropriate here.</i> <br>Why not, how many languages are there around the world? If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.</p><p> <i>The 32-bit page\_sequence\_number is inexplicable. The intent is to allow detection of page loss due to transmission errors. ISO MPEG-TS uses a 4-bit counter per 188-byte packet for this purpose, and that format is used where packet loss actually happens, unlike any use of Ogg to date.</i> <br>Well, maybe the makers intended Ogg to be used eventually to replace MPEG (c)(patented) and used across links with much higher transmission errors. Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts. When NASA wants to use Ogg for a non-repeatable stream from outer space, they should be able to. Again, overhead is a small cost to pay these days.</p><p> <i>A mandatory 32-bit checksum is nothing but a waste of space when using a reliable storage/transmission medium. Again, a flag could be used to signal the presence of an optional checksum field</i> <br>Ah, well, what is reliable these days? Ever used a large array of hard drives? Ever used a freakin' dial-up connection? As the makers of ZFS, Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted. Silent data corruption is a major cause of data loss these days.</p><p> <i>With the changes suggested above, the page header would shrink from 27 bytes to 12 bytes in size.</i> <br>Whoop-dee-doo, you made it half the size but you sacrificed reliability, error correction and future-proofness.</p><p> <i>Latency</i> <br>You show that the overhead is anywhere from 1\% to 7\%. That might not be the requirements for latency-sensitive applications but then you would again sacrifice other features. That is always a balance between speed and reliability but for most applications it doesn't really matter if the  movie needs to be buffered 5ms longer.</p><p> <i>Random access</i> <br>You've got somewhat of a point there, maybe somebody will find a solution for that. The issues around indexing however is that seeking within a stream <b>is</b> possible. HTTP servers</p></htmltext>
<tokenext>His complaints : On top of this we have the 27-byte page header which , although paling in comparison to the packet size encoding , is still much larger than necessary .
Ok , it 's a container format , nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing .
And if you 're complaining because it needs to go in the intertubes , gz compression on the server does a very good job of extracting and compressing plain non-random text like page headers but again , MBits are cheap and unless you 're living in the US they are plenty .
The version field could be disposed of , a single-bit marker being adequate to separate this first version from hypothetical future versions .
One of the unused positions in the flags field could be used for this purpose It 's kind of important to keep track of versions .
If your player ca n't play the next version or an older version it should be able to detect that so it does n't try-and-fail .
It might also want to suggest what version of the player is required .
A 64-bit granule \ _position is completely overkill .
32 bits would be more than enough for the vast majority of use cases .
In extreme cases , a one-bit flag could be used to signal an extended timestamp field .
That 's what they said about our memory too back in the early 90 's .
32-bit addressing is enough , nobody will ever have more than 4G of RAM .
Again , these open formats tend to be scalable across time because they need to fulfill a certain mission .
Look at ZFS , they have 128-bit addressing but nobody ( currently ) needs that amount of storage .
32-bit elementary stream number ?
Are they anticipating files with four billion elementary streams ?
An eight-bit field , if not smaller , would seem more appropriate here .
Why not , how many languages are there around the world ?
If you need to bring out a media file with subtitles and audio-tracks for each language , braille instructions and who knows what else for open access to certain media , you might want to use more than 256 streams .
The 32-bit page \ _sequence \ _number is inexplicable .
The intent is to allow detection of page loss due to transmission errors .
ISO MPEG-TS uses a 4-bit counter per 188-byte packet for this purpose , and that format is used where packet loss actually happens , unlike any use of Ogg to date .
Well , maybe the makers intended Ogg to be used eventually to replace MPEG ( c ) ( patented ) and used across links with much higher transmission errors .
Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts .
When NASA wants to use Ogg for a non-repeatable stream from outer space , they should be able to .
Again , overhead is a small cost to pay these days .
A mandatory 32-bit checksum is nothing but a waste of space when using a reliable storage/transmission medium .
Again , a flag could be used to signal the presence of an optional checksum field Ah , well , what is reliable these days ?
Ever used a large array of hard drives ?
Ever used a freakin ' dial-up connection ?
As the makers of ZFS , Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted .
Silent data corruption is a major cause of data loss these days .
With the changes suggested above , the page header would shrink from 27 bytes to 12 bytes in size .
Whoop-dee-doo , you made it half the size but you sacrificed reliability , error correction and future-proofness .
Latency You show that the overhead is anywhere from 1 \ % to 7 \ % .
That might not be the requirements for latency-sensitive applications but then you would again sacrifice other features .
That is always a balance between speed and reliability but for most applications it does n't really matter if the movie needs to be buffered 5ms longer .
Random access You 've got somewhat of a point there , maybe somebody will find a solution for that .
The issues around indexing however is that seeking within a stream is possible .
HTTP servers</tokentext>
<sentencetext>His complaints: On top of this we have the 27-byte page header which, although paling in comparison to the packet size encoding, is still much larger than necessary.
Ok, it's a container format, nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing.
And if you're complaining because it needs to go in the intertubes, gz compression on the server does a very good job of extracting and compressing plain non-random text like page headers but again, MBits are cheap and unless you're living in the US they are plenty.
The version field could be disposed of, a single-bit marker being adequate to separate this first version from hypothetical future versions.
One of the unused positions in the flags field could be used for this purpose It's kind of important to keep track of versions.
If your player can't play the next version or an older version it should be able to detect that so it doesn't try-and-fail.
It might also want to suggest what version of the player is required.
A 64-bit granule\_position is completely overkill.
32 bits would be more than enough for the vast majority of use cases.
In extreme cases, a one-bit flag could be used to signal an extended timestamp field.
That's what they said about our memory too back in the early 90's.
32-bit addressing is enough, nobody will ever have more than 4G of RAM.
Again, these open formats tend to be scalable across time because they need to fulfill a certain mission.
Look at ZFS, they have 128-bit addressing but nobody (currently) needs that amount of storage.
32-bit elementary stream number?
Are they anticipating files with four billion elementary streams?
An eight-bit field, if not smaller, would seem more appropriate here.
Why not, how many languages are there around the world?
If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.
The 32-bit page\_sequence\_number is inexplicable.
The intent is to allow detection of page loss due to transmission errors.
ISO MPEG-TS uses a 4-bit counter per 188-byte packet for this purpose, and that format is used where packet loss actually happens, unlike any use of Ogg to date.
Well, maybe the makers intended Ogg to be used eventually to replace MPEG (c)(patented) and used across links with much higher transmission errors.
Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts.
When NASA wants to use Ogg for a non-repeatable stream from outer space, they should be able to.
Again, overhead is a small cost to pay these days.
A mandatory 32-bit checksum is nothing but a waste of space when using a reliable storage/transmission medium.
Again, a flag could be used to signal the presence of an optional checksum field Ah, well, what is reliable these days?
Ever used a large array of hard drives?
Ever used a freakin' dial-up connection?
As the makers of ZFS, Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted.
Silent data corruption is a major cause of data loss these days.
With the changes suggested above, the page header would shrink from 27 bytes to 12 bytes in size.
Whoop-dee-doo, you made it half the size but you sacrificed reliability, error correction and future-proofness.
Latency You show that the overhead is anywhere from 1\% to 7\%.
That might not be the requirements for latency-sensitive applications but then you would again sacrifice other features.
That is always a balance between speed and reliability but for most applications it doesn't really matter if the  movie needs to be buffered 5ms longer.
Random access You've got somewhat of a point there, maybe somebody will find a solution for that.
The issues around indexing however is that seeking within a stream is possible.
HTTP servers</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350328</id>
	<title>Re:Flawed reasoning...</title>
	<author>keeboo</author>
	<datestamp>1267610400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>It is not in the header, the 8-bit version field is in every single page. As according to the post a page is mostly 64K due to a strange length encoding, you send the version very, very often. I don't see any reason, why the version would have to change in the middle of a file in any case. And honestly, would you write a decoder taking that into account, if the probability of stumbling onto such a file was currently 0 (due to there being only one version) and very, very low in the future? That means it just adds to the size of the file.</p></div><p>I think the idea of sending such redundant data is to allow decoding from any point of the stream (think of internet radio, for example... are they going to compress the data for each user connected?).</p></div>
	</htmltext>
<tokenext>It is not in the header , the 8-bit version field is in every single page .
As according to the post a page is mostly 64K due to a strange length encoding , you send the version very , very often .
I do n't see any reason , why the version would have to change in the middle of a file in any case .
And honestly , would you write a decoder taking that into account , if the probability of stumbling onto such a file was currently 0 ( due to there being only one version ) and very , very low in the future ?
That means it just adds to the size of the file.I think the idea of sending such redundant data is to allow decoding from any point of the stream ( think of internet radio , for example... are they going to compress the data for each user connected ?
) .</tokentext>
<sentencetext>It is not in the header, the 8-bit version field is in every single page.
As according to the post a page is mostly 64K due to a strange length encoding, you send the version very, very often.
I don't see any reason, why the version would have to change in the middle of a file in any case.
And honestly, would you write a decoder taking that into account, if the probability of stumbling onto such a file was currently 0 (due to there being only one version) and very, very low in the future?
That means it just adds to the size of the file.I think the idea of sending such redundant data is to allow decoding from any point of the stream (think of internet radio, for example... are they going to compress the data for each user connected?
).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349708</id>
	<title>Re:what is the point, exactly.</title>
	<author>Anonymous</author>
	<datestamp>1267607580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>well without containers, you'd have to have separate files for the audio and video, and subtitles</p></htmltext>
<tokenext>well without containers , you 'd have to have separate files for the audio and video , and subtitles</tokentext>
<sentencetext>well without containers, you'd have to have separate files for the audio and video, and subtitles</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360524</id>
	<title>Re:what is the point, exactly.</title>
	<author>stardaemon</author>
	<datestamp>1267730280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I'm not an expert in video or audio production, I just dabble in it as a hobby. but one thing I often wonder is, what is the point of these container formats?</p><p>I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video.  Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg.  Mjpeg files don't work in my editor, while miniDV does.  but I didn't know this at first, all I knew was that I have a bunch of<nobr> <wbr></nobr>.AVI files sitting in my hard drive, some work, some don't.  I dont care about file extensions, I care about having files that work.  I care about codecs.  If they were named "filename.minidv" and "filename.mjpg" that information would be useful to me.  What good is a container format when only half of the files within that container will play on my system?
I'm not trying to knock the idea of container formats, if they exist, their must be some beneficial reason for them.  Could someone please enlighten me on what that reason is?</p></div><p>Faster seeking (index), multiple audio and subtitle streams, chapters. Just of the top of my head. There are probably others, like having video and audio in the same file to begin with;)</p></div>
	</htmltext>
<tokenext>I 'm not an expert in video or audio production , I just dabble in it as a hobby .
but one thing I often wonder is , what is the point of these container formats ? I 've got a miniDV camera , and a canon point and shoot that thanks to chdk can record good-enough video .
Both give me " .AVI " files , even though one is miniDV , while the other is Mjpeg .
Mjpeg files do n't work in my editor , while miniDV does .
but I did n't know this at first , all I knew was that I have a bunch of .AVI files sitting in my hard drive , some work , some do n't .
I dont care about file extensions , I care about having files that work .
I care about codecs .
If they were named " filename.minidv " and " filename.mjpg " that information would be useful to me .
What good is a container format when only half of the files within that container will play on my system ?
I 'm not trying to knock the idea of container formats , if they exist , their must be some beneficial reason for them .
Could someone please enlighten me on what that reason is ? Faster seeking ( index ) , multiple audio and subtitle streams , chapters .
Just of the top of my head .
There are probably others , like having video and audio in the same file to begin with ; )</tokentext>
<sentencetext>I'm not an expert in video or audio production, I just dabble in it as a hobby.
but one thing I often wonder is, what is the point of these container formats?I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video.
Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg.
Mjpeg files don't work in my editor, while miniDV does.
but I didn't know this at first, all I knew was that I have a bunch of .AVI files sitting in my hard drive, some work, some don't.
I dont care about file extensions, I care about having files that work.
I care about codecs.
If they were named "filename.minidv" and "filename.mjpg" that information would be useful to me.
What good is a container format when only half of the files within that container will play on my system?
I'm not trying to knock the idea of container formats, if they exist, their must be some beneficial reason for them.
Could someone please enlighten me on what that reason is?Faster seeking (index), multiple audio and subtitle streams, chapters.
Just of the top of my head.
There are probably others, like having video and audio in the same file to begin with;)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349842</id>
	<title>Re:what is the point, exactly.</title>
	<author>Anonymous</author>
	<datestamp>1267608060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you dont have a standard container then you would have to invent new ways of encoding audio video and subtitle information into one file anyways. Containers allow you to use already well developed ways of encoding this information (mp3, mpeg, ASS for example) and combine them into one file which is properly synced and aligned. If you didnt have container formats you would have to develop a bunch of new technologies to encode them all together in some new way and then play them back. Or you could just leave them seperate, but this means to play a video you would have to keep at least 3 times as many files around, and manually point your player to each, not to mention syncing issues.</p></htmltext>
<tokenext>If you dont have a standard container then you would have to invent new ways of encoding audio video and subtitle information into one file anyways .
Containers allow you to use already well developed ways of encoding this information ( mp3 , mpeg , ASS for example ) and combine them into one file which is properly synced and aligned .
If you didnt have container formats you would have to develop a bunch of new technologies to encode them all together in some new way and then play them back .
Or you could just leave them seperate , but this means to play a video you would have to keep at least 3 times as many files around , and manually point your player to each , not to mention syncing issues .</tokentext>
<sentencetext>If you dont have a standard container then you would have to invent new ways of encoding audio video and subtitle information into one file anyways.
Containers allow you to use already well developed ways of encoding this information (mp3, mpeg, ASS for example) and combine them into one file which is properly synced and aligned.
If you didnt have container formats you would have to develop a bunch of new technologies to encode them all together in some new way and then play them back.
Or you could just leave them seperate, but this means to play a video you would have to keep at least 3 times as many files around, and manually point your player to each, not to mention syncing issues.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174</id>
	<title>Just complaining</title>
	<author>Anonymous</author>
	<datestamp>1267648200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>"I would have done it diffferently" does not mean that the format is bad.  None of these "flaws" render the format unusable.  Maybe it doesn't perform as well as another format, maybe it isn't designed the way you would like, but it's implemented, it's available, and it's in use.</p></htmltext>
<tokenext>" I would have done it diffferently " does not mean that the format is bad .
None of these " flaws " render the format unusable .
Maybe it does n't perform as well as another format , maybe it is n't designed the way you would like , but it 's implemented , it 's available , and it 's in use .</tokentext>
<sentencetext>"I would have done it diffferently" does not mean that the format is bad.
None of these "flaws" render the format unusable.
Maybe it doesn't perform as well as another format, maybe it isn't designed the way you would like, but it's implemented, it's available, and it's in use.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350220</id>
	<title>Re:Flawed reasoning...</title>
	<author>noidentity</author>
	<datestamp>1267609860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>There's at least one obvious flaw in his reasoning. He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version. That only works if one assumes there will only *ever* be two versions (v1 and v2). Such a basic failing of analysis is a pretty good indicator that he hasn't thought it all through as completely as he thinks he has.</p></div>
</blockquote><p>Actually, it shows the opposite to me. You have the current version, which decoders know how to decode. You also have slight revisions that don't break current decoders. And you have a future version that does break current decoders. Thus, you have a single flag in <i>each</i> version, specifying whether the file is that version, or the next one.

</p><p>To determine file version, you first parse the file as the first version; if its "next version" flag is set, you then parse it as the second version; if <i>its</i> "next version" flag is set, you parse as version 3, etc. It only makes sense for a bitstream though (I haven't looked to see which this is). And it seems mostly a theoretically-elegant approach, in that it has no limit to the number of versions, and for each new version, the change is the same.

</p><p>Practically, a version field seems simpler for everyone. And this doesn't rule out the above scheme, it just means you have versions 0-254 (assuming an 8-bit version field), and then version 255 which adds a second version field. Maybe the site isn't Slashdotted anymore so I can read his comments as well.</p></div>
	</htmltext>
<tokenext>There 's at least one obvious flaw in his reasoning .
He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version .
That only works if one assumes there will only * ever * be two versions ( v1 and v2 ) .
Such a basic failing of analysis is a pretty good indicator that he has n't thought it all through as completely as he thinks he has .
Actually , it shows the opposite to me .
You have the current version , which decoders know how to decode .
You also have slight revisions that do n't break current decoders .
And you have a future version that does break current decoders .
Thus , you have a single flag in each version , specifying whether the file is that version , or the next one .
To determine file version , you first parse the file as the first version ; if its " next version " flag is set , you then parse it as the second version ; if its " next version " flag is set , you parse as version 3 , etc .
It only makes sense for a bitstream though ( I have n't looked to see which this is ) .
And it seems mostly a theoretically-elegant approach , in that it has no limit to the number of versions , and for each new version , the change is the same .
Practically , a version field seems simpler for everyone .
And this does n't rule out the above scheme , it just means you have versions 0-254 ( assuming an 8-bit version field ) , and then version 255 which adds a second version field .
Maybe the site is n't Slashdotted anymore so I can read his comments as well .</tokentext>
<sentencetext>There's at least one obvious flaw in his reasoning.
He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version.
That only works if one assumes there will only *ever* be two versions (v1 and v2).
Such a basic failing of analysis is a pretty good indicator that he hasn't thought it all through as completely as he thinks he has.
Actually, it shows the opposite to me.
You have the current version, which decoders know how to decode.
You also have slight revisions that don't break current decoders.
And you have a future version that does break current decoders.
Thus, you have a single flag in each version, specifying whether the file is that version, or the next one.
To determine file version, you first parse the file as the first version; if its "next version" flag is set, you then parse it as the second version; if its "next version" flag is set, you parse as version 3, etc.
It only makes sense for a bitstream though (I haven't looked to see which this is).
And it seems mostly a theoretically-elegant approach, in that it has no limit to the number of versions, and for each new version, the change is the same.
Practically, a version field seems simpler for everyone.
And this doesn't rule out the above scheme, it just means you have versions 0-254 (assuming an 8-bit version field), and then version 255 which adds a second version field.
Maybe the site isn't Slashdotted anymore so I can read his comments as well.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150</id>
	<title>Still better than AVI</title>
	<author>Anonymous</author>
	<datestamp>1267648140000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>No matter how bad it is, it's still better than AVI. I personally use Matroska, it has all of the ideological benefits (free, non-encumbered, open-source) over stuff like MP4.</htmltext>
<tokenext>No matter how bad it is , it 's still better than AVI .
I personally use Matroska , it has all of the ideological benefits ( free , non-encumbered , open-source ) over stuff like MP4 .</tokentext>
<sentencetext>No matter how bad it is, it's still better than AVI.
I personally use Matroska, it has all of the ideological benefits (free, non-encumbered, open-source) over stuff like MP4.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349764</id>
	<title>Re:what is the point, exactly.</title>
	<author>Anonymous</author>
	<datestamp>1267607820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Because historically (and for good reason) audio and video have been encoded separately. Thus you need a master format that can wrap around both and coordinate their playback.</p></htmltext>
<tokenext>Because historically ( and for good reason ) audio and video have been encoded separately .
Thus you need a master format that can wrap around both and coordinate their playback .</tokentext>
<sentencetext>Because historically (and for good reason) audio and video have been encoded separately.
Thus you need a master format that can wrap around both and coordinate their playback.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349678</id>
	<title>Re:what is the point, exactly.</title>
	<author>Anonymous</author>
	<datestamp>1267607460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>I'm not an expert in video or audio production, I just dabble in it as a hobby. but one thing I often wonder is, what is the point of these container formats?</p></div><p>The point of containers is to make the contained media modular.  This way, you can assemble a multimedia ("many media"... whodathunkit) file from several individual pieces of media, each with codecs that may or may not be on speaking terms, into a cohesive file that i played as a unit.</p><p>If you define a format that has a video track and two channels of audio, you might think, hey, that's great, and play stuff on your computer.  But what if you want a 5.1 audio track?  Make another format, one for stereo and one for 5.1. Second audio program, like an alternate language?  More formats: one for stereo + stereo SAP, one for 5.1 main + stereo SAP, one for 5.1 both; up to 5 formats now.  Subtitles or closed captioning?  More formats: up to 20 now.  A different audio codec?  Even assuming the SAP tracks and main use the same codec (they might not; depends on where you got the SAP track from), add 20 formats per audio codec.  Multiple video codecs?  The number of formats can grow exponentially.  And we haven't even gotten to things like multiple camera angles and sideband info like text commentary, HTML links to things discussed in the show, or TV listings.</p><p>Or you can define a container and then, in each of those cases, only need to define a new component to be put into the container, and you're done.  Containers make things much simpler and easier to implement.</p></div>
	</htmltext>
<tokenext>I 'm not an expert in video or audio production , I just dabble in it as a hobby .
but one thing I often wonder is , what is the point of these container formats ? The point of containers is to make the contained media modular .
This way , you can assemble a multimedia ( " many media " ... whodathunkit ) file from several individual pieces of media , each with codecs that may or may not be on speaking terms , into a cohesive file that i played as a unit.If you define a format that has a video track and two channels of audio , you might think , hey , that 's great , and play stuff on your computer .
But what if you want a 5.1 audio track ?
Make another format , one for stereo and one for 5.1 .
Second audio program , like an alternate language ?
More formats : one for stereo + stereo SAP , one for 5.1 main + stereo SAP , one for 5.1 both ; up to 5 formats now .
Subtitles or closed captioning ?
More formats : up to 20 now .
A different audio codec ?
Even assuming the SAP tracks and main use the same codec ( they might not ; depends on where you got the SAP track from ) , add 20 formats per audio codec .
Multiple video codecs ?
The number of formats can grow exponentially .
And we have n't even gotten to things like multiple camera angles and sideband info like text commentary , HTML links to things discussed in the show , or TV listings.Or you can define a container and then , in each of those cases , only need to define a new component to be put into the container , and you 're done .
Containers make things much simpler and easier to implement .</tokentext>
<sentencetext>I'm not an expert in video or audio production, I just dabble in it as a hobby.
but one thing I often wonder is, what is the point of these container formats?The point of containers is to make the contained media modular.
This way, you can assemble a multimedia ("many media"... whodathunkit) file from several individual pieces of media, each with codecs that may or may not be on speaking terms, into a cohesive file that i played as a unit.If you define a format that has a video track and two channels of audio, you might think, hey, that's great, and play stuff on your computer.
But what if you want a 5.1 audio track?
Make another format, one for stereo and one for 5.1.
Second audio program, like an alternate language?
More formats: one for stereo + stereo SAP, one for 5.1 main + stereo SAP, one for 5.1 both; up to 5 formats now.
Subtitles or closed captioning?
More formats: up to 20 now.
A different audio codec?
Even assuming the SAP tracks and main use the same codec (they might not; depends on where you got the SAP track from), add 20 formats per audio codec.
Multiple video codecs?
The number of formats can grow exponentially.
And we haven't even gotten to things like multiple camera angles and sideband info like text commentary, HTML links to things discussed in the show, or TV listings.Or you can define a container and then, in each of those cases, only need to define a new component to be put into the container, and you're done.
Containers make things much simpler and easier to implement.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349164</id>
	<title>Flamebait much?</title>
	<author>Anonymous</author>
	<datestamp>1267648200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Who cares about container formats anyway? I could write ten before I get up in the morning. The codecs are the hard part.</p></htmltext>
<tokenext>Who cares about container formats anyway ?
I could write ten before I get up in the morning .
The codecs are the hard part .</tokentext>
<sentencetext>Who cares about container formats anyway?
I could write ten before I get up in the morning.
The codecs are the hard part.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351158</id>
	<title>Re:Technical Objections by Armchair Engineer?</title>
	<author>Anonymous</author>
	<datestamp>1267614240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My guess is you haven't worked in embedded where the difference between a $10 chip and a $9 chip due to complexity is the difference between being fired or promoted - Every little bit helps if it's simple to implement and easy to expand in the future.</p></htmltext>
<tokenext>My guess is you have n't worked in embedded where the difference between a $ 10 chip and a $ 9 chip due to complexity is the difference between being fired or promoted - Every little bit helps if it 's simple to implement and easy to expand in the future .</tokentext>
<sentencetext>My guess is you haven't worked in embedded where the difference between a $10 chip and a $9 chip due to complexity is the difference between being fired or promoted - Every little bit helps if it's simple to implement and easy to expand in the future.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349936</id>
	<title>Re:Still better than AVI</title>
	<author>Anonymous</author>
	<datestamp>1267608420000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>I use Handbrake <a href="http://handbrake.fr/" title="handbrake.fr">http://handbrake.fr/</a> [handbrake.fr] for encoding.  Handbrake will let you chose from MP4 or MKV for container, H.264 or Theora for video and MP3, AAC or Vorbis for audio.</htmltext>
<tokenext>I use Handbrake http : //handbrake.fr/ [ handbrake.fr ] for encoding .
Handbrake will let you chose from MP4 or MKV for container , H.264 or Theora for video and MP3 , AAC or Vorbis for audio .</tokentext>
<sentencetext>I use Handbrake http://handbrake.fr/ [handbrake.fr] for encoding.
Handbrake will let you chose from MP4 or MKV for container, H.264 or Theora for video and MP3, AAC or Vorbis for audio.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894</id>
	<title>Re:Flawed reasoning...</title>
	<author>Josef Meixner</author>
	<datestamp>1267608300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>It is not in the header, the 8-bit version field is in every single page. As according to the post a page is mostly 64K due to a strange length encoding, you send the version very, very often. I don't see any reason, why the version would have to change in the middle of a file in any case. And honestly, would you write a decoder taking that into account, if the probability of stumbling onto such a file was currently 0 (due to there being only one version) and very, very low in the future? That means it just adds to the size of the file.</p><p>The second reason is even simpler, you only need one bit to tell the current format from the future formats. As there hopefully will be a good reason for a future version the page header will probably be different, so I can add a version field there when I at least found one reason why I need it, no? That way I need one bit now and can still have different versions later.</p></htmltext>
<tokenext>It is not in the header , the 8-bit version field is in every single page .
As according to the post a page is mostly 64K due to a strange length encoding , you send the version very , very often .
I do n't see any reason , why the version would have to change in the middle of a file in any case .
And honestly , would you write a decoder taking that into account , if the probability of stumbling onto such a file was currently 0 ( due to there being only one version ) and very , very low in the future ?
That means it just adds to the size of the file.The second reason is even simpler , you only need one bit to tell the current format from the future formats .
As there hopefully will be a good reason for a future version the page header will probably be different , so I can add a version field there when I at least found one reason why I need it , no ?
That way I need one bit now and can still have different versions later .</tokentext>
<sentencetext>It is not in the header, the 8-bit version field is in every single page.
As according to the post a page is mostly 64K due to a strange length encoding, you send the version very, very often.
I don't see any reason, why the version would have to change in the middle of a file in any case.
And honestly, would you write a decoder taking that into account, if the probability of stumbling onto such a file was currently 0 (due to there being only one version) and very, very low in the future?
That means it just adds to the size of the file.The second reason is even simpler, you only need one bit to tell the current format from the future formats.
As there hopefully will be a good reason for a future version the page header will probably be different, so I can add a version field there when I at least found one reason why I need it, no?
That way I need one bit now and can still have different versions later.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349658</id>
	<title>Re:Flamebait much?</title>
	<author>Anonymous</author>
	<datestamp>1267607400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Sure you could... but would those 10 meet the needs of developers, content creators, and everyone else to whom the container does matter.</p><p>Most container formats are limiting on the users of the format... and they must be to ensure that someone can develop for them, if there weren't rules, then it wouldn't be a specification.  The best format is the one that imposes the right limitations while remaining very flexible for future technologies and uses.</p><p>While there are a multitude of container formats, few have met the ideal balance between flexibility and restriction.  I haven't read the linked article, but I suspect it will highlight how OGG is to restricting and/or not flexible enough to stand the test of time.</p><p>It would be trivial to create a completely unrestricted container format, but no one could use it as there would be no standard for reading the content contained within it.</p></htmltext>
<tokenext>Sure you could... but would those 10 meet the needs of developers , content creators , and everyone else to whom the container does matter.Most container formats are limiting on the users of the format... and they must be to ensure that someone can develop for them , if there were n't rules , then it would n't be a specification .
The best format is the one that imposes the right limitations while remaining very flexible for future technologies and uses.While there are a multitude of container formats , few have met the ideal balance between flexibility and restriction .
I have n't read the linked article , but I suspect it will highlight how OGG is to restricting and/or not flexible enough to stand the test of time.It would be trivial to create a completely unrestricted container format , but no one could use it as there would be no standard for reading the content contained within it .</tokentext>
<sentencetext>Sure you could... but would those 10 meet the needs of developers, content creators, and everyone else to whom the container does matter.Most container formats are limiting on the users of the format... and they must be to ensure that someone can develop for them, if there weren't rules, then it wouldn't be a specification.
The best format is the one that imposes the right limitations while remaining very flexible for future technologies and uses.While there are a multitude of container formats, few have met the ideal balance between flexibility and restriction.
I haven't read the linked article, but I suspect it will highlight how OGG is to restricting and/or not flexible enough to stand the test of time.It would be trivial to create a completely unrestricted container format, but no one could use it as there would be no standard for reading the content contained within it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349164</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350214</id>
	<title>Re:Flawed reasoning...</title>
	<author>Areyoukiddingme</author>
	<datestamp>1267609800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I would assume that redundant page level data as fundamental as the encoding version would be most helpful when streaming, especially streaming live.  I can't be bothered to read the article, but it sounds like the critic isn't taking into account all of the reasonable use cases.  Not everybody downloads a file and plays it from beginning to end and not everybody can start from the beginning.  If the stream started yesterday and I want to start watching it today, there had better not be any indispensable data at the very beginning.</p><p>Building the data into the stream means the stream server can be fairly simple, too.  It doesn't have to cache that indispensable data from the very beginning to get my stream client to figure out what's going on.  It just starts sending bytes and my client can figure it out.  It would be most convenient for my client if the server started transmitting at the beginning of a page, but if the redundant data at the beginning of a page is large enough (i.e. more than 1 bit), that might be unnecessary.  The page header may have a distinctive enough pattern for my client to detect the beginning of a page even if the stream started in the middle of a page.</p></htmltext>
<tokenext>I would assume that redundant page level data as fundamental as the encoding version would be most helpful when streaming , especially streaming live .
I ca n't be bothered to read the article , but it sounds like the critic is n't taking into account all of the reasonable use cases .
Not everybody downloads a file and plays it from beginning to end and not everybody can start from the beginning .
If the stream started yesterday and I want to start watching it today , there had better not be any indispensable data at the very beginning.Building the data into the stream means the stream server can be fairly simple , too .
It does n't have to cache that indispensable data from the very beginning to get my stream client to figure out what 's going on .
It just starts sending bytes and my client can figure it out .
It would be most convenient for my client if the server started transmitting at the beginning of a page , but if the redundant data at the beginning of a page is large enough ( i.e .
more than 1 bit ) , that might be unnecessary .
The page header may have a distinctive enough pattern for my client to detect the beginning of a page even if the stream started in the middle of a page .</tokentext>
<sentencetext>I would assume that redundant page level data as fundamental as the encoding version would be most helpful when streaming, especially streaming live.
I can't be bothered to read the article, but it sounds like the critic isn't taking into account all of the reasonable use cases.
Not everybody downloads a file and plays it from beginning to end and not everybody can start from the beginning.
If the stream started yesterday and I want to start watching it today, there had better not be any indispensable data at the very beginning.Building the data into the stream means the stream server can be fairly simple, too.
It doesn't have to cache that indispensable data from the very beginning to get my stream client to figure out what's going on.
It just starts sending bytes and my client can figure it out.
It would be most convenient for my client if the server started transmitting at the beginning of a page, but if the redundant data at the beginning of a page is large enough (i.e.
more than 1 bit), that might be unnecessary.
The page header may have a distinctive enough pattern for my client to detect the beginning of a page even if the stream started in the middle of a page.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351972</id>
	<title>Re:Technical Objections by Armchair Engineer?</title>
	<author>shutdown -p now</author>
	<datestamp>1267618200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I wonder who's the armchair engineer here...</p><p><div class="quote"><p>Ok, it's a container format, nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing.</p></div><p>It's extra 27 bytes per page, not per total file. "Tb of storage" reference is irrelevant, since we're talking about streaming here.</p><p><div class="quote"><p>And if you're complaining because it needs to go in the intertubes, gz compression on the server does a very good job of extracting and compressing plain non-random text like page headers</p></div><p>Are you seriously proposing <em>live streaming</em> the entire an audio or video stream (presumably produced by a compressing, lossy codec) through gzip?...</p><p>Or did you suggest just running gzip on the headers? In the latter case, you do realize that the overhead will likely be larger than header size?</p><p><div class="quote"><p>It's kind of important to keep track of versions. If your player can't play the next version or an older version it should be able to detect that so it doesn't try-and-fail. It might also want to suggest what version of the player is required.</p></div><p>TFA doesn't say that it's not important. It says that there are more space-efficient ways of doing so, especially when there is only a single container version so far in practice (so we may just as well optimize for this case).</p><p><div class="quote"><p>That's what they said about our memory too back in the early 90's. 32-bit addressing is enough, nobody will ever have more than 4G of RAM. Again, these open formats tend to be scalable across time because they need to fulfill a certain mission. Look at ZFS, they have 128-bit addressing but nobody (currently) needs that amount of storage.</p></div><p>Again, TFA does say that, for those <em>extremely rare</em> cases where 64-bit positions would be needed, a more efficient variable-length encoding could be devised, so that the common case is smaller (e.g. 31 bits lower + 1 bit flag + optional 32 bits upper).</p><p><div class="quote"><p>Why not, how many languages are there around the world? If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.</p></div><p>I can actually agree on the reasoning here, but again, there are more efficient ways to encode a number of "usually less than 16, very unlikely but still possibly hundreds".</p><p><div class="quote"><p>Well, maybe the makers intended Ogg to be used eventually to replace MPEG (c)(patented) and used across links with much higher transmission errors. Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts. When NASA wants to use Ogg for a non-repeatable stream from outer space, they should be able to. Again, overhead is a small cost to pay these days.</p></div><p>If they "maybe intended" it for some hypothetical applications, making it a mandatory feature that is useless in 99\% of all practical applications both today and in foreseeable future is kinda useless. In any case, error detection is much better handled at lower level, on the transmission protocol.</p><p><div class="quote"><p>Ah, well, what is reliable these days? Ever used a large array of hard drives? Ever used a freakin' dial-up connection? As the makers of ZFS, Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted. Silent data corruption is a major cause of data loss these days.</p></div><p>You need to start with a solid reference for your final claim. Even if provided, though, this doesn't change the fact that a container format for streaming data is not the best place to do error checking, since it imposes this burden on all users, regardless of any error checking already present on lower levels (which may, and, in fact, almost always is enough for the practical application at hand).</p><p><div class="quote"><p>Whoop-dee-doo, you made it half the size but you sacrificed reliability, error correction and future-proofness.</p></div><p>See above. Nothing was sacrificed, only optimized.</p><p><div class="quote"><p>You've got somewhat of a point there, maybe somebody will find a solution for that.</p></div><p>I wonder who would be that mysterious "somebody". Say, maybe we could ask the authors of <em>any other container format</em> out there? Or even the author of TFA? Oh, actually... no need to bother... he explained precisely how to handle this right after explaining how it's broken in Ogg.</p><p><div class="quote"><p>he issues around indexing however is that seeking within a stream is possible. HTTP servers allow you to start/stop downloading from different points in time and QuickTime is one of those formats that uses this feature.</p></div><p>This isn't really seeking within a stream in a sense stream is defined in TFA. When you seek that way, you do in effect get a new, separate stream (it's a new HTTP request), so the actual seeking - i.e. determining the starting packet/page - is handled on server-side.</p><p><div class="quote"><p>That is a very neat feature. It allows you to do very simple file operations to create longer streams, files etc. It allows even very simple hardware to make streams out of independent ogg files.</p></div><p>How many times did you actually have a need to do so, especially on "simple hardware"? How would having a separate tool for that make it any more complicated, given that you already need a special tool for encoding?</p><p><div class="quote"><p>However the benefits of those features far outweigh the downsides.</p></div><p>What features, exactly, does Ogg offer over other competing container formats?</p></div>
	</htmltext>
<tokenext>I wonder who 's the armchair engineer here...Ok , it 's a container format , nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing.It 's extra 27 bytes per page , not per total file .
" Tb of storage " reference is irrelevant , since we 're talking about streaming here.And if you 're complaining because it needs to go in the intertubes , gz compression on the server does a very good job of extracting and compressing plain non-random text like page headersAre you seriously proposing live streaming the entire an audio or video stream ( presumably produced by a compressing , lossy codec ) through gzip ? ...Or did you suggest just running gzip on the headers ?
In the latter case , you do realize that the overhead will likely be larger than header size ? It 's kind of important to keep track of versions .
If your player ca n't play the next version or an older version it should be able to detect that so it does n't try-and-fail .
It might also want to suggest what version of the player is required.TFA does n't say that it 's not important .
It says that there are more space-efficient ways of doing so , especially when there is only a single container version so far in practice ( so we may just as well optimize for this case ) .That 's what they said about our memory too back in the early 90 's .
32-bit addressing is enough , nobody will ever have more than 4G of RAM .
Again , these open formats tend to be scalable across time because they need to fulfill a certain mission .
Look at ZFS , they have 128-bit addressing but nobody ( currently ) needs that amount of storage.Again , TFA does say that , for those extremely rare cases where 64-bit positions would be needed , a more efficient variable-length encoding could be devised , so that the common case is smaller ( e.g .
31 bits lower + 1 bit flag + optional 32 bits upper ) .Why not , how many languages are there around the world ?
If you need to bring out a media file with subtitles and audio-tracks for each language , braille instructions and who knows what else for open access to certain media , you might want to use more than 256 streams.I can actually agree on the reasoning here , but again , there are more efficient ways to encode a number of " usually less than 16 , very unlikely but still possibly hundreds " .Well , maybe the makers intended Ogg to be used eventually to replace MPEG ( c ) ( patented ) and used across links with much higher transmission errors .
Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts .
When NASA wants to use Ogg for a non-repeatable stream from outer space , they should be able to .
Again , overhead is a small cost to pay these days.If they " maybe intended " it for some hypothetical applications , making it a mandatory feature that is useless in 99 \ % of all practical applications both today and in foreseeable future is kinda useless .
In any case , error detection is much better handled at lower level , on the transmission protocol.Ah , well , what is reliable these days ?
Ever used a large array of hard drives ?
Ever used a freakin ' dial-up connection ?
As the makers of ZFS , Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted .
Silent data corruption is a major cause of data loss these days.You need to start with a solid reference for your final claim .
Even if provided , though , this does n't change the fact that a container format for streaming data is not the best place to do error checking , since it imposes this burden on all users , regardless of any error checking already present on lower levels ( which may , and , in fact , almost always is enough for the practical application at hand ) .Whoop-dee-doo , you made it half the size but you sacrificed reliability , error correction and future-proofness.See above .
Nothing was sacrificed , only optimized.You 've got somewhat of a point there , maybe somebody will find a solution for that.I wonder who would be that mysterious " somebody " .
Say , maybe we could ask the authors of any other container format out there ?
Or even the author of TFA ?
Oh , actually... no need to bother... he explained precisely how to handle this right after explaining how it 's broken in Ogg.he issues around indexing however is that seeking within a stream is possible .
HTTP servers allow you to start/stop downloading from different points in time and QuickTime is one of those formats that uses this feature.This is n't really seeking within a stream in a sense stream is defined in TFA .
When you seek that way , you do in effect get a new , separate stream ( it 's a new HTTP request ) , so the actual seeking - i.e .
determining the starting packet/page - is handled on server-side.That is a very neat feature .
It allows you to do very simple file operations to create longer streams , files etc .
It allows even very simple hardware to make streams out of independent ogg files.How many times did you actually have a need to do so , especially on " simple hardware " ?
How would having a separate tool for that make it any more complicated , given that you already need a special tool for encoding ? However the benefits of those features far outweigh the downsides.What features , exactly , does Ogg offer over other competing container formats ?</tokentext>
<sentencetext>I wonder who's the armchair engineer here...Ok, it's a container format, nobody cares about an extra 27 bytes when you can buy TB of storage for virtually nothing.It's extra 27 bytes per page, not per total file.
"Tb of storage" reference is irrelevant, since we're talking about streaming here.And if you're complaining because it needs to go in the intertubes, gz compression on the server does a very good job of extracting and compressing plain non-random text like page headersAre you seriously proposing live streaming the entire an audio or video stream (presumably produced by a compressing, lossy codec) through gzip?...Or did you suggest just running gzip on the headers?
In the latter case, you do realize that the overhead will likely be larger than header size?It's kind of important to keep track of versions.
If your player can't play the next version or an older version it should be able to detect that so it doesn't try-and-fail.
It might also want to suggest what version of the player is required.TFA doesn't say that it's not important.
It says that there are more space-efficient ways of doing so, especially when there is only a single container version so far in practice (so we may just as well optimize for this case).That's what they said about our memory too back in the early 90's.
32-bit addressing is enough, nobody will ever have more than 4G of RAM.
Again, these open formats tend to be scalable across time because they need to fulfill a certain mission.
Look at ZFS, they have 128-bit addressing but nobody (currently) needs that amount of storage.Again, TFA does say that, for those extremely rare cases where 64-bit positions would be needed, a more efficient variable-length encoding could be devised, so that the common case is smaller (e.g.
31 bits lower + 1 bit flag + optional 32 bits upper).Why not, how many languages are there around the world?
If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.I can actually agree on the reasoning here, but again, there are more efficient ways to encode a number of "usually less than 16, very unlikely but still possibly hundreds".Well, maybe the makers intended Ogg to be used eventually to replace MPEG (c)(patented) and used across links with much higher transmission errors.
Sometimes my MPEG-encoded stream I get from my DTV provider has enough errors to stall and cause artifacts.
When NASA wants to use Ogg for a non-repeatable stream from outer space, they should be able to.
Again, overhead is a small cost to pay these days.If they "maybe intended" it for some hypothetical applications, making it a mandatory feature that is useless in 99\% of all practical applications both today and in foreseeable future is kinda useless.
In any case, error detection is much better handled at lower level, on the transmission protocol.Ah, well, what is reliable these days?
Ever used a large array of hard drives?
Ever used a freakin' dial-up connection?
As the makers of ZFS, Google and a few others recently have shown hard drive and memory reliability is not as good as we take for granted.
Silent data corruption is a major cause of data loss these days.You need to start with a solid reference for your final claim.
Even if provided, though, this doesn't change the fact that a container format for streaming data is not the best place to do error checking, since it imposes this burden on all users, regardless of any error checking already present on lower levels (which may, and, in fact, almost always is enough for the practical application at hand).Whoop-dee-doo, you made it half the size but you sacrificed reliability, error correction and future-proofness.See above.
Nothing was sacrificed, only optimized.You've got somewhat of a point there, maybe somebody will find a solution for that.I wonder who would be that mysterious "somebody".
Say, maybe we could ask the authors of any other container format out there?
Or even the author of TFA?
Oh, actually... no need to bother... he explained precisely how to handle this right after explaining how it's broken in Ogg.he issues around indexing however is that seeking within a stream is possible.
HTTP servers allow you to start/stop downloading from different points in time and QuickTime is one of those formats that uses this feature.This isn't really seeking within a stream in a sense stream is defined in TFA.
When you seek that way, you do in effect get a new, separate stream (it's a new HTTP request), so the actual seeking - i.e.
determining the starting packet/page - is handled on server-side.That is a very neat feature.
It allows you to do very simple file operations to create longer streams, files etc.
It allows even very simple hardware to make streams out of independent ogg files.How many times did you actually have a need to do so, especially on "simple hardware"?
How would having a separate tool for that make it any more complicated, given that you already need a special tool for encoding?However the benefits of those features far outweigh the downsides.What features, exactly, does Ogg offer over other competing container formats?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384</id>
	<title>Re:Still better than AVI</title>
	<author>rwa2</author>
	<datestamp>1267649280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'd like to use Matroska more, I like the DVD-like features such as alternate audio tracks and switchable subtitles.  Have any recommendations for encoders that can include these features?  VLC appears to work pretty well on the player side.</p></htmltext>
<tokenext>I 'd like to use Matroska more , I like the DVD-like features such as alternate audio tracks and switchable subtitles .
Have any recommendations for encoders that can include these features ?
VLC appears to work pretty well on the player side .</tokentext>
<sentencetext>I'd like to use Matroska more, I like the DVD-like features such as alternate audio tracks and switchable subtitles.
Have any recommendations for encoders that can include these features?
VLC appears to work pretty well on the player side.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349910</id>
	<title>Ogg is a nice format</title>
	<author>cereda</author>
	<datestamp>1267608360000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext>I can't say anything about video, but for audio all my CD collection is converted to Ogg instead of MP3, you can't even spot the difference in quality, thou the filesize is smaller. BTW, my MP3 player supports Ogg playing as well.</htmltext>
<tokenext>I ca n't say anything about video , but for audio all my CD collection is converted to Ogg instead of MP3 , you ca n't even spot the difference in quality , thou the filesize is smaller .
BTW , my MP3 player supports Ogg playing as well .</tokentext>
<sentencetext>I can't say anything about video, but for audio all my CD collection is converted to Ogg instead of MP3, you can't even spot the difference in quality, thou the filesize is smaller.
BTW, my MP3 player supports Ogg playing as well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349488</id>
	<title>umm..</title>
	<author>PPNSteve</author>
	<datestamp>1267649760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>[flamebait]<br>
OR, we could go back to<nobr> <wbr></nobr>.rm<br>
[/flamebait]</htmltext>
<tokenext>[ flamebait ] OR , we could go back to .rm [ /flamebait ]</tokentext>
<sentencetext>[flamebait]
OR, we could go back to .rm
[/flamebait]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349706</id>
	<title>Re:what is the point, exactly.</title>
	<author>reacocard</author>
	<datestamp>1267607580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>But its not just one codec that's involved, it's multiple. A typical video file will have at least two, one for video, one for audio. If you have alternate audio streams or subtitles, you need a codec for each of those as well.  The purpose of a container is to let you take all these streams in their individual codecs and put them together in one file for easy playback.  I'll grant you that it's not optimal to have some files with a given extension playable and some not, but with such a multitude of codecs in a single file it's just not possible to condense all that information down to a single file extension.</p></htmltext>
<tokenext>But its not just one codec that 's involved , it 's multiple .
A typical video file will have at least two , one for video , one for audio .
If you have alternate audio streams or subtitles , you need a codec for each of those as well .
The purpose of a container is to let you take all these streams in their individual codecs and put them together in one file for easy playback .
I 'll grant you that it 's not optimal to have some files with a given extension playable and some not , but with such a multitude of codecs in a single file it 's just not possible to condense all that information down to a single file extension .</tokentext>
<sentencetext>But its not just one codec that's involved, it's multiple.
A typical video file will have at least two, one for video, one for audio.
If you have alternate audio streams or subtitles, you need a codec for each of those as well.
The purpose of a container is to let you take all these streams in their individual codecs and put them together in one file for easy playback.
I'll grant you that it's not optimal to have some files with a given extension playable and some not, but with such a multitude of codecs in a single file it's just not possible to condense all that information down to a single file extension.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352580</id>
	<title>There are authoring-side issues also</title>
	<author>gig</author>
	<datestamp>1267621320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This article looks at the view from the player, but there are authoring issues also.</p><p>A key feature of ISO MPEG-4 is it is based on the QuickTime file format that authoring tools all speak. So adding ISO MPEG-4 support to an authoring tool was a minimal job, and it happened quickly and broadly. The fact that ISO MPEG-4 was a standardization of the QuickTime we were already using was very practical. Very much like how many HTML5 features are things the browsers or authors were already doing.</p><p>This all happened years ago, of course. The funny thing with the patent debate is the ISO MPEG-4 patents will expire before we could ever move everybody over to Ogg. And until then, it is a patent pool with cheap licensing that can't be denied to anyone, like GSM in phones, protection from liability, and with no content tax. Hardly the terrible evil it is made out to be.</p><p>But even so, the author is right: you have to bring the tech first. It has to be practical.</p></htmltext>
<tokenext>This article looks at the view from the player , but there are authoring issues also.A key feature of ISO MPEG-4 is it is based on the QuickTime file format that authoring tools all speak .
So adding ISO MPEG-4 support to an authoring tool was a minimal job , and it happened quickly and broadly .
The fact that ISO MPEG-4 was a standardization of the QuickTime we were already using was very practical .
Very much like how many HTML5 features are things the browsers or authors were already doing.This all happened years ago , of course .
The funny thing with the patent debate is the ISO MPEG-4 patents will expire before we could ever move everybody over to Ogg .
And until then , it is a patent pool with cheap licensing that ca n't be denied to anyone , like GSM in phones , protection from liability , and with no content tax .
Hardly the terrible evil it is made out to be.But even so , the author is right : you have to bring the tech first .
It has to be practical .</tokentext>
<sentencetext>This article looks at the view from the player, but there are authoring issues also.A key feature of ISO MPEG-4 is it is based on the QuickTime file format that authoring tools all speak.
So adding ISO MPEG-4 support to an authoring tool was a minimal job, and it happened quickly and broadly.
The fact that ISO MPEG-4 was a standardization of the QuickTime we were already using was very practical.
Very much like how many HTML5 features are things the browsers or authors were already doing.This all happened years ago, of course.
The funny thing with the patent debate is the ISO MPEG-4 patents will expire before we could ever move everybody over to Ogg.
And until then, it is a patent pool with cheap licensing that can't be denied to anyone, like GSM in phones, protection from liability, and with no content tax.
Hardly the terrible evil it is made out to be.But even so, the author is right: you have to bring the tech first.
It has to be practical.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350378</id>
	<title>Re:Still better than AVI</title>
	<author>Anonymous</author>
	<datestamp>1267610640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Thank you so much for mentioning Matroska.</p><p>I was not aware of it, and it's helpful in this context, providing a solution rather than rehashing possible problems.</p></htmltext>
<tokenext>Thank you so much for mentioning Matroska.I was not aware of it , and it 's helpful in this context , providing a solution rather than rehashing possible problems .</tokentext>
<sentencetext>Thank you so much for mentioning Matroska.I was not aware of it, and it's helpful in this context, providing a solution rather than rehashing possible problems.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349762</id>
	<title>slashdotted</title>
	<author>WhiteDragon</author>
	<datestamp>1267607760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Here's the coral mirror:</p><p><a href="http://hardwarebug.org.nyud.net/2010/03/03/ogg-objections/" title="nyud.net">http://hardwarebug.org.nyud.net/2010/03/03/ogg-objections/</a> [nyud.net]</p></htmltext>
<tokenext>Here 's the coral mirror : http : //hardwarebug.org.nyud.net/2010/03/03/ogg-objections/ [ nyud.net ]</tokentext>
<sentencetext>Here's the coral mirror:http://hardwarebug.org.nyud.net/2010/03/03/ogg-objections/ [nyud.net]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351360</id>
	<title>Ah, and now slashdot...</title>
	<author>Anonymous</author>
	<datestamp>1267615260000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>This whole thing is really about bad blood between Xiph and the mplayer folks.  Once, long ago, I made disparaging remarks about a particular mplayer developer's extensive collection of ass hats, and they declared war. This stopped being about facts or reason years ago. Here's the last blog thread that got completely hijacked by the anti-Ogg container wingnuts.  It's a hell of a read:</p><p> <a href="http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/" title="gingertech.net" rel="nofollow">http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/</a> [gingertech.net] </p><p>So, rehashing this yet again: The Anti-Ogg bullet points [Not going to bother with complete sentences, because I've wasted too much typing on this recently]:</p><p>1) A few of the mplayer/x264 hackers are right pissed that Ogg and Theora are getting all this attention when x264 is so obviously superior. That simply cannot stand. Since only America has patents and there are no computers there anyway, nobody should have to worry about them.  Stick it to The Man! (How very ironic, Xiph being considered 'The Man' by folks contributing to an h264 encoder).</p><p>2) Xiph should immediately drop Ogg for [insert container here], breaking millions of hardware decoders and hundreds of millions of software decoders:</p><p>
  a) the [patented] mp4/MOV container is one suggestion they actually make seriously.  Never mind adding 'willful infringement' to breaking the entire installed software/hardware base, this choice would totally redeem Xiph in their eyes.  The benefit: by their own figures, it would reduce container overhead from<nobr> <wbr></nobr>.7\% to<nobr> <wbr></nobr>.3\%.</p><p>
  (Except that number is wrong. I found later that DonDiego screwed up his mp4 overhead figures at the link above; I had simply assumed he got his container numbers right.  The mp4 file in his example has almost identical container overhead to the Ogg, a shade under 1\%.  His demultiplexed mpeg audio and video had framing in them, so it made it appear the mp4 container overhead was much smaller when he subtracted their file sizes.)</p><p>
  b) OK, mp4 is patented and no better, fine, Xiph should have just used Matroska from the beginning.  Despite the fact that Ogg and Vorbis predated it by about five years (also mkv's not been able to interleave until just recently, which == no streaming).  This is not to say you can't put Theora and Vorbis in Matroska.  It's even a good idea!  I've come to like MKV.  But for streaming, Ogg is still much easier to deal with.  Ogg was designed to stream, mkv was not.</p><p>
  c) OK, so, mp4 and Matroska are right out for streaming, Xiph should use Nut, which is the system they designed.  Nut came ten years after Ogg was already widespread.  And looks almost exactly like Ogg.  Which is not to say there aren't things about it I like that improved on the Ogg approach.  Eg, the packet length encoding is better.  It has a conditional checksum coverage feature I had never considered, etc. At some point we'll make those changes when that wouldn't mean completely abandoning any chance we have at adoption just to save a fraction of a percent and add... no new features.</p><p>
  d) but.. but.. even FLV is better! OK, at this point I can't even entertain the arguement.</p><p>3) OK, maybe not adopt another container, but Xiph should immediately improve/change Ogg for, breaking millions of hardware decoders and hundreds of millions of software decoders for a 'better' implementation that won't actually give users any features they don't have now.  FOSS need \_tools\_, not us wasting time overoptimizing something they couldn't care less about.</p><p>3) 64 bit timestamp!  OMG, waste!  Wait, mov/mp4 uses 64 bit stamps... Also, plenty of things in Ogg use a full byte instead of one bit because the container assumes octet alignment.  Alignment makes it much faster/easier to deal with (you don't need a bitpacker to read pages, and you don't have to repack packet data to embed it into the page).  Remember, all the completely unacc</p></htmltext>
<tokenext>This whole thing is really about bad blood between Xiph and the mplayer folks .
Once , long ago , I made disparaging remarks about a particular mplayer developer 's extensive collection of ass hats , and they declared war .
This stopped being about facts or reason years ago .
Here 's the last blog thread that got completely hijacked by the anti-Ogg container wingnuts .
It 's a hell of a read : http : //blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/ [ gingertech.net ] So , rehashing this yet again : The Anti-Ogg bullet points [ Not going to bother with complete sentences , because I 've wasted too much typing on this recently ] : 1 ) A few of the mplayer/x264 hackers are right pissed that Ogg and Theora are getting all this attention when x264 is so obviously superior .
That simply can not stand .
Since only America has patents and there are no computers there anyway , nobody should have to worry about them .
Stick it to The Man !
( How very ironic , Xiph being considered 'The Man ' by folks contributing to an h264 encoder ) .2 ) Xiph should immediately drop Ogg for [ insert container here ] , breaking millions of hardware decoders and hundreds of millions of software decoders : a ) the [ patented ] mp4/MOV container is one suggestion they actually make seriously .
Never mind adding 'willful infringement ' to breaking the entire installed software/hardware base , this choice would totally redeem Xiph in their eyes .
The benefit : by their own figures , it would reduce container overhead from .7 \ % to .3 \ % .
( Except that number is wrong .
I found later that DonDiego screwed up his mp4 overhead figures at the link above ; I had simply assumed he got his container numbers right .
The mp4 file in his example has almost identical container overhead to the Ogg , a shade under 1 \ % .
His demultiplexed mpeg audio and video had framing in them , so it made it appear the mp4 container overhead was much smaller when he subtracted their file sizes .
) b ) OK , mp4 is patented and no better , fine , Xiph should have just used Matroska from the beginning .
Despite the fact that Ogg and Vorbis predated it by about five years ( also mkv 's not been able to interleave until just recently , which = = no streaming ) .
This is not to say you ca n't put Theora and Vorbis in Matroska .
It 's even a good idea !
I 've come to like MKV .
But for streaming , Ogg is still much easier to deal with .
Ogg was designed to stream , mkv was not .
c ) OK , so , mp4 and Matroska are right out for streaming , Xiph should use Nut , which is the system they designed .
Nut came ten years after Ogg was already widespread .
And looks almost exactly like Ogg .
Which is not to say there are n't things about it I like that improved on the Ogg approach .
Eg , the packet length encoding is better .
It has a conditional checksum coverage feature I had never considered , etc .
At some point we 'll make those changes when that would n't mean completely abandoning any chance we have at adoption just to save a fraction of a percent and add... no new features .
d ) but.. but.. even FLV is better !
OK , at this point I ca n't even entertain the arguement.3 ) OK , maybe not adopt another container , but Xiph should immediately improve/change Ogg for , breaking millions of hardware decoders and hundreds of millions of software decoders for a 'better ' implementation that wo n't actually give users any features they do n't have now .
FOSS need \ _tools \ _ , not us wasting time overoptimizing something they could n't care less about.3 ) 64 bit timestamp !
OMG , waste !
Wait , mov/mp4 uses 64 bit stamps... Also , plenty of things in Ogg use a full byte instead of one bit because the container assumes octet alignment .
Alignment makes it much faster/easier to deal with ( you do n't need a bitpacker to read pages , and you do n't have to repack packet data to embed it into the page ) .
Remember , all the completely unacc</tokentext>
<sentencetext>This whole thing is really about bad blood between Xiph and the mplayer folks.
Once, long ago, I made disparaging remarks about a particular mplayer developer's extensive collection of ass hats, and they declared war.
This stopped being about facts or reason years ago.
Here's the last blog thread that got completely hijacked by the anti-Ogg container wingnuts.
It's a hell of a read: http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/ [gingertech.net] So, rehashing this yet again: The Anti-Ogg bullet points [Not going to bother with complete sentences, because I've wasted too much typing on this recently]:1) A few of the mplayer/x264 hackers are right pissed that Ogg and Theora are getting all this attention when x264 is so obviously superior.
That simply cannot stand.
Since only America has patents and there are no computers there anyway, nobody should have to worry about them.
Stick it to The Man!
(How very ironic, Xiph being considered 'The Man' by folks contributing to an h264 encoder).2) Xiph should immediately drop Ogg for [insert container here], breaking millions of hardware decoders and hundreds of millions of software decoders:
  a) the [patented] mp4/MOV container is one suggestion they actually make seriously.
Never mind adding 'willful infringement' to breaking the entire installed software/hardware base, this choice would totally redeem Xiph in their eyes.
The benefit: by their own figures, it would reduce container overhead from .7\% to .3\%.
(Except that number is wrong.
I found later that DonDiego screwed up his mp4 overhead figures at the link above; I had simply assumed he got his container numbers right.
The mp4 file in his example has almost identical container overhead to the Ogg, a shade under 1\%.
His demultiplexed mpeg audio and video had framing in them, so it made it appear the mp4 container overhead was much smaller when he subtracted their file sizes.
)
  b) OK, mp4 is patented and no better, fine, Xiph should have just used Matroska from the beginning.
Despite the fact that Ogg and Vorbis predated it by about five years (also mkv's not been able to interleave until just recently, which == no streaming).
This is not to say you can't put Theora and Vorbis in Matroska.
It's even a good idea!
I've come to like MKV.
But for streaming, Ogg is still much easier to deal with.
Ogg was designed to stream, mkv was not.
c) OK, so, mp4 and Matroska are right out for streaming, Xiph should use Nut, which is the system they designed.
Nut came ten years after Ogg was already widespread.
And looks almost exactly like Ogg.
Which is not to say there aren't things about it I like that improved on the Ogg approach.
Eg, the packet length encoding is better.
It has a conditional checksum coverage feature I had never considered, etc.
At some point we'll make those changes when that wouldn't mean completely abandoning any chance we have at adoption just to save a fraction of a percent and add... no new features.
d) but.. but.. even FLV is better!
OK, at this point I can't even entertain the arguement.3) OK, maybe not adopt another container, but Xiph should immediately improve/change Ogg for, breaking millions of hardware decoders and hundreds of millions of software decoders for a 'better' implementation that won't actually give users any features they don't have now.
FOSS need \_tools\_, not us wasting time overoptimizing something they couldn't care less about.3) 64 bit timestamp!
OMG, waste!
Wait, mov/mp4 uses 64 bit stamps... Also, plenty of things in Ogg use a full byte instead of one bit because the container assumes octet alignment.
Alignment makes it much faster/easier to deal with (you don't need a bitpacker to read pages, and you don't have to repack packet data to embed it into the page).
Remember, all the completely unacc</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361224</id>
	<title>Re:Dirac may have more future</title>
	<author>hazydave</author>
	<datestamp>1267733760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Dirac is potentially wonderful. But it will need work. It's based on Wavelets, which have a ton of potential, but not much practical use. I'm familiar enough, though, I have been using Cineform on the PC for about 5 years. Cineform is proprietary, Wavelet based, and much more comparable to Dirac Pro (now enshrined as the SMPTE VC-2 standard) than Dirac (the whole intraframe compression issue).</p><p>In short, AVC, DiVX, Theora, MPEG-2, WMV, etc. are all DCT-based. That's both good and bad. The good is that there's sometimes hardware to accelerate that, there is a long tradition of understanding these things, some of it's actually mature enough to live in realtime hardware, etc. On the downside, there's been so much work there, there are patent minefields... one factor preventing Theora from matching VC-1 or AVC in efficiency. And DCT-based compression artifacts are inherently more obvious to the human eye than Wavelet artifacts... they're there, but to my eye anyway, they seem more "organic".</p><p>But Dirac will need work to speed it up and perfect it. The good thing is that it's starting out open source, so this work can technically happen in full view of the FOSS community.</p></htmltext>
<tokenext>Dirac is potentially wonderful .
But it will need work .
It 's based on Wavelets , which have a ton of potential , but not much practical use .
I 'm familiar enough , though , I have been using Cineform on the PC for about 5 years .
Cineform is proprietary , Wavelet based , and much more comparable to Dirac Pro ( now enshrined as the SMPTE VC-2 standard ) than Dirac ( the whole intraframe compression issue ) .In short , AVC , DiVX , Theora , MPEG-2 , WMV , etc .
are all DCT-based .
That 's both good and bad .
The good is that there 's sometimes hardware to accelerate that , there is a long tradition of understanding these things , some of it 's actually mature enough to live in realtime hardware , etc .
On the downside , there 's been so much work there , there are patent minefields... one factor preventing Theora from matching VC-1 or AVC in efficiency .
And DCT-based compression artifacts are inherently more obvious to the human eye than Wavelet artifacts... they 're there , but to my eye anyway , they seem more " organic " .But Dirac will need work to speed it up and perfect it .
The good thing is that it 's starting out open source , so this work can technically happen in full view of the FOSS community .</tokentext>
<sentencetext>Dirac is potentially wonderful.
But it will need work.
It's based on Wavelets, which have a ton of potential, but not much practical use.
I'm familiar enough, though, I have been using Cineform on the PC for about 5 years.
Cineform is proprietary, Wavelet based, and much more comparable to Dirac Pro (now enshrined as the SMPTE VC-2 standard) than Dirac (the whole intraframe compression issue).In short, AVC, DiVX, Theora, MPEG-2, WMV, etc.
are all DCT-based.
That's both good and bad.
The good is that there's sometimes hardware to accelerate that, there is a long tradition of understanding these things, some of it's actually mature enough to live in realtime hardware, etc.
On the downside, there's been so much work there, there are patent minefields... one factor preventing Theora from matching VC-1 or AVC in efficiency.
And DCT-based compression artifacts are inherently more obvious to the human eye than Wavelet artifacts... they're there, but to my eye anyway, they seem more "organic".But Dirac will need work to speed it up and perfect it.
The good thing is that it's starting out open source, so this work can technically happen in full view of the FOSS community.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351916</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353694</id>
	<title>How Do Container Formats Work?</title>
	<author>logicnazi</author>
	<datestamp>1267630080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Alright, so despite doing a bit of reading on wikipedia I'm still pretty puzzled about exactly how container formats can work.  Setting aside fancy features like user menus and things like chaptering it seems to me the primary purpose of a container format is to do two things.</p><p>1) Define a format to multiplex many different data streams, e.g., allow packets in the audio stream, video stream, subtitle data to be interleaved so the right data can be available when needed (putting all the video stream first then the audio stream would be a bad idea).</p><p>2) Provide synchronization information to let arbitrary video, audio, and subtitle formats coordinate their display.</p><p>----</p><p>Now 1 seems relatively straightforward.  What confuses me is part 2.  I mean if we were encoding video as a simple list of pictures and audio in pcm this would seem straightforward.  Each packet encoding a video frame gets tagged with the frame number and each audio packet gets tagged with the frame number it should be played with.</p><p>However, how does this work given the fact that to display frame 10034 the video codec may need to use information from frame 10000 and similarly with the audio codec.  So if I want to jump to frame 10034 the player needs to know to look back at the info for frame 10000.  I mean I can think of various ways this might be done but they all would seem to require particular knowledge about how the individual streams work.</p><p>Could someone explain how these work or give me a pointer to a good explanation?</p><p>Thanks</p></htmltext>
<tokenext>Alright , so despite doing a bit of reading on wikipedia I 'm still pretty puzzled about exactly how container formats can work .
Setting aside fancy features like user menus and things like chaptering it seems to me the primary purpose of a container format is to do two things.1 ) Define a format to multiplex many different data streams , e.g. , allow packets in the audio stream , video stream , subtitle data to be interleaved so the right data can be available when needed ( putting all the video stream first then the audio stream would be a bad idea ) .2 ) Provide synchronization information to let arbitrary video , audio , and subtitle formats coordinate their display.----Now 1 seems relatively straightforward .
What confuses me is part 2 .
I mean if we were encoding video as a simple list of pictures and audio in pcm this would seem straightforward .
Each packet encoding a video frame gets tagged with the frame number and each audio packet gets tagged with the frame number it should be played with.However , how does this work given the fact that to display frame 10034 the video codec may need to use information from frame 10000 and similarly with the audio codec .
So if I want to jump to frame 10034 the player needs to know to look back at the info for frame 10000 .
I mean I can think of various ways this might be done but they all would seem to require particular knowledge about how the individual streams work.Could someone explain how these work or give me a pointer to a good explanation ? Thanks</tokentext>
<sentencetext>Alright, so despite doing a bit of reading on wikipedia I'm still pretty puzzled about exactly how container formats can work.
Setting aside fancy features like user menus and things like chaptering it seems to me the primary purpose of a container format is to do two things.1) Define a format to multiplex many different data streams, e.g., allow packets in the audio stream, video stream, subtitle data to be interleaved so the right data can be available when needed (putting all the video stream first then the audio stream would be a bad idea).2) Provide synchronization information to let arbitrary video, audio, and subtitle formats coordinate their display.----Now 1 seems relatively straightforward.
What confuses me is part 2.
I mean if we were encoding video as a simple list of pictures and audio in pcm this would seem straightforward.
Each packet encoding a video frame gets tagged with the frame number and each audio packet gets tagged with the frame number it should be played with.However, how does this work given the fact that to display frame 10034 the video codec may need to use information from frame 10000 and similarly with the audio codec.
So if I want to jump to frame 10034 the player needs to know to look back at the info for frame 10000.
I mean I can think of various ways this might be done but they all would seem to require particular knowledge about how the individual streams work.Could someone explain how these work or give me a pointer to a good explanation?Thanks</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352154</id>
	<title>Re:Still better than AVI</title>
	<author>wolrahnaes</author>
	<datestamp>1267619040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The great thing about AVI is that it supports (or at least can support) absolutely everything.<br>The main drawback of AVI is that it supports (or at least can support) absolutely everything.</p><p>AVI is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a AVI file is going to be playable on your system. You can't reasonably expect browser maker to standardise on AVI if it will mean having to include 30+ different codecs in their software, which from a practical standpoint it will. The unfortunate reality is that most of the world's population still doesn't have access to a comprehensive library of software like apt, and while our current software IP regime reigns, they never will.</p><p>Oh wait...</p></htmltext>
<tokenext>The great thing about AVI is that it supports ( or at least can support ) absolutely everything.The main drawback of AVI is that it supports ( or at least can support ) absolutely everything.AVI is a great container format , but unless you have a program like mplayer or vlc you ca n't guarantee that a AVI file is going to be playable on your system .
You ca n't reasonably expect browser maker to standardise on AVI if it will mean having to include 30 + different codecs in their software , which from a practical standpoint it will .
The unfortunate reality is that most of the world 's population still does n't have access to a comprehensive library of software like apt , and while our current software IP regime reigns , they never will.Oh wait.. .</tokentext>
<sentencetext>The great thing about AVI is that it supports (or at least can support) absolutely everything.The main drawback of AVI is that it supports (or at least can support) absolutely everything.AVI is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a AVI file is going to be playable on your system.
You can't reasonably expect browser maker to standardise on AVI if it will mean having to include 30+ different codecs in their software, which from a practical standpoint it will.
The unfortunate reality is that most of the world's population still doesn't have access to a comprehensive library of software like apt, and while our current software IP regime reigns, they never will.Oh wait...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351646</id>
	<title>Ogg sucks, MKV is what's hot now.</title>
	<author>Anonymous</author>
	<datestamp>1267616640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Ogg is silly.  Matroska stomps it in every way possible except for a *slightly* higher amount of overhead--which, when compared to the total size of any audio-visual file, is negligible.  There's no reason to use Ogg now that MKV is reasonably stable.</p></htmltext>
<tokenext>Ogg is silly .
Matroska stomps it in every way possible except for a * slightly * higher amount of overhead--which , when compared to the total size of any audio-visual file , is negligible .
There 's no reason to use Ogg now that MKV is reasonably stable .</tokentext>
<sentencetext>Ogg is silly.
Matroska stomps it in every way possible except for a *slightly* higher amount of overhead--which, when compared to the total size of any audio-visual file, is negligible.
There's no reason to use Ogg now that MKV is reasonably stable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351980</id>
	<title>Thanks</title>
	<author>justthinkit</author>
	<datestamp>1267618200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>The great thing about Matroska is that it supports (or at least can support) absolutely everything.<br>
The main drawback of Matroska is that it supports (or at least can support) absolutely everything.</i>
<br>
<br>
Thanks!  I had forgotten that Fight Club is on tonight on TCM.</htmltext>
<tokenext>The great thing about Matroska is that it supports ( or at least can support ) absolutely everything .
The main drawback of Matroska is that it supports ( or at least can support ) absolutely everything .
Thanks ! I had forgotten that Fight Club is on tonight on TCM .</tokentext>
<sentencetext>The great thing about Matroska is that it supports (or at least can support) absolutely everything.
The main drawback of Matroska is that it supports (or at least can support) absolutely everything.
Thanks!  I had forgotten that Fight Club is on tonight on TCM.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361398</id>
	<title>Re:Ogg needs to die so Vorbis and Theora can live.</title>
	<author>pslam</author>
	<datestamp>1267734540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And an old work colleague reminds me of another annoyance of the format: page numbering. Yes, the article already touches on it being too big and unnecessary. It's also a pain when it comes to tagging.
</p><p>All metadata/headers for Ogg files must be at the start of file. This is unfortunate, because it means if you re-tag a file, you need to resize the entire file and move the majority of it forward or backwards some bytes. Worse still, if you re-tag and end up creating a new page because it got large, you need to <i>renumber the page numbers of the entire stream</i>. That means <i>reparsing the entire Ogg stream</i>. Other containers stick metadata at the end of file, for good reason. This makes tagging utilities much more complicated for Ogg than other containers.</p></htmltext>
<tokenext>And an old work colleague reminds me of another annoyance of the format : page numbering .
Yes , the article already touches on it being too big and unnecessary .
It 's also a pain when it comes to tagging .
All metadata/headers for Ogg files must be at the start of file .
This is unfortunate , because it means if you re-tag a file , you need to resize the entire file and move the majority of it forward or backwards some bytes .
Worse still , if you re-tag and end up creating a new page because it got large , you need to renumber the page numbers of the entire stream .
That means reparsing the entire Ogg stream .
Other containers stick metadata at the end of file , for good reason .
This makes tagging utilities much more complicated for Ogg than other containers .</tokentext>
<sentencetext>And an old work colleague reminds me of another annoyance of the format: page numbering.
Yes, the article already touches on it being too big and unnecessary.
It's also a pain when it comes to tagging.
All metadata/headers for Ogg files must be at the start of file.
This is unfortunate, because it means if you re-tag a file, you need to resize the entire file and move the majority of it forward or backwards some bytes.
Worse still, if you re-tag and end up creating a new page because it got large, you need to renumber the page numbers of the entire stream.
That means reparsing the entire Ogg stream.
Other containers stick metadata at the end of file, for good reason.
This makes tagging utilities much more complicated for Ogg than other containers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351708</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382</id>
	<title>Flawed reasoning...</title>
	<author>Anonymous</author>
	<datestamp>1267649280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>There's at least one obvious flaw in his reasoning.  He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version.  That only works if one assumes there will only *ever* be two versions (v1 and v2).  Such a basic failing of analysis is a pretty good indicator that he hasn't thought it all through as completely as he thinks he has.</p></htmltext>
<tokenext>There 's at least one obvious flaw in his reasoning .
He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version .
That only works if one assumes there will only * ever * be two versions ( v1 and v2 ) .
Such a basic failing of analysis is a pretty good indicator that he has n't thought it all through as completely as he thinks he has .</tokentext>
<sentencetext>There's at least one obvious flaw in his reasoning.
He talks about removing the 8-bit version field in the header and replacing that with a 1-bit portion of the flags field to distinguish it from a hypothetical future version.
That only works if one assumes there will only *ever* be two versions (v1 and v2).
Such a basic failing of analysis is a pretty good indicator that he hasn't thought it all through as completely as he thinks he has.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349826</id>
	<title>Re:Still better than AVI</title>
	<author>stms</author>
	<datestamp>1267608000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I prefer Matroska as well... personally I think that xilph should drop the ogg container since mkv is doing such a good job then it would leave slightly more time to work on their video codec (perhaps they could even merge the projects if everyone was happy with it).</htmltext>
<tokenext>I prefer Matroska as well... personally I think that xilph should drop the ogg container since mkv is doing such a good job then it would leave slightly more time to work on their video codec ( perhaps they could even merge the projects if everyone was happy with it ) .</tokentext>
<sentencetext>I prefer Matroska as well... personally I think that xilph should drop the ogg container since mkv is doing such a good job then it would leave slightly more time to work on their video codec (perhaps they could even merge the projects if everyone was happy with it).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31355930</id>
	<title>Re:Ah, and now slashdot...</title>
	<author>Anonymous</author>
	<datestamp>1267698600000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Yes you suck, you don't even know how to program. Improved? It might as well be made again, I only hope people realize what a piece of ill-designed garbage your container is and simply stop using it.</p><p>There is an excuse for bugs, there is an excuse for missing features, there is no excuse to do something in such a bad way no serious programmer would do, some of those are errors that would made most college students fail the subject if they ever made them.</p><p>And as for being a Nazi, it amuses me to see that your container almost appears as if it was made to support your codecs.</p></htmltext>
<tokenext>Yes you suck , you do n't even know how to program .
Improved ? It might as well be made again , I only hope people realize what a piece of ill-designed garbage your container is and simply stop using it.There is an excuse for bugs , there is an excuse for missing features , there is no excuse to do something in such a bad way no serious programmer would do , some of those are errors that would made most college students fail the subject if they ever made them.And as for being a Nazi , it amuses me to see that your container almost appears as if it was made to support your codecs .</tokentext>
<sentencetext>Yes you suck, you don't even know how to program.
Improved? It might as well be made again, I only hope people realize what a piece of ill-designed garbage your container is and simply stop using it.There is an excuse for bugs, there is an excuse for missing features, there is no excuse to do something in such a bad way no serious programmer would do, some of those are errors that would made most college students fail the subject if they ever made them.And as for being a Nazi, it amuses me to see that your container almost appears as if it was made to support your codecs.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351360</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350450</id>
	<title>Re:Still better than AVI</title>
	<author>EdZ</author>
	<datestamp>1267611120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Encode with whatever codec you want. For putting stuff into the MKV container, MKVtoolnix works pretty damn well (and has source and binaries for pretty much everything).</htmltext>
<tokenext>Encode with whatever codec you want .
For putting stuff into the MKV container , MKVtoolnix works pretty damn well ( and has source and binaries for pretty much everything ) .</tokentext>
<sentencetext>Encode with whatever codec you want.
For putting stuff into the MKV container, MKVtoolnix works pretty damn well (and has source and binaries for pretty much everything).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353396</id>
	<title>Re:Flawed reasoning...</title>
	<author>logicnazi</author>
	<datestamp>1267628040000</datestamp>
	<modclass>None</modclass>
	<modscore>2</modscore>
	<htmltext><p>No, that's not true.  Version 2 can simply define a new bit to indicate whether it's version 2 or later.</p><p>The real problem with this optimization is it's effect on later versions.</p><p>Say one eventually moves to version 12 and each version along the way defines it's own flag.  That mean's you've used 12 bits and some very nasty decoding logic to indicate you are a version 12 format when you could have just reserved that one byte and used a case statement.</p><p>I mean the annoyance and difficulties created by using a next version flag (and the poor scaling behavior with higher version numbers) is a high price to pay to save a couple bytes in a multimedia codec.</p></htmltext>
<tokenext>No , that 's not true .
Version 2 can simply define a new bit to indicate whether it 's version 2 or later.The real problem with this optimization is it 's effect on later versions.Say one eventually moves to version 12 and each version along the way defines it 's own flag .
That mean 's you 've used 12 bits and some very nasty decoding logic to indicate you are a version 12 format when you could have just reserved that one byte and used a case statement.I mean the annoyance and difficulties created by using a next version flag ( and the poor scaling behavior with higher version numbers ) is a high price to pay to save a couple bytes in a multimedia codec .</tokentext>
<sentencetext>No, that's not true.
Version 2 can simply define a new bit to indicate whether it's version 2 or later.The real problem with this optimization is it's effect on later versions.Say one eventually moves to version 12 and each version along the way defines it's own flag.
That mean's you've used 12 bits and some very nasty decoding logic to indicate you are a version 12 format when you could have just reserved that one byte and used a case statement.I mean the annoyance and difficulties created by using a next version flag (and the poor scaling behavior with higher version numbers) is a high price to pay to save a couple bytes in a multimedia codec.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351382</id>
	<title>Re:Still better than AVI</title>
	<author>drinkypoo</author>
	<datestamp>1267615380000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>0</modscore>
	<htmltext><p>This doesn't differentiate it from AVI in any way...</p></htmltext>
<tokenext>This does n't differentiate it from AVI in any way.. .</tokentext>
<sentencetext>This doesn't differentiate it from AVI in any way...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351908</id>
	<title>Re:Still better than AVI</title>
	<author>Dahamma</author>
	<datestamp>1267617840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>But that's the point of independent container formats and codecs - they are orthogonal.  Just because a container supports a large set of codecs doesn't mean your decoder/player software has to support them all!  A well designed media playback engine can support an arbitrary set of containers and codecs, so MKV should be no different from any other container in this case.</p></htmltext>
<tokenext>But that 's the point of independent container formats and codecs - they are orthogonal .
Just because a container supports a large set of codecs does n't mean your decoder/player software has to support them all !
A well designed media playback engine can support an arbitrary set of containers and codecs , so MKV should be no different from any other container in this case .</tokentext>
<sentencetext>But that's the point of independent container formats and codecs - they are orthogonal.
Just because a container supports a large set of codecs doesn't mean your decoder/player software has to support them all!
A well designed media playback engine can support an arbitrary set of containers and codecs, so MKV should be no different from any other container in this case.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352922</id>
	<title>Re:Ah, and now slashdot...</title>
	<author>Anonymous</author>
	<datestamp>1267623900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I like OGG.  I use OGG.  OGG good.  Thank you.</p></htmltext>
<tokenext>I like OGG .
I use OGG .
OGG good .
Thank you .</tokentext>
<sentencetext>I like OGG.
I use OGG.
OGG good.
Thank you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351360</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361058</id>
	<title>Re:Technical Objections by Armchair Engineer?</title>
	<author>hazydave</author>
	<datestamp>1267732800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The reason he cares about all those large fields is support on small devices, and support for good streaming. On a PC, from disc, "who cares" is the right answer. On a pocket media player, it's not. Or on a network, where small packets work much better. In MPEG-2 transport streams, the packet is about 208 bytes in size. TS works very well over any kind of streaming media, and it's the format of choice on Blu-Ray and most digital camcorders. If you hinky up a packet with all kinds of needless overhead, you need gigantic packets, which means less effective streaming.</p><p>For devices, he predicts a minimum of 128K just for packet management. Not a huge amount by PC or smartphone standards, but that's crazy RAM for many embedded CPUs, which could otherwise handle the playback just fine. Thus, the nearly complete lack of Ogg support in small devices.</p></htmltext>
<tokenext>The reason he cares about all those large fields is support on small devices , and support for good streaming .
On a PC , from disc , " who cares " is the right answer .
On a pocket media player , it 's not .
Or on a network , where small packets work much better .
In MPEG-2 transport streams , the packet is about 208 bytes in size .
TS works very well over any kind of streaming media , and it 's the format of choice on Blu-Ray and most digital camcorders .
If you hinky up a packet with all kinds of needless overhead , you need gigantic packets , which means less effective streaming.For devices , he predicts a minimum of 128K just for packet management .
Not a huge amount by PC or smartphone standards , but that 's crazy RAM for many embedded CPUs , which could otherwise handle the playback just fine .
Thus , the nearly complete lack of Ogg support in small devices .</tokentext>
<sentencetext>The reason he cares about all those large fields is support on small devices, and support for good streaming.
On a PC, from disc, "who cares" is the right answer.
On a pocket media player, it's not.
Or on a network, where small packets work much better.
In MPEG-2 transport streams, the packet is about 208 bytes in size.
TS works very well over any kind of streaming media, and it's the format of choice on Blu-Ray and most digital camcorders.
If you hinky up a packet with all kinds of needless overhead, you need gigantic packets, which means less effective streaming.For devices, he predicts a minimum of 128K just for packet management.
Not a huge amount by PC or smartphone standards, but that's crazy RAM for many embedded CPUs, which could otherwise handle the playback just fine.
Thus, the nearly complete lack of Ogg support in small devices.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361642</id>
	<title>Re:Still better than AVI</title>
	<author>metamatic</author>
	<datestamp>1267735740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Unless you're going to use Theora and Vorbis, why not use MPEG-4? It supports all the same features, and has the added benefit of being playable everywhere.</p><p>If you're already using patented codecs, why not use the standard patented container?</p></htmltext>
<tokenext>Unless you 're going to use Theora and Vorbis , why not use MPEG-4 ?
It supports all the same features , and has the added benefit of being playable everywhere.If you 're already using patented codecs , why not use the standard patented container ?</tokentext>
<sentencetext>Unless you're going to use Theora and Vorbis, why not use MPEG-4?
It supports all the same features, and has the added benefit of being playable everywhere.If you're already using patented codecs, why not use the standard patented container?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31354512</id>
	<title>Re:Still better than AVI</title>
	<author>buzzn</author>
	<datestamp>1267638000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>... and has incredibly sucky UI to boot.</htmltext>
<tokenext>... and has incredibly sucky UI to boot .</tokentext>
<sentencetext>... and has incredibly sucky UI to boot.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349936</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350154</id>
	<title>In the long run</title>
	<author>istartedi</author>
	<datestamp>1267609440000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>"In the long run, all file formats become programming languages."</p><p>From this I draw a number of conclusions, the first being
that when designing a format you need to bring a "language sensibility"
to it.  If you don't, it's only a question of *when*, not if, your
format will become a poorly designed language.  OK, "language" may
not be the right word.  I'd also accept, "byte code" or "executable file",
but it's the same idea.  JMHO.</p></htmltext>
<tokenext>" In the long run , all file formats become programming languages .
" From this I draw a number of conclusions , the first being that when designing a format you need to bring a " language sensibility " to it .
If you do n't , it 's only a question of * when * , not if , your format will become a poorly designed language .
OK , " language " may not be the right word .
I 'd also accept , " byte code " or " executable file " , but it 's the same idea .
JMHO .</tokentext>
<sentencetext>"In the long run, all file formats become programming languages.
"From this I draw a number of conclusions, the first being
that when designing a format you need to bring a "language sensibility"
to it.
If you don't, it's only a question of *when*, not if, your
format will become a poorly designed language.
OK, "language" may
not be the right word.
I'd also accept, "byte code" or "executable file",
but it's the same idea.
JMHO.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349694</id>
	<title>Re:Flawed reasoning...</title>
	<author>blair1q</author>
	<datestamp>1267607520000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p>No, he's saying that since nobody ever sets the field it's of limited current use.  It can be replaced by a single bit which, when set to 1, would invoke processing of another version field.  But his argument is begging the question, as the field is there clearly to allow for more than one version, so the designers had prescience in that regard.  He's saying they shouldn't have bothered.  But if they hadn't, he'd probably be asking what happens if someone wants to use a different version.</p><p>If they had used a single bit to indicate a version-field extension was present, he would have had nothing to complain about, but since nobody designs packet headers that way, it's almost unthinkable that anyone would have done it that way in the first place.</p><p>Most of his objections are correct in detail, but pointless in gross.  It's clear to anyone watching that the inner workings of file formats are not of economic interest to the end user.  They are only too happy to download files in a dozen formats, totally ignorant of these petty inefficiencies, but getting furious when the player refuses to render them.</p><p>So everyone should just shut up and implement the ogg decoder we have, along with every other decoder necessary to read every file format in existence, because to do otherwise ranks you with the weak, lame, and lazy.</p></htmltext>
<tokenext>No , he 's saying that since nobody ever sets the field it 's of limited current use .
It can be replaced by a single bit which , when set to 1 , would invoke processing of another version field .
But his argument is begging the question , as the field is there clearly to allow for more than one version , so the designers had prescience in that regard .
He 's saying they should n't have bothered .
But if they had n't , he 'd probably be asking what happens if someone wants to use a different version.If they had used a single bit to indicate a version-field extension was present , he would have had nothing to complain about , but since nobody designs packet headers that way , it 's almost unthinkable that anyone would have done it that way in the first place.Most of his objections are correct in detail , but pointless in gross .
It 's clear to anyone watching that the inner workings of file formats are not of economic interest to the end user .
They are only too happy to download files in a dozen formats , totally ignorant of these petty inefficiencies , but getting furious when the player refuses to render them.So everyone should just shut up and implement the ogg decoder we have , along with every other decoder necessary to read every file format in existence , because to do otherwise ranks you with the weak , lame , and lazy .</tokentext>
<sentencetext>No, he's saying that since nobody ever sets the field it's of limited current use.
It can be replaced by a single bit which, when set to 1, would invoke processing of another version field.
But his argument is begging the question, as the field is there clearly to allow for more than one version, so the designers had prescience in that regard.
He's saying they shouldn't have bothered.
But if they hadn't, he'd probably be asking what happens if someone wants to use a different version.If they had used a single bit to indicate a version-field extension was present, he would have had nothing to complain about, but since nobody designs packet headers that way, it's almost unthinkable that anyone would have done it that way in the first place.Most of his objections are correct in detail, but pointless in gross.
It's clear to anyone watching that the inner workings of file formats are not of economic interest to the end user.
They are only too happy to download files in a dozen formats, totally ignorant of these petty inefficiencies, but getting furious when the player refuses to render them.So everyone should just shut up and implement the ogg decoder we have, along with every other decoder necessary to read every file format in existence, because to do otherwise ranks you with the weak, lame, and lazy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352430</id>
	<title>MXF</title>
	<author>TheSync</author>
	<datestamp>1267620360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>SMPTE (in coordination with the European Boradcasting Union and other groups) developed the Material eXchange Format (<a href="http://en.wikipedia.org/wiki/MXF" title="wikipedia.org">MXF</a> [wikipedia.org]) container:</p><p>MXF is exceedingly flexible.  Many MXF-wrapped files play back in VLC today.</p></htmltext>
<tokenext>SMPTE ( in coordination with the European Boradcasting Union and other groups ) developed the Material eXchange Format ( MXF [ wikipedia.org ] ) container : MXF is exceedingly flexible .
Many MXF-wrapped files play back in VLC today .</tokentext>
<sentencetext>SMPTE (in coordination with the European Boradcasting Union and other groups) developed the Material eXchange Format (MXF [wikipedia.org]) container:MXF is exceedingly flexible.
Many MXF-wrapped files play back in VLC today.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</id>
	<title>Re:Still better than AVI</title>
	<author>ObsessiveMathsFreak</author>
	<datestamp>1267649820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>The great thing about Matroska is that it supports (or at least can support) absolutely everything.<br>The main drawback of Matroska is that it supports (or at least can support) absolutely everything.</p><p>Matroska is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your system. You can't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30+ different codecs in their software, which from a practical standpoint it will. The unfortunate reality is that most of the world's population still doesn't have access to a comprehensive library of software like apt, and while our current software IP regime reigns, they never will.</p></htmltext>
<tokenext>The great thing about Matroska is that it supports ( or at least can support ) absolutely everything.The main drawback of Matroska is that it supports ( or at least can support ) absolutely everything.Matroska is a great container format , but unless you have a program like mplayer or vlc you ca n't guarantee that a Matroska file is going to be playable on your system .
You ca n't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30 + different codecs in their software , which from a practical standpoint it will .
The unfortunate reality is that most of the world 's population still does n't have access to a comprehensive library of software like apt , and while our current software IP regime reigns , they never will .</tokentext>
<sentencetext>The great thing about Matroska is that it supports (or at least can support) absolutely everything.The main drawback of Matroska is that it supports (or at least can support) absolutely everything.Matroska is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your system.
You can't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30+ different codecs in their software, which from a practical standpoint it will.
The unfortunate reality is that most of the world's population still doesn't have access to a comprehensive library of software like apt, and while our current software IP regime reigns, they never will.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349800</id>
	<title>Re:what is the point, exactly.</title>
	<author>cheesybagel</author>
	<datestamp>1267607940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Code reusability. You can use an MPEG-4, MPEG-2, or MPEG video codec with the same MP3 audio codec. The integration parts of the code can be reused as well. Forward compatibility: you can easily make a library so programs can use the same API to decode a variety of codecs. This means a program can support file formats which did not exist when it was written.
<p>
Of course this is mostly true for player software. Editing software sometimes wants to do more low level bit twiddling (e.g. to minimize recompression) and accesses the files in a more direct fashion, bypassing the standard OS APIs. It is also likely your programs use different OS media APIs. Windows has like two different APIs: VfW, DirectShow. There are also some apps that use the Quicktime API.</p></htmltext>
<tokenext>Code reusability .
You can use an MPEG-4 , MPEG-2 , or MPEG video codec with the same MP3 audio codec .
The integration parts of the code can be reused as well .
Forward compatibility : you can easily make a library so programs can use the same API to decode a variety of codecs .
This means a program can support file formats which did not exist when it was written .
Of course this is mostly true for player software .
Editing software sometimes wants to do more low level bit twiddling ( e.g .
to minimize recompression ) and accesses the files in a more direct fashion , bypassing the standard OS APIs .
It is also likely your programs use different OS media APIs .
Windows has like two different APIs : VfW , DirectShow .
There are also some apps that use the Quicktime API .</tokentext>
<sentencetext>Code reusability.
You can use an MPEG-4, MPEG-2, or MPEG video codec with the same MP3 audio codec.
The integration parts of the code can be reused as well.
Forward compatibility: you can easily make a library so programs can use the same API to decode a variety of codecs.
This means a program can support file formats which did not exist when it was written.
Of course this is mostly true for player software.
Editing software sometimes wants to do more low level bit twiddling (e.g.
to minimize recompression) and accesses the files in a more direct fashion, bypassing the standard OS APIs.
It is also likely your programs use different OS media APIs.
Windows has like two different APIs: VfW, DirectShow.
There are also some apps that use the Quicktime API.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351662</id>
	<title>OGM is criticized as well</title>
	<author>Antiocheian</author>
	<datestamp>1267616640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>As you have seen, those properties of OGM used by people who propagate<br>it are no real advandage, and at least one major drawback could be easily<br>xed to some extent without breaking compatibility to anything. But no one<br>seems to care to x it. It seems that people who could x don&rsquo;t care enough<br>about OGM to really do it.<br>Finally, here the excerpt of a &rsquo;discussion&rsquo; between one of the most famous<br>OGM Zealot and other people:<br><i>Zealot: "Who would put ac3 or dts into ogm btw.? OGM is meant to be<br>a container for ogg vorbis sondtracks and video as well as subtitles."<br>Someone else: "So you acknowledge the fact that OGM is just a technology<br>demonstration to advertise Vorbis ? Not a general purpose container ?"<br>Zealot: "You know very well that OGM is a general purpose container..."</i><br>As you can see, not even OGM Zealots trying to defend OGM at all costs<br>(again, OGM, I don&rsquo;t speak about OGG here!) can write reasonable sen-<br>tences not contradicting each other.</p></div><p> <a href="http://www.alexander-noe.com/video/documentation/containers.pdf" title="alexander-noe.com" rel="nofollow">http://www.alexander-noe.com/video/documentation/containers.pdf</a> [alexander-noe.com]</p></div>
	</htmltext>
<tokenext>As you have seen , those properties of OGM used by people who propagateit are no real advandage , and at least one major drawback could be easilyxed to some extent without breaking compatibility to anything .
But no oneseems to care to x it .
It seems that people who could x don    t care enoughabout OGM to really do it.Finally , here the excerpt of a    discussion    between one of the most famousOGM Zealot and other people : Zealot : " Who would put ac3 or dts into ogm btw. ?
OGM is meant to bea container for ogg vorbis sondtracks and video as well as subtitles .
" Someone else : " So you acknowledge the fact that OGM is just a technologydemonstration to advertise Vorbis ?
Not a general purpose container ?
" Zealot : " You know very well that OGM is a general purpose container... " As you can see , not even OGM Zealots trying to defend OGM at all costs ( again , OGM , I don    t speak about OGG here !
) can write reasonable sen-tences not contradicting each other .
http : //www.alexander-noe.com/video/documentation/containers.pdf [ alexander-noe.com ]</tokentext>
<sentencetext>As you have seen, those properties of OGM used by people who propagateit are no real advandage, and at least one major drawback could be easilyxed to some extent without breaking compatibility to anything.
But no oneseems to care to x it.
It seems that people who could x don’t care enoughabout OGM to really do it.Finally, here the excerpt of a ’discussion’ between one of the most famousOGM Zealot and other people:Zealot: "Who would put ac3 or dts into ogm btw.?
OGM is meant to bea container for ogg vorbis sondtracks and video as well as subtitles.
"Someone else: "So you acknowledge the fact that OGM is just a technologydemonstration to advertise Vorbis ?
Not a general purpose container ?
"Zealot: "You know very well that OGM is a general purpose container..."As you can see, not even OGM Zealots trying to defend OGM at all costs(again, OGM, I don’t speak about OGG here!
) can write reasonable sen-tences not contradicting each other.
http://www.alexander-noe.com/video/documentation/containers.pdf [alexander-noe.com]
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349314</id>
	<title>The Biggest Technical Objection</title>
	<author>Anonymous</author>
	<datestamp>1267648920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Is that the ogg container format doesn't play itself.</p></htmltext>
<tokenext>Is that the ogg container format does n't play itself .</tokentext>
<sentencetext>Is that the ogg container format doesn't play itself.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350570</id>
	<title>Re:Just complaining</title>
	<author>teknomage1</author>
	<datestamp>1267611600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I wonder how many of the technical objections are workarounds for where the "obvious" choice is already covered by software patents. One of ogg's selling points is that it isn't covered by any patents, and we know there are a lot of lame software patents out there.</htmltext>
<tokenext>I wonder how many of the technical objections are workarounds for where the " obvious " choice is already covered by software patents .
One of ogg 's selling points is that it is n't covered by any patents , and we know there are a lot of lame software patents out there .</tokentext>
<sentencetext>I wonder how many of the technical objections are workarounds for where the "obvious" choice is already covered by software patents.
One of ogg's selling points is that it isn't covered by any patents, and we know there are a lot of lame software patents out there.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351124</id>
	<title>Re:Technical Objections by Armchair Engineer?</title>
	<author>bbn</author>
	<datestamp>1267614180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p> <i>Random access</i><br>You've got somewhat of a point there, maybe somebody will find a solution for that. The issues around indexing however is that seeking within a stream <b>is</b> possible. HTTP servers allow you to start/stop downloading from different points in time and QuickTime is one of those formats that uses this feature.</p></div><p>He is trying too hard make an issue out of it. Read this:</p><p><div class="quote"><p>In a large file (sizes upwards of 10 GB are common), 50 seeks might be required to find the correct position.</p><p>A typical hard drive has an average seek time of roughly 10 ms, giving a total time for the seek operation of around 500 ms, an annoyingly long time.</p></div><p>Now being a binary search, each seek halves the size of the search domain. The minimum size a harddrive can read is 512 bytes, so there will be no further seeks after we find a search domain less than that.</p><p>So 50 seeks is only needed with a filesize of 512 * 2^50 = 576460 terabytes.</p><p>For a 10 GB file you would need no more than half that many seeks (25). Take into account that most filesystems do not distribute the file at random over the whole harddrive, which makes the average seek time for the file much smaller than 10 ms. We are probably looking at no more than 100 ms to do this random access search on a 10 GB file.</p><p>100 ms might still be enough to complain about. But he is not making his point stronger by exaggerating the problem.</p></div>
	</htmltext>
<tokenext>Random accessYou 've got somewhat of a point there , maybe somebody will find a solution for that .
The issues around indexing however is that seeking within a stream is possible .
HTTP servers allow you to start/stop downloading from different points in time and QuickTime is one of those formats that uses this feature.He is trying too hard make an issue out of it .
Read this : In a large file ( sizes upwards of 10 GB are common ) , 50 seeks might be required to find the correct position.A typical hard drive has an average seek time of roughly 10 ms , giving a total time for the seek operation of around 500 ms , an annoyingly long time.Now being a binary search , each seek halves the size of the search domain .
The minimum size a harddrive can read is 512 bytes , so there will be no further seeks after we find a search domain less than that.So 50 seeks is only needed with a filesize of 512 * 2 ^ 50 = 576460 terabytes.For a 10 GB file you would need no more than half that many seeks ( 25 ) .
Take into account that most filesystems do not distribute the file at random over the whole harddrive , which makes the average seek time for the file much smaller than 10 ms. We are probably looking at no more than 100 ms to do this random access search on a 10 GB file.100 ms might still be enough to complain about .
But he is not making his point stronger by exaggerating the problem .</tokentext>
<sentencetext> Random accessYou've got somewhat of a point there, maybe somebody will find a solution for that.
The issues around indexing however is that seeking within a stream is possible.
HTTP servers allow you to start/stop downloading from different points in time and QuickTime is one of those formats that uses this feature.He is trying too hard make an issue out of it.
Read this:In a large file (sizes upwards of 10 GB are common), 50 seeks might be required to find the correct position.A typical hard drive has an average seek time of roughly 10 ms, giving a total time for the seek operation of around 500 ms, an annoyingly long time.Now being a binary search, each seek halves the size of the search domain.
The minimum size a harddrive can read is 512 bytes, so there will be no further seeks after we find a search domain less than that.So 50 seeks is only needed with a filesize of 512 * 2^50 = 576460 terabytes.For a 10 GB file you would need no more than half that many seeks (25).
Take into account that most filesystems do not distribute the file at random over the whole harddrive, which makes the average seek time for the file much smaller than 10 ms. We are probably looking at no more than 100 ms to do this random access search on a 10 GB file.100 ms might still be enough to complain about.
But he is not making his point stronger by exaggerating the problem.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351586</id>
	<title>Re:Technical Objections by Armchair Engineer?</title>
	<author>flabordec</author>
	<datestamp>1267616340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p>32-bit elementary stream number? Are they anticipating files with four billion elementary streams? An eight-bit field, if not smaller, would seem more appropriate here.</p></div><p>Why not, how many languages are there around the world? If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.</p></div><p>I know I'm nitpicking but according to wikipedia there are <a href="http://en.wikipedia.org/wiki/List\_of\_languages\_by\_number\_of\_native\_speakers" title="wikipedia.org" rel="nofollow">around 514 languages</a> [wikipedia.org]. Which does make the four billion streams seem wasteful, even if you wanted to add subtitles, audio tracks, braille instructions, different camera views and director's commentary in Ter Sami for the two native speakers of that language.</p><p>I agree that these formats should be planning for the future and a big stream number allows for that (640kb ought to be enough for anybody, right?) but I find four billion streams a bit excessive.</p></div>
	</htmltext>
<tokenext>32-bit elementary stream number ?
Are they anticipating files with four billion elementary streams ?
An eight-bit field , if not smaller , would seem more appropriate here.Why not , how many languages are there around the world ?
If you need to bring out a media file with subtitles and audio-tracks for each language , braille instructions and who knows what else for open access to certain media , you might want to use more than 256 streams.I know I 'm nitpicking but according to wikipedia there are around 514 languages [ wikipedia.org ] .
Which does make the four billion streams seem wasteful , even if you wanted to add subtitles , audio tracks , braille instructions , different camera views and director 's commentary in Ter Sami for the two native speakers of that language.I agree that these formats should be planning for the future and a big stream number allows for that ( 640kb ought to be enough for anybody , right ?
) but I find four billion streams a bit excessive .</tokentext>
<sentencetext>32-bit elementary stream number?
Are they anticipating files with four billion elementary streams?
An eight-bit field, if not smaller, would seem more appropriate here.Why not, how many languages are there around the world?
If you need to bring out a media file with subtitles and audio-tracks for each language, braille instructions and who knows what else for open access to certain media, you might want to use more than 256 streams.I know I'm nitpicking but according to wikipedia there are around 514 languages [wikipedia.org].
Which does make the four billion streams seem wasteful, even if you wanted to add subtitles, audio tracks, braille instructions, different camera views and director's commentary in Ter Sami for the two native speakers of that language.I agree that these formats should be planning for the future and a big stream number allows for that (640kb ought to be enough for anybody, right?
) but I find four billion streams a bit excessive.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349352</id>
	<title>Re:Just complaining</title>
	<author>sopssa</author>
	<datestamp>1267649160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Uh, wtf? Just because none of the flaws make it completely unusable doesn't mean it's not bad. If it has serious flaws, it <i>is</i>. As the writer states, it's a complete mess for app developers and lacks some required features that other formats have.</p><p>I can implement, make available and use a format I made in a few hours without thinking about it. Maybe it misses features for seeking because I didn't think about adding timestamps, and probably only usable audio format is WAV. But in your words it doesn't make my container bad and anyone criticizing it would be just complaining.</p></htmltext>
<tokenext>Uh , wtf ?
Just because none of the flaws make it completely unusable does n't mean it 's not bad .
If it has serious flaws , it is .
As the writer states , it 's a complete mess for app developers and lacks some required features that other formats have.I can implement , make available and use a format I made in a few hours without thinking about it .
Maybe it misses features for seeking because I did n't think about adding timestamps , and probably only usable audio format is WAV .
But in your words it does n't make my container bad and anyone criticizing it would be just complaining .</tokentext>
<sentencetext>Uh, wtf?
Just because none of the flaws make it completely unusable doesn't mean it's not bad.
If it has serious flaws, it is.
As the writer states, it's a complete mess for app developers and lacks some required features that other formats have.I can implement, make available and use a format I made in a few hours without thinking about it.
Maybe it misses features for seeking because I didn't think about adding timestamps, and probably only usable audio format is WAV.
But in your words it doesn't make my container bad and anyone criticizing it would be just complaining.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31357038</id>
	<title>Re:Still better than AVI</title>
	<author>Ltap</author>
	<datestamp>1267712100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you don't have VLC/mplayer (Linux) or home media player classic (Windows) you don't deserve to get the benefits of Matroska. What happened to the days when people would distribute in deliberately obscure formats? We shouldn't encode to crappy formats just to please the people who download stuff, they should be happy that they're getting it for free.</htmltext>
<tokenext>If you do n't have VLC/mplayer ( Linux ) or home media player classic ( Windows ) you do n't deserve to get the benefits of Matroska .
What happened to the days when people would distribute in deliberately obscure formats ?
We should n't encode to crappy formats just to please the people who download stuff , they should be happy that they 're getting it for free .</tokentext>
<sentencetext>If you don't have VLC/mplayer (Linux) or home media player classic (Windows) you don't deserve to get the benefits of Matroska.
What happened to the days when people would distribute in deliberately obscure formats?
We shouldn't encode to crappy formats just to please the people who download stuff, they should be happy that they're getting it for free.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350900</id>
	<title>Re:what is the point, exactly.</title>
	<author>jedidiah</author>
	<datestamp>1267613040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; I'm not an expert in video or audio production, I just dabble in it as a hobby. but one thing I often wonder is, what is the point of these container formats?</p><p>Contemplate the difference between an AVI file and a DVD for awhile.</p><p>Not everyone is interested in the simplest sort of content imaginable.</p></htmltext>
<tokenext>&gt; I 'm not an expert in video or audio production , I just dabble in it as a hobby .
but one thing I often wonder is , what is the point of these container formats ? Contemplate the difference between an AVI file and a DVD for awhile.Not everyone is interested in the simplest sort of content imaginable .</tokentext>
<sentencetext>&gt; I'm not an expert in video or audio production, I just dabble in it as a hobby.
but one thing I often wonder is, what is the point of these container formats?Contemplate the difference between an AVI file and a DVD for awhile.Not everyone is interested in the simplest sort of content imaginable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351450</id>
	<title>Re:Technical Objections by Armchair Engineer?</title>
	<author>pslam</author>
	<datestamp>1267615740000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>Your objective is to Armchair engineers? Ok, well I'm not an armchair engineer. I've written my own Ogg/Vorbis decoder from scratch in the past (<a href="http://umbel.mooo.com/" title="mooo.com" rel="nofollow">here</a> [mooo.com]). I've worked on codecs for about 10 years. I'm a fan of Vorbis and Theora, but Ogg needs to die a horrible death.
</p><p>Ogg was by far the most bug-inducing part of the code. It's just AWFUL. It's ill-designed. It's incredibly complicated. It's inherently inefficient (copy sometimes required).
</p><p>In short, it's the worst container format I've used in any serious application, and I've used pretty much all the common ones.
</p><p>The irony of what you're saying, is that actually Ogg is what you'd end up with if an armchair engineer designed an audio codec container from scratch.</p></htmltext>
<tokenext>Your objective is to Armchair engineers ?
Ok , well I 'm not an armchair engineer .
I 've written my own Ogg/Vorbis decoder from scratch in the past ( here [ mooo.com ] ) .
I 've worked on codecs for about 10 years .
I 'm a fan of Vorbis and Theora , but Ogg needs to die a horrible death .
Ogg was by far the most bug-inducing part of the code .
It 's just AWFUL .
It 's ill-designed .
It 's incredibly complicated .
It 's inherently inefficient ( copy sometimes required ) .
In short , it 's the worst container format I 've used in any serious application , and I 've used pretty much all the common ones .
The irony of what you 're saying , is that actually Ogg is what you 'd end up with if an armchair engineer designed an audio codec container from scratch .</tokentext>
<sentencetext>Your objective is to Armchair engineers?
Ok, well I'm not an armchair engineer.
I've written my own Ogg/Vorbis decoder from scratch in the past (here [mooo.com]).
I've worked on codecs for about 10 years.
I'm a fan of Vorbis and Theora, but Ogg needs to die a horrible death.
Ogg was by far the most bug-inducing part of the code.
It's just AWFUL.
It's ill-designed.
It's incredibly complicated.
It's inherently inefficient (copy sometimes required).
In short, it's the worst container format I've used in any serious application, and I've used pretty much all the common ones.
The irony of what you're saying, is that actually Ogg is what you'd end up with if an armchair engineer designed an audio codec container from scratch.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351708</id>
	<title>Ogg needs to die so Vorbis and Theora can live.</title>
	<author>Anonymous</author>
	<datestamp>1267616880000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>I sadly have to agree, and I've voiced the same objections for a long time. It really is like he tells it: it's just bad at everything it was intended to achieve. It's a source of bugs, it's horrendously complicated to support, and it's horrendously inefficient at anything but audio (and even then, not so good).
</p><p>It seems to me, most of what went wrong was trying to support concatenation of Ogg streams. This is a nice idea, but actually quite a rare case. It's also incredibly naive for the specification document to request that Ogg implementation detect this. What, I'm supposed to scan <i>the entire file</i> in case that happens? No. I'll just not be compliant to that, thank you very much.
</p><p>I even <a href="http://umbel.mooo.com/" title="mooo.com" rel="nofollow">wrote my own Ogg/Vorbis decoder from scratch</a> [mooo.com] a while back (and dabble every now and then), and found Ogg to be a never-cooling, never-extinguishing steaming pile of hippo crap left over from consuming a dog. It just made everything so difficult to do. Seeking a stream involves divide-and-conquer - not necessarily a bad thing, but when you have huge streams the number of seeks can be bad. Not to mention if your stream has an endpoint the other side of the Atlantic Ocean. Why oh why did they pick timestamps being at the END of a page and indicating the output byte count produced by the END of that page? That little detail alone probably cost me days of debug.
</p><p>I almost gave up at one point and went to a container format of my own which would have worked much better. Header: 'CONTAINER v1'. Packet: 'MAGIC', 4 byte Length, 4 byte Output pos. Job done. The sad fact is, that's easier than Ogg, smaller than Ogg (unless you're talking really low bit rate), and does entirely the job of Ogg without the complexity.
</p><p>I'm probably going to add a Matroska container to my codec just to see how easy they are to produce. The spec looks fantastic, but the devil's always in the details - although seeing the praise on various (engineer) forums, it looks like the way to go.
</p><p>So, Ogg, please die. We need you to get out of the way.</p></htmltext>
<tokenext>I sadly have to agree , and I 've voiced the same objections for a long time .
It really is like he tells it : it 's just bad at everything it was intended to achieve .
It 's a source of bugs , it 's horrendously complicated to support , and it 's horrendously inefficient at anything but audio ( and even then , not so good ) .
It seems to me , most of what went wrong was trying to support concatenation of Ogg streams .
This is a nice idea , but actually quite a rare case .
It 's also incredibly naive for the specification document to request that Ogg implementation detect this .
What , I 'm supposed to scan the entire file in case that happens ?
No. I 'll just not be compliant to that , thank you very much .
I even wrote my own Ogg/Vorbis decoder from scratch [ mooo.com ] a while back ( and dabble every now and then ) , and found Ogg to be a never-cooling , never-extinguishing steaming pile of hippo crap left over from consuming a dog .
It just made everything so difficult to do .
Seeking a stream involves divide-and-conquer - not necessarily a bad thing , but when you have huge streams the number of seeks can be bad .
Not to mention if your stream has an endpoint the other side of the Atlantic Ocean .
Why oh why did they pick timestamps being at the END of a page and indicating the output byte count produced by the END of that page ?
That little detail alone probably cost me days of debug .
I almost gave up at one point and went to a container format of my own which would have worked much better .
Header : 'CONTAINER v1' .
Packet : 'MAGIC ' , 4 byte Length , 4 byte Output pos .
Job done .
The sad fact is , that 's easier than Ogg , smaller than Ogg ( unless you 're talking really low bit rate ) , and does entirely the job of Ogg without the complexity .
I 'm probably going to add a Matroska container to my codec just to see how easy they are to produce .
The spec looks fantastic , but the devil 's always in the details - although seeing the praise on various ( engineer ) forums , it looks like the way to go .
So , Ogg , please die .
We need you to get out of the way .</tokentext>
<sentencetext>I sadly have to agree, and I've voiced the same objections for a long time.
It really is like he tells it: it's just bad at everything it was intended to achieve.
It's a source of bugs, it's horrendously complicated to support, and it's horrendously inefficient at anything but audio (and even then, not so good).
It seems to me, most of what went wrong was trying to support concatenation of Ogg streams.
This is a nice idea, but actually quite a rare case.
It's also incredibly naive for the specification document to request that Ogg implementation detect this.
What, I'm supposed to scan the entire file in case that happens?
No. I'll just not be compliant to that, thank you very much.
I even wrote my own Ogg/Vorbis decoder from scratch [mooo.com] a while back (and dabble every now and then), and found Ogg to be a never-cooling, never-extinguishing steaming pile of hippo crap left over from consuming a dog.
It just made everything so difficult to do.
Seeking a stream involves divide-and-conquer - not necessarily a bad thing, but when you have huge streams the number of seeks can be bad.
Not to mention if your stream has an endpoint the other side of the Atlantic Ocean.
Why oh why did they pick timestamps being at the END of a page and indicating the output byte count produced by the END of that page?
That little detail alone probably cost me days of debug.
I almost gave up at one point and went to a container format of my own which would have worked much better.
Header: 'CONTAINER v1'.
Packet: 'MAGIC', 4 byte Length, 4 byte Output pos.
Job done.
The sad fact is, that's easier than Ogg, smaller than Ogg (unless you're talking really low bit rate), and does entirely the job of Ogg without the complexity.
I'm probably going to add a Matroska container to my codec just to see how easy they are to produce.
The spec looks fantastic, but the devil's always in the details - although seeing the praise on various (engineer) forums, it looks like the way to go.
So, Ogg, please die.
We need you to get out of the way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349996</id>
	<title>Re:what is the point, exactly.</title>
	<author>jhfry</author>
	<datestamp>1267608780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A container format is a necessary evil.  There is much more to any media file than just the content. Potentially in any media file there may be metadata, timing information, synchronization information, subtitles, multiple language audio streams, multiple video streams, 3d video streams, surround sound information, interactive content, etc.</p><p>A good container format is one that allows all of those things in a way that developers supporting that container format can utilize in a standard predictable way.</p><p>If you did away with the container, your issues with<nobr> <wbr></nobr>.avi now would be severely compounded as your software must determine how to combine several files into one complete presentation.  This is what many editing packages do... and even ones costing hundreds of dollars can have a hard time of it sometimes.</p></htmltext>
<tokenext>A container format is a necessary evil .
There is much more to any media file than just the content .
Potentially in any media file there may be metadata , timing information , synchronization information , subtitles , multiple language audio streams , multiple video streams , 3d video streams , surround sound information , interactive content , etc.A good container format is one that allows all of those things in a way that developers supporting that container format can utilize in a standard predictable way.If you did away with the container , your issues with .avi now would be severely compounded as your software must determine how to combine several files into one complete presentation .
This is what many editing packages do... and even ones costing hundreds of dollars can have a hard time of it sometimes .</tokentext>
<sentencetext>A container format is a necessary evil.
There is much more to any media file than just the content.
Potentially in any media file there may be metadata, timing information, synchronization information, subtitles, multiple language audio streams, multiple video streams, 3d video streams, surround sound information, interactive content, etc.A good container format is one that allows all of those things in a way that developers supporting that container format can utilize in a standard predictable way.If you did away with the container, your issues with .avi now would be severely compounded as your software must determine how to combine several files into one complete presentation.
This is what many editing packages do... and even ones costing hundreds of dollars can have a hard time of it sometimes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351244</id>
	<title>Re:Still better than AVI</title>
	<author>Anonymous</author>
	<datestamp>1267614660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I liked the article, it actually discussed the technical reasons and wasn't a simple rant. I wonder if the author could review Matroska (and possibly other formats) too. I'd love to see how they all stack up.</p></htmltext>
<tokenext>I liked the article , it actually discussed the technical reasons and was n't a simple rant .
I wonder if the author could review Matroska ( and possibly other formats ) too .
I 'd love to see how they all stack up .</tokentext>
<sentencetext>I liked the article, it actually discussed the technical reasons and wasn't a simple rant.
I wonder if the author could review Matroska (and possibly other formats) too.
I'd love to see how they all stack up.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349836</id>
	<title>Re:what is the point, exactly.</title>
	<author>MobyDisk</author>
	<datestamp>1267608060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are a lot of benefits to containers.  I'm sure I can't name them all.</p><p>These container formats contain multiple types of data streams.  Ex: audio, video, multi-language subtitles, etc.  If you don't have a container format, then the software must guess at what streams are in the file.  Would a file with H264 video + MP3 audio have a different extension from H264 + AAC?  What if I add subtitles, does that need another extension?  The container file solves this.</p><p>Because there are multiple streams, the software could simply pass-through unknown data streams.  Maybe this particular app doesn't understand subtitles.  So it doesn't recognize a stream ID of 12345 - it can display a warning, but preserve the data in the container.</p><p>It makes it possible for software to support new codecs because there is a globally unique way to identify the codec.  So your software opens an AVI file with an MJPG stream.  What can it do?  Well, it could go to it's update site, query for MJPG codecs, and download it.  Without the container format, the software has to guess based on the extension.  And that isn't necessarily enough to know exactly what the file contains - this relates to my first paragraph, about the multitude of extensions.</p><p>Having a container format also means a lot of code is shared.  Code for buffering, I/O, handling time stamps, live data streaming, synchronizing different streams -- those things are going to vary based on how the container is put together.  Some things work on time stamps, others work on integer time indexes.  Some interleave data, and use different methods for doing so.  There are different ways of handling variable-bitrate data.   It makes it easier for the developers, and faster to add additional codecs.</p><p>Metadata such as copyright information won't get lost when transcoding the file if the container format is the same.</p><p>Having lots of containers is a pain.  It would be best if we could standardize on one.  You are right that it does make it harder for the user to determine if the file is supported by that particular app.  Not sure what to do about that though.</p><p>Lastly -- what app doesn't work with MJPEG<nobr> <wbr></nobr>.AVI files????  That's like the absolute baseline most commonly, easily-supported format.</p></htmltext>
<tokenext>There are a lot of benefits to containers .
I 'm sure I ca n't name them all.These container formats contain multiple types of data streams .
Ex : audio , video , multi-language subtitles , etc .
If you do n't have a container format , then the software must guess at what streams are in the file .
Would a file with H264 video + MP3 audio have a different extension from H264 + AAC ?
What if I add subtitles , does that need another extension ?
The container file solves this.Because there are multiple streams , the software could simply pass-through unknown data streams .
Maybe this particular app does n't understand subtitles .
So it does n't recognize a stream ID of 12345 - it can display a warning , but preserve the data in the container.It makes it possible for software to support new codecs because there is a globally unique way to identify the codec .
So your software opens an AVI file with an MJPG stream .
What can it do ?
Well , it could go to it 's update site , query for MJPG codecs , and download it .
Without the container format , the software has to guess based on the extension .
And that is n't necessarily enough to know exactly what the file contains - this relates to my first paragraph , about the multitude of extensions.Having a container format also means a lot of code is shared .
Code for buffering , I/O , handling time stamps , live data streaming , synchronizing different streams -- those things are going to vary based on how the container is put together .
Some things work on time stamps , others work on integer time indexes .
Some interleave data , and use different methods for doing so .
There are different ways of handling variable-bitrate data .
It makes it easier for the developers , and faster to add additional codecs.Metadata such as copyright information wo n't get lost when transcoding the file if the container format is the same.Having lots of containers is a pain .
It would be best if we could standardize on one .
You are right that it does make it harder for the user to determine if the file is supported by that particular app .
Not sure what to do about that though.Lastly -- what app does n't work with MJPEG .AVI files ? ? ? ?
That 's like the absolute baseline most commonly , easily-supported format .</tokentext>
<sentencetext>There are a lot of benefits to containers.
I'm sure I can't name them all.These container formats contain multiple types of data streams.
Ex: audio, video, multi-language subtitles, etc.
If you don't have a container format, then the software must guess at what streams are in the file.
Would a file with H264 video + MP3 audio have a different extension from H264 + AAC?
What if I add subtitles, does that need another extension?
The container file solves this.Because there are multiple streams, the software could simply pass-through unknown data streams.
Maybe this particular app doesn't understand subtitles.
So it doesn't recognize a stream ID of 12345 - it can display a warning, but preserve the data in the container.It makes it possible for software to support new codecs because there is a globally unique way to identify the codec.
So your software opens an AVI file with an MJPG stream.
What can it do?
Well, it could go to it's update site, query for MJPG codecs, and download it.
Without the container format, the software has to guess based on the extension.
And that isn't necessarily enough to know exactly what the file contains - this relates to my first paragraph, about the multitude of extensions.Having a container format also means a lot of code is shared.
Code for buffering, I/O, handling time stamps, live data streaming, synchronizing different streams -- those things are going to vary based on how the container is put together.
Some things work on time stamps, others work on integer time indexes.
Some interleave data, and use different methods for doing so.
There are different ways of handling variable-bitrate data.
It makes it easier for the developers, and faster to add additional codecs.Metadata such as copyright information won't get lost when transcoding the file if the container format is the same.Having lots of containers is a pain.
It would be best if we could standardize on one.
You are right that it does make it harder for the user to determine if the file is supported by that particular app.
Not sure what to do about that though.Lastly -- what app doesn't work with MJPEG .AVI files????
That's like the absolute baseline most commonly, easily-supported format.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350282</id>
	<title>Which doesn't answer the question ...</title>
	<author>ITMagic</author>
	<datestamp>1267610160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>... of what format *should* be used in its place.</p><p>
It is all very well claiming one format is not particularly good, but overall rather pointless if you don't argue an alternative.</p><p>So the question any<nobr> <wbr></nobr>.ogg user will have (since they probably chose this slightly obscure format over the more 'normal'<nobr> <wbr></nobr>.mp3 alternative due to the reputation of being better to listen to from an audiophile POV) is what to use instead? FLAC is fine if you have the space, but sometimes you want to compromise in order to save storage space...</p></htmltext>
<tokenext>... of what format * should * be used in its place .
It is all very well claiming one format is not particularly good , but overall rather pointless if you do n't argue an alternative.So the question any .ogg user will have ( since they probably chose this slightly obscure format over the more 'normal ' .mp3 alternative due to the reputation of being better to listen to from an audiophile POV ) is what to use instead ?
FLAC is fine if you have the space , but sometimes you want to compromise in order to save storage space.. .</tokentext>
<sentencetext>... of what format *should* be used in its place.
It is all very well claiming one format is not particularly good, but overall rather pointless if you don't argue an alternative.So the question any .ogg user will have (since they probably chose this slightly obscure format over the more 'normal' .mp3 alternative due to the reputation of being better to listen to from an audiophile POV) is what to use instead?
FLAC is fine if you have the space, but sometimes you want to compromise in order to save storage space...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360860</id>
	<title>Re:what is the point, exactly.</title>
	<author>hazydave</author>
	<datestamp>1267731900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I should also point out that media containers were not originally designed for random things being distributed over the internet. Rather, they are for developers to author and users to play back.</p><p>As a professional, if I put stuff on a DVD or a Web site that the average computer user couldn't see, that disc or site would include whatever drivers or CODECs one needed in order to video my media. That's still pretty much the rule.</p><p>This is very useful for professional work. For example, I bought a license for the Cineform CODEC, which is an "intermediate" CODEC, designed for fast editing of computationally expensive formats like MPEG-2 and AVC. Not so expensive on their own, but try doing 10 or 20 layers of video in a single project, and you'll meet "slow" on any PC. The multimedia frameworks allow video and audio editors to use new CODECs without any changes to their own code.</p><p>At the fringes, sure, you have pirates and crazy people putting weird stuff inside AVIs, without telling you what it is. But this is not a general problem.</p></htmltext>
<tokenext>I should also point out that media containers were not originally designed for random things being distributed over the internet .
Rather , they are for developers to author and users to play back.As a professional , if I put stuff on a DVD or a Web site that the average computer user could n't see , that disc or site would include whatever drivers or CODECs one needed in order to video my media .
That 's still pretty much the rule.This is very useful for professional work .
For example , I bought a license for the Cineform CODEC , which is an " intermediate " CODEC , designed for fast editing of computationally expensive formats like MPEG-2 and AVC .
Not so expensive on their own , but try doing 10 or 20 layers of video in a single project , and you 'll meet " slow " on any PC .
The multimedia frameworks allow video and audio editors to use new CODECs without any changes to their own code.At the fringes , sure , you have pirates and crazy people putting weird stuff inside AVIs , without telling you what it is .
But this is not a general problem .</tokentext>
<sentencetext>I should also point out that media containers were not originally designed for random things being distributed over the internet.
Rather, they are for developers to author and users to play back.As a professional, if I put stuff on a DVD or a Web site that the average computer user couldn't see, that disc or site would include whatever drivers or CODECs one needed in order to video my media.
That's still pretty much the rule.This is very useful for professional work.
For example, I bought a license for the Cineform CODEC, which is an "intermediate" CODEC, designed for fast editing of computationally expensive formats like MPEG-2 and AVC.
Not so expensive on their own, but try doing 10 or 20 layers of video in a single project, and you'll meet "slow" on any PC.
The multimedia frameworks allow video and audio editors to use new CODECs without any changes to their own code.At the fringes, sure, you have pirates and crazy people putting weird stuff inside AVIs, without telling you what it is.
But this is not a general problem.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350204</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</id>
	<title>what is the point, exactly.</title>
	<author>Anonymous</author>
	<datestamp>1267649580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>I'm not an expert in video or audio production, I just dabble in it as a hobby. but one thing I often wonder is, what is the point of these container formats?</p><p>I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video.  Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg.  Mjpeg files don't work in my editor, while miniDV does.  but I didn't know this at first, all I knew was that I have a bunch of<nobr> <wbr></nobr>.AVI files sitting in my hard drive, some work, some don't.  I dont care about file extensions, I care about having files that work.  I care about codecs.  If they were named "filename.minidv" and "filename.mjpg" that information would be useful to me.  What good is a container format when only half of the files within that container will play on my system?<br>I'm not trying to knock the idea of container formats, if they exist, their must be some beneficial reason for them.  Could someone please enlighten me on what that reason is?</p></htmltext>
<tokenext>I 'm not an expert in video or audio production , I just dabble in it as a hobby .
but one thing I often wonder is , what is the point of these container formats ? I 've got a miniDV camera , and a canon point and shoot that thanks to chdk can record good-enough video .
Both give me " .AVI " files , even though one is miniDV , while the other is Mjpeg .
Mjpeg files do n't work in my editor , while miniDV does .
but I did n't know this at first , all I knew was that I have a bunch of .AVI files sitting in my hard drive , some work , some do n't .
I dont care about file extensions , I care about having files that work .
I care about codecs .
If they were named " filename.minidv " and " filename.mjpg " that information would be useful to me .
What good is a container format when only half of the files within that container will play on my system ? I 'm not trying to knock the idea of container formats , if they exist , their must be some beneficial reason for them .
Could someone please enlighten me on what that reason is ?</tokentext>
<sentencetext>I'm not an expert in video or audio production, I just dabble in it as a hobby.
but one thing I often wonder is, what is the point of these container formats?I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video.
Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg.
Mjpeg files don't work in my editor, while miniDV does.
but I didn't know this at first, all I knew was that I have a bunch of .AVI files sitting in my hard drive, some work, some don't.
I dont care about file extensions, I care about having files that work.
I care about codecs.
If they were named "filename.minidv" and "filename.mjpg" that information would be useful to me.
What good is a container format when only half of the files within that container will play on my system?I'm not trying to knock the idea of container formats, if they exist, their must be some beneficial reason for them.
Could someone please enlighten me on what that reason is?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349144</id>
	<title>already slashdotted ?</title>
	<author>godrik</author>
	<datestamp>1267648080000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>I don't see any comment and the website is already down. gg<nobr> <wbr></nobr>/.</p></htmltext>
<tokenext>I do n't see any comment and the website is already down .
gg / .</tokentext>
<sentencetext>I don't see any comment and the website is already down.
gg /.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349326</id>
	<title>TFA does NOT concern THEORA vs h264</title>
	<author>Anonymous</author>
	<datestamp>1267649040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The article complains about the container format, not about the codec actually used in the container.</p><p>Therefore, please: do not confuse ogg - the - container - format with<br>theora - the codec used to encode the video.</p><p>It would be rather easy to replace / reimplement the container format with something else (easy compared to replacing<br>the codec with a newly designed codec anyway)</p></htmltext>
<tokenext>The article complains about the container format , not about the codec actually used in the container.Therefore , please : do not confuse ogg - the - container - format withtheora - the codec used to encode the video.It would be rather easy to replace / reimplement the container format with something else ( easy compared to replacingthe codec with a newly designed codec anyway )</tokentext>
<sentencetext>The article complains about the container format, not about the codec actually used in the container.Therefore, please: do not confuse ogg - the - container - format withtheora - the codec used to encode the video.It would be rather easy to replace / reimplement the container format with something else (easy compared to replacingthe codec with a newly designed codec anyway)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350204</id>
	<title>Re:what is the point, exactly.</title>
	<author>Neon Spiral Injector</author>
	<datestamp>1267609740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You do make a good point about the name, though.  A name like:  filename.pcm.dv.avi, or filename.mp3.mjpg.avi would reveal a lot more information.  Too bad that scheme isn't more widely used.</p></htmltext>
<tokenext>You do make a good point about the name , though .
A name like : filename.pcm.dv.avi , or filename.mp3.mjpg.avi would reveal a lot more information .
Too bad that scheme is n't more widely used .</tokentext>
<sentencetext>You do make a good point about the name, though.
A name like:  filename.pcm.dv.avi, or filename.mp3.mjpg.avi would reveal a lot more information.
Too bad that scheme isn't more widely used.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350796</id>
	<title>A better free container, IMO: Matroska.</title>
	<author>Hurricane78</author>
	<datestamp>1267612560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Besides it being EBML (a binary and efficient kind of XML), I&rsquo;ve yet to see a feature that it can&rsquo;t do. Even a complete 3D TV series with multiple perspectives, languages, subtitles, additional content, hull cover... streamed over the net in one file? No problem.</p><p>Also, it&rsquo;s already the format of choice for HD video and multichannel audio format rips on the net.</p><p>A competitor would be nice. Unfortunately, OGG can&rsquo;t hold a candle to it. But if they manage to catch up, they will be very welcome.</p></htmltext>
<tokenext>Besides it being EBML ( a binary and efficient kind of XML ) , I    ve yet to see a feature that it can    t do .
Even a complete 3D TV series with multiple perspectives , languages , subtitles , additional content , hull cover... streamed over the net in one file ?
No problem.Also , it    s already the format of choice for HD video and multichannel audio format rips on the net.A competitor would be nice .
Unfortunately , OGG can    t hold a candle to it .
But if they manage to catch up , they will be very welcome .</tokentext>
<sentencetext>Besides it being EBML (a binary and efficient kind of XML), I’ve yet to see a feature that it can’t do.
Even a complete 3D TV series with multiple perspectives, languages, subtitles, additional content, hull cover... streamed over the net in one file?
No problem.Also, it’s already the format of choice for HD video and multichannel audio format rips on the net.A competitor would be nice.
Unfortunately, OGG can’t hold a candle to it.
But if they manage to catch up, they will be very welcome.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350218</id>
	<title>"Everything is broken"</title>
	<author>Anonymous</author>
	<datestamp>1267609860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>His website says "Everything is broken". If that were true wouldn't that, you know, mean that Ogg is no different than its competitors?</p></htmltext>
<tokenext>His website says " Everything is broken " .
If that were true would n't that , you know , mean that Ogg is no different than its competitors ?</tokentext>
<sentencetext>His website says "Everything is broken".
If that were true wouldn't that, you know, mean that Ogg is no different than its competitors?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350418</id>
	<title>Re:Still better than AVI</title>
	<author>Late Adopter</author>
	<datestamp>1267610820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your system</p></div><p>I see the problem, but consider that it's also sort of a feature: your video player knows that it's a Matroska file, so it can determine the codec and tell you what you need to download, or autodownload it, so you can continue to use the same video player for a variety of types of Matroska files.
<br> <br>
In terms of standardizing, there's no need to support all possible codecs, an HTML5 spec could in theory say "browsers must support Matroska+h264 and Matroska+theora files".</p></div>
	</htmltext>
<tokenext>Unless you have a program like mplayer or vlc you ca n't guarantee that a Matroska file is going to be playable on your systemI see the problem , but consider that it 's also sort of a feature : your video player knows that it 's a Matroska file , so it can determine the codec and tell you what you need to download , or autodownload it , so you can continue to use the same video player for a variety of types of Matroska files .
In terms of standardizing , there 's no need to support all possible codecs , an HTML5 spec could in theory say " browsers must support Matroska + h264 and Matroska + theora files " .</tokentext>
<sentencetext>Unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your systemI see the problem, but consider that it's also sort of a feature: your video player knows that it's a Matroska file, so it can determine the codec and tell you what you need to download, or autodownload it, so you can continue to use the same video player for a variety of types of Matroska files.
In terms of standardizing, there's no need to support all possible codecs, an HTML5 spec could in theory say "browsers must support Matroska+h264 and Matroska+theora files".
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353076</id>
	<title>Re:what is the point, exactly.</title>
	<author>Bent Mind</author>
	<datestamp>1267624980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video. Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg. Mjpeg files don't work in my editor, while miniDV does.</p></div><p>If you are just doing web-cam quality recording, AVI should be just fine. If you want DVD( or higher) quality video longer than about an hour, multiple sound tracks, subtitles, or menus, AVI files no longer work.</p><p><div class="quote"><p>Mjpeg files don't work in my editor,</p></div><p>Ironically enough, this is one of the major problems with most (all?) proprietary codecs. They cost money to use. Most times, this payment is made by the programmer/publisher. To keep the software affordable, they limit the number of proprietary codecs used. If you want software that supports more proprietary codecs, pay more. Your other choices are to pick a common codec that supports what you need and software that supports it, or use non-proprietary codecs.</p></div>
	</htmltext>
<tokenext>I 've got a miniDV camera , and a canon point and shoot that thanks to chdk can record good-enough video .
Both give me " .AVI " files , even though one is miniDV , while the other is Mjpeg .
Mjpeg files do n't work in my editor , while miniDV does.If you are just doing web-cam quality recording , AVI should be just fine .
If you want DVD ( or higher ) quality video longer than about an hour , multiple sound tracks , subtitles , or menus , AVI files no longer work.Mjpeg files do n't work in my editor,Ironically enough , this is one of the major problems with most ( all ?
) proprietary codecs .
They cost money to use .
Most times , this payment is made by the programmer/publisher .
To keep the software affordable , they limit the number of proprietary codecs used .
If you want software that supports more proprietary codecs , pay more .
Your other choices are to pick a common codec that supports what you need and software that supports it , or use non-proprietary codecs .</tokentext>
<sentencetext>I've got a miniDV camera, and a canon point and shoot that thanks to chdk can record good-enough video.
Both give me ".AVI" files, even though one is miniDV, while the other is Mjpeg.
Mjpeg files don't work in my editor, while miniDV does.If you are just doing web-cam quality recording, AVI should be just fine.
If you want DVD( or higher) quality video longer than about an hour, multiple sound tracks, subtitles, or menus, AVI files no longer work.Mjpeg files don't work in my editor,Ironically enough, this is one of the major problems with most (all?
) proprietary codecs.
They cost money to use.
Most times, this payment is made by the programmer/publisher.
To keep the software affordable, they limit the number of proprietary codecs used.
If you want software that supports more proprietary codecs, pay more.
Your other choices are to pick a common codec that supports what you need and software that supports it, or use non-proprietary codecs.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350316</id>
	<title>Re:Flawed reasoning...</title>
	<author>Anonymous</author>
	<datestamp>1267610340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>go tell those ipvX guys. they reserved a whole byte, in every packet, when thay could have used one, and the other 7 for qos or other... guess why?<br>hint: because if you know the version is specified in the first 8 bits, you just read a char, instead of reading a bit, then reading an other to see if it's version 2 or 2+, then an other...<br>and at the 8th version you have already occupied 8 bits!<br>so it's a little more difficoult to parse, it's inefficient at the 8th version, just to save 7 BITS on a stream that is 1MB per second at least???</p></htmltext>
<tokenext>go tell those ipvX guys .
they reserved a whole byte , in every packet , when thay could have used one , and the other 7 for qos or other... guess why ? hint : because if you know the version is specified in the first 8 bits , you just read a char , instead of reading a bit , then reading an other to see if it 's version 2 or 2 + , then an other...and at the 8th version you have already occupied 8 bits ! so it 's a little more difficoult to parse , it 's inefficient at the 8th version , just to save 7 BITS on a stream that is 1MB per second at least ? ?
?</tokentext>
<sentencetext>go tell those ipvX guys.
they reserved a whole byte, in every packet, when thay could have used one, and the other 7 for qos or other... guess why?hint: because if you know the version is specified in the first 8 bits, you just read a char, instead of reading a bit, then reading an other to see if it's version 2 or 2+, then an other...and at the 8th version you have already occupied 8 bits!so it's a little more difficoult to parse, it's inefficient at the 8th version, just to save 7 BITS on a stream that is 1MB per second at least??
?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351136</id>
	<title>Re:Flawed reasoning...</title>
	<author>Anonymous</author>
	<datestamp>1267614180000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Why is this stupid comment +4 insightful? Read the follow up posts if you moderators totally clueless.</p></htmltext>
<tokenext>Why is this stupid comment + 4 insightful ?
Read the follow up posts if you moderators totally clueless .</tokentext>
<sentencetext>Why is this stupid comment +4 insightful?
Read the follow up posts if you moderators totally clueless.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350062</id>
	<title>Re:what is the point, exactly.</title>
	<author>JesseMcDonald</author>
	<datestamp>1267609080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If all you have is a single video stream then you don't really need a container. However, once you start adding in audio tracks, subtitles, and interactive features (e.g. menus), you need some way to combine these streams together in a manner which minimizes the need for buffering and/or random access (seeking) during normal playback. Container formats also supply the format identification, tags/metadata, and indexing/seeking support which raw formats typically lack.</p></htmltext>
<tokenext>If all you have is a single video stream then you do n't really need a container .
However , once you start adding in audio tracks , subtitles , and interactive features ( e.g .
menus ) , you need some way to combine these streams together in a manner which minimizes the need for buffering and/or random access ( seeking ) during normal playback .
Container formats also supply the format identification , tags/metadata , and indexing/seeking support which raw formats typically lack .</tokentext>
<sentencetext>If all you have is a single video stream then you don't really need a container.
However, once you start adding in audio tracks, subtitles, and interactive features (e.g.
menus), you need some way to combine these streams together in a manner which minimizes the need for buffering and/or random access (seeking) during normal playback.
Container formats also supply the format identification, tags/metadata, and indexing/seeking support which raw formats typically lack.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350306</id>
	<title>Re:Just complaining</title>
	<author>evilviper</author>
	<datestamp>1267610280000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>"I would have done it diffferently" does not mean that the format is bad.</p></div></blockquote><p>Every open source multimedia developer outside of Xiph.org, who has had to do anything with Ogg, will tell you that Ogg is a flaming pile of crap.  This notably includes Moritz Bunkus, the author of Ogmtools.  Quotes of such are easy to find.</p><p>For a real challenge, just try to find ANYONE saying Ogg is a well-deigned and well thought-out container format...</p></div>
	</htmltext>
<tokenext>" I would have done it diffferently " does not mean that the format is bad.Every open source multimedia developer outside of Xiph.org , who has had to do anything with Ogg , will tell you that Ogg is a flaming pile of crap .
This notably includes Moritz Bunkus , the author of Ogmtools .
Quotes of such are easy to find.For a real challenge , just try to find ANYONE saying Ogg is a well-deigned and well thought-out container format.. .</tokentext>
<sentencetext>"I would have done it diffferently" does not mean that the format is bad.Every open source multimedia developer outside of Xiph.org, who has had to do anything with Ogg, will tell you that Ogg is a flaming pile of crap.
This notably includes Moritz Bunkus, the author of Ogmtools.
Quotes of such are easy to find.For a real challenge, just try to find ANYONE saying Ogg is a well-deigned and well thought-out container format...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351408</id>
	<title>Re:Flawed reasoning...</title>
	<author>Anonymous</author>
	<datestamp>1267615500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>&gt;<em>I don't see any reason, why the version would have to change in the middle of a file in any case.</em> </p><p>Possibly because cat one.ogg two.ogg &gt;onethentwo.ogg creates a valid ogg file which behaves as you would expect it to (which is to say, it plays fine).</p></htmltext>
<tokenext>&gt; I do n't see any reason , why the version would have to change in the middle of a file in any case .
Possibly because cat one.ogg two.ogg &gt; onethentwo.ogg creates a valid ogg file which behaves as you would expect it to ( which is to say , it plays fine ) .</tokentext>
<sentencetext>&gt;I don't see any reason, why the version would have to change in the middle of a file in any case.
Possibly because cat one.ogg two.ogg &gt;onethentwo.ogg creates a valid ogg file which behaves as you would expect it to (which is to say, it plays fine).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353242</id>
	<title>Re:NUT open container format</title>
	<author>Anonymous</author>
	<datestamp>1267626660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>a Matroska file can only contain one timebase. Thus, in order to mux streams with different timebases, approximation is required. To accurately represent the converted timebases, it is necessary to use a much finer granularity, and then you also lose the exact timestamps.</p></div></blockquote><p>Well, yeah.  If you mix 25fps video and 30fps video, then you need to convert the timestamps to units of 1/150 of second.  That's just how the math works out.  How would you do it differently?</p></div>
	</htmltext>
<tokenext>a Matroska file can only contain one timebase .
Thus , in order to mux streams with different timebases , approximation is required .
To accurately represent the converted timebases , it is necessary to use a much finer granularity , and then you also lose the exact timestamps.Well , yeah .
If you mix 25fps video and 30fps video , then you need to convert the timestamps to units of 1/150 of second .
That 's just how the math works out .
How would you do it differently ?</tokentext>
<sentencetext>a Matroska file can only contain one timebase.
Thus, in order to mux streams with different timebases, approximation is required.
To accurately represent the converted timebases, it is necessary to use a much finer granularity, and then you also lose the exact timestamps.Well, yeah.
If you mix 25fps video and 30fps video, then you need to convert the timestamps to units of 1/150 of second.
That's just how the math works out.
How would you do it differently?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351826</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349938</id>
	<title>Re:what is the point, exactly.</title>
	<author>ink</author>
	<datestamp>1267608420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Think about an HTML file.  It can contain embedded objects and/or alternative tags, or newer tags, all of which your browser may or may not work with.  Containers are important because they provide the meta information that players need to orchestrate the various streams embedded in them.  Some containers were built for instant streaming in mind (FLV).  Some were simple data partitions (AVI).  Some are jack-of-all-trades that do everything (MKV).  Some are so simple that the user has to provide information about the video in order to interpret them (raw YUV).  Some containers are horrible at seeking to key frames (WMV).  Some easily get out of sync audio (AVI).  Ideally, we should be using Matroska for everything -- but we don't live in an ideal world.</p></htmltext>
<tokenext>Think about an HTML file .
It can contain embedded objects and/or alternative tags , or newer tags , all of which your browser may or may not work with .
Containers are important because they provide the meta information that players need to orchestrate the various streams embedded in them .
Some containers were built for instant streaming in mind ( FLV ) .
Some were simple data partitions ( AVI ) .
Some are jack-of-all-trades that do everything ( MKV ) .
Some are so simple that the user has to provide information about the video in order to interpret them ( raw YUV ) .
Some containers are horrible at seeking to key frames ( WMV ) .
Some easily get out of sync audio ( AVI ) .
Ideally , we should be using Matroska for everything -- but we do n't live in an ideal world .</tokentext>
<sentencetext>Think about an HTML file.
It can contain embedded objects and/or alternative tags, or newer tags, all of which your browser may or may not work with.
Containers are important because they provide the meta information that players need to orchestrate the various streams embedded in them.
Some containers were built for instant streaming in mind (FLV).
Some were simple data partitions (AVI).
Some are jack-of-all-trades that do everything (MKV).
Some are so simple that the user has to provide information about the video in order to interpret them (raw YUV).
Some containers are horrible at seeking to key frames (WMV).
Some easily get out of sync audio (AVI).
Ideally, we should be using Matroska for everything -- but we don't live in an ideal world.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349470</id>
	<title>Re:Just complaining</title>
	<author>Aladrin</author>
	<datestamp>1267649700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Actually, they never said 'unusable'.  They said 'ill-suited'.  And it is, if their technical objections are all correct.</p><p>It sounds like Ogg tried to be too much and as with any over-generalization, the specifics suffer for it.</p><p>That doesn't mean it should't be used, it just means it's not optimal.</p></htmltext>
<tokenext>Actually , they never said 'unusable' .
They said 'ill-suited' .
And it is , if their technical objections are all correct.It sounds like Ogg tried to be too much and as with any over-generalization , the specifics suffer for it.That does n't mean it should't be used , it just means it 's not optimal .</tokentext>
<sentencetext>Actually, they never said 'unusable'.
They said 'ill-suited'.
And it is, if their technical objections are all correct.It sounds like Ogg tried to be too much and as with any over-generalization, the specifics suffer for it.That doesn't mean it should't be used, it just means it's not optimal.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349446</id>
	<title>Re:Just complaining</title>
	<author>Anonymous</author>
	<datestamp>1267649580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You know what's also implemented, available and in use? <a href="http://news.ycombinator.com/item?id=1138923" title="ycombinator.com" rel="nofollow">Matroska</a> [ycombinator.com]<br>While it isn't perfect it has certainly seen more use than Ogg, at least in the video world. Haven't read the article, because it's slashdoted, but I assume it's about the fact that the Ogg container was initially designed as a transport stream format for audio. While that's nice for streaming most video sites use progressive download to deliver the files, so it's not an advantage in that situation. I read that Xiph is only now working on implementing a keyframe index to allow proper seeking in video. Ogg also makes it complicated to integrate support for new codecs. You basically have to rewrite the splitter to support them. See <a href="http://x264dev.multimedia.cx/?p=292#comments" title="multimedia.cx" rel="nofollow">here</a> [multimedia.cx] posts 48 to 52. The last post also has a link to an older hardwarebug article describing problems with the Ogg container.</p></htmltext>
<tokenext>You know what 's also implemented , available and in use ?
Matroska [ ycombinator.com ] While it is n't perfect it has certainly seen more use than Ogg , at least in the video world .
Have n't read the article , because it 's slashdoted , but I assume it 's about the fact that the Ogg container was initially designed as a transport stream format for audio .
While that 's nice for streaming most video sites use progressive download to deliver the files , so it 's not an advantage in that situation .
I read that Xiph is only now working on implementing a keyframe index to allow proper seeking in video .
Ogg also makes it complicated to integrate support for new codecs .
You basically have to rewrite the splitter to support them .
See here [ multimedia.cx ] posts 48 to 52 .
The last post also has a link to an older hardwarebug article describing problems with the Ogg container .</tokentext>
<sentencetext>You know what's also implemented, available and in use?
Matroska [ycombinator.com]While it isn't perfect it has certainly seen more use than Ogg, at least in the video world.
Haven't read the article, because it's slashdoted, but I assume it's about the fact that the Ogg container was initially designed as a transport stream format for audio.
While that's nice for streaming most video sites use progressive download to deliver the files, so it's not an advantage in that situation.
I read that Xiph is only now working on implementing a keyframe index to allow proper seeking in video.
Ogg also makes it complicated to integrate support for new codecs.
You basically have to rewrite the splitter to support them.
See here [multimedia.cx] posts 48 to 52.
The last post also has a link to an older hardwarebug article describing problems with the Ogg container.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351826</id>
	<title>NUT open container format</title>
	<author>Anonymous</author>
	<datestamp>1267617360000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>NUT is another alternative, which is open, simple, and well designed.  Along with Matroska, it is also capable of containing Ogg Theora and Vorbis streams, so there is really is no good reason to use the Ogg container anymore.  The author of the article is correct--the Ogg container is an awful format.</p><p>The main complaints about Matroska are two-fold.  One, the EMBL encoding is overly complicated.  It requires a considerable amount of code to parse, and also imposes an unnecessary degree of overhead.  The second is a much more serious problem: a Matroska file can only contain one timebase.  Thus, in order to mux streams with different timebases, approximation is required.  To accurately represent the converted timebases, it is necessary to use a much finer granularity, and then you also lose the exact timestamps.</p><p>The NUT specification and code is available from svn://svn.mplayerhq.hu/nut, and the (de)muxers are included in MPlayer/FFmpeg, VLC, and probably elsewhere.</p></htmltext>
<tokenext>NUT is another alternative , which is open , simple , and well designed .
Along with Matroska , it is also capable of containing Ogg Theora and Vorbis streams , so there is really is no good reason to use the Ogg container anymore .
The author of the article is correct--the Ogg container is an awful format.The main complaints about Matroska are two-fold .
One , the EMBL encoding is overly complicated .
It requires a considerable amount of code to parse , and also imposes an unnecessary degree of overhead .
The second is a much more serious problem : a Matroska file can only contain one timebase .
Thus , in order to mux streams with different timebases , approximation is required .
To accurately represent the converted timebases , it is necessary to use a much finer granularity , and then you also lose the exact timestamps.The NUT specification and code is available from svn : //svn.mplayerhq.hu/nut , and the ( de ) muxers are included in MPlayer/FFmpeg , VLC , and probably elsewhere .</tokentext>
<sentencetext>NUT is another alternative, which is open, simple, and well designed.
Along with Matroska, it is also capable of containing Ogg Theora and Vorbis streams, so there is really is no good reason to use the Ogg container anymore.
The author of the article is correct--the Ogg container is an awful format.The main complaints about Matroska are two-fold.
One, the EMBL encoding is overly complicated.
It requires a considerable amount of code to parse, and also imposes an unnecessary degree of overhead.
The second is a much more serious problem: a Matroska file can only contain one timebase.
Thus, in order to mux streams with different timebases, approximation is required.
To accurately represent the converted timebases, it is necessary to use a much finer granularity, and then you also lose the exact timestamps.The NUT specification and code is available from svn://svn.mplayerhq.hu/nut, and the (de)muxers are included in MPlayer/FFmpeg, VLC, and probably elsewhere.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351916</id>
	<title>Dirac may have more future</title>
	<author>Anonymous</author>
	<datestamp>1267617900000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Overall, most experts would agree that Theora is still a good codec but it seems like the latest talk is all about Dirac: http://en.wikipedia.org/wiki/Dirac\_\%28codec\%29 and http://diracvideo.org which is a very strong contender. It has suddenly gained backing from a number of the major corporations who were previously in favor of H.264... This is good news since Dirac offers much better quality than either of the other codecs, is royalty-free, and released under either GPL2, LGPL2, or MPL.</p></htmltext>
<tokenext>Overall , most experts would agree that Theora is still a good codec but it seems like the latest talk is all about Dirac : http : //en.wikipedia.org/wiki/Dirac \ _ \ % 28codec \ % 29 and http : //diracvideo.org which is a very strong contender .
It has suddenly gained backing from a number of the major corporations who were previously in favor of H.264... This is good news since Dirac offers much better quality than either of the other codecs , is royalty-free , and released under either GPL2 , LGPL2 , or MPL .</tokentext>
<sentencetext>Overall, most experts would agree that Theora is still a good codec but it seems like the latest talk is all about Dirac: http://en.wikipedia.org/wiki/Dirac\_\%28codec\%29 and http://diracvideo.org which is a very strong contender.
It has suddenly gained backing from a number of the major corporations who were previously in favor of H.264... This is good news since Dirac offers much better quality than either of the other codecs, is royalty-free, and released under either GPL2, LGPL2, or MPL.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360430</id>
	<title>Re:Still better than AVI</title>
	<author>stardaemon</author>
	<datestamp>1267729920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The great thing about Matroska is that it supports (or at least can support) absolutely everything.
The main drawback of Matroska is that it supports (or at least can support) absolutely everything.</p><p>Matroska is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your system. You can't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30+ different codecs in their software, which from a practical standpoint it will. The unfortunate reality is that most of the world's population still doesn't have access to a comprehensive library of software like apt, and while our current software IP regime reigns, they never will.</p></div><p>Which would be why you would specify the codecs in the standard as well, which is what the html5 video debate is mostly about.</p></div>
	</htmltext>
<tokenext>The great thing about Matroska is that it supports ( or at least can support ) absolutely everything .
The main drawback of Matroska is that it supports ( or at least can support ) absolutely everything.Matroska is a great container format , but unless you have a program like mplayer or vlc you ca n't guarantee that a Matroska file is going to be playable on your system .
You ca n't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30 + different codecs in their software , which from a practical standpoint it will .
The unfortunate reality is that most of the world 's population still does n't have access to a comprehensive library of software like apt , and while our current software IP regime reigns , they never will.Which would be why you would specify the codecs in the standard as well , which is what the html5 video debate is mostly about .</tokentext>
<sentencetext>The great thing about Matroska is that it supports (or at least can support) absolutely everything.
The main drawback of Matroska is that it supports (or at least can support) absolutely everything.Matroska is a great container format, but unless you have a program like mplayer or vlc you can't guarantee that a Matroska file is going to be playable on your system.
You can't reasonably expect browser maker to standardise on Matroska if it will mean having to include 30+ different codecs in their software, which from a practical standpoint it will.
The unfortunate reality is that most of the world's population still doesn't have access to a comprehensive library of software like apt, and while our current software IP regime reigns, they never will.Which would be why you would specify the codecs in the standard as well, which is what the html5 video debate is mostly about.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350770</id>
	<title>Because its a f*king streaming format</title>
	<author>Anonymous</author>
	<datestamp>1267612440000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>The reason that the page header data is repeated is because Ogg is a streaming file format.  You can write it out live in real time, and decoders can decode it as you write it... you can arbitrarily chop it in the middle and or truncated off the end and still get something demuxable.  You don't have to seek back and rewrite headers when you're done writing, and you don't have to seek to the end to read footers when you're done reading.   Other formats (e.g. MKV) don't handle truncation, incremental writing, and streaming as well (or without putting them into a mode that makes their behaviour and overhead more similar to Ogg.</p><p>This means that some header data must be repeated frequently.    The version number is 8 bits so that highly simplistic code can implement a version check with simple character level logic and without implementing a fancy format-specific bit unpacker.     Yes, it costs a little efficiency, but if you really can't tolerate 7 BITS of additional overhead per greater than 500k bits (0.001\%) then you have no business using \_any\_ multimedia transport format.</p></htmltext>
<tokenext>The reason that the page header data is repeated is because Ogg is a streaming file format .
You can write it out live in real time , and decoders can decode it as you write it... you can arbitrarily chop it in the middle and or truncated off the end and still get something demuxable .
You do n't have to seek back and rewrite headers when you 're done writing , and you do n't have to seek to the end to read footers when you 're done reading .
Other formats ( e.g .
MKV ) do n't handle truncation , incremental writing , and streaming as well ( or without putting them into a mode that makes their behaviour and overhead more similar to Ogg.This means that some header data must be repeated frequently .
The version number is 8 bits so that highly simplistic code can implement a version check with simple character level logic and without implementing a fancy format-specific bit unpacker .
Yes , it costs a little efficiency , but if you really ca n't tolerate 7 BITS of additional overhead per greater than 500k bits ( 0.001 \ % ) then you have no business using \ _any \ _ multimedia transport format .</tokentext>
<sentencetext>The reason that the page header data is repeated is because Ogg is a streaming file format.
You can write it out live in real time, and decoders can decode it as you write it... you can arbitrarily chop it in the middle and or truncated off the end and still get something demuxable.
You don't have to seek back and rewrite headers when you're done writing, and you don't have to seek to the end to read footers when you're done reading.
Other formats (e.g.
MKV) don't handle truncation, incremental writing, and streaming as well (or without putting them into a mode that makes their behaviour and overhead more similar to Ogg.This means that some header data must be repeated frequently.
The version number is 8 bits so that highly simplistic code can implement a version check with simple character level logic and without implementing a fancy format-specific bit unpacker.
Yes, it costs a little efficiency, but if you really can't tolerate 7 BITS of additional overhead per greater than 500k bits (0.001\%) then you have no business using \_any\_ multimedia transport format.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350702</id>
	<title>Re:Which doesn't answer the question ...</title>
	<author>tbannist</author>
	<datestamp>1267612200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm not sure if the author of the article assumed people knew the intimate details of other formats, but if he had included some relevant compare and contrast with other formats, I might have been moved to actually care about what appears to me to be nothing more than an impotent rant.</p><p>It's got technical details in it, but they lack context and objectivity to anyone who's not a specialist in container encodings.</p><p>Frankly, the random swipes at people who disagree with him, and some of the more bizarre claims (All formats should use a 1-bit version field?) don't inspire me to believe the author or the article.</p></htmltext>
<tokenext>I 'm not sure if the author of the article assumed people knew the intimate details of other formats , but if he had included some relevant compare and contrast with other formats , I might have been moved to actually care about what appears to me to be nothing more than an impotent rant.It 's got technical details in it , but they lack context and objectivity to anyone who 's not a specialist in container encodings.Frankly , the random swipes at people who disagree with him , and some of the more bizarre claims ( All formats should use a 1-bit version field ?
) do n't inspire me to believe the author or the article .</tokentext>
<sentencetext>I'm not sure if the author of the article assumed people knew the intimate details of other formats, but if he had included some relevant compare and contrast with other formats, I might have been moved to actually care about what appears to me to be nothing more than an impotent rant.It's got technical details in it, but they lack context and objectivity to anyone who's not a specialist in container encodings.Frankly, the random swipes at people who disagree with him, and some of the more bizarre claims (All formats should use a 1-bit version field?
) don't inspire me to believe the author or the article.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350282</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351056</id>
	<title>Overly-large analysis of article</title>
	<author>Anonymous</author>
	<datestamp>1267613820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Quite a bit of the analysis seems to be reasonable on the surface, but something about the way it was presented set me off in a geek-rant that I put in the comments.  Since I'm having trouble posting that comment on the site, here it is.</p><p>Many of the points sound reasonable, but the argument is strongly undermined by the fact that it offers not a single apples-to-apples comparison between ogg and any other container format in the article.  On a section-by-section basis:</p><p>Generalities/codec mapping:</p><p>Article complains about how there is no global mapping, but does not assert that other containers have one.</p><p>Overhead:</p><p>The breakdown of where space is wasted is informative and mostly reasonable, but some of them seem to be a reach, such as the checksum being unneeded, and the suggestion of implementing the functionality in optional fields seems like a bad idea to me in general, since it will make the header variable-length, which is something to strongly avoid in my experience.  Finally, when the article does "compare" ogg to mp4, it compares some rather hand-wavey numbers for ogg to a different scenario for mp4.</p><p>Latency:</p><p>The article fires off a bunch of numbers here, but then offers no comparison to the alternatives.  In fact it don't even provide an explanation of how other formats avoid this latency in theory, much less in practice, and instead of showing how bad the latency is, it uses it as a platform to show that a naive reaction to the issue will cause bad header overhead.</p><p>Random Access:</p><p>In this section it lists quite a few worst-case numbers for disk accesses (why isn't it being pre-cached by the filesystem?) and then ends with no comparison to alternatives at all.</p><p>Complexity:</p><p>Once again it has a bunch of statements of problems the author has with the format, but no comparisons to "good" formats, in addition this section is particularly weak, with statements like, "implementation is annoying", and "ambiguity is bad".</p><p>Final Words:</p><p>"We have shown" is a rather specific claim to make, which the article has not remotely achieved.  This pretty much sums up the whole article, which is titled "Ogg objections", but then tries in the text to bill itself as a rigorous analysis of ogg, which it is not.</p><p>If the author had matched the tone of the article to the title, this would be reasonable, but he only hurts his position when he throws around phrases like, "True generality is evidently not to be found with the Ogg format.", "The Ogg format is clearly not a good choice for a low-latency application.", and "We have shown the Ogg format to be a dubious choice in just about every situation.".  He has demonstrated NONE of the above claims, and by making them the article has rendered me skeptical of the rest of its claims.</p></htmltext>
<tokenext>Quite a bit of the analysis seems to be reasonable on the surface , but something about the way it was presented set me off in a geek-rant that I put in the comments .
Since I 'm having trouble posting that comment on the site , here it is.Many of the points sound reasonable , but the argument is strongly undermined by the fact that it offers not a single apples-to-apples comparison between ogg and any other container format in the article .
On a section-by-section basis : Generalities/codec mapping : Article complains about how there is no global mapping , but does not assert that other containers have one.Overhead : The breakdown of where space is wasted is informative and mostly reasonable , but some of them seem to be a reach , such as the checksum being unneeded , and the suggestion of implementing the functionality in optional fields seems like a bad idea to me in general , since it will make the header variable-length , which is something to strongly avoid in my experience .
Finally , when the article does " compare " ogg to mp4 , it compares some rather hand-wavey numbers for ogg to a different scenario for mp4.Latency : The article fires off a bunch of numbers here , but then offers no comparison to the alternatives .
In fact it do n't even provide an explanation of how other formats avoid this latency in theory , much less in practice , and instead of showing how bad the latency is , it uses it as a platform to show that a naive reaction to the issue will cause bad header overhead.Random Access : In this section it lists quite a few worst-case numbers for disk accesses ( why is n't it being pre-cached by the filesystem ?
) and then ends with no comparison to alternatives at all.Complexity : Once again it has a bunch of statements of problems the author has with the format , but no comparisons to " good " formats , in addition this section is particularly weak , with statements like , " implementation is annoying " , and " ambiguity is bad " .Final Words : " We have shown " is a rather specific claim to make , which the article has not remotely achieved .
This pretty much sums up the whole article , which is titled " Ogg objections " , but then tries in the text to bill itself as a rigorous analysis of ogg , which it is not.If the author had matched the tone of the article to the title , this would be reasonable , but he only hurts his position when he throws around phrases like , " True generality is evidently not to be found with the Ogg format .
" , " The Ogg format is clearly not a good choice for a low-latency application .
" , and " We have shown the Ogg format to be a dubious choice in just about every situation. " .
He has demonstrated NONE of the above claims , and by making them the article has rendered me skeptical of the rest of its claims .</tokentext>
<sentencetext>Quite a bit of the analysis seems to be reasonable on the surface, but something about the way it was presented set me off in a geek-rant that I put in the comments.
Since I'm having trouble posting that comment on the site, here it is.Many of the points sound reasonable, but the argument is strongly undermined by the fact that it offers not a single apples-to-apples comparison between ogg and any other container format in the article.
On a section-by-section basis:Generalities/codec mapping:Article complains about how there is no global mapping, but does not assert that other containers have one.Overhead:The breakdown of where space is wasted is informative and mostly reasonable, but some of them seem to be a reach, such as the checksum being unneeded, and the suggestion of implementing the functionality in optional fields seems like a bad idea to me in general, since it will make the header variable-length, which is something to strongly avoid in my experience.
Finally, when the article does "compare" ogg to mp4, it compares some rather hand-wavey numbers for ogg to a different scenario for mp4.Latency:The article fires off a bunch of numbers here, but then offers no comparison to the alternatives.
In fact it don't even provide an explanation of how other formats avoid this latency in theory, much less in practice, and instead of showing how bad the latency is, it uses it as a platform to show that a naive reaction to the issue will cause bad header overhead.Random Access:In this section it lists quite a few worst-case numbers for disk accesses (why isn't it being pre-cached by the filesystem?
) and then ends with no comparison to alternatives at all.Complexity:Once again it has a bunch of statements of problems the author has with the format, but no comparisons to "good" formats, in addition this section is particularly weak, with statements like, "implementation is annoying", and "ambiguity is bad".Final Words:"We have shown" is a rather specific claim to make, which the article has not remotely achieved.
This pretty much sums up the whole article, which is titled "Ogg objections", but then tries in the text to bill itself as a rigorous analysis of ogg, which it is not.If the author had matched the tone of the article to the title, this would be reasonable, but he only hurts his position when he throws around phrases like, "True generality is evidently not to be found with the Ogg format.
", "The Ogg format is clearly not a good choice for a low-latency application.
", and "We have shown the Ogg format to be a dubious choice in just about every situation.".
He has demonstrated NONE of the above claims, and by making them the article has rendered me skeptical of the rest of its claims.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349226</id>
	<title>MKV</title>
	<author>Rickz0rz</author>
	<datestamp>1267648500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Just use MKV and be done with it already<nobr> <wbr></nobr>:/</htmltext>
<tokenext>Just use MKV and be done with it already : /</tokentext>
<sentencetext>Just use MKV and be done with it already :/</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350900
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351980
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350450
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351586
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360860
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350204
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351124
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350418
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350770
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353396
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350220
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349708
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352922
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351360
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31357038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349800
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351972
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351408
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351382
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361642
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361224
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351916
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350702
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350282
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350378
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350570
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361398
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351708
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350328
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360430
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353076
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31354512
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349936
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351136
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349938
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351450
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349352
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352154
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31355930
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351360
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360524
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349996
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350316
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361058
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349826
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349678
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349446
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349706
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351244
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351158
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353242
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351826
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350062
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349694
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349764
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350214
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349470
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_03_1913246_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349658
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349164
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349382
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351136
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353396
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349894
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350214
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351408
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350770
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350316
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350328
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350220
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349694
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351708
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361398
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353694
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349144
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349326
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350154
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349150
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349384
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349936
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31354512
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361642
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350450
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351244
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350378
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349498
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31357038
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351382
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350418
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351980
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352154
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351908
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360430
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349826
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351056
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349164
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349658
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349910
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351916
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361224
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349174
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349446
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349470
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349352
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350570
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349448
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349800
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349842
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349708
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349678
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360524
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349706
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353076
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349764
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350900
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349938
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349996
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350204
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31360860
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349836
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350282
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350702
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31349226
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351360
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31355930
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31352922
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351826
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31353242
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_03_1913246.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31350382
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351450
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351158
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351124
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31361058
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351972
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_03_1913246.31351586
</commentlist>
</conversation>
