https://wiki.xiph.org/api.php?action=feedcontributions&user=J%5E&feedformat=atomXiphWiki - User contributions [en]2024-03-28T23:06:03ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=MatroskaOpus&diff=14354MatroskaOpus2013-12-10T00:35:31Z<p>J^: move Proposal 8 into list</p>
<hr />
<div>== '''DRAFT''' ==<br />
<br />
This is an encapsulation spec for the [[Opus]] codec in [[http://matroska.org/ Matroska]]. There are a number of outstanding functional issues with muxing Opus in Matroska, and until those are resolved, use of this spec is NOT RECOMMENDED.<br />
<br />
- CodecID is A_OPUS<br />
- SampleFrequecy is 48000<br />
- Channels is number of output PCM channels<br />
- SeekPreRoll is set to 80000000<br />
- CodecPrivate starts with the 'OpusHead' packet, identical to the Ogg mapping, followed by the pre-skip data.<br />
<br />
The 'OpusHead' format is defined by the [[http://tools.ietf.org/html/draft-terriberry-oggopus Ogg Opus]] mapping. In particular it includes pre-skip, gain, and the channel mapping table required for correct surround output.<br />
<br />
The second 'OpusTags' header packet from Ogg Opus is not used in the Matroska encapsulation. Matroska has its own system for tag metadata, and this avoids duplicating it and the need for sub-framing to index multiple packets within the CodecPrivate element.<br />
<br />
SeekPreRoll [56][BB] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, after a seek until the decoded data is valid to render.<br />
<br />
CodecDelay [56][AA] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation timestamp. (This will fix Vorbis encoding as well.)<br />
<br />
DiscardPadding [75][A2] is a new signed integer element added to the BlockGroup element. DiscardPadding is the duration in nanoseconds of the silent data added to the Block (padding at the end of the block). The duration of DiscardPadding is not calculated in the duration of the Track and should be discarded during playback. (This will fix Vorbis encoding as well.)<br />
<br />
<br />
(TODO) Define layout of CodecPrivate.<br />
<br />
== Muxing Recommendations ==<br />
<br />
In order to prevent extraneous parsing of muxed content for the players that want to start playback at exactly time T, we will recommend muxers create files with another Cluster within N-1 at T-SeekPreRoll, where T is the start time of Cluster N. Then add CuePoints for all the new T-SeekPreRoll Clusters with a CueTrack of the audio stream. The CuePoints for the video stream will not change. <br />
<br />
For example, a file is a muxed MKV with the following characteristics:<br />
- 5 second interval between video keyframes<br />
- Each video keyframe begins a new Cluster<br />
- Cues will contain video keyframe CuePoints<br />
- For each video keyframe at time T there will be new Cluster at T-SeekPreRoll<br />
- Cues will contain audio CuePoints for T-SeekPreRoll Clusters<br />
- Audio and video are interleaved in monotonically increasing order<br />
<br />
Assume SeekPreRoll is 80 milliseconds, the first Cluster starts at 0 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The second Cluster starts at 4920 milliseconds with an audio Block and has a duration of 80 milliseconds. Just to be clear, the second Cluster can contain Blocks from all streams. The third Cluster starts at 5000 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The fourth Cluster starts at 9920 milliseconds with an audio Block and has a duration of 80 milliseconds.<br />
<br />
With this recommendation players that want audio and video to start playback at time T can seek to Cluster T-SeekPreRoll and start decoding the audio stream. This will work the same for both local and HTTP playback.<br />
<br />
== Open Questions ==<br />
<br />
<ul><br />
<li>Should we say muxers MAY or SHOULD NOT produce simple streams without filling in CodecPrivate?</li><br />
<br />
<ul><br />
<li>If the CodecPrivate is empty or not present and Channels is 1 or 2, players MAY treat it as a sane set of defaults, I guess. e.g. channel mapping family 0, no pre-skip or gain.<br />
</li><br />
<li>For Channels > 2 the track MUST be rejected, since there's no way to map the encoded substreams to channels.<br />
</li><br />
<li>We would also have to decide on a default value for OutputGain.<br />
</li><br />
<li>Version must be 1.<br />
</li><br />
</ul><br />
<br />
<li>How can sample-accurate end-time trimming work in Matroska?</li><br />
<ul><br />
<li> We defined a new element added to a BlockGroup, DiscardPadding(previously PostPadding), which is defined as the number of nanoseconds to discard from the Block.<br />
</ul><br />
<br />
<ul><br />
<li>Currently all software encapsulating Vorbis in Matroska is broken in this regard, and muxing a Vorbis file in Matroska causes it to get longer (i.e., produce more audio output than the original Ogg file). It would be unfortunate to repeat this disaster for Opus. This needs a new element specifying the number of samples to trim, perhaps a new BlockGroup child.<br />
</li><br />
<ul><br />
<li>This has been addressed with DiscardPadding for Opus. DiscardPadding was speced to fix Vorbis (as well as other codecs) too.<br />
</li><br />
</ul><br />
</ul><br />
<br />
<li><br />
If new elements are required, can they be defined so as to enable correct seeking in rolling intra (a.k.a intra refresh) video as well?<br />
</li><br />
<ul><br />
<li>SeekPreRoll should work for rolling intra video.</li><br />
</ul><br />
<br />
</ul><br />
<br />
== Handling Pre-skip data ==<br />
<br />
<ul><br />
<li>'''On [http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel [Matroska-dev]] we decided to implement proposal one. [http://lists.matroska.org/pipermail/matroska-devel/2013-June/004475.html[ref]]'''<br />
</li><br />
</ul><br />
<br />
<ul><br />
<li>Use Cases:</li><br />
<ul><br />
<li>UC1: Playback starts from the beginning of the stream. Source stream time starts at 0.</li><br />
<li>UC2: Playback starts from the beginning of the stream. Pre-skip data ends in middle of compressed packet.</li><br />
<li>UC3: Playback starts from the middle of the stream > SeekPreRoll time.</li><br />
<li>UC4: Playback starts from the middle of the stream < SeekPreRoll time.</li><br />
<li>UC5: Encode source stream to Opus, mux to Matroksa, then decode Opus stream, must have same number of samples as source stream.</li><br />
</ul><br />
</ul><br />
<br />
<ul><br />
<br />
<li>one: Timeshift the timestamps by pre-skip data<br />
<br />
<ul><br />
<li><br />
The Opus audio stream pre-skip data starts from time 0 and adds the pre-skip time to the normal audio time, like how Opus files are muxed into ogg files. We would add a new element to the TrackEntry element, CodecDelay, and the player would adjust the timestamps of the decoded samples by subtracting CodecDelay. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>The timestamp of the Block does not match the timestamp of the playback position.</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>two: Add pre-skip data to CodecPrivate.</li><br />
<ul><br />
<li><br />
On every discontinuity the decoder would need to decode and throw away the pre-skip data.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>UC2 will throw away valid data and the AV sync will be off.</li><br />
<li>UC3 will redundantly decode the pre-skip data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>three: Add TimeToDiscard to Block.</li><br />
<ul><br />
<li><br />
Add an element to the Block element, TimeToDiscard in nanoseconds. A value of -1 would not render the whole Block, which would have the same effect as setting the invisible bit. How would this affect the Block timestamp? Maybe the new element should be SamplesToDiscard or DataToDiscard?<br />
</li><br />
<br />
<li>Cons:</li><br />
<br />
</ul><br />
<br />
<li>four: Blocks that contain pre-skip data will set invisible flag.</li><br />
<ul><br />
<li><br />
Blocks that contain pre-skip data have timestamps from the beginning of the stream. Blocks that only contain normal data have timestamps from the playback position.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
<li>UC2 will throw away valid data and the AV sync will be off. Other use cases should be fine.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>five: Force pre-skip packets to be prepended to the first normal packet in the first Block.</li><br />
<ul><br />
<li><br />
The first Block's timestmap will be set to the start time of the source playback position. We would add a new element to the TrackEntry element, CodecDelay. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>six: Create a new codec, OPUS_MKV.</li><br />
<ul><br />
<li><br />
Basically the codec will wrap Opus packets with data telling the decoder what type of Opus packet it contains. Essentially we would be creating a new codec to handle pre-skip data within the decoder.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>There will be two types of Opus data streams!</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>seven: Negative timestamps.</li><br />
<ul><br />
<li><br />
The SimpleBlock timestamp is signed 16 bits, so the format can signal about half of the pre-skip if playback timestamps are to start at zero.<br />
</li><br />
<li> One could set an incorrect timestamp on the skipped blocks, and rely on the decoder to drop them based on the OpusHead preskip value. As long as the initial blocks are timestamped <= start of output this shouldn't affect seeking.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Moritz suggests this won't work because the resolution of the timestamps is controlled by the muxer, so the SimpleBlock timestamp offset isn't sample accurate anyway.[[http://lists.matroska.org/pipermail/matroska-devel/2012-September/004254.html ref]]</li><br />
</ul><br />
<br />
</ul><br />
<li>Proposal 8</li><br />
<ul><br />
<li><br />
The Ogg format uses granule positions which are converted to presentation <br />
timecodes using codec specific information on a per logical stream basis.<br />
</li><br />
<li><br />
The Matroska format uses absolute timecodes with an arbitrary per <br />
segement accuracy for all tracks in the segment.<br />
</li><br />
<li><br />
It is the belief of this tikiman that using a timecode offset of any kind in MKV is unholy.<br />
</li><br />
<li><br />
The preskip is communicated to the media software via the Opus header <br />
in the codec private data. At the begining of the track, the track <br />
timecode is not increased until prekip samples are in track frames.<br />
</li><br />
<li><br />
From then on audio is muxed as normal, however the audio should be<br />
muxed >= 3840 samples behind video frames.<br />
<br />
* i.e. Cluster Timecode: 5.000 seconds<br />
* Video Track Key Frame 5.000 seconds<br />
* Opus Track Frame 4.920 seconds<br />
</li><br />
</ul><br />
</ul></div>J^https://wiki.xiph.org/index.php?title=MatroskaOpus&diff=14196MatroskaOpus2013-06-18T13:28:43Z<p>J^: /* Handling Pre-skip data */ PreSkip -> CodecDelay</p>
<hr />
<div>== '''DRAFT''' ==<br />
<br />
This is an encapsulation spec for the [[Opus]] codec in [[http://matroska.org/ Matroska]]. There are a number of outstanding functional issues with muxing Opus in Matroska, and until those are resolved, use of this spec is NOT RECOMMENDED.<br />
<br />
- CodecID is A_OPUS<br />
- SampleFrequecy is 48000<br />
- Channels is number of output PCM channels<br />
- SeekPreRoll is set to 80000000<br />
- CodecPrivate starts with the 'OpusHead' packet, identical to the Ogg mapping, followed by the pre-skip data.<br />
<br />
The 'OpusHead' format is defined by the [[http://tools.ietf.org/html/draft-terriberry-oggopus Ogg Opus]] mapping. In particular it includes pre-skip, gain, and the channel mapping table required for correct surround output.<br />
<br />
The second 'OpusTags' header packet from Ogg Opus is not used in the Matroska encapsulation. Matroska has its own system for tag metadata, and this avoids duplicating it and the need for sub-framing to index multiple packets within the CodecPrivate element.<br />
<br />
SeekPreRoll [56][BB] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, after a seek until the decoded data is valid to render.<br />
<br />
CodecDelay [56][AA] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation timestamp. (This will fix Vorbis encoding as well.)<br />
<br />
DiscardPadding [75][A2] is a new signed integer element added to the BlockGroup element. DiscardPadding is the duration in nanoseconds of the silent data added to the Block (padding at the end of the block). The duration of DiscardPadding is not calculated in the duration of the Track and should be discarded during playback. (This will fix Vorbis encoding as well.)<br />
<br />
<br />
(TODO) Define layout of CodecPrivate.<br />
<br />
== Muxing Recommendations ==<br />
<br />
In order to prevent extraneous parsing of muxed content for the players that want to start playback at exactly time T, we will recommend muxers create files with another Cluster within N-1 at T-SeekPreRoll, where T is the start time of Cluster N. Then add CuePoints for all the new T-SeekPreRoll Clusters with a CueTrack of the audio stream. The CuePoints for the video stream will not change. <br />
<br />
For example, a file is a muxed MKV with the following characteristics:<br />
- 5 second interval between video keyframes<br />
- Each video keyframe begins a new Cluster<br />
- Cues will contain video keyframe CuePoints<br />
- For each video keyframe at time T there will be new Cluster at T-SeekPreRoll<br />
- Cues will contain audio CuePoints for T-SeekPreRoll Clusters<br />
- Audio and video are interleaved in monotonically increasing order<br />
<br />
Assume SeekPreRoll is 80 milliseconds, the first Cluster starts at 0 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The second Cluster starts at 4920 milliseconds with an audio Block and has a duration of 80 milliseconds. Just to be clear, the second Cluster can contain Blocks from all streams. The third Cluster starts at 5000 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The fourth Cluster starts at 9920 milliseconds with an audio Block and has a duration of 80 milliseconds.<br />
<br />
With this recommendation players that want audio and video to start playback at time T can seek to Cluster T-SeekPreRoll and start decoding the audio stream. This will work the same for both local and HTTP playback.<br />
<br />
== Open Questions ==<br />
<br />
<ul><br />
<li>Should we say muxers MAY or SHOULD NOT produce simple streams without filling in CodecPrivate?</li><br />
<br />
<ul><br />
<li>If the CodecPrivate is empty or not present and Channels is 1 or 2, players MAY treat it as a sane set of defaults, I guess. e.g. channel mapping family 0, no pre-skip or gain.<br />
</li><br />
<li>For Channels > 2 the track MUST be rejected, since there's no way to map the encoded substreams to channels.<br />
</li><br />
<li>We would also have to decide on a default value for OutputGain.<br />
</li><br />
<li>Version must be 1.<br />
</li><br />
</ul><br />
<br />
<li>How can sample-accurate end-time trimming work in Matroska?</li><br />
<ul><br />
<li> We defined a new element added to a BlockGroup, DiscardPadding(previously PostPadding), which is defined as the number of nanoseconds to discard from the Block.<br />
</ul><br />
<br />
<ul><br />
<li>Currently all software encapsulating Vorbis in Matroska is broken in this regard, and muxing a Vorbis file in Matroska causes it to get longer (i.e., produce more audio output than the original Ogg file). It would be unfortunate to repeat this disaster for Opus. This needs a new element specifying the number of samples to trim, perhaps a new BlockGroup child.<br />
</li><br />
<ul><br />
<li>This has been addressed with DiscardPadding for Opus. DiscardPadding was speced to fix Vorbis (as well as other codecs) too.<br />
</li><br />
</ul><br />
</ul><br />
<br />
<li><br />
If new elements are required, can they be defined so as to enable correct seeking in rolling intra (a.k.a intra refresh) video as well?<br />
</li><br />
<ul><br />
<li>SeekPreRoll should work for rolling intra video.</li><br />
</ul><br />
<br />
</ul><br />
<br />
== Handling Pre-skip data ==<br />
<br />
<ul><br />
<li>'''On [http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel [Matroska-dev]] we decided to implement proposal one. [http://lists.matroska.org/pipermail/matroska-devel/2013-June/004475.html[ref]]'''<br />
</li><br />
</ul><br />
<br />
<ul><br />
<li>Use Cases:</li><br />
<ul><br />
<li>UC1: Playback starts from the beginning of the stream. Source stream time starts at 0.</li><br />
<li>UC2: Playback starts from the beginning of the stream. Pre-skip data ends in middle of compressed packet.</li><br />
<li>UC3: Playback starts from the middle of the stream > SeekPreRoll time.</li><br />
<li>UC4: Playback starts from the middle of the stream < SeekPreRoll time.</li><br />
<li>UC5: Encode source stream to Opus, mux to Matroksa, then decode Opus stream, must have same number of samples as source stream.</li><br />
</ul><br />
</ul><br />
<br />
<ul><br />
<br />
<li>one: Timeshift the timestamps by pre-skip data<br />
<br />
<ul><br />
<li><br />
The Opus audio stream pre-skip data starts from time 0 and adds the pre-skip time to the normal audio time, like how Opus files are muxed into ogg files. We would add a new element to the TrackEntry element, CodecDelay, and the player would adjust the timestamps of the decoded samples by subtracting CodecDelay. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>The timestamp of the Block does not match the timestamp of the playback position.</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>two: Add pre-skip data to CodecPrivate.</li><br />
<ul><br />
<li><br />
On every discontinuity the decoder would need to decode and throw away the pre-skip data.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>UC2 will throw away valid data and the AV sync will be off.</li><br />
<li>UC3 will redundantly decode the pre-skip data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>three: Add TimeToDiscard to Block.</li><br />
<ul><br />
<li><br />
Add an element to the Block element, TimeToDiscard in nanoseconds. A value of -1 would not render the whole Block, which would have the same effect as setting the invisible bit. How would this affect the Block timestamp? Maybe the new element should be SamplesToDiscard or DataToDiscard?<br />
</li><br />
<br />
<li>Cons:</li><br />
<br />
</ul><br />
<br />
<li>four: Blocks that contain pre-skip data will set invisible flag.</li><br />
<ul><br />
<li><br />
Blocks that contain pre-skip data have timestamps from the beginning of the stream. Blocks that only contain normal data have timestamps from the playback position.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
<li>UC2 will throw away valid data and the AV sync will be off. Other use cases should be fine.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>five: Force pre-skip packets to be prepended to the first normal packet in the first Block.</li><br />
<ul><br />
<li><br />
The first Block's timestmap will be set to the start time of the source playback position. We would add a new element to the TrackEntry element, CodecDelay. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>six: Create a new codec, OPUS_MKV.</li><br />
<ul><br />
<li><br />
Basically the codec will wrap Opus packets with data telling the decoder what type of Opus packet it contains. Essentially we would be creating a new codec to handle pre-skip data within the decoder.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>There will be two types of Opus data streams!</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>seven: Negative timestamps.</li><br />
<ul><br />
<li><br />
The SimpleBlock timestamp is signed 16 bits, so the format can signal about half of the pre-skip if playback timestamps are to start at zero.<br />
</li><br />
<li> One could set an incorrect timestamp on the skipped blocks, and rely on the decoder to drop them based on the OpusHead preskip value. As long as the initial blocks are timestamped <= start of output this shouldn't affect seeking.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Moritz suggests this won't work because the resolution of the timestamps is controlled by the muxer, so the SimpleBlock timestamp offset isn't sample accurate anyway.[[http://lists.matroska.org/pipermail/matroska-devel/2012-September/004254.html ref]]</li><br />
</ul><br />
<br />
</ul><br />
<br />
</ul><br />
<br />
== Proposal 8 == <br />
<br />
The Ogg format uses granule positions which are converted to presentation <br />
timecodes using codec specific information on a per logical stream basis.<br />
<br />
The Matroska format uses absolute timecodes with an arbitrary per <br />
segement accuracy for all tracks in the segment.<br />
<br />
It is the belief of this tikiman that using a timecode offset of any kind in MKV is unholy.<br />
<br />
The preskip is communicated to the media software via the Opus header <br />
in the codec private data. At the begining of the track, the track <br />
timecode is not increased until prekip samples are in track frames.<br />
<br />
From then on audio is muxed as normal, however the audio should be<br />
muxed >= 3840 samples behind video frames.<br />
<br />
* i.e. Cluster Timecode: 5.000 seconds<br />
* Video Track Key Frame 5.000 seconds<br />
* Opus Track Frame 4.920 seconds</div>J^https://wiki.xiph.org/index.php?title=MatroskaOpus&diff=14195MatroskaOpus2013-06-18T13:27:16Z<p>J^: /* Open Questions */ more PostPadding->DiscardPadding</p>
<hr />
<div>== '''DRAFT''' ==<br />
<br />
This is an encapsulation spec for the [[Opus]] codec in [[http://matroska.org/ Matroska]]. There are a number of outstanding functional issues with muxing Opus in Matroska, and until those are resolved, use of this spec is NOT RECOMMENDED.<br />
<br />
- CodecID is A_OPUS<br />
- SampleFrequecy is 48000<br />
- Channels is number of output PCM channels<br />
- SeekPreRoll is set to 80000000<br />
- CodecPrivate starts with the 'OpusHead' packet, identical to the Ogg mapping, followed by the pre-skip data.<br />
<br />
The 'OpusHead' format is defined by the [[http://tools.ietf.org/html/draft-terriberry-oggopus Ogg Opus]] mapping. In particular it includes pre-skip, gain, and the channel mapping table required for correct surround output.<br />
<br />
The second 'OpusTags' header packet from Ogg Opus is not used in the Matroska encapsulation. Matroska has its own system for tag metadata, and this avoids duplicating it and the need for sub-framing to index multiple packets within the CodecPrivate element.<br />
<br />
SeekPreRoll [56][BB] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, after a seek until the decoded data is valid to render.<br />
<br />
CodecDelay [56][AA] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation timestamp. (This will fix Vorbis encoding as well.)<br />
<br />
DiscardPadding [75][A2] is a new signed integer element added to the BlockGroup element. DiscardPadding is the duration in nanoseconds of the silent data added to the Block (padding at the end of the block). The duration of DiscardPadding is not calculated in the duration of the Track and should be discarded during playback. (This will fix Vorbis encoding as well.)<br />
<br />
<br />
(TODO) Define layout of CodecPrivate.<br />
<br />
== Muxing Recommendations ==<br />
<br />
In order to prevent extraneous parsing of muxed content for the players that want to start playback at exactly time T, we will recommend muxers create files with another Cluster within N-1 at T-SeekPreRoll, where T is the start time of Cluster N. Then add CuePoints for all the new T-SeekPreRoll Clusters with a CueTrack of the audio stream. The CuePoints for the video stream will not change. <br />
<br />
For example, a file is a muxed MKV with the following characteristics:<br />
- 5 second interval between video keyframes<br />
- Each video keyframe begins a new Cluster<br />
- Cues will contain video keyframe CuePoints<br />
- For each video keyframe at time T there will be new Cluster at T-SeekPreRoll<br />
- Cues will contain audio CuePoints for T-SeekPreRoll Clusters<br />
- Audio and video are interleaved in monotonically increasing order<br />
<br />
Assume SeekPreRoll is 80 milliseconds, the first Cluster starts at 0 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The second Cluster starts at 4920 milliseconds with an audio Block and has a duration of 80 milliseconds. Just to be clear, the second Cluster can contain Blocks from all streams. The third Cluster starts at 5000 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The fourth Cluster starts at 9920 milliseconds with an audio Block and has a duration of 80 milliseconds.<br />
<br />
With this recommendation players that want audio and video to start playback at time T can seek to Cluster T-SeekPreRoll and start decoding the audio stream. This will work the same for both local and HTTP playback.<br />
<br />
== Open Questions ==<br />
<br />
<ul><br />
<li>Should we say muxers MAY or SHOULD NOT produce simple streams without filling in CodecPrivate?</li><br />
<br />
<ul><br />
<li>If the CodecPrivate is empty or not present and Channels is 1 or 2, players MAY treat it as a sane set of defaults, I guess. e.g. channel mapping family 0, no pre-skip or gain.<br />
</li><br />
<li>For Channels > 2 the track MUST be rejected, since there's no way to map the encoded substreams to channels.<br />
</li><br />
<li>We would also have to decide on a default value for OutputGain.<br />
</li><br />
<li>Version must be 1.<br />
</li><br />
</ul><br />
<br />
<li>How can sample-accurate end-time trimming work in Matroska?</li><br />
<ul><br />
<li> We defined a new element added to a BlockGroup, DiscardPadding(previously PostPadding), which is defined as the number of nanoseconds to discard from the Block.<br />
</ul><br />
<br />
<ul><br />
<li>Currently all software encapsulating Vorbis in Matroska is broken in this regard, and muxing a Vorbis file in Matroska causes it to get longer (i.e., produce more audio output than the original Ogg file). It would be unfortunate to repeat this disaster for Opus. This needs a new element specifying the number of samples to trim, perhaps a new BlockGroup child.<br />
</li><br />
<ul><br />
<li>This has been addressed with DiscardPadding for Opus. DiscardPadding was speced to fix Vorbis (as well as other codecs) too.<br />
</li><br />
</ul><br />
</ul><br />
<br />
<li><br />
If new elements are required, can they be defined so as to enable correct seeking in rolling intra (a.k.a intra refresh) video as well?<br />
</li><br />
<ul><br />
<li>SeekPreRoll should work for rolling intra video.</li><br />
</ul><br />
<br />
</ul><br />
<br />
== Handling Pre-skip data ==<br />
<br />
<ul><br />
<li>'''On [http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel [Matroska-dev]] we decided to implement proposal one. [http://lists.matroska.org/pipermail/matroska-devel/2013-June/004475.html[ref]]'''<br />
</li><br />
</ul><br />
<br />
<ul><br />
<li>Use Cases:</li><br />
<ul><br />
<li>UC1: Playback starts from the beginning of the stream. Source stream time starts at 0.</li><br />
<li>UC2: Playback starts from the beginning of the stream. Pre-skip data ends in middle of compressed packet.</li><br />
<li>UC3: Playback starts from the middle of the stream > SeekPreRoll time.</li><br />
<li>UC4: Playback starts from the middle of the stream < SeekPreRoll time.</li><br />
<li>UC5: Encode source stream to Opus, mux to Matroksa, then decode Opus stream, must have same number of samples as source stream.</li><br />
</ul><br />
</ul><br />
<br />
<ul><br />
<br />
<li>one: Timeshift the timestamps by pre-skip data<br />
<br />
<ul><br />
<li><br />
The Opus audio stream pre-skip data starts from time 0 and adds the pre-skip time to the normal audio time, like how Opus files are muxed into ogg files. We would add a new element to the TrackEntry element, PreSkip, and the player would adjust the timestamps of the decoded samples by subtracting PreSkip. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>The timestamp of the Block does not match the timestamp of the playback position.</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>two: Add pre-skip data to CodecPrivate.</li><br />
<ul><br />
<li><br />
On every discontinuity the decoder would need to decode and throw away the pre-skip data.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>UC2 will throw away valid data and the AV sync will be off.</li><br />
<li>UC3 will redundantly decode the pre-skip data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>three: Add TimeToDiscard to Block.</li><br />
<ul><br />
<li><br />
Add an element to the Block element, TimeToDiscard in nanoseconds. A value of -1 would not render the whole Block, which would have the same effect as setting the invisible bit. How would this affect the Block timestamp? Maybe the new element should be SamplesToDiscard or DataToDiscard?<br />
</li><br />
<br />
<li>Cons:</li><br />
<br />
</ul><br />
<br />
<li>four: Blocks that contain pre-skip data will set invisible flag.</li><br />
<ul><br />
<li><br />
Blocks that contain pre-skip data have timestamps from the beginning of the stream. Blocks that only contain normal data have timestamps from the playback position.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
<li>UC2 will throw away valid data and the AV sync will be off. Other use cases should be fine.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>five: Force pre-skip packets to be prepended to the first normal packet in the first Block.</li><br />
<ul><br />
<li><br />
The first Block's timestmap will be set to the start time of the source playback position. We would add a new element to the TrackEntry element, PreSkip. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>six: Create a new codec, OPUS_MKV.</li><br />
<ul><br />
<li><br />
Basically the codec will wrap Opus packets with data telling the decoder what type of Opus packet it contains. Essentially we would be creating a new codec to handle pre-skip data within the decoder.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>There will be two types of Opus data streams!</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>seven: Negative timestamps.</li><br />
<ul><br />
<li><br />
The SimpleBlock timestamp is signed 16 bits, so the format can signal about half of the pre-skip if playback timestamps are to start at zero.<br />
</li><br />
<li> One could set an incorrect timestamp on the skipped blocks, and rely on the decoder to drop them based on the OpusHead preskip value. As long as the initial blocks are timestamped <= start of output this shouldn't affect seeking.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Moritz suggests this won't work because the resolution of the timestamps is controlled by the muxer, so the SimpleBlock timestamp offset isn't sample accurate anyway.[[http://lists.matroska.org/pipermail/matroska-devel/2012-September/004254.html ref]]</li><br />
</ul><br />
<br />
</ul><br />
<br />
</ul><br />
<br />
== Proposal 8 == <br />
<br />
The Ogg format uses granule positions which are converted to presentation <br />
timecodes using codec specific information on a per logical stream basis.<br />
<br />
The Matroska format uses absolute timecodes with an arbitrary per <br />
segement accuracy for all tracks in the segment.<br />
<br />
It is the belief of this tikiman that using a timecode offset of any kind in MKV is unholy.<br />
<br />
The preskip is communicated to the media software via the Opus header <br />
in the codec private data. At the begining of the track, the track <br />
timecode is not increased until prekip samples are in track frames.<br />
<br />
From then on audio is muxed as normal, however the audio should be<br />
muxed >= 3840 samples behind video frames.<br />
<br />
* i.e. Cluster Timecode: 5.000 seconds<br />
* Video Track Key Frame 5.000 seconds<br />
* Opus Track Frame 4.920 seconds</div>J^https://wiki.xiph.org/index.php?title=MatroskaOpus&diff=14194MatroskaOpus2013-06-18T13:25:25Z<p>J^: /* DRAFT */ rename elements to be in line with latest version of the matroska spec</p>
<hr />
<div>== '''DRAFT''' ==<br />
<br />
This is an encapsulation spec for the [[Opus]] codec in [[http://matroska.org/ Matroska]]. There are a number of outstanding functional issues with muxing Opus in Matroska, and until those are resolved, use of this spec is NOT RECOMMENDED.<br />
<br />
- CodecID is A_OPUS<br />
- SampleFrequecy is 48000<br />
- Channels is number of output PCM channels<br />
- SeekPreRoll is set to 80000000<br />
- CodecPrivate starts with the 'OpusHead' packet, identical to the Ogg mapping, followed by the pre-skip data.<br />
<br />
The 'OpusHead' format is defined by the [[http://tools.ietf.org/html/draft-terriberry-oggopus Ogg Opus]] mapping. In particular it includes pre-skip, gain, and the channel mapping table required for correct surround output.<br />
<br />
The second 'OpusTags' header packet from Ogg Opus is not used in the Matroska encapsulation. Matroska has its own system for tag metadata, and this avoids duplicating it and the need for sub-framing to index multiple packets within the CodecPrivate element.<br />
<br />
SeekPreRoll [56][BB] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, after a seek until the decoded data is valid to render.<br />
<br />
CodecDelay [56][AA] is a new unsigned integer element added to the TrackEntry element. The value is the number of nanoseconds that must be discarded, for that stream, from the start of that stream. The value is also the number of nanoseconds that all encoded timestamps for that stream must be shifted to get the presentation timestamp. (This will fix Vorbis encoding as well.)<br />
<br />
DiscardPadding [75][A2] is a new signed integer element added to the BlockGroup element. DiscardPadding is the duration in nanoseconds of the silent data added to the Block (padding at the end of the block). The duration of DiscardPadding is not calculated in the duration of the Track and should be discarded during playback. (This will fix Vorbis encoding as well.)<br />
<br />
<br />
(TODO) Define layout of CodecPrivate.<br />
<br />
== Muxing Recommendations ==<br />
<br />
In order to prevent extraneous parsing of muxed content for the players that want to start playback at exactly time T, we will recommend muxers create files with another Cluster within N-1 at T-SeekPreRoll, where T is the start time of Cluster N. Then add CuePoints for all the new T-SeekPreRoll Clusters with a CueTrack of the audio stream. The CuePoints for the video stream will not change. <br />
<br />
For example, a file is a muxed MKV with the following characteristics:<br />
- 5 second interval between video keyframes<br />
- Each video keyframe begins a new Cluster<br />
- Cues will contain video keyframe CuePoints<br />
- For each video keyframe at time T there will be new Cluster at T-SeekPreRoll<br />
- Cues will contain audio CuePoints for T-SeekPreRoll Clusters<br />
- Audio and video are interleaved in monotonically increasing order<br />
<br />
Assume SeekPreRoll is 80 milliseconds, the first Cluster starts at 0 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The second Cluster starts at 4920 milliseconds with an audio Block and has a duration of 80 milliseconds. Just to be clear, the second Cluster can contain Blocks from all streams. The third Cluster starts at 5000 milliseconds with a video keyframe Block and has a duration of 4920 milliseconds. The fourth Cluster starts at 9920 milliseconds with an audio Block and has a duration of 80 milliseconds.<br />
<br />
With this recommendation players that want audio and video to start playback at time T can seek to Cluster T-SeekPreRoll and start decoding the audio stream. This will work the same for both local and HTTP playback.<br />
<br />
== Open Questions ==<br />
<br />
<ul><br />
<li>Should we say muxers MAY or SHOULD NOT produce simple streams without filling in CodecPrivate?</li><br />
<br />
<ul><br />
<li>If the CodecPrivate is empty or not present and Channels is 1 or 2, players MAY treat it as a sane set of defaults, I guess. e.g. channel mapping family 0, no pre-skip or gain.<br />
</li><br />
<li>For Channels > 2 the track MUST be rejected, since there's no way to map the encoded substreams to channels.<br />
</li><br />
<li>We would also have to decide on a default value for OutputGain.<br />
</li><br />
<li>Version must be 1.<br />
</li><br />
</ul><br />
<br />
<li>How can sample-accurate end-time trimming work in Matroska?</li><br />
<ul><br />
<li> We defined a new element added to a BlockGroup, PostPadding, which is defined as the number of nanoseconds to discard from the Block.<br />
</ul><br />
<br />
<ul><br />
<li>Currently all software encapsulating Vorbis in Matroska is broken in this regard, and muxing a Vorbis file in Matroska causes it to get longer (i.e., produce more audio output than the original Ogg file). It would be unfortunate to repeat this disaster for Opus. This needs a new element specifying the number of samples to trim, perhaps a new BlockGroup child.<br />
</li><br />
<ul><br />
<li>This has been addressed with PostPadding for Opus. PostPadding was speced to fix Vorbis (as well as other codecs) too.<br />
</li><br />
</ul><br />
</ul><br />
<br />
<li><br />
If new elements are required, can they be defined so as to enable correct seeking in rolling intra (a.k.a intra refresh) video as well?<br />
</li><br />
<ul><br />
<li>SeekPreRoll should work for rolling intra video.</li><br />
</ul><br />
<br />
</ul><br />
<br />
== Handling Pre-skip data ==<br />
<br />
<ul><br />
<li>'''On [http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel [Matroska-dev]] we decided to implement proposal one. [http://lists.matroska.org/pipermail/matroska-devel/2013-June/004475.html[ref]]'''<br />
</li><br />
</ul><br />
<br />
<ul><br />
<li>Use Cases:</li><br />
<ul><br />
<li>UC1: Playback starts from the beginning of the stream. Source stream time starts at 0.</li><br />
<li>UC2: Playback starts from the beginning of the stream. Pre-skip data ends in middle of compressed packet.</li><br />
<li>UC3: Playback starts from the middle of the stream > SeekPreRoll time.</li><br />
<li>UC4: Playback starts from the middle of the stream < SeekPreRoll time.</li><br />
<li>UC5: Encode source stream to Opus, mux to Matroksa, then decode Opus stream, must have same number of samples as source stream.</li><br />
</ul><br />
</ul><br />
<br />
<ul><br />
<br />
<li>one: Timeshift the timestamps by pre-skip data<br />
<br />
<ul><br />
<li><br />
The Opus audio stream pre-skip data starts from time 0 and adds the pre-skip time to the normal audio time, like how Opus files are muxed into ogg files. We would add a new element to the TrackEntry element, PreSkip, and the player would adjust the timestamps of the decoded samples by subtracting PreSkip. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>The timestamp of the Block does not match the timestamp of the playback position.</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>two: Add pre-skip data to CodecPrivate.</li><br />
<ul><br />
<li><br />
On every discontinuity the decoder would need to decode and throw away the pre-skip data.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>UC2 will throw away valid data and the AV sync will be off.</li><br />
<li>UC3 will redundantly decode the pre-skip data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>three: Add TimeToDiscard to Block.</li><br />
<ul><br />
<li><br />
Add an element to the Block element, TimeToDiscard in nanoseconds. A value of -1 would not render the whole Block, which would have the same effect as setting the invisible bit. How would this affect the Block timestamp? Maybe the new element should be SamplesToDiscard or DataToDiscard?<br />
</li><br />
<br />
<li>Cons:</li><br />
<br />
</ul><br />
<br />
<li>four: Blocks that contain pre-skip data will set invisible flag.</li><br />
<ul><br />
<li><br />
Blocks that contain pre-skip data have timestamps from the beginning of the stream. Blocks that only contain normal data have timestamps from the playback position.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
<li>UC2 will throw away valid data and the AV sync will be off. Other use cases should be fine.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>five: Force pre-skip packets to be prepended to the first normal packet in the first Block.</li><br />
<ul><br />
<li><br />
The first Block's timestmap will be set to the start time of the source playback position. We would add a new element to the TrackEntry element, PreSkip. All use cases should be covered.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
<li>Forces the player to handle the pre-skip samples. I.e. not the decoder.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>six: Create a new codec, OPUS_MKV.</li><br />
<ul><br />
<li><br />
Basically the codec will wrap Opus packets with data telling the decoder what type of Opus packet it contains. Essentially we would be creating a new codec to handle pre-skip data within the decoder.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>There will be two types of Opus data streams!</li><br />
<li>Does not generalize known "decode, but not render" data.</li><br />
</ul><br />
<br />
</ul><br />
<br />
<li>seven: Negative timestamps.</li><br />
<ul><br />
<li><br />
The SimpleBlock timestamp is signed 16 bits, so the format can signal about half of the pre-skip if playback timestamps are to start at zero.<br />
</li><br />
<li> One could set an incorrect timestamp on the skipped blocks, and rely on the decoder to drop them based on the OpusHead preskip value. As long as the initial blocks are timestamped <= start of output this shouldn't affect seeking.<br />
</li><br />
<br />
<li>Cons:</li><br />
<ul><br />
<li>Moritz suggests this won't work because the resolution of the timestamps is controlled by the muxer, so the SimpleBlock timestamp offset isn't sample accurate anyway.[[http://lists.matroska.org/pipermail/matroska-devel/2012-September/004254.html ref]]</li><br />
</ul><br />
<br />
</ul><br />
<br />
</ul><br />
<br />
== Proposal 8 == <br />
<br />
The Ogg format uses granule positions which are converted to presentation <br />
timecodes using codec specific information on a per logical stream basis.<br />
<br />
The Matroska format uses absolute timecodes with an arbitrary per <br />
segement accuracy for all tracks in the segment.<br />
<br />
It is the belief of this tikiman that using a timecode offset of any kind in MKV is unholy.<br />
<br />
The preskip is communicated to the media software via the Opus header <br />
in the codec private data. At the begining of the track, the track <br />
timecode is not increased until prekip samples are in track frames.<br />
<br />
From then on audio is muxed as normal, however the audio should be<br />
muxed >= 3840 samples behind video frames.<br />
<br />
* i.e. Cluster Timecode: 5.000 seconds<br />
* Video Track Key Frame 5.000 seconds<br />
* Opus Track Frame 4.920 seconds</div>J^https://wiki.xiph.org/index.php?title=OggKate&diff=13496OggKate2012-06-15T11:24:49Z<p>J^: Reverted edits by WikiCleaner (talk) to last revision by Ogg.k.ogg.k</p>
<hr />
<div>== Disclaimer ==<br />
This is not a Xiph codec, though it may be embedded in Ogg alonside other Xiph<br />
codecs, such as Vorbis and Theora. As such, please do not assume that Xiph has<br />
anything to do with this, much less responsibility.<br />
<br />
== What is Kate? ==<br />
<br />
Kate is an overlay codec, originally designed for karaoke and text, that can be<br />
multiplixed in Ogg. Text and images can be carried by a Kate stream, and animated.<br />
Most of the time, this would be multiplexed with audio/video to carry subtitles,<br />
song lyrics (with or without karaoke data), etc, but doesn't have to be.<br />
<br />
Series of curves (splines, segments, etc) may be attached to various properties<br />
(text position, font size, etc) to create animated overlays. This allows scrolling<br />
or fading text to be defined. This can even be used to draw arbitrary shapes, so<br />
hand drawing can also be represented by a Kate stream.<br />
<br />
Example uses of Kate streams are movie subtitles for Theora videos, either text based,<br />
as may be created by [http://www.v2v.cc/~j/ffmpeg2theora ffmpeg2theora], or image<br />
based, such as created by [http://thoggen.net Thoggen] (patching needed), and lyrics,<br />
as created by oggenc, from vorbis-tools.<br />
<br />
== Why a new codec? ==<br />
<br />
As I was adding support for Theora, Speex and FLAC to some software of mine, I found myself<br />
wanting to have song lyrics accompanying Vorbis audio. Since Vorbis comments are limited to<br />
the headers, one can't add them in the stream as they are sung, so another multiplexed stream<br />
would be needed to carry them.<br />
<br />
The three possible bases usable for such a codec I found were Writ, CMML, and OGM/SRT.<br />
<br />
*[[OggWrit|Writ]] is an unmaintained start at an implementation of a very basic design, though I did find an encoder/decoder in py-ogg2 later on - I'd been quicker to write Kate from scratch anyway.<br />
*[[CMML]] is more geared towards encapsulating metadata about an accompanying stream, rather than being a data stream itself, and seemed complex for a simple use, though I have now revised my view on this - besides, it seems designed for Annodex (which I haven't had a look at), though it does seems relatively generic for use outwith Annodex - though it is being "repurposed" as timed text now, bringing it closer to what I'm doing<br />
*OGM/SRT, which I only found when I added Kate support to MPlayer, is shoehorning various data formats into an Ogg stream, and just dumps the SRT subtitle format as is, AFAICS (though I haven't looked at this one in detail, since I'd already had a working Kate implementation by that time)<br />
<br />
I then decided to roll my own, not least because it's a fun thing to do.<br />
<br />
I found other formats, such as USF (designed for inclusion in Matroska) and various subtitle formats,<br />
but none were designed for embedding inside an Ogg container.<br />
<br />
== Overview of the Kate bitstream format ==<br />
<br />
I've taken much inspiration from Vorbis and Theora here.<br />
Headers and packets (as well as the API design) follow the design of these two codecs.<br />
<br />
A rough overview (see [[#Format specification|Format specification]] for more details) is:<br />
<br />
Headers packets:<br />
*ID header [BOS]: magic, version, granule fraction, encoding, language, etc<br />
*Comment header: Vorbis comments, as per Vorbis/Theora streams<br />
*Style definitions header: a list of predefined styles to be referred to by data packets<br />
*Region definitions header: a list of predefined regions to be referred to by data packets<br />
*Curves definitions header: a list of predefined curves to be referred to by data packets<br />
*Motion definitions header: a list of predefined motions to be referred to by data packets<br />
*Palette definitions header: a list of predefined palettes to be referred to by data packets<br />
*Bitmap definitions header: a list of predefined bitmaps to be referred to by data packets<br />
*Font mapping definitions header: a list of predefined font mappings to be referred to by data packets<br />
<br />
Other header packets are ignored, and left for future expansion.<br />
<br />
Data packets:<br />
*text data: text/image and optional motions, accompanied by optional overrides for style, region, language, etc<br />
*keepalive: can be emitted at any time to help a demuxer know where we're at, but those packets are optional<br />
*repeats: a verbatim repeat of a text packet's payload, in order to bound any backward seeking needed when starting to play a stream partway through. These are also optional.<br />
*end data [EOS]: marks the end of the stream, it doesn't have any useful payload<br />
<br />
Other data packets are ignored, and left for future expansion.<br />
<br />
The intent of the "keepalive" packet is to be sent at regular<br />
intervals when no other packet has been emitted for a while. This would be to help seeking code<br />
find a kate page more easily.<br />
<br />
Things of note:<br />
*Kate is a discontinuous codec, as defined in [http://www.xiph.org/ogg/doc/ogg-multiplex.html ogg-multiplex.html] in the Ogg documentation, which means it's timed by start granule, not end granule (as Theora and Vorbis).<br />
* All data packets are on their own page, for two reasons:<br />
**Ogg keeps track of granules at the page level, not the packet level<br />
**if no text event happens for a while after a particular text event, we don't want to delay it so a larger page can be issued<br />
<br />
See also [[#Seeking and memory|Problems to solve: Seeking and memory]].<br />
<br />
*The granule encoding is not a direct time/granule correspondance, see the granule encoding section.<br />
*The EOS packet should have a granule pos higher or equal to the end time of all events.<br />
*User code doesn't have to know the number of headers to expect, this is moved inside the library code (as opposed to Vorbis and Theora).<br />
*The format contains hooks so that additional information may be added in future revisions while keeping backward compatibility (though old decoders will correctly parse, but ignore the new information).<br />
<br />
== Format specification ==<br />
<br />
The Kate bitstream format consists of a number of sequential packets.<br />
Packets can be either header packets or data packets. All header packets<br />
must appear before any data packet.<br />
<br />
Header packets must appear in order. Decoding of a data packet is not<br />
possible until all header packets have been decoded.<br />
<br />
Each Kate packet starts with a one byte type. A type with the MSB set<br />
(eg, between 0x80 and 0xff) indicates a header packet, while a type with<br />
the MSB cleared (eg, between 0x00 and 0x7f) indicates a data packet.<br />
All header packets then have the Kate magic, from byte offset 1 to byte<br />
offset 7 ("kate\0\0\0"). Note that this applies only to header packets:<br />
data packets do not contain the Kate signature.<br />
<br />
Since the ID header must appear first, a Kate stream can be recognized<br />
by comparing the first eight bytes of the first packet with the signature<br />
string "\200kate\0\0\0".<br />
<br />
<br />
When embedded in Ogg,the first packet in a Kate stream (always packet type 0x80,<br />
the id header packet) must be placed on a separate page. The corresponding Ogg<br />
packet must be marked as beginning of stream (BOS).All subsequent header packets<br />
must be on one or more pages. Subsequently, each data packet must be on a separate<br />
page.<br />
<br />
The last data packet must be the end of stream packet (packet type 0x7f).<br />
<br />
When embedded in Ogg, the corresponding Ogg packet must be marked as end of stream (EOS).<br />
<br />
As per the Ogg specification, granule positions must be non decreasing<br />
within the stream. Header packets have granule position 0.<br />
<br />
Currently existing packet types are:<br />
:headers:<br />
::0x80 ID header (BOS)<br />
::0x81 Vorbis comment header<br />
::0x82 regions list header<br />
::0x83 styles list header<br />
::0x84 curves list header<br />
::0x85 motions list header<br />
::0x86 palettes list header<br />
::0x87 bitmaps list header<br />
::0x88 font ranges and mappings header<br />
:data:<br />
::0x00 text data (including optional motions and overrides)<br />
::0x01 keepalive<br />
::0x02 repeat<br />
::0x7f end packet (EOS)<br />
<br />
<br />
<br />
This format described here is for bitstream version 0.x.<br />
As or 19 december 2008, the latest bitstream version is 0.4.<br />
<br />
For more detailed information, refer to the format documentation<br />
in libkate (see URL below in the [[#Downloading|Downlading]] section).<br />
<br />
Following is the definition of the ID header (packet type 0x80).<br />
This works out to a 64 byte ID header. This is the header that should be<br />
used to detect a Kate stream within an Ogg stream.<br />
<br />
<br />
<br />
0 1 2 3 |<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| packtype | Identifier char[7]: 'kate\0\0\0' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| kate magic continued | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved - 0 | version major | version minor | num headers | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| text encoding | directionality| reserved - 0 | granule shift | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| cw sh | canvas width | ch sh | canvas height | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved - 0 | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| granule rate numerator | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| granule rate denominator | 28-31<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (NUL terminated) | 32-35<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 36-39<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 40-43<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 44-47<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (NUL terminated) | 48-51<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 52-55<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 56-59<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 60-63<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
<br />
The fields cw sh, canvas width, cw sh, and canvas height were introduced<br />
in bistream 0.3. Earlier bitstreams will have 0 in these fields.<br />
<br />
language and category are NUL terminating ASCII strings.<br />
Language follows RFC 3066, though obviously will not accommodate language tags<br />
with lots of subtags.<br />
<br />
Category is currently loosely defined, and I haven't found yet a nice way to<br />
present it in a generic way, but is meant for automatic classifying of<br />
various multiplexed Kate streams (eg, to recognize that some streams are<br />
subtitles (in a set of languages), and some others are commentary (in a<br />
possibly different set of languages, etc).<br />
<br />
== API overview ==<br />
<br />
libkate offers an API very similar to that of libvorbis and libtheora, as well as<br />
an extra higher level decoding API.<br />
<br />
Here's an overview of the three main modules:<br />
<br />
=== Decoding ===<br />
<br />
Decoding is done in a way similar to libvorbis. First, initialize a kate_info and a<br />
kate_comment structure. Then, read headers by calling kate_decode_headerin. Once<br />
all headers have been read, a kate_state is initialized for decoding using kate_decode_init,<br />
and kate_decode_packetin is called repeatedly with data packets. Events (eg, text) can be<br />
retrieved via kate_decode_eventout.<br />
<br />
=== Encoding ===<br />
<br />
Encoding is also done in a way similar to libvorbis. First initialize a kate_info<br />
and a kate_comment structure, and fill them out as needed. kate_encode_headers will<br />
create ogg packets from those. Then, kate_encode_text is called repeatedly for all<br />
the text events to add. When done, calling kate_encode_finish will create an end of<br />
stream packet.<br />
<br />
=== High level decoding API ===<br />
<br />
There are only 3 calls here:<br />
<br />
kate_high_decode_init<br />
kate_high_decode_packetin<br />
kate_high_decode_clear<br />
<br />
Here, all Ogg packets are sent to kate_high_decode_packetin, which does the right<br />
thing (header/data classification, decoding, and event retrieval). Note that you<br />
do not get access to the comments directly using this, but you do get access to the<br />
kate_info via events.<br />
<br />
The libkate distribution includes commented examples for each of those.<br />
<br />
Additionally, libkate includes a layer (liboggkate) to make it easier to use when<br />
embedded in Ogg. While the normal API uses kate_packet structures, liboggkate uses<br />
ogg_packet structures.<br />
<br />
The High level decoding API does not have an Ogg specific layer, but functions exist<br />
to wrap a kate_packet around a memory buffer (such as the one ogg_packet uses, for instance).<br />
<br />
== Support ==<br />
<br />
Among the software with Kate support:<br />
*VLC<br />
*ffmpeg2theora<br />
*liboggz<br />
*liboggplay<br />
*Cortado (wikimedia version)<br />
*vorbis-tools<br />
<br />
I have patches for the following with Kate support:<br />
*MPlayer<br />
*xine<br />
*GStreamer<br />
*Thoggen<br />
*Audacious<br />
*and more...<br />
<br />
These may be found in the libkate source distribution (see [[#Downloading|Downloading]]<br />
for links).<br />
<br />
In addition, libtiger is a rendering library for Kate streams using Pango and Cairo,<br />
though it is not quite yet API stable (though no major changes are expected).<br />
<br />
== Granule encoding ==<br />
<br />
=== Ogg ===<br />
<br />
Ogg leaves the encoding of granules up to a particular codec, only<br />
mandating that granules be non decreasing with time.<br />
<br />
The Kate bitstream format uses a linear mapping between time and<br />
granule, described here.<br />
<br />
A Kate granule position is composed of two different parts:<br />
- a base granule, in the high bits<br />
- a granule offset, in the low bits<br />
<br />
+----------------+----------------+<br />
| base | offset |<br />
+----------------+----------------+<br />
<br />
The number of bits these parts occupy is variable, and each stream<br />
may choose how many bits to dedicate to each. The kate_info structure<br />
for a stream holds that information in the granule_shift field,<br />
so each part may be reconstructed from a granulepos.<br />
<br />
The timestamp T of a given Kate packet is split into a base B and<br />
offset O, and these are stored in the granulepos of that packet.<br />
The split is done such that the B is the time of the earliest event<br />
still active at the time, and the O is the time elapsed between B<br />
and T. Thus, T = B + O. This mimics the way Theora stores its own<br />
timestamps in granulepos, where the base acts as a keyframe, and<br />
an offset acts as the position of an intra frame from the previous<br />
keyframe. Since Kate allows time overlapping events, however, the<br />
choice of the base to use is slightly more complex, as it may not<br />
be the starting time of the previous event, if the stream contains<br />
time overlapping events.<br />
<br />
The kate_info structure for a stream holds a rational fraction<br />
representing the time span of granule units for both the base and<br />
the offset parts.<br />
<br />
The granule rate is defined by the two fields:<br />
<br />
kate_info::gps_numerator<br />
kate_info::gps_denominator<br />
<br />
<br />
The number of bits reserved for the offset is defined by the field:<br />
<br />
kate_info::granule_shift<br />
<br />
=== Generic timing ===<br />
<br />
Kate data packets (data packet type 0) includes timing information (start time,<br />
end time, and time of the earliest event still active). All these are stored as<br />
64 bit at the rate defined by the granule rate, so they do not suffer from the<br />
granule_shift space limitation.<br />
<br />
This also allows for Kate streams to be stored in other containers.<br />
<br />
== Motion ==<br />
<br />
The Kate bitstream format includes motion definition, originally for karaoke purposes, but<br />
which can be used for more general purpose, such as line based drawing, or animation of<br />
the text (position, color, etc)<br />
<br />
Motions are defined by the means of a series of curves (static points, segments, splines (catmull-rom, bezier, and b-splines)).<br />
A 2D point can be obtained from a motion for any timestamp during the lifetime of a text.<br />
This can be used for moving a marker in 2D above the text for karaoke, or to use the x<br />
coordinate to color text when the motion position passes each letter or word, etc.<br />
Motions have an attached semantics so the client code knows how to use a particular motion.<br />
Predefined semantics include text color, text position, etc).<br />
<br />
Since a motion can be composed of an arbitrary number of curves, each of which may have<br />
an arbitrary number of control points, complex motions can be achieved. If the motion is<br />
the main object of an event, it is even possible to have an empty text, and use the motion<br />
as a virtual pencil to draw arbitrary shapes. Even on-the-fly handwriting subtitles could<br />
be done this way, though this would require a lot of control points, and would not be able<br />
to be used with text-to-speech.<br />
<br />
As a proof of concept, I also have a "draw chat" program where two people can draw, and<br />
the shapes are turned to b-splines and sent as a kate motion to be displayed on the other<br />
person's window.<br />
<br />
It is also possible for motions to be discontinuous - simply insert a curve of 'none' type.<br />
While the timestamp lies within such a curve, no 2D point will be generated. This can be<br />
used to temporarily hide a marker, for instance.<br />
<br />
It is worth mentionning that pauses in the motion can be trivially included by inserting<br />
at the right time and for the right duration a simple linear interpolation curve with only<br />
two equal points, equal to the position the motion is supposed to pause at.<br />
<br />
Kate defines a set of predefined mappings so that each decoder user interprets a motion in<br />
the same way. A mapping is coded on 8 bits in the bitstream, and the first 128 are reserved<br />
for Kate, leaving 128 for application specific mappings, to avoid constraining creative uses<br />
of that feature. Predefined mappings include frame (eg, 0-1 points are mapped to the size of<br />
the current video frame), or region, to scale 0-1 to the current region. This allows curves<br />
to be defined without knowing in advance the pixel size of the area it should cover.<br />
<br />
For uses which require more than two coordinates (eg, text color, where 4 (RGBA) values are<br />
needed, Kate predefines the semantics text_color_rg and text_color_ba, so a 4D point can be<br />
obtained using two different motions.<br />
<br />
There are higher level constructs, such as morphing between two styles, or predefined<br />
karaoke effects. More are planned to be added in the future.<br />
<br />
See also [[#Trackers|Trackers]].<br />
<br />
== Trackers ==<br />
<br />
Since attaching motions to text position, etc, makes it hard for the client to keep track of<br />
everything, doing interpolation, etc, the library supplies a tracker object, which handles the<br />
interpolation of the relevant properties.<br />
Once initialized with a text and a set of motions, the client code can give the tracker a new<br />
timestamp, and get back the current text position, text color, etc.<br />
<br />
Using a tracker is not necessary, if one wants to use the motions directly, or just ignore them,<br />
but it makes life easier, especially when considering the the order in which motions are applied<br />
does matter (to be defined formally, but the current source code is informative at this point).<br />
<br />
<br />
== The Kate file format ==<br />
<br />
Though this is not a feature of the bitstream format, I have created a text file format to<br />
describe a series of events to be turned into a Kate bitstream.<br />
At its minimum, the following is a valid input to the encoder:<br />
<br />
: kate {<br />
:: event { 00:00:05 --> 00:00:10 "This is a text" }<br />
: }<br />
<br />
This will create a simple stream with "This is a text" emitted at an offset of 5 seconds into<br />
the track, lasting 5 seconds to an end time at 10 seconds.<br />
<br />
Motions, regions, styles can be declared in a definitions block to be reused by events, or can<br />
be defined inline. Defining those in the definitions block places them in a header so they can<br />
be reused later, saving space. However, they can also be defined in each event, so they will be<br />
sent with the event. This allows them to be generated on the fly (eg, if the bitstream is being<br />
streamed from a realtime input).<br />
<br />
For convenience, the Kate file format also allows C style macros, though without parameters.<br />
<br />
Please note that the Kate file format is fully separate from the Kate bitstream format. The<br />
difference between the two is similar to the difference between a C source file and the resulting<br />
object file, when compiled.<br />
<br />
Note that the format is not based on XML for a very parochial reason: I tend to dislike very<br />
much editing XML by hand, as it's really hard to read. XML is really meant for machines to parse<br />
generically text data in a shared syntax but with possibly unknown semantics, and I need those<br />
text representations to be editable easily.<br />
<br />
This also implies that there could be an XML representation of a Kate stream, which would be<br />
useful if one were to make an editor that worked on a higher level than the current all-text<br />
representation, and it is something that might very well happen in the future, in parallel with<br />
the current format.<br />
<br />
== Karaoke ==<br />
<br />
Karaoke effects rely on motions, and there will be predefined higher level ways of specifying<br />
timings and effects, two of which are already done. As an example, this is a valid Karaoke script:<br />
<br />
:kate {<br />
:: simple_timed_glyph_style_morph {<br />
::: from style "start_style" to style "end_style"<br />
::: "Let " at 1.0<br />
::: "us " at 1.2<br />
::: "sing " at 1.4<br />
::: "to" at 2.0<br />
::: "ge" at 2.5<br />
::: "ther" at 3.0<br />
:: }<br />
:}<br />
<br />
The syllables will change from a style to another as time passes. The definition of the start_style<br />
and end_style styles is omitted for brevity.<br />
<br />
<br />
== Problems to solve ==<br />
<br />
There are a few things to solve before the Kate bitstream format can be considered good<br />
enough to be frozen:<br />
<br />
Note: the following is mostly solved, and the bitstream is now stable, and has been<br />
backward and forward compatible since the first released version. This will be updated<br />
when I get some time.<br />
<br />
=== Seeking and memory ===<br />
<br />
When seeking to a particular time in a movie with subtitles, we may end up at a place when a subtitle has been started, but is not removed yet. Pure streaming doesn't have this problem as it remembers the subtitle being issued (as opposed to, say, Vorbis, for which all data valid now is decoded from the last packet). With Kate, a text string valid now may have been issued long ago.<br />
<br />
I see three possible ways to solve this:<br />
*each data packet includes the granule of the earliest still active packet (if none, this will be the granule of this very packet)<br />
**this means seeks are two phased: first seek, find the next Kate packet, and seek again if the granule of the earlier still active packet is less than the original seeked granule. This implies support code on players to do the double seek.<br />
<br />
*use "reference frames", a bit like Theora does, where the granule position is split in several fields: the higher bits represent a position for the reference frame, and the lowest bits a delta time to the current position. When seeking to a granule position, the lower bits are cleared off, yielding the granule position of the previous reference frame, so the seek ends up at the reference frame. The reference frame is a sync point where any active strings are issued again. This is a variant of the method described in the Writ wiki page, but the granule splitting avoids any "downtime".<br />
**this requires reissuing packets, and it doesn't feel right (and wastes space).<br />
**it also requires "dummy" decoding of Kate data from the reference frame to the actual seek point to fully refresh the state "memory".<br />
<br />
*A variant of the two-granules-in-one system used by libcmml, where the "back link" points to the earliest still active string, rather than the previous one (this allows a two phase seek, rather than a multiphase seek, hopping back from event to event, with no real way to know if there is or not a previous event which is still active - I suppose CMML has no need to know this, if their "clips" do not overlap - mine can do).<br />
**Such a system considerably shortens the usable granule space, though it can do a one phase seek, if I understand the system correctly, which I am not certain.<br />
*** Well, it seems it can't do a one phase seek anyway.<br />
<br />
*Additionally, it could be possible to emit simple "keepalive" packets at regular intervals to help a seek algorithm to sync up to the stream without needing too much data reading - this helps for discontinuous streams where there could be no pages for a while if no data is needed at that time.<br />
<br />
=== Text encoding ===<br />
<br />
A header field declares the text encoding used in the stream. At the moment, only UTF-8 is<br />
supported, for simplicity. There are no plans to support other encodings, such as UTF-16,<br />
at the moment.<br />
<br />
Note that strings included in the header (language, category) are not affected by that<br />
language encoding (rather obviously for language itself). These are ASCII.<br />
<br />
The actual text in events may include simple HTML-like markup (at the moment, allowed markup<br />
is the same as the one Pango uses, but more markup types may be defined in the future).<br />
It is also possible to ask libkate to remove this markup if the client prefers to receive<br />
plain text without the markup.<br />
<br />
=== Language encoding ===<br />
<br />
A header field defines the language (if any) used in the stream (this can be overridden in a<br />
data packet, but this is not relevant to this point). At the moment, my test code uses<br />
ISO 639-1 two letter codes, but I originally thought to use RFC 3066 tags. However, matching<br />
a language to a user selection may be simpler for user code if the language encoding is kept<br />
simple. At the moment, I tend to favor allowing both two letter tags (eg, "en") and secondary<br />
tags (like "en_EN"), as RFC 3066 tags can be quite complex, but I welcome comments on this.<br />
<br />
If a stream contains more than one language, there usually is a predominant language, which<br />
can be set as the default language for the stream. Each event can then have a language<br />
override. If there is no predominant language, and it is not possible to split the stream<br />
into multiple substreams, each with its own language, then it is possible to use the "mul"<br />
language tag, as a last resort.<br />
<br />
=== Bitstream format for floating point values ===<br />
<br />
Floating point values are be turned to a 16.16 fixed point format, then stored in a bitpacked<br />
format, storing the number of zero bits at the head and tail of the floating point values once<br />
per stream, and the remainder bits for all values in the stream. This seems to yield good results<br />
(typically a 50% reduction over 32 bits raw writes, and 70% over the snprintf based storage), and<br />
has the big advantage of being portable (eg, independant of any IEEE format).<br />
However, this means reduced precision due to the quantization to 16.16. I may add support for<br />
variable precision (eg, 8.24 fixed point formats) to alleviate this. This would however mean less<br />
space savings, though these are likely to be insignificant when Kate streams are interleaved with<br />
a video.<br />
<br />
*Though this is not a Kate issue per se, the motion feature is very difficult to use without a curve editor. While tools may be coded to create a Kate bitstream for various existing subtitle formats, it is not certain it will be easy to find a good authoring tool for a series of curves. That said, it's not exactly difficult to do if you know a widget set.<br />
<br />
=== Higher dimensional curves/motions ===<br />
<br />
It is quite annoying to have to create two motions to control a color change, due to curves<br />
being restricted to two dimensions. I may add support for arbitrary dimensions. It would also<br />
help for 1D motions, like changing the time flow, where one coordinate is simply ignored at<br />
the moment.<br />
Alternatively, changes could be made to the Kate file format to hide the two dimensionality and<br />
allow simpler specification of non-2 dimensional motions, but still map them to 2D in the kate<br />
bitstream format.<br />
<br />
=== Category definition ===<br />
<br />
The category field in the BOS packet is a 16 byte text field (15 really, as it is zero terminated<br />
in the bitstream itself). Its goal is to provide the reader with a short description of what kind<br />
of information the stream contains, eg subtitles, lyrics, etc. This would be displayed to the user,<br />
possibly to allow to choose to turn some streams on and off.<br />
<br />
Since this category is meant primarily for a machine to parse, they will be kept to ASCII. When<br />
a player recognizes a category, it is free to replace its name with one in the user's language if<br />
it prefers. Even in English, the "lyrics" category could be displayed by a player as "Lyrics".<br />
<br />
Since this is a free text field rather than an enumeration, it would be good to have a list of<br />
common predefined category names that Kate streams can use.<br />
<br />
This is a list of proposed predefined categories, feedback/additions welcome:<br />
<br />
* subtitles - the usual movie subtitles, as text<br />
* spu-subtitles - movie subtitles in DVD style paletted images<br />
* lyrics - song lyrics<br />
<br />
Please remember the 15 character limit if proposing other categories.<br />
<br />
Note that the list of categories is subject to change, and will likely<br />
be replaced by new, more "identifier like" ones. The three ones above,<br />
however, would be kept for backward compatibility as they're already used.<br />
<br />
== Text to speech ==<br />
<br />
One of the goals of the Kate bitstream format is that text data can be easily parsed<br />
by the user of the decoder, so any additional information, such as style, placement,<br />
karaoke data, etc, should be able to be stripped to leave only the bare text. This is<br />
in view of allowing text-to-speech software to use Kate bitstreams as a bandwith-cheap<br />
way of conveying speech data, and could also allow things like e-books which can be<br />
either read or listened to from the same bitstream (I have seen no reference to this<br />
being used anywhere, but I see no reason why the granule progression should be temporal,<br />
and not user controlled, such as by using a "next" button which would bump a granule<br />
postion by a preset amount, simulating turning a page (this would be close to necessary<br />
for text-to-speech, as the wall time duration of the spoken speech is not known in<br />
advance to the Kate encoder, and can't be mapped to a time based granule progression)).<br />
All text strings triggered consecutively between the two granule positions would then<br />
be read in order.<br />
<br />
== Possible additions ==<br />
<br />
=== Embedded binary data ===<br />
<br />
Images and font mappings can be included within a Kate stream.<br />
<br />
==== Images ====<br />
<br />
Though this could be misused to interfere with ability to render as text-to-speech, Kate<br />
can use images as well as text. The same caveat as for fonts applies with regard to data<br />
duplication.<br />
<br />
Complex images might however be best left to a multiplexed OggSpots or OggMNG stream, unless the<br />
images mesh with the text (eg, graphical exclamation points, custom fonts, (see next<br />
paragraph), etc).<br />
<br />
There is support for simple paletted bitmap images, with a variable length palette of up<br />
to 256 colors (in fact, sized in powers of 2 up to 256) and matching pixel data in as<br />
many bits per pixel as can address the palette. Palettes and images are stored separately,<br />
so can be used with one another with no fixed assignment.<br />
<br />
Palettes and bitmaps are put in two separate header for later use by reference, but can<br />
also be placed in data packets, as with motions, etc, if they are not going to be reused.<br />
<br />
PNG bitmaps can also be embedded in a Kate stream. These do not have associated palettes<br />
(but the PNGs themselves may or may not be paletted). There is no support for decoding PNG<br />
images in libkate itself, so a program will have to use libpng (or similar code) to decode<br />
the PNG image. For instance, the libtiger rendering library uses Cairo to decode and render<br />
PNG images in Kate streams.<br />
<br />
This can be used to have custom fonts, so that raw text is still available if the stream<br />
creator wants a custom look.<br />
<br />
I expect that the need for more than 256 colors in a bitmap, or non palette bitmap data,<br />
would be best handled by another codec, eg OggMNG or OggSpots. The goal of images in a<br />
Kate stream is to mesh the images with the text, not to have large images by themselves.<br />
<br />
On the other hand, interesting Karaoke effects could be achieved by having MNG images<br />
instead of simple paletted bitmaps in a Kate streams. Comments would be most welcome on<br />
whether this is going too far, however.<br />
<br />
I am also investigating SVG images. These allow for very small footprint images for simple<br />
vector drawings, and could be very useful for things like background gradients below text.<br />
<br />
A possible solution to the duplication issue is to have another stream in the container<br />
stream, which would hold the shared data (eg, fonts), which the user program could load,<br />
and which could then be used by any Kate (and other) stream. Typically, this type of stream<br />
would be a degenerate stream with only header packets (so it is fully processed before any<br />
other stream presents data packets that might make use of that shared data), and all payload<br />
such as fonts being contained within the headers. Thinking about it, it has parallels with<br />
the way Vorbis stores its codebooks within a header packet, or even the way Kate stores the<br />
list of styles within a header packet.<br />
<br />
==== Fonts ====<br />
<br />
Custom fonts are merely a set of ranges mapping unicode code points to bitmaps. As this implies,<br />
fonts are bitmap fonts, not vector fonts, so scaling, if supported by the rendering client,<br />
may not look as good as with a vector font.<br />
<br />
A style may also refer to a font name to use (eg, "Tahoma"). These fonts may or may not be<br />
available on the playing system, however, since the font data is not included in the stream,<br />
just referenced by name. For this reason, it is best to keep to widely known fonts.<br />
<br />
== Reference encoder/decoder ==<br />
<br />
A encoder (kateenc) and a decoder (katedec) are included in the tools directory.<br />
The encoder supports input from several different formats:<br />
* a custom text based file format (see [[#The Kate file format|The Kate file format]]), which is by no means meant to be part of the Kate bitstream specification itself<br />
* SubRip (.srt), the most common subtitle format I found<br />
* LRC lyrics format.<br />
<br />
As an example for the widely used SRT subtitles format, the following command line<br />
create a Kate subtitles stream from an SRT file:<br />
<br />
kateenc -l en -c subtitles -t srt -o subtites.ogg subtitles.srt<br />
<br />
The reverse is possible, to recover an SRT file from a Kate stream, with katedec.<br />
<br />
Note that the subtitles.ogg file should then be multiplexed into the A/V stream,<br />
using either ogg-tools or oggz-tools.<br />
<br />
The Kate bitstreams encoded and decoded by those tools are (supposed to be) correct for this<br />
specification, provided their input is correct.<br />
<br />
== Next steps ==<br />
<br />
=== Continuations ===<br />
<br />
Continuations are a way to add to existing events, and are mostly meant for motions. When streaming<br />
in real time, what motions may be applied to events may not be known in advance (for instance, for a<br />
draw chat program where two programs exchange Kate streams, the drawing motions are only known as<br />
they are drawn. Continuations will allow an event to be extended in time, and motions to be appended<br />
to it. This is only useful for streaming, as when stored in a file, everything is already known in<br />
advance.<br />
<br />
=== A rendering library ===<br />
<br />
This will allow easier integration in other packages (movie players, etc).<br />
I have started working on an implementation using Cairo and Pango, though I'm still at the early stages.<br />
I might add support for embedding vector fonts in a Kate stream if I was going that way. Still need to think about this.<br />
Another point of note is that when this library is available, it would make it easier to add<br />
capabilities such as rotation, scaling, etc, to the bitstream, since this would not cause too<br />
much work for playing programs using the rendering library. It is expected that these additions<br />
would stay backward compatible (eg, an old player would ignore this information but still correctly<br />
decode the information they can work with from a newly encoded stream).<br />
<br />
=== An XML representation ===<br />
<br />
While I purposefully did not write Kate description files in XML due to me finding editing XML such<br />
a chore, it would be nice to be able to losslessly convert between the more user friendly representation<br />
and an XML document, so one can do what one does with XML documents, like transformations.<br />
<br />
And after all, some people might prefer editing the XML version.<br />
<br />
=== Packaging ===<br />
<br />
It would be really nice to have packages for libkate/libtiger for many distros.<br />
<br />
If you're a packager for a distro which doesn't have yet packages for libkate<br />
or libtiger, please consider helping :)<br />
<br />
In particular, packages for Debian would be grand.<br />
<br />
== Matroska mapping ==<br />
<br />
The codec ID is "S_KATE".<br />
<br />
As for Theora and Vorbis, Kate headers are stored in the private data as xiph-laced packets:<br />
<br />
Byte 0: number of packets present, minus 1 (there must be at least one packet) - let this number be NP<br />
Bytes 1..n: lengths of the first NP packets, coded in xiph style lacing<br />
Bytes n+1..end: the data packets themselves concatenated one after the other<br />
<br />
Note that the length of the last packet isn't encoded, it is deduced from the sizes of the other<br />
packets and the total size of the private data.<br />
<br />
This mapping is similar to the Vorbis and Theora mappings, with the caveat that one should not<br />
expect a set number of headers.<br />
<br />
== Downloading ==<br />
<br />
libkate encodes and decodes Kate streams, and is API and ABI stable.<br />
<br />
The libkate source distribution is available at [http://libkate.googlecode.com/ http://libkate.googlecode.com/].<br />
<br />
A public git repository is available at [http://git.xiph.org/?p=users/oggk/kate.git;a=summary http://git.xiph.org/?p=users/oggk/kate.git;a=summary].<br />
<br />
libtiger renders Kate streams using Pango and Cairo, and is alpha, with API changes still possible.<br />
<br />
The libtiger source distribution is available at [http://libtiger.googlecode.com/ http://libtiger.googlecode.com/].<br />
<br />
A public git repository is available at [http://git.xiph.org/?p=users/oggk/tiger.git;a=summary http://git.xiph.org/?p=users/oggk/tiger.git;a=summary].<br />
<br />
== HOWTOs ==<br />
<br />
These paragraphs describe a few ways to use Kate streams:<br />
<br />
=== Text movie subtitles ===<br />
<br />
Kate streams can carry Unicode text (that is, text that can represent<br />
pretty much any existing language/script). If several Kate streams are<br />
multiplexed along with a video, subtitles in various languages can be<br />
made for that movie.<br />
<br />
An easy way to create such subtitles is to use ffmpeg2theora, which<br />
can create Kate streams from SubRip (.srt) format files, a simple but<br />
common text subtitles format. ffmpeg2theora 0.21 or later is needed.<br />
<br />
At its simplest:<br />
<br />
ffmpeg2theora -o video-with-subtitles.ogg --subtitles subtitles.srt<br />
video-without-subtitles.avi<br />
<br />
Several languages may be created and tagged with their language code<br />
for easy selection in a media player:<br />
<br />
ffmpeg2theora -o video-with-subtitles.ogg video-without-subtitles.avi<br />
--subtitles japanese-subtitles.srt --subtitles-language ja<br />
--subtitles welsh-subtitles.srt --subtitles-language cy<br />
--subtitles english-subtitles.srt --subtitles-language en_GB<br />
<br />
Alternatively, kateenc (which comes with the libkate distribution) can<br />
create Kate streams from SubRip files as well. These can then be merged<br />
with a video with oggz-tools:<br />
<br />
kateenc -t srt -c SUB -l it -o subtitles.ogg italian-subtitles.srt<br />
oggz merge -o movie-with-subtitles.ogg movie-without-subtitles.ogg subtitles.ogg<br />
<br />
This second method can also be used to add subtitles to a video which<br />
is already encoded to Theora, as it will not transcode the video again.<br />
<br />
<br />
=== DVD subtitles ===<br />
<br />
DVD subtitles are not text, but images. Thoggen, a DVD ripper program,<br />
can convert these subtitles to Kate streams (at the time of writing,<br />
Thoggen and GStreamer have not applied the necessary patches for this<br />
to be possible out of the box, so patching them will be required).<br />
<br />
When configuring how to rip DVD tracks, any subtitles will be detected<br />
by Thoggen, and selecting them in the GUI will cause them to be saved as<br />
Kate tracks along with the movie.<br />
<br />
<br />
=== Song lyrics ===<br />
<br />
Kate streams carrying song lyrics can be embedded in an Ogg file. The<br />
oggenc Vorbis encoding tool from the Xiph.Org Vorbis tools allows lyrics<br />
to be loaded from a LRC or SRT text file and converted to a Kate stream<br />
multiplexed with the resulting Vorbis audio. At the time of writing,<br />
the patch to oggenc was not applied yet, so it will have to be patched<br />
manually with the patch found in the diffs directory.<br />
<br />
oggenc -o song-with-lyrics.ogg --lyrics lyrics.lrc --lyrics-language en_US song.wav<br />
<br />
So called 'enhanced LRC' files (containing extra karaoke timing information)<br />
are supported, and a simple karaoke color change scheme will be saved<br />
out for these files. For more complex karaoke effects (such as more <br />
complex style changes, or sprite animation), kateenc should be used with<br />
a Kate description file to create a separate Kate stream, which can then<br />
be merged with a Vorbis only song with oggz-tools:<br />
<br />
oggenc -o song.ogg song.wav<br />
kateenc -t kate -c LRC -l en_US -o lyrics.ogg lyrics-with-karaoke.kate<br />
oggz merge -o song-with-karaoke.ogg lyrics-with-karaoke.ogg song.ogg<br />
<br />
This latter method may also be used if you already have an encoded Vorbis song<br />
with no lyrics, and just want to add the lyrics without reencoding.<br />
<br />
<br />
=== Metadata ===<br />
<br />
Metadata can be attached to events, or to styles, bitmaps, regions, etc.<br />
Metadata are free form tag/value pairs, and can be used to enrich their<br />
attached data with extra information. However, how this information is<br />
interpreted is up to the application layer.<br />
<br />
It is worth noting that an event may not have attached text, so it is<br />
possible to create an empty timed event with attached metadata.<br />
<br />
For instance, let's say we have a documentary, with footage from various<br />
places, as well as short interviews, and we want two things:<br />
- tag footage with metadata about the location and date that footage was shot<br />
- subtitle the interviews and tag those subtitles with information about the speaker<br />
<br />
You can then create an empty Kate event for each footage part, synchronized<br />
with the footage, and attach a new metadata item called GEO_LOCATION, filled<br />
with latitude and longitude of the place the footage was shot at.<br />
Similarly, for each subtitle event, a metadata item called SPEAKER can be<br />
attached.<br />
<br />
An empty event to tag a long 4:20 footage shot in Tokyo on 2011/08/12, and<br />
inserted at 18:30 in the documentary could look like:<br />
<br />
event {<br />
00:18:30,000 --> 00:22:50,000<br />
meta "GEO_LOCATION" = "35.42; 139.42"<br />
meta "DATE" = "2011-08-12"<br />
}<br />
<br />
Here's a example for a line spoken by Dr Joe Bloggs at 18:30 into the documentary:<br />
<br />
event {<br />
00:18:30,000 --> 00:18:32,000<br />
"Notice how the subtitles for my words have metadata attached to them"<br />
meta "SPEAKER" = "Dr Joe Bloggs"<br />
meta "URL" = "http://www.example.com/biography?name=Joe+Bloggs"<br />
}<br />
<br />
Notice how another metadata item, URL, is also present. The application<br />
will have to be aware of those metadata in order to do something with it<br />
though. Since those are free form, it is up to you to think of what<br />
metadata you want, and make use of it.<br />
<br />
Note that metadata may be attached to other objects, such as regions.<br />
This way, you can for example create a region tagged with a name, and<br />
track a person's movements with that region. Or you can tag a bitmap<br />
with a copyright and a URL to a larger version of the image.<br />
<br />
<br />
<br />
=== Changing a Kate stream embedded in an Ogg stream ===<br />
<br />
If you need to change a Kate stream already embedded in an Ogg stream (eg, you have a movie with subtitles, and you want to fix a spelling mistake, or want to bring one of the subtitles forward in time, etc), you can do this easily with KateDJ, a tool that will extract Kate streams, decode them to a temporary location, and rebuild the original stream after you've made whatever changes you want.<br />
<br />
KateDJ (included with the libkate distribution) is a GUI program using wxPython, a Python module for the wxWidgets GUI library, and the oggz tools (both needing installing separately if they are not already).<br />
<br />
The procedure consists of:<br />
<br />
* Run KateDJ<br />
* Click 'Load Ogg stream' and select the file to load<br />
* Click 'Demux file' to decode Kate streams in a temporary location<br />
* Edit the Kate streams (a message box tells you where they are placed)<br />
* When done, click 'Remux file from parts'<br />
* If any errors are reported, continue editing until the remux step succeeds<br />
<br />
== Frequently Asked Questions ==<br />
<br />
=== Does libkate work on other plaforms than Linux ? ===<br />
<br />
Yes, libkate is not Linux specific in any way. It optionally relies on libogg<br />
and libpng, two libraries widely ported to various platforms.<br />
It has been reported to work on Windows and MacOS X as well as UNIX platforms.<br />
<br />
However, libtiger, a rendering library for Kate streams, relies on Pango and Cairo,<br />
which are not easy to build on Windows, though they can be.<br />
The Tiger renderer is however completely separate from libkate, and is not needed<br />
for full encoding and decoding of Kate streams.<br />
<br />
=== Where can I find some example files ? ===<br />
<br />
The libkate distribution can generate various examples, but already built files<br />
can be found there:<br />
[http://people.xiph.org/~oggk/elephants_dream/elephantsdream-with-subtitles.ogg]<br />
[http://stallman.org/fry/Stephen_Fry-Happy_Birthday_GNU-nq_600px_425kbit.ogv]<br />
<br />
These files use raw text only.<br />
<br />
<br />
<br />
[[Category:Drafts]]<br />
[[Category:Ogg Mappings]]</div>J^https://wiki.xiph.org/index.php?title=Ambisonics&diff=13495Ambisonics2012-06-15T11:24:04Z<p>J^: Reverted edits by WikiCleaner (talk) to last revision by Martin.leese</p>
<hr />
<div><i><br />
This page is part of the XiphWiki, and is aimed at people developing file <br />
formats and associated software for Ambisonics. For an general introduction <br />
to Ambisonics, please go to the <br />
</i><br />
[[Wikipedia:Ambisonics|Wikipedia page on Ambisonics]].<br />
<br />
'''Ambisonics''' is a surround sound system first developed in the 1970s. <br />
Its main difference from other surround techniques is that it separates <br />
transmission channels from speaker feeds, the speaker feeds being derived <br />
using a decoder situated in the living room. Decoders can be implemented <br />
in either hardware or software. Typically more speakers are used than <br />
transmission channels, and the more speakers used then the more stable the <br />
resulting soundfield. Speakers can be arranged in a number of configurations, <br />
regular polygons being the most popular.<br />
<br />
Ambisonic files can come in a number of different formats. The main one is <br />
called B-Format, the other formats being derived from this. UHJ format is <br />
mono- and stereo-compatible. G-Format is a set of speaker feeds, so can be <br />
enjoyed in surround sound without the need for a decoder in the living room.<br />
<br />
== Ambisonics and 5.1 ==<br />
<br />
Ambisonics and conventional 5.1 surround sound are very different. 5.1 is a <br />
set speaker feeds, the signal only being fully defined for sounds coming <br />
from a speaker. Phantom images between speakers can be created, but the <br />
technique to do so is left unspecified. Many 5.1 releases use pair-wise <br />
mixing to create phantom images. This is understandable as almost all <br />
stereo recordings are mixed using pair-wise mixing.<br />
<br />
Pair-wise mixing is also called "pan-potting", "amplitude mixing" and <br />
"intensity stereophony". It mixes signals into the feeds for a pair of <br />
speakers to create the illusion that a sound is coming from a point <br />
somewhere between the speakers. During mixing, the apparent location of <br />
each sound is determined only by the relative amplitude of that sound in <br />
the two speakers.<br />
<br />
Unfortunately, pair-wise mixing works poorly when the speakers are to the <br />
rear of the listener and not-at-all when they are to one side. You can <br />
demonstrate this for yourself by performing <br />
[http://members.tripod.com/martin_leese/Ambisonic/exper.html a very simple experiment].<br />
Pair-wise mixing did not work in the quadraphonic era and it will not work <br />
now. Such an absolute statement can be made because the way that humans <br />
localise sound has not changed.<br />
<br />
Ambisonics is fundamentally different from 5.1. What is encoded in <br />
Ambisonics is not speaker feeds, but ''direction''. When mixing in <br />
Ambisonics, the positions of the speakers are unknown <br />
''and are of no interest''. Further, when Ambisonics is decoded to speaker <br />
feeds all of the speakers cooperate to localise a sound in its correct <br />
position so, for example, when the speakers on the left push those on the <br />
right pull. The speakers all contribute to the creation of a single <br />
coherent soundfield.<br />
<br />
=== Ambisonics to 5.1 ===<br />
Converting Ambisonics to 5.1 is straightforward, and is discussed below <br />
(see [[#G-Format|G-Format]]).<br />
<br />
=== 5.1 to Ambisonics ===<br />
Converting 5.1 to Ambisonics is more difficult. It is easy to make the <br />
five speaker feeds phantom images, called "virtual speakers". (The ".1" <br />
channel can be folded into W.) The problem with this is that even if the <br />
Ambisonic rendering is perfect, the result will only be as good as the <br />
original 5.1 played through ''real'' speakers. It will not be an <br />
improvement. Nobody has yet come up with a way for Ambisonics to improve <br />
5.1; 5.1 is simply too broken.<br />
<br />
== B-Format ==<br />
<br />
B-Format is a single coherent soundfield composed of a set of related <br />
channels. The number of channels used depends on whether the soundfiled <br />
is horizontal-only or full-sphere, and on the order. These B-Format <br />
channels are transmission channels, not speaker feeds. Listening to <br />
B-Format requires a decoder in your living room. Some numbers of <br />
channels are tabulated below.<br />
<br />
=== Channel correlation ===<br />
Compression techniques typically make use of channel correlation to <br />
remove redundancy from the audio data, and so improve the compression <br />
ratio.<br />
<br />
The correlation between B-Format channels depends on the content. <br />
Four-channel B-Format consists of an <br />
omni-directional component, called W, and three figure-of-eight <br />
components pointing forward, left and up, called X, Y, Z. <br />
([http://members.tripod.com/martin_leese/Ambisonic/Harmonic.html Pictures are available].) <br />
Three-channel, horizontal-only B-Format simply omits the Z channel. This <br />
means that anything in X also appears in W. Same for Y and Z. (W is <br />
omni-directional; everything appears in W.) Also, if content comes from <br />
Front-Left then it appears equally in X and Y. Same for content from <br />
Front-Right, Back-Left, Back-Right; only the relative polarities change. <br />
So there can be a lot of correlation between B-Format channels, but it is <br />
content dependent.<br />
<br />
One problem with B-Format is that it is big on low-frequency phase. The <br />
phase relationships between the different B-Format channels are important <br />
if the resulting soundfield is to correctly "gel". This may be a problem <br />
when B-Format channels are compressed using lossy compression.<br />
<br />
There is a file specification in use for downloadable B-Format files <br />
called the <br />
[http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification].<br />
<br />
=== Limitations of the ".amb" specification ===<br />
The [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] <br />
for downloadable B-Format files is based on the WAVE-EX format. There are <br />
currently over 200 pieces available in this format <br />
[http://www.ambisonia.com for free download]. Most of these are <br />
first-order full-sphere soundfields. (The same website also has details of <br />
[http://www.ambisonia.com/wiki/index.php/Playback_Software ad hoc software decoders].) <br />
Some of the limitations of the specification are: <br />
<br />
#It is limited to 4 GByte files (2 GBytes if somebody screwed up).<br />
#It is limited to third-order soundfields and below. While third-order looks like a lot (16 channels), there already exists a prototype mic that can record up to fourth-order (25 channels).<br />
#No compression (particularly lossless).<br />
<br />
The reason that the ".amb" file specification is limited to third-order <br />
and below is because it uses the number of channels to uniquely define the <br />
soundfield order. Unfortunately this simple and elegant scheme does not <br />
work above third-order as ambiguities creep in. (One ambiguity is <br />
illustrated in the table below.)<br />
<br />
A more general file format will have to use something else, such as <br />
''Malham notation'', or storing both the horizontal-order and <br />
height-order. There is a one-to-one correspondence between Malham notation <br />
and the pair of orders, and either can generate the number of channels.<br />
<br />
==== Malham notation ====<br />
Malham notation specifies the order of a B-Format soundfield using a <br />
string of characters, each character being either '''f''' (for full-sphere) <br />
or '''h''' (for horizontal). The first character in the string specifies <br />
the type of the first-order components, the second character the type of <br />
the second-order components, etc.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|<br />
|-<br />
!<span style="font-size:80%">Horizontal<br>order</span><br />
!<span style="font-size:80%">Height<br>order</span><br />
!<span style="font-size:80%">Soundfield_type</span><br />
!<span style="font-size:80%">Malham<br>notation</span><br />
!<span style="font-size:80%">Number<br>of_channels</span><br />
!<span style="font-size:80%">Channels</span><br />
|-<br />
| 1|| 0||horizontal||'''h'''|| 3||WXY<br />
|-<br />
| 1|| 1||full-sphere||'''f'''|| 4||WXYZ<br />
|-<br />
| 2|| 0||horizontal||'''hh'''|| 5||WXYUV<br />
|-<br />
| 2|| 1||mixed-order||'''fh'''|| 6||WXYZUV<br />
|-<br />
| 2|| 2||full-sphere||'''ff'''|| 9||WXYZRSTUV<br />
|-<br />
| 3|| 0||horizontal||'''hhh'''|| 7||WXYUVPQ<br />
|-<br />
| 3|| 1||mixed-order||'''fhh'''|| 8||WXYZUVPQ<br />
|-<br />
| 3|| 2||mixed-order||'''ffh'''|| 11||WXYZRSTUVPQ<br />
|-<br />
| 3|| 3||full-sphere||'''fff'''|| 16||WXYZRSTUVKLMNOPQ<br />
|-<br />
| 4|| 0||horizontal||'''hhhh'''|| 9||extra channels unlabled<br />
|}<br />
<br />
=== Default channel conversions from B-Format ===<br />
Converting a B-Format file to a mono file is straightforward. Use Mono = <br />
W*sqrt(2).<br />
<br />
Converting a B-Format file to a stereo file is more difficult. The "proper" <br />
way to do this is to convert the W,X,Y channels to two-channel UHJ. <br />
Unfortunately this requires the use of wide-band 90-degree phase shifters. <br />
In the digital domain these are usually implemented as convolution filters.<br />
<br />
Assuming 90-degree phase shifters are unavailable then the problem is one of <br />
choice. Starting from B-Format, it is possible to synthesize ''any'' mic <br />
response pointing in ''any'' direction. Hence, it is possible to synthesize <br />
''all'' coincident stereo mic techniques. Two popular stereo techniques are <br />
''Blumlein Mid-Side'' and ''Blumlein Crossed Pair''.<br />
<br />
==== Blumlein Mid-Side ====<br />
<pre><br />
Mid = (W*sqrt(2)) + X /*This is a cardioid response pointing forward*/<br />
Left = Mid + Y<br />
Right = Mid - Y<br />
</pre><br />
<br />
==== Blumlein Crossed Pair ====<br />
<pre><br />
Left = (X + Y)/sqrt(2) /* (Left, Right) are just the (Y, X) */<br />
Right = (X - Y)/sqrt(2) /* responses rotated by -45 degrees */<br />
</pre><br />
<br />
Which conversion to stereo is better depends on the material and how it was <br />
recorded. A good suggestion is to not specify a ''particular'' default <br />
channel conversion; instead, simply specify that there must be one. If one <br />
has to be specified then Blumlein Crossed Pair is the simpler.<br />
<br />
== UHJ format ==<br />
<br />
B-Format is the main format for Ambisonic files. However, B-Format is <br />
not mono- or stereo-compatible. This is why the UHJ hierarchical system <br />
was developed. Depending on the number of channels available, the UHJ <br />
system can carry more or less information, but at all times it is fully <br />
mono- and stereo-compatible. Up to four channels (Left, Right, T, Q) may <br />
be used. The T-channel can also be band-limited but, as this <br />
"2&frac12;-channel UHJ" was only ever used for FM radio transmission, it <br />
will not be discussed further.<br />
<br />
To listen to UHJ files in surround requires a decoder in your living room. <br />
Also, UHJ is restricted to first-order soundfields, either horizontal (two- <br />
and three-channel UHJ) or full-sphere (four-channel UHJ).<br />
<br />
Converting B-Format channels to UHJ channels, and vice versa, requires the <br />
use of wide-band 90-degree phase shifters. In the digital domain these <br />
are usually implemented as convolution filters. Conversion between <br />
four-channel B-Format (W, X, Y, Z) and four-channel UHJ (Left, Right, T, <br />
Q) can be accomplished without loss of information. The same with <br />
three-channel to three-channel (W, X, Y) <=> (Left, Right, T). It is <br />
possible to recover three-channel B-Format (W, X, Y) from two-channel UHJ <br />
(Left, Right), but not without loss. It is also important for the Ambisonic <br />
decoder to be aware that the B-Format channels were recovered from <br />
two-channel UHJ (because of the need to apply different shelf filters).<br />
<br />
Several hundred <br />
[http://members.cox.net/surround/uhjdisc/ambindex.htm two-channel UHJ LPs and CDs] <br />
have been released. Three- and four-channel UHJ recordings have never been <br />
commercially released.<br />
<br />
=== UHJ encoding and decoding equations ===<br />
<br />
==== Encoding ====<br />
<pre><br />
S = 0.9396926*W + 0.1855740*X<br />
D = j(-0.3420201*W + 0.5098604*X) + 0.6554516*Y<br />
<br />
Left = (S + D)/2.0<br />
Right = (S - D)/2.0<br />
T = j(-0.1432*W + 0.6512*X) - 0.7071*Y<br />
Q = 0.9772*Z<br />
<br />
where j is a +90 degree phase shift<br />
</pre><br />
<br />
==== Decoding ====<br />
For two-channel UHJ:<br />
<pre><br />
S = (Left + Right)/2.0<br />
D = (Left - Right)/2.0<br />
<br />
W = 0.982*S + j*0.164*D<br />
X = 0.419*S - j*0.828*D<br />
Y = 0.763*D + j*0.385*S<br />
<br />
where j is a +90 degree phase shift<br />
</pre><br />
Note that two-channel UHJ requires the player to use different shelf filters than for B-Format.<br />
<br />
For three- and four-channel UHJ:<br />
<pre><br />
S = (Left + Right)/2.0<br />
D = (Left - Right)/2.0<br />
<br />
W = 0.982*S + j*0.197(0.828*D + 0.768*T)<br />
X = 0.419*S - j(0.828*D + 0.768*T)<br />
Y = 0.796*D - 0.676*T + j*0.187*S<br />
Z = 1.023*Q<br />
<br />
where j is a +90 degree phase shift<br />
</pre><br />
<br />
There is a file specification for downloadable two-channel UHJ files <br />
called the <br />
[http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification], but it is not currently in use.<br />
<br />
=== Limitations of the ".uhj" specification ===<br />
The [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] <br />
for downloadable two-channel UHJ files is based on the WAVE or WAVE-EX <br />
format. A UHJ chunk is added to the file to indicate it is UHJ. As <br />
unrecognized chunks are always skipped, use of this chunk maintains stereo <br />
compatibility. Some of the limitations of the specification are: <br />
<br />
#It is limited to 4 GByte files (2 GBytes if somebody screwed up).<br />
#It is limited to two-channel UHJ files. Three- and four-channel UHJ are not accommodated.<br />
#No compression.<br />
<br />
The ".uhj" spcecification is only defined for two-channel UHJ to maintain <br />
stereo compatibility. While it would be possible to add the UHJ chunk to <br />
three- and four-channel WAVE-EX files, the recommendations from Microsoft <br />
for playing such files is that the audio device should render the extra <br />
channels to output ports not in use. This can happen even when the extra <br />
channels are masked off. (Put simply, in WAVE-EX files the channel mask <br />
does ''not'' mask channels.) Because of this, three- and four-channel <br />
WAVE-EX files can not be made stereo compatible.<br />
<br />
In the Xiph world, it should be possible to use default channel conversions <br />
to ensure that three- and four-channel UHJ files remain stereo compatible.<br />
<br />
=== Default channel conversions from UHJ ===<br />
Converting a UHJ file to a mono file is straightforward. Use Mono = <br />
(Left + Right) / sqrt(2).<br />
<br />
Converting a UHJ file to a stereo file is even easier. Use Left = Left, Right = Right, and discard T and Q if present.<br />
<br />
== G-Format ==<br />
<br />
A G-Format file is any common multi-channel surround file containing an <br />
Ambisonic soundfield pre-decoded to its speaker feeds. This allows <br />
listeners who do not own an Ambisonic decoder to enjoy Ambisonics.<br />
<br />
The sound engineer creates a set of speaker feeds for a particular number <br />
and arrangement of speakers. This is typically four speakers arranged in <br />
a square. Other speaker arrangements are also possible<br />
<br />
In Ambisonics, all speakers cooperate to localise sounds in any particular <br />
direction; there are no "surround speakers" as such. Because of this, best <br />
results when playing G-Format recordings (and Ambisonics in general) are <br />
obtained when the speakers are matched. The easiest way to accomplish this <br />
is to use identical speakers. Unfortunately, many home theatre systems <br />
include a centre-front speaker which is different from the other speakers.<br />
<br />
An easy way to cope with this is adopted on G-Format recordings commercially <br />
released on DVD-A by [http://www.wyastone.co.uk/nrl/dvd.html Nimbus Records]. <br />
They use four speakers in a square, the centre-front speaker being unused. <br />
<br />
=== Recovering B-Format from G-Format ===<br />
It is sometimes possible to recover the original B-Format channels from <br />
the G-Format speaker feeds. The recovered B-Format channels can then be <br />
fed to a decoder in the listener's living room, and so accommodate a <br />
speaker arrangement different from the one used when the G-Format file <br />
was produced. Each B-Format channel is recovered using a weighted <br />
combination of the speaker feeds in the G-Format file. The conversion <br />
coefficients required for the B-Format recovery depend on the particular <br />
speaker arrangment chosen by the sound engineer. (Obviously, if a <br />
B-Format version of the file also exists then it can be fed to the <br />
decoder directly without the need for G-Format.)<br />
<br />
File formats for G-Format include all multi-channel formats that contain <br />
speaker feeds. However, these will not contain information to allow the <br />
B-Format channels to be automatically recovered. A [http://members.tripod.com/martin_leese/Ambisonic/G-Format_chunk.html ".amg" file format] <br />
(based on WAVE-EX) for downloadable G-Format files, which will allow <br />
the B-Format channels to be automatically recovered, has been proposed. <br />
Such file formats have the advantage of storing the conversion <br />
coefficients at the time the G-Format file is created. This is the only <br />
time the required information is readily available.<br />
<br />
=== Default channel conversions from G-Format ===<br />
Converting a G-Format file to a mono or stereo file is straightforward. <br />
First, recover the B-Format channels using the conversion coefficients <br />
contained in the file. Second, follow the advice given above for <br />
[[#Default channel conversions from B-Format|Default channel conversions from B-Format]].<br />
<br />
== Resources on Ambisonics ==<br />
<br />
*There is a set of [http://en.wikipedia.org/wiki/Ambisonics Wikipedia articles on Ambisonics].<br />
*Of particular relevance is the [http://members.tripod.com/martin_leese/Ambisonic/B-Format_file_format.html ".amb" specification] in use for downloadable B-Format files. However the ".amb" spec has some limitations which it would be useful to overcome.<br />
*There is also the [http://members.tripod.com/martin_leese/Ambisonic/UHJ_file_format.html ".uhj" specification] for downloadable two-channel UHJ files, but it is not currently in use. The ".uhj" spec also has some limitations which it would be useful to overcome.<br />
*[http://members.tripod.com/martin_leese/Ambisonic/ This website] has many pages on Ambisonics (including at the bottom links to other Ambisonic websites).<br />
*[http://www.ambisonic.net/ Ambisonic.Net website] includes a detailed series of descriptive and practical articles on current and past Ambisonic techniques with links to tools, other sites and additional material.<br />
*[http://ambisonic.info/info/ricardo.html Richard Lee's page on Ambisonics] contains articles on shelf filters and the design of Ambisonic decoders.<br />
<br />
[[Category:Developers stuff]]</div>J^https://wiki.xiph.org/index.php?title=Icecast_Server&diff=13113Icecast Server2011-11-13T16:11:38Z<p>J^: Reverted edits by Pamwoods (talk) to last revision by Dm8tbr</p>
<hr />
<div>'''Icecast''' is an open source multi-platform streaming server. It supports [[Ogg]] [[Vorbis]], Ogg [[Theora]], and [[MP3]].<br />
<br />
== External links ==<br />
<br />
* [http://www.icecast.org/ Icecast homepage]<br />
* [http://dir.xiph.org/index.php Stream directory]<br />
* [http://www.nabble.com/Icecast-f2880.html Icecast archive / forum] - an Icecast mailing list archive that combines both user and dev lists. It is hosted by [http://www.nabble.com/ Nabble]. You can search or browse Icecast discussions here.<br />
<br />
== Development ==<br />
<br />
*trunk http://svn.xiph.org/icecast/trunk/icecast<br />
*kh-branch http://svn.xiph.org/icecast/branches/kh/icecast<br />
**diff to trunk<br />
***fast pre-buffering aka burst-on-connect. <br>State a burst size in bytes to indicate how much should be sent at listener connect.<br />
***mp3 accepts artist and title separately on the url.<br />
***program invocation at stream start and end, per mount based.<br />
***on-demand relays, activated on first listener, disconnected when listenersfalls to 0. <br>Available for master relays as well.<br />
***multiple Ogg codec streaming. Current codecs handled are Theora, Vorbis, Speex, Writ.<br />
***Clients are started at theora key frame if theora is being streamed.<br />
***Added URL and command based listener authentication<br />
***server xml reload, and reopen logging available via admin url<br />
***slave startup re-organised so that relays are more independant<br />
***on xml reload, active sources are updated as well<br />
***When max-listeners reached, a HTTP 302 code can be sent to redirect clients to alternative slave hosts.<br />
***authenticated relays, those that match the relay user/pass, bypass the max-listener check<br />
<br />
== Wish List ==<br />
<br />
As good ideas are never a waste, and for tracking purposes, please list here all the features you're missing in icecast trunk.<br />
<br />
Note: please check that the feature you request is not already in trunk before posting !<br />
<br />
* Ponnies<br />
<br />
[[Category:Xiph-related Software]]</div>J^https://wiki.xiph.org/index.php?title=Icecast_Server&diff=12881Icecast Server2011-07-03T16:27:03Z<p>J^: Undo revision 12866 by WikiAdmin (talk)</p>
<hr />
<div>'''Icecast''' is an open source multi-platform streaming server. It supports [[Ogg]] [[Vorbis]], Ogg [[Theora]], and [[MP3]].<br />
<br />
== External links ==<br />
<br />
* [http://www.icecast.org/ Icecast homepage]<br />
* [http://dir.xiph.org/index.php Stream directory]<br />
* [http://www.OutdoorFountains.com Outdoor Fountains]- To find out and learn helpful tips in our outdoor living learning center.<br />
* [http://www.nabble.com/Icecast-f2880.html Icecast archive / forum] - an Icecast mailing list archive that combines both user and dev lists. It is hosted by [http://www.nabble.com/ Nabble]. You can search or browse Icecast discussions here.<br />
<br />
== Development ==<br />
<br />
*trunk http://svn.xiph.org/icecast/trunk/icecast<br />
*kh-branch http://svn.xiph.org/icecast/branches/kh/icecast<br />
**diff to trunk<br />
***fast pre-buffering aka burst-on-connect. <br>State a burst size in bytes to indicate how much should be sent at listener connect.<br />
***mp3 accepts artist and title separately on the url.<br />
***program invocation at stream start and end, per mount based.<br />
***on-demand relays, activated on first listener, disconnected when listenersfalls to 0. <br>Available for master relays as well.<br />
***multiple Ogg codec streaming. Current codecs handled are Theora, Vorbis, Speex, Writ.<br />
***Clients are started at theora key frame if theora is being streamed.<br />
***Added URL and command based listener authentication<br />
***server xml reload, and reopen logging available via admin url<br />
***slave startup re-organised so that relays are more independant<br />
***on xml reload, active sources are updated as well<br />
***When max-listeners reached, a HTTP 302 code can be sent to redirect clients to alternative slave hosts.<br />
***authenticated relays, those that match the relay user/pass, bypass the max-listener check<br />
<br />
== Wish List ==<br />
<br />
As good ideas are never a waste, and for tracking purposes, please list here all the features you're missing in icecast trunk.<br />
<br />
Note: please check that the feature you request is not already in trunk before posting !<br />
<br />
* Ponnies<br />
<br />
[[Category:Xiph-related Software]]</div>J^https://wiki.xiph.org/index.php?title=Icecast_Server&diff=12880Icecast Server2011-07-03T16:26:08Z<p>J^: Reverted edits by Jmorris14 (talk) to last revision by WikiAdmin</p>
<hr />
<div>'''Icecast''' is an open source multi-platform streaming server. It supports [[Ogg]] [[Vorbis]], Ogg [[Theora]], and [[MP3]].<br />
<br />
== External links ==<br />
<br />
* [http://www.icecast.org/ Icecast homepage]<br />
* [http://dir.xiph.org/index.php Stream directory]<br />
* [http://www.OutdoorFountains.com Outdoor Fountains]- To find out and learn helpful tips in our outdoor living learning center.<br />
* [http://www.shindiristudio.com/ Web Design]- To find out and learn helpful tips about web design.<br />
* [http://www.nabble.com/Icecast-f2880.html Icecast archive / forum] - an Icecast mailing list archive that combines both user and dev lists. It is hosted by [http://www.nabble.com/ Nabble]. You can search or browse Icecast discussions here.<br />
<br />
== Development ==<br />
<br />
*trunk http://svn.xiph.org/icecast/trunk/icecast<br />
*kh-branch http://svn.xiph.org/icecast/branches/kh/icecast<br />
**diff to trunk<br />
***fast pre-buffering aka burst-on-connect. <br>State a burst size in bytes to indicate how much should be sent at listener connect.<br />
***mp3 accepts artist and title separately on the url.<br />
***program invocation at stream start and end, per mount based.<br />
***on-demand relays, activated on first listener, disconnected when listenersfalls to 0. <br>Available for master relays as well.<br />
***multiple Ogg codec streaming. Current codecs handled are Theora, Vorbis, Speex, Writ.<br />
***Clients are started at theora key frame if theora is being streamed.<br />
***Added URL and command based listener authentication<br />
***server xml reload, and reopen logging available via admin url<br />
***slave startup re-organised so that relays are more independant<br />
***on xml reload, active sources are updated as well<br />
***When max-listeners reached, a HTTP 302 code can be sent to redirect clients to alternative slave hosts.<br />
***authenticated relays, those that match the relay user/pass, bypass the max-listener check<br />
<br />
== Wish List ==<br />
<br />
As good ideas are never a waste, and for tracking purposes, please list here all the features you're missing in icecast trunk.<br />
<br />
Note: please check that the feature you request is not already in trunk before posting !<br />
<br />
* Ponnies<br />
<br />
[[Category:Xiph-related Software]]</div>J^https://wiki.xiph.org/index.php?title=XiphWiki:Sandbox&diff=12879XiphWiki:Sandbox2011-07-03T16:25:02Z<p>J^: Reverted edits by WikiAdmin (talk) to last revision by Lucas gonze</p>
<hr />
<div>= Headline 1 =<br />
foo<br />
== Headline 2 ==<br />
=== Headline 3 ===<br />
=== Headline 4 ===<br />
{| border=2 cellpadding=10<br />
|+ '''Table test'''<br />
| x || 'One' || ''Two2'' || '''Three'''<br />
|-<br />
! what is this<br />
| 'yes' <br />
| ''no'' <br />
! maybe<br />
FooBar<br />
|-<br />
!<br />
{| border=1 cellpadding =2<br />
|+ for you<br />
| a<br />
| b<br />
| c<br />
|-<br />
| d || e|| f<br />
|}<br />
| 1 || 2 || 3<br />
|}<br />
<br />
This is a good test<br />
<br />
== Headline 5 ==<br />
<br />
* Item 1<br />
* Item 2<br />
* Item 3<br />
<br />
<br />
LoSSSSSSSSSSSSSSSSSSSSSSSSSSSSSStus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.<br />
<br />
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<br />
<br />
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.<br />
<br />
== Headline 2 ==<br />
Good goodess, don't you hate wiki spam?<br />
<br />
External link: [[http://google.com This is an external link]]<br />
<br />
Link to PortablePlayers page:[[PortablePlayers]]<br />
<br />
Using different value for the link text: [[PortablePlayers|link to page PortablePlayers]]<br />
<br />
Link to [[DummyApps]] sandbox<br />
<br />
== Headline 3 ==<br />
It seems that [[Talk:Sandbox]] is the canonical way to link to [[Talk:Sandbox|Talk]].<br />
<br />
Fun with tables and templates.<br />
{{PlayersTableHeader|ManufacturerLink=iAudio}}<br />
{{PlayersTableBody|Model=G3|MemType=Flash (builtin)<br />
|MemSize=256MB, 512MB, 1GB<br />
|UMS=Yes<br />
|NeedUpd=NA<br />
|Power=AA battery<br />
|LineIn=Yes<br />
|Mic=Yes<br />
|Radio=Yes<br />
|Formats= MP3, MP2, Ogg, WMA, ASF and WAV<br />
|Comments= Very white, available from online retailers in UK<br />
}}<br />
{{PlayersTableFooter}}<br />
<br />
== Subpages? ==<br />
[[Sandbox/Subpage]]</div>J^https://wiki.xiph.org/index.php?title=XSPF&diff=12878XSPF2011-07-03T16:25:00Z<p>J^: Reverted edits by WikiAdmin (talk) to last revision by Ph3-der-loewe</p>
<hr />
<div>'''XML Shareable Playlist Format''' ('''XSPF'''), pronounced "spiff", is a next-generation [http://en.wikipedia.org/wiki/playlist playlist] format for digital media such as songs in Vorbis or MP3 format. This wiki is for developers.<br />
<br />
The mime type for XSPF playlists is <tt>application/xspf+xml</tt>.<br />
<br />
Spec is at http://www.xspf.org/specs/<br />
<br />
== Supporting applications ==<br />
<br />
These are applications which support XSPF and have not yet been added to the [[http://xspf.org/applications][main applications list]].<br />
<br />
* [http://www.jamendo.com/ Jamendo]<br />
** You have to be a member and to select "XSPF" in your preferences to use them by default, but you can look and test a sample playlist here: http://www.jamendo.com/get/track/id/album/audio/xspf/1003/?aue=ogg2<br />
* http://www.ArtistServer.com<br />
** on artist profile pages http://www.artistserver.com/bliss<br />
** on stations and playlists http://www.artistserver.com/stations/<br />
** on genre pages http://www.artistserver.com/DownTempo<br />
* Project Opus http://projectopus.com<br />
** see http://www.projectopus.com/new-player for details<br />
** includes modified version of Fabricio's player<br />
<br />
"We added: A Scrubber/Shuttle so the lister can move the playhead to any point along the song. Time Remaining, Elapsed Time Played, Genre of Song, Origin/Location (city) of artist. Site specific stuff which my not be of interest to others is: Review song link: we were adding as a layer to the player but, it got too large and ugly. Buy song link. And a bunch of nice styling/skin tweaks."<br />
<br />
* trend of XSLT for xspf to html example<br />
** http://dokerlund.edhsweb.org/wordpress/archives/23 is announce<br />
** http://dokerlund.edhsweb.org/wordpress/xspf/media/playlist.xml is in practice<br />
* Zuardi player modified to support FLV and SWF as well as mp3: http://blitz-xplore.blogspot.com/2006/05/file-xspfplayer.html<br />
<br />
== Limited supporting applications ==<br />
* foo_xspf - writes xspf files only with location. So the goal of playlist sharing between friends is not achieved.<br />
* [http://roaraudio.keep-cool.org/rpld.html RoarAudio PlayList Daemon] - no read support yet.<br />
<br />
== Non supporting applications listed as supporting ==<br />
* http://php4xspf.berlios.de/ - From their page: Note: The classes are stil in alpha and do not incorporate ... even the possibility to parse a XSPF file.<br />
<br />
== See also ==<br />
<br />
* [[XSPF FAQ]]<br />
* [[XSPF v1 Notes and Errata]]<br />
* '''[[XSPF Year 2009]]'''<br />
* [[XSPF Conformance Tests]]<br />
* [[XSPF Wish List]]<br />
* [[XSPF Examples in the wild]]<br />
* [[List of known XSPF extensions]]<br />
* [[List of known XSPF metas]]<br />
* [[JSPF Draft|JSPF]] (''JSON Sharable Playlist Format'' a.k.a. ''XSPF on JSON'')<br />
<br />
== External links ==<br />
<br />
* [http://xspf.org/xspf-v1.html XSPF specification]<br />
* [http://validator.xspf.org/ Online XSPF Validator]<br />
* [https://trac.xiph.org/browser/websites/xspf.org/images/banners "Valid XSPF" button]<br />
* [https://trac.xiph.org/browser/trunk/xspf/ Source control for source code, spec, XSLT, validation]<br />
* [https://trac.xiph.org/browser/websites/xspf.org/ Source control for XSPF.org website]<br />
* [http://downloads.xiph.org/releases/xspf/ XSPF-related releases]<br />
* [http://gonze.com/playlists/playlist-format-survey.html A survey of playlist formats], by Lucas Gonze<br />
* [http://en.wikipedia.org/wiki/XSPF XSPF Reference page on Wikipedia]<br />
* [http://web.archive.org/web/20060410160006/http://playlist.musicbrainz.org/playlist/moin.cgi/ Old XSPF wiki]<br />
<br />
[[Category:XSPF]]</div>J^https://wiki.xiph.org/index.php?title=CMML&diff=12877CMML2011-07-03T16:24:59Z<p>J^: Reverted edits by WikiAdmin (talk) to last revision by Saoshyant</p>
<hr />
<div>'''CMML''' stands for <b>Continuous Media Markup Language</b> and is to audio or video what HTML is to text. CMML is essentially a timed text codec. It allows to structure a time-continuously sampled data file by dividing it into temporal sections (so-called <i>clips</i>) and provides these clips with some additional information. This information is HTML-like and is essentially a textual representation of the audio or video file. CMML enables textual searches on these otherwise binary files.<br />
<br />
CMML is appropriate for use with all [[Ogg]] media formats, to provide subtitles and timed metadata. This description gives a quick introduction only and explains how to map CMML into Ogg. For full specifications, see [http://www.annodex.net/specifications.html http://www.annodex.net/specifications.html].<br />
<br />
<br />
== CMML specification ==<br />
<br />
Before describing the actual data that goes into a logical Ogg bitstream, we need to understand what the stand-alone "codec" packets contains.<br />
<br />
CMML basically consists of:<br />
<br />
* a <b>head</b> tag which contains information for the complete audio/video file<br />
* a set of <b>clip</b> tags which each contains information on a temporal section of the file<br />
* for authoring purposes, CMML also allows a <b>stream</b> tag which spcifies the file it describes<br />
<br />
An example CMML file looks like this:<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><br />
<!DOCTYPE cmml SYSTEM "cmml.dtd"><br />
<br />
<cmml lang="en" id="simple" granulerate="1000/1"><br />
<br />
<stream id="fish" basetime="0"><br />
<import id="videosrc" lang="en" title="Video fish" <br />
granulerate="25/1" contenttype="video/ogg" <br />
src="fish.ogv" start="0" end="360"><br />
<param id="vheight" name="video.height" value="250"/><br />
<param id="vwidth" name="video.width" value="180"/><br />
</import><br />
</stream><br />
<br />
<head><br />
<title>Types of fish</title><br />
<meta name="Producer" content="Joe Ordinary"/><br />
<meta name="DC.Author" content="Joe's friend"/><br />
</head><br />
<br />
<clip id="intro" start="0"><br />
<a href="http://www.example.com/fish.html">Read more about fish</a><br />
<desc>This is the introduction to the film Joe made about fish.</desc><br />
</clip><br />
<br />
<clip id="dolphin" start="npt:3.5" end="npt:5:5.9"><br />
<img src="dolphin.jpg"/><br />
<desc>Here, Joe caught sight of a dolphin in the ocean.</desc><br />
<meta name="Subject" content="dolphin"/><br />
</clip><br />
<br />
<clip id="goldfish" start="npt:5:5.9"><br />
<a href="http://www.example.com/morefish.anx?id=goldfish">More video clips on goldfish.</a><br />
<img src="http://www.example.com/goldfish.jpg"/><br />
<desc>Joe has a fishtank at home with many colourful fish. The common goldfish is one of them and Joe's favourite.<br />
Here are some fabulous pictures he has taken of them.</desc><br />
<meta name="Location" content="Joe's fishtank"/><br />
<meta name="Subject" content="goldfish"/><br />
</clip><br />
<br />
</cmml><br />
</pre><br />
<br />
<br />
The head element is a standard head element from html.<br />
<br />
Clips contain (amongst others) the following information:<br />
<br />
* a name in the <b>id</b> attribute so addressing of the clips is possible, as in http://www.example.com/morefish.anx?id=goldfish (Web server needs to [http://annodex.net/software/mod_annodex/ support] this)<br />
* a <b>start</b> and possibly an <b>end</b> attribute, to tell the clip where it is temporally located<br />
* a <b>title</b> attribute to give it a short description<br />
* <b>meta</b> elements to provide it with structed meta data as name-value pairs<br />
* a <b>img</b> element which links to a picture that represents the content of the clip visually<br />
* a <b>a</b> element which puts a hyperlink to another Web resource into the clip<br />
* a <b>desc</b> element giving a long, free-text description/annotation/transcription for the clip<br />
<br />
Most of this information is optional.<br />
<br />
== CMML mapping into Ogg ==<br />
<br />
When CMML is mapped into an Ogg logical bitstream it needs to be serialised first. XML is a hierarchical file format, so is not generally serialisable. However, CMML has been designed to be serialised easily.<br />
<br />
CMML is serialised by having some initial header packets that set up the CMML decoding environment, and contain header type information. The content packets of a CMML logical bitstream then consists of <b>clip</b> tags only. The <b>stream</b> tag is not copied into the CMML bitstream as it controls the authoring only.<br />
<br />
All of the CMML bitstream information is text. As it gets encoded into a binary bitstream, an encoding format has to be specified. To simplify things, UTF-8 is defined as the mandatory encoding format for all data in a CMML binary bitstream. Also, the encoding process MUST ensure that newline characters are represented as LF (or "\n" in C) only and replace any new line representations that come as CR LF combinations (or "\r\n" in C) with LF only.<br />
<br />
The media mapping for CMML into Ogg is as follows:<br />
* The bos page contains a CMML ident packet.<br />
* The first secondary header packet of CMML contains the xml preamble.<br />
* The second secondary header packet contains the CMML "head" tag.<br />
* The content or data packets for CMML contain the CMML "clip" tags each encoded in their own packet and inserted at the accurate time.<br />
* The eos page contains a packet with an empty clip tag.<br />
<br />
<br />
=== The CMML ident header packet ===<br />
<br />
The CMML logical bitstream starts with an ident header which is encapsulated into the CMML bos page. The ident header contains all information required to identify the CMML bitstream and to set up a CMML decoder. It has the following format:<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Identifier 'CMML\0\0\0\0' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Version major | Version minor | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granulerate numerator | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granulerate denominator | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granuleshift | 28<br />
+-+-+-+-+-+-+-+-+<br />
| ...<br />
<br />
The CMML <i>version</i> as described here is major=2 minor=1.<br />
<br />
The <i>granulerate</i> represents the temporal resolution of the logical bitstream in Hz given as a rational number in the same way as the [[OggSkeleton]] fisbone secondary header specifies granulerate. It enables a mapping of granule position of the data pages to time by calculating "granulepos / granulerate".<br />
<br />
The default granule rate for CMML is: 1/1000.<br />
<br />
The <i>granuleshift</i> is a 1 Byte integer number describing whether to partition the granule_position into two for the CMML logical bitstream, and how many of the lower bits to use for the partitioning. The upper bits then still signify a time-continuous granule position for a directly decodable and presentable data granule. The lower bits allow for specification of the granule position of a previous CMML data packet (i.e. "clip" element), which helps to identify how much backwards seeking is necessary to get to the last and still active "clip" element (of the given track). The granuleshift is therefore the log of the maximum possible clip spacing.<br />
<br />
The default granule shift used is 32, which halfs the granule position to allow for the backwards pointer.<br />
<br />
=== The CMML secondary header packets ===<br />
<br />
The CMML secondary headers are a sequence of two packets that contain the CMML and XML "setup" information:<br />
* one packet with the CMML xml preamble and <b>cmml</b> tag.<br />
* one packet with the CMML <b>head</b> tag.<br />
<br />
These packets contain textual, not binary information.<br />
<br />
The CMML preamble tags are all single-line tags, such as the xml processing instruction (<?xml...>) and the document type declaration (<!DOCTYPE...>).<br />
<br />
The only CMML tag that is not already serialized from a CMML file is the <b>cmml</b> tag, as it encloses all the other content tags. To serialise it, the <b>cmml</b> start tag is transformed into a processing instruction, retaining all its attributes (<?cmml ...>), and the <b>cmml</b> end tag is deleted.<br />
<br />
The first CMML secondary header packet has the following format:<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <?xml ... | 0-<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <!DOCTYPE ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <?cmml ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
The second CMML secondary header packet contains the CMML <b>head</b> element with all its attributes and other containing elements and has the following format.<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <head ... | 0-<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| </head> |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
=== The CMML data packets ===<br />
<br />
The data packets of the CMML bitstream contain the CMML <b>clip</b> elements. Their <b>start</b> and <b>end</b> attributes however only exist for authoring purposes and are not copied into the bitstream (to avoid contradictory information), but are rather represented through the time mapping of the encapsulation format that interleaves CMML data with data from other time-continuous bitstreams. Generally the time mapping is done through some timestamp representation and through the position in the stream.<br />
<br />
A <b>clip</b> tag is encoded with all tags (except for the <b>start</b> and <b>end</b> attributes) as a string printed into a clip packet. The <b>clip</b> tag's <b>start</b> attribute tells the encapsulator at what time to insert the clip packet into the bitstream. If an <b>end</b> attribute is present, it leads to the creation of another clip packet, unless another clip packet starts on the same track beforehand. This clip packet contains an "empty" <b>clip</b> tag, i.e. a <b>clip</b> tag without <b>meta</b>, <b>a</b>, <b>img</b> or <b>desc</b> elements and no attribute values except for a copy of the <b>track</b> attribute from the original <b>clip</b> tag.<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <clip ... | 0-<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| </clip> |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
== Development ==<br />
<br />
Ogg CMML is being supported by the following projects:<br />
* the Ogg Directshow filters: see [http://www.illiminable.com/ogg/ illiminable]<br />
* liboggz: [http://svn.annodex.net/liboggz/ liboggz svn] or [http://annodex.net/software/liboggz/ liboggz]<br />
* libcmml: [http://svn.annodex.net/libcmml/ libcmml svn] or [http://annodex.net/software/libcmml/ libcmml]<br />
* libannodex: [http://svn.annodex.net/libannodex/ libannodex svn] or [http://annodex.net/software/libannodex/ libannodex]<br />
* the Annodex technology: [http://www.annodex.net/ annodex.net] including perl, python, php bindings, a firefox plugin, authoring software etc.<br />
<br />
<br />
== External links ==<br />
<br />
* CMML is described in more detail in the CMML v2.1 specification: [http://svn.annodex.net/standards/ I-D in svn] or [http://annodex.net/specifications.html I-D]<br />
<br />
[[Category:Ogg Mappings]]</div>J^https://wiki.xiph.org/index.php?title=OggKate&diff=12876OggKate2011-07-03T16:24:34Z<p>J^: Reverted edits by WikiAdmin (talk) to last revision by Ogg.k.ogg.k</p>
<hr />
<div>== Disclaimer ==<br />
This is not a Xiph codec, though it may be embedded in Ogg alonside other Xiph<br />
codecs, such as Vorbis and Theora. As such, please do not assume that Xiph has<br />
anything to do with this, much less responsibility.<br />
<br />
== What is Kate? ==<br />
<br />
Kate is an overlay codec, originally designed for karaoke and text, that can be<br />
multiplixed in Ogg. Text and images can be carried by a Kate stream, and animated.<br />
Most of the time, this would be multiplexed with audio/video to carry subtitles,<br />
song lyrics (with or without karaoke data), etc, but doesn't have to be.<br />
<br />
Series of curves (splines, segments, etc) may be attached to various properties<br />
(text position, font size, etc) to create animated overlays. This allows scrolling<br />
or fading text to be defined. This can even be used to draw arbitrary shapes, so<br />
hand drawing can also be represented by a Kate stream.<br />
<br />
Example uses of Kate streams are movie subtitles for Theora videos, either text based,<br />
as may be created by [http://www.v2v.cc/~j/ffmpeg2theora ffmpeg2theora], or image<br />
based, such as created by [http://thoggen.net Thoggen] (patching needed), and lyrics,<br />
as created by oggenc, from vorbis-tools.<br />
<br />
== Why a new codec? ==<br />
<br />
As I was adding support for Theora, Speex and FLAC to some software of mine, I found myself<br />
wanting to have song lyrics accompanying Vorbis audio. Since Vorbis comments are limited to<br />
the headers, one can't add them in the stream as they are sung, so another multiplexed stream<br />
would be needed to carry them.<br />
<br />
The three possible bases usable for such a codec I found were Writ, CMML, and OGM/SRT.<br />
<br />
*[[OggWrit|Writ]] is an unmaintained start at an implementation of a very basic design, though I did find an encoder/decoder in py-ogg2 later on - I'd been quicker to write Kate from scratch anyway.<br />
*[[CMML]] is more geared towards encapsulating metadata about an accompanying stream, rather than being a data stream itself, and seemed complex for a simple use, though I have now revised my view on this - besides, it seems designed for Annodex (which I haven't had a look at), though it does seems relatively generic for use outwith Annodex - though it is being "repurposed" as timed text now, bringing it closer to what I'm doing<br />
*OGM/SRT, which I only found when I added Kate support to MPlayer, is shoehorning various data formats into an Ogg stream, and just dumps the SRT subtitle format as is, AFAICS (though I haven't looked at this one in detail, since I'd already had a working Kate implementation by that time)<br />
<br />
I then decided to roll my own, not least because it's a fun thing to do.<br />
<br />
I found other formats, such as USF (designed for inclusion in Matroska) and various subtitle formats,<br />
but none were designed for embedding inside an Ogg container.<br />
<br />
== Overview of the Kate bitstream format ==<br />
<br />
I've taken much inspiration from Vorbis and Theora here.<br />
Headers and packets (as well as the API design) follow the design of these two codecs.<br />
<br />
A rough overview (see [[#Format specification|Format specification]] for more details) is:<br />
<br />
Headers packets:<br />
*ID header [BOS]: magic, version, granule fraction, encoding, language, etc<br />
*Comment header: Vorbis comments, as per Vorbis/Theora streams<br />
*Style definitions header: a list of predefined styles to be referred to by data packets<br />
*Region definitions header: a list of predefined regions to be referred to by data packets<br />
*Curves definitions header: a list of predefined curves to be referred to by data packets<br />
*Motion definitions header: a list of predefined motions to be referred to by data packets<br />
*Palette definitions header: a list of predefined palettes to be referred to by data packets<br />
*Bitmap definitions header: a list of predefined bitmaps to be referred to by data packets<br />
*Font mapping definitions header: a list of predefined font mappings to be referred to by data packets<br />
<br />
Other header packets are ignored, and left for future expansion.<br />
<br />
Data packets:<br />
*text data: text/image and optional motions, accompanied by optional overrides for style, region, language, etc<br />
*keepalive: can be emitted at any time to help a demuxer know where we're at, but those packets are optional<br />
*repeats: a verbatim repeat of a text packet's payload, in order to bound any backward seeking needed when starting to play a stream partway through. These are also optional.<br />
*end data [EOS]: marks the end of the stream, it doesn't have any useful payload<br />
<br />
Other data packets are ignored, and left for future expansion.<br />
<br />
The intent of the "keepalive" packet is to be sent at regular<br />
intervals when no other packet has been emitted for a while. This would be to help seeking code<br />
find a kate page more easily.<br />
<br />
Things of note:<br />
*Kate is a discontinuous codec, as defined in [http://www.xiph.org/ogg/doc/ogg-multiplex.html ogg-multiplex.html] in the Ogg documentation, which means it's timed by start granule, not end granule (as Theora and Vorbis).<br />
* All data packets are on their own page, for two reasons:<br />
**Ogg keeps track of granules at the page level, not the packet level<br />
**if no text event happens for a while after a particular text event, we don't want to delay it so a larger page can be issued<br />
<br />
See also [[#Seeking and memory|Problems to solve: Seeking and memory]].<br />
<br />
*The granule encoding is not a direct time/granule correspondance, see the granule encoding section.<br />
*The EOS packet should have a granule pos higher or equal to the end time of all events.<br />
*User code doesn't have to know the number of headers to expect, this is moved inside the library code (as opposed to Vorbis and Theora).<br />
*The format contains hooks so that additional information may be added in future revisions while keeping backward compatibility (though old decoders will correctly parse, but ignore the new information).<br />
<br />
== Format specification ==<br />
<br />
The Kate bitstream format consists of a number of sequential packets.<br />
Packets can be either header packets or data packets. All header packets<br />
must appear before any data packet.<br />
<br />
Header packets must appear in order. Decoding of a data packet is not<br />
possible until all header packets have been decoded.<br />
<br />
Each Kate packet starts with a one byte type. A type with the MSB set<br />
(eg, between 0x80 and 0xff) indicates a header packet, while a type with<br />
the MSB cleared (eg, between 0x00 and 0x7f) indicates a data packet.<br />
All header packets then have the Kate magic, from byte offset 1 to byte<br />
offset 7 ("kate\0\0\0"). Note that this applies only to header packets:<br />
data packets do not contain the Kate signature.<br />
<br />
Since the ID header must appear first, a Kate stream can be recognized<br />
by comparing the first eight bytes of the first packet with the signature<br />
string "\200kate\0\0\0".<br />
<br />
<br />
When embedded in Ogg,the first packet in a Kate stream (always packet type 0x80,<br />
the id header packet) must be placed on a separate page. The corresponding Ogg<br />
packet must be marked as beginning of stream (BOS).All subsequent header packets<br />
must be on one or more pages. Subsequently, each data packet must be on a separate<br />
page.<br />
<br />
The last data packet must be the end of stream packet (packet type 0x7f).<br />
<br />
When embedded in Ogg, the corresponding Ogg packet must be marked as end of stream (EOS).<br />
<br />
As per the Ogg specification, granule positions must be non decreasing<br />
within the stream. Header packets have granule position 0.<br />
<br />
Currently existing packet types are:<br />
:headers:<br />
::0x80 ID header (BOS)<br />
::0x81 Vorbis comment header<br />
::0x82 regions list header<br />
::0x83 styles list header<br />
::0x84 curves list header<br />
::0x85 motions list header<br />
::0x86 palettes list header<br />
::0x87 bitmaps list header<br />
::0x88 font ranges and mappings header<br />
:data:<br />
::0x00 text data (including optional motions and overrides)<br />
::0x01 keepalive<br />
::0x02 repeat<br />
::0x7f end packet (EOS)<br />
<br />
<br />
<br />
This format described here is for bitstream version 0.x.<br />
As or 19 december 2008, the latest bitstream version is 0.4.<br />
<br />
For more detailed information, refer to the format documentation<br />
in libkate (see URL below in the [[#Downloading|Downlading]] section).<br />
<br />
Following is the definition of the ID header (packet type 0x80).<br />
This works out to a 64 byte ID header. This is the header that should be<br />
used to detect a Kate stream within an Ogg stream.<br />
<br />
<br />
<br />
0 1 2 3 |<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| packtype | Identifier char[7]: 'kate\0\0\0' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| kate magic continued | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved - 0 | version major | version minor | num headers | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| text encoding | directionality| reserved - 0 | granule shift | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| cw sh | canvas width | ch sh | canvas height | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved - 0 | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| granule rate numerator | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| granule rate denominator | 28-31<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (NUL terminated) | 32-35<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 36-39<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 40-43<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 44-47<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (NUL terminated) | 48-51<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 52-55<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 56-59<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 60-63<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
<br />
The fields cw sh, canvas width, cw sh, and canvas height were introduced<br />
in bistream 0.3. Earlier bitstreams will have 0 in these fields.<br />
<br />
language and category are NUL terminating ASCII strings.<br />
Language follows RFC 3066, though obviously will not accommodate language tags<br />
with lots of subtags.<br />
<br />
Category is currently loosely defined, and I haven't found yet a nice way to<br />
present it in a generic way, but is meant for automatic classifying of<br />
various multiplexed Kate streams (eg, to recognize that some streams are<br />
subtitles (in a set of languages), and some others are commentary (in a<br />
possibly different set of languages, etc).<br />
<br />
== API overview ==<br />
<br />
libkate offers an API very similar to that of libvorbis and libtheora, as well as<br />
an extra higher level decoding API.<br />
<br />
Here's an overview of the three main modules:<br />
<br />
=== Decoding ===<br />
<br />
Decoding is done in a way similar to libvorbis. First, initialize a kate_info and a<br />
kate_comment structure. Then, read headers by calling kate_decode_headerin. Once<br />
all headers have been read, a kate_state is initialized for decoding using kate_decode_init,<br />
and kate_decode_packetin is called repeatedly with data packets. Events (eg, text) can be<br />
retrieved via kate_decode_eventout.<br />
<br />
=== Encoding ===<br />
<br />
Encoding is also done in a way similar to libvorbis. First initialize a kate_info<br />
and a kate_comment structure, and fill them out as needed. kate_encode_headers will<br />
create ogg packets from those. Then, kate_encode_text is called repeatedly for all<br />
the text events to add. When done, calling kate_encode_finish will create an end of<br />
stream packet.<br />
<br />
=== High level decoding API ===<br />
<br />
There are only 3 calls here:<br />
<br />
kate_high_decode_init<br />
kate_high_decode_packetin<br />
kate_high_decode_clear<br />
<br />
Here, all Ogg packets are sent to kate_high_decode_packetin, which does the right<br />
thing (header/data classification, decoding, and event retrieval). Note that you<br />
do not get access to the comments directly using this, but you do get access to the<br />
kate_info via events.<br />
<br />
The libkate distribution includes commented examples for each of those.<br />
<br />
Additionally, libkate includes a layer (liboggkate) to make it easier to use when<br />
embedded in Ogg. While the normal API uses kate_packet structures, liboggkate uses<br />
ogg_packet structures.<br />
<br />
The High level decoding API does not have an Ogg specific layer, but functions exist<br />
to wrap a kate_packet around a memory buffer (such as the one ogg_packet uses, for instance).<br />
<br />
== Support ==<br />
<br />
Among the software with Kate support:<br />
*VLC<br />
*ffmpeg2theora<br />
*liboggz<br />
*liboggplay<br />
*Cortado (wikimedia version)<br />
*vorbis-tools<br />
<br />
I have patches for the following with Kate support:<br />
*MPlayer<br />
*xine<br />
*GStreamer<br />
*Thoggen<br />
*Audacious<br />
*and more...<br />
<br />
These may be found in the libkate source distribution (see [[#Downloading|Downloading]]<br />
for links).<br />
<br />
In addition, libtiger is a rendering library for Kate streams using Pango and Cairo,<br />
though it is not quite yet API stable (though no major changes are expected).<br />
<br />
== Granule encoding ==<br />
<br />
=== Ogg ===<br />
<br />
Ogg leaves the encoding of granules up to a particular codec, only<br />
mandating that granules be non decreasing with time.<br />
<br />
The Kate bitstream format uses a linear mapping between time and<br />
granule, described here.<br />
<br />
A Kate granule position is composed of two different parts:<br />
- a base granule, in the high bits<br />
- a granule offset, in the low bits<br />
<br />
+----------------+----------------+<br />
| base | offset |<br />
+----------------+----------------+<br />
<br />
The number of bits these parts occupy is variable, and each stream<br />
may choose how many bits to dedicate to each. The kate_info structure<br />
for a stream holds that information in the granule_shift field,<br />
so each part may be reconstructed from a granulepos.<br />
<br />
The timestamp T of a given Kate packet is split into a base B and<br />
offset O, and these are stored in the granulepos of that packet.<br />
The split is done such that the B is the time of the earliest event<br />
still active at the time, and the O is the time elapsed between B<br />
and T. Thus, T = B + O. This mimics the way Theora stores its own<br />
timestamps in granulepos, where the base acts as a keyframe, and<br />
an offset acts as the position of an intra frame from the previous<br />
keyframe. Since Kate allows time overlapping events, however, the<br />
choice of the base to use is slightly more complex, as it may not<br />
be the starting time of the previous event, if the stream contains<br />
time overlapping events.<br />
<br />
The kate_info structure for a stream holds a rational fraction<br />
representing the time span of granule units for both the base and<br />
the offset parts.<br />
<br />
The granule rate is defined by the two fields:<br />
<br />
kate_info::gps_numerator<br />
kate_info::gps_denominator<br />
<br />
<br />
The number of bits reserved for the offset is defined by the field:<br />
<br />
kate_info::granule_shift<br />
<br />
=== Generic timing ===<br />
<br />
Kate data packets (data packet type 0) includes timing information (start time,<br />
end time, and time of the earliest event still active). All these are stored as<br />
64 bit at the rate defined by the granule rate, so they do not suffer from the<br />
granule_shift space limitation.<br />
<br />
This also allows for Kate streams to be stored in other containers.<br />
<br />
== Motion ==<br />
<br />
The Kate bitstream format includes motion definition, originally for karaoke purposes, but<br />
which can be used for more general purpose, such as line based drawing, or animation of<br />
the text (position, color, etc)<br />
<br />
Motions are defined by the means of a series of curves (static points, segments, splines (catmull-rom, bezier, and b-splines)).<br />
A 2D point can be obtained from a motion for any timestamp during the lifetime of a text.<br />
This can be used for moving a marker in 2D above the text for karaoke, or to use the x<br />
coordinate to color text when the motion position passes each letter or word, etc.<br />
Motions have an attached semantics so the client code knows how to use a particular motion.<br />
Predefined semantics include text color, text position, etc).<br />
<br />
Since a motion can be composed of an arbitrary number of curves, each of which may have<br />
an arbitrary number of control points, complex motions can be achieved. If the motion is<br />
the main object of an event, it is even possible to have an empty text, and use the motion<br />
as a virtual pencil to draw arbitrary shapes. Even on-the-fly handwriting subtitles could<br />
be done this way, though this would require a lot of control points, and would not be able<br />
to be used with text-to-speech.<br />
<br />
As a proof of concept, I also have a "draw chat" program where two people can draw, and<br />
the shapes are turned to b-splines and sent as a kate motion to be displayed on the other<br />
person's window.<br />
<br />
It is also possible for motions to be discontinuous - simply insert a curve of 'none' type.<br />
While the timestamp lies within such a curve, no 2D point will be generated. This can be<br />
used to temporarily hide a marker, for instance.<br />
<br />
It is worth mentionning that pauses in the motion can be trivially included by inserting<br />
at the right time and for the right duration a simple linear interpolation curve with only<br />
two equal points, equal to the position the motion is supposed to pause at.<br />
<br />
Kate defines a set of predefined mappings so that each decoder user interprets a motion in<br />
the same way. A mapping is coded on 8 bits in the bitstream, and the first 128 are reserved<br />
for Kate, leaving 128 for application specific mappings, to avoid constraining creative uses<br />
of that feature. Predefined mappings include frame (eg, 0-1 points are mapped to the size of<br />
the current video frame), or region, to scale 0-1 to the current region. This allows curves<br />
to be defined without knowing in advance the pixel size of the area it should cover.<br />
<br />
For uses which require more than two coordinates (eg, text color, where 4 (RGBA) values are<br />
needed, Kate predefines the semantics text_color_rg and text_color_ba, so a 4D point can be<br />
obtained using two different motions.<br />
<br />
There are higher level constructs, such as morphing between two styles, or predefined<br />
karaoke effects. More are planned to be added in the future.<br />
<br />
See also [[#Trackers|Trackers]].<br />
<br />
== Trackers ==<br />
<br />
Since attaching motions to text position, etc, makes it hard for the client to keep track of<br />
everything, doing interpolation, etc, the library supplies a tracker object, which handles the<br />
interpolation of the relevant properties.<br />
Once initialized with a text and a set of motions, the client code can give the tracker a new<br />
timestamp, and get back the current text position, text color, etc.<br />
<br />
Using a tracker is not necessary, if one wants to use the motions directly, or just ignore them,<br />
but it makes life easier, especially when considering the the order in which motions are applied<br />
does matter (to be defined formally, but the current source code is informative at this point).<br />
<br />
<br />
== The Kate file format ==<br />
<br />
Though this is not a feature of the bitstream format, I have created a text file format to<br />
describe a series of events to be turned into a Kate bitstream.<br />
At its minimum, the following is a valid input to the encoder:<br />
<br />
: kate {<br />
:: event { 00:00:05 --> 00:00:10 "This is a text" }<br />
: }<br />
<br />
This will create a simple stream with "This is a text" emitted at an offset of 5 seconds into<br />
the track, lasting 5 seconds to an end time at 10 seconds.<br />
<br />
Motions, regions, styles can be declared in a definitions block to be reused by events, or can<br />
be defined inline. Defining those in the definitions block places them in a header so they can<br />
be reused later, saving space. However, they can also be defined in each event, so they will be<br />
sent with the event. This allows them to be generated on the fly (eg, if the bitstream is being<br />
streamed from a realtime input).<br />
<br />
For convenience, the Kate file format also allows C style macros, though without parameters.<br />
<br />
Please note that the Kate file format is fully separate from the Kate bitstream format. The<br />
difference between the two is similar to the difference between a C source file and the resulting<br />
object file, when compiled.<br />
<br />
Note that the format is not based on XML for a very parochial reason: I tend to dislike very<br />
much editing XML by hand, as it's really hard to read. XML is really meant for machines to parse<br />
generically text data in a shared syntax but with possibly unknown semantics, and I need those<br />
text representations to be editable easily.<br />
<br />
This also implies that there could be an XML representation of a Kate stream, which would be<br />
useful if one were to make an editor that worked on a higher level than the current all-text<br />
representation, and it is something that might very well happen in the future, in parallel with<br />
the current format.<br />
<br />
== Karaoke ==<br />
<br />
Karaoke effects rely on motions, and there will be predefined higher level ways of specifying<br />
timings and effects, two of which are already done. As an example, this is a valid Karaoke script:<br />
<br />
:kate {<br />
:: simple_timed_glyph_style_morph {<br />
::: from style "start_style" to style "end_style"<br />
::: "Let " at 1.0<br />
::: "us " at 1.2<br />
::: "sing " at 1.4<br />
::: "to" at 2.0<br />
::: "ge" at 2.5<br />
::: "ther" at 3.0<br />
:: }<br />
:}<br />
<br />
The syllables will change from a style to another as time passes. The definition of the start_style<br />
and end_style styles is omitted for brevity.<br />
<br />
<br />
== Problems to solve ==<br />
<br />
There are a few things to solve before the Kate bitstream format can be considered good<br />
enough to be frozen:<br />
<br />
Note: the following is mostly solved, and the bitstream is now stable, and has been<br />
backward and forward compatible since the first released version. This will be updated<br />
when I get some time.<br />
<br />
=== Seeking and memory ===<br />
<br />
When seeking to a particular time in a movie with subtitles, we may end up at a place when a subtitle has been started, but is not removed yet. Pure streaming doesn't have this problem as it remembers the subtitle being issued (as opposed to, say, Vorbis, for which all data valid now is decoded from the last packet). With Kate, a text string valid now may have been issued long ago.<br />
<br />
I see three possible ways to solve this:<br />
*each data packet includes the granule of the earliest still active packet (if none, this will be the granule of this very packet)<br />
**this means seeks are two phased: first seek, find the next Kate packet, and seek again if the granule of the earlier still active packet is less than the original seeked granule. This implies support code on players to do the double seek.<br />
<br />
*use "reference frames", a bit like Theora does, where the granule position is split in several fields: the higher bits represent a position for the reference frame, and the lowest bits a delta time to the current position. When seeking to a granule position, the lower bits are cleared off, yielding the granule position of the previous reference frame, so the seek ends up at the reference frame. The reference frame is a sync point where any active strings are issued again. This is a variant of the method described in the Writ wiki page, but the granule splitting avoids any "downtime".<br />
**this requires reissuing packets, and it doesn't feel right (and wastes space).<br />
**it also requires "dummy" decoding of Kate data from the reference frame to the actual seek point to fully refresh the state "memory".<br />
<br />
*A variant of the two-granules-in-one system used by libcmml, where the "back link" points to the earliest still active string, rather than the previous one (this allows a two phase seek, rather than a multiphase seek, hopping back from event to event, with no real way to know if there is or not a previous event which is still active - I suppose CMML has no need to know this, if their "clips" do not overlap - mine can do).<br />
**Such a system considerably shortens the usable granule space, though it can do a one phase seek, if I understand the system correctly, which I am not certain.<br />
*** Well, it seems it can't do a one phase seek anyway.<br />
<br />
*Additionally, it could be possible to emit simple "keepalive" packets at regular intervals to help a seek algorithm to sync up to the stream without needing too much data reading - this helps for discontinuous streams where there could be no pages for a while if no data is needed at that time.<br />
<br />
=== Text encoding ===<br />
<br />
A header field declares the text encoding used in the stream. At the moment, only UTF-8 is<br />
supported, for simplicity. There are no plans to support other encodings, such as UTF-16,<br />
at the moment.<br />
<br />
Note that strings included in the header (language, category) are not affected by that<br />
language encoding (rather obviously for language itself). These are ASCII.<br />
<br />
The actual text in events may include simple HTML-like markup (at the moment, allowed markup<br />
is the same as the one Pango uses, but more markup types may be defined in the future).<br />
It is also possible to ask libkate to remove this markup if the client prefers to receive<br />
plain text without the markup.<br />
<br />
=== Language encoding ===<br />
<br />
A header field defines the language (if any) used in the stream (this can be overridden in a<br />
data packet, but this is not relevant to this point). At the moment, my test code uses<br />
ISO 639-1 two letter codes, but I originally thought to use RFC 3066 tags. However, matching<br />
a language to a user selection may be simpler for user code if the language encoding is kept<br />
simple. At the moment, I tend to favor allowing both two letter tags (eg, "en") and secondary<br />
tags (like "en_EN"), as RFC 3066 tags can be quite complex, but I welcome comments on this.<br />
<br />
If a stream contains more than one language, there usually is a predominant language, which<br />
can be set as the default language for the stream. Each event can then have a language<br />
override. If there is no predominant language, and it is not possible to split the stream<br />
into multiple substreams, each with its own language, then it is possible to use the "mul"<br />
language tag, as a last resort.<br />
<br />
=== Bitstream format for floating point values ===<br />
<br />
Floating point values are be turned to a 16.16 fixed point format, then stored in a bitpacked<br />
format, storing the number of zero bits at the head and tail of the floating point values once<br />
per stream, and the remainder bits for all values in the stream. This seems to yield good results<br />
(typically a 50% reduction over 32 bits raw writes, and 70% over the snprintf based storage), and<br />
has the big advantage of being portable (eg, independant of any IEEE format).<br />
However, this means reduced precision due to the quantization to 16.16. I may add support for<br />
variable precision (eg, 8.24 fixed point formats) to alleviate this. This would however mean less<br />
space savings, though these are likely to be insignificant when Kate streams are interleaved with<br />
a video.<br />
<br />
*Though this is not a Kate issue per se, the motion feature is very difficult to use without a curve editor. While tools may be coded to create a Kate bitstream for various existing subtitle formats, it is not certain it will be easy to find a good authoring tool for a series of curves. That said, it's not exactly difficult to do if you know a widget set.<br />
<br />
=== Higher dimensional curves/motions ===<br />
<br />
It is quite annoying to have to create two motions to control a color change, due to curves<br />
being restricted to two dimensions. I may add support for arbitrary dimensions. It would also<br />
help for 1D motions, like changing the time flow, where one coordinate is simply ignored at<br />
the moment.<br />
Alternatively, changes could be made to the Kate file format to hide the two dimensionality and<br />
allow simpler specification of non-2 dimensional motions, but still map them to 2D in the kate<br />
bitstream format.<br />
<br />
=== Category definition ===<br />
<br />
The category field in the BOS packet is a 16 byte text field (15 really, as it is zero terminated<br />
in the bitstream itself). Its goal is to provide the reader with a short description of what kind<br />
of information the stream contains, eg subtitles, lyrics, etc. This would be displayed to the user,<br />
possibly to allow to choose to turn some streams on and off.<br />
<br />
Since this category is meant primarily for a machine to parse, they will be kept to ASCII. When<br />
a player recognizes a category, it is free to replace its name with one in the user's language if<br />
it prefers. Even in English, the "lyrics" category could be displayed by a player as "Lyrics".<br />
<br />
Since this is a free text field rather than an enumeration, it would be good to have a list of<br />
common predefined category names that Kate streams can use.<br />
<br />
This is a list of proposed predefined categories, feedback/additions welcome:<br />
<br />
* subtitles - the usual movie subtitles, as text<br />
* spu-subtitles - movie subtitles in DVD style paletted images<br />
* lyrics - song lyrics<br />
<br />
Please remember the 15 character limit if proposing other categories.<br />
<br />
Note that the list of categories is subject to change, and will likely<br />
be replaced by new, more "identifier like" ones. The three ones above,<br />
however, would be kept for backward compatibility as they're already used.<br />
<br />
== Text to speech ==<br />
<br />
One of the goals of the Kate bitstream format is that text data can be easily parsed<br />
by the user of the decoder, so any additional information, such as style, placement,<br />
karaoke data, etc, should be able to be stripped to leave only the bare text. This is<br />
in view of allowing text-to-speech software to use Kate bitstreams as a bandwith-cheap<br />
way of conveying speech data, and could also allow things like e-books which can be<br />
either read or listened to from the same bitstream (I have seen no reference to this<br />
being used anywhere, but I see no reason why the granule progression should be temporal,<br />
and not user controlled, such as by using a "next" button which would bump a granule<br />
postion by a preset amount, simulating turning a page (this would be close to necessary<br />
for text-to-speech, as the wall time duration of the spoken speech is not known in<br />
advance to the Kate encoder, and can't be mapped to a time based granule progression)).<br />
All text strings triggered consecutively between the two granule positions would then<br />
be read in order.<br />
<br />
== Possible additions ==<br />
<br />
=== Embedded binary data ===<br />
<br />
Images and font mappings can be included within a Kate stream.<br />
<br />
==== Images ====<br />
<br />
Though this could be misused to interfere with ability to render as text-to-speech, Kate<br />
can use images as well as text. The same caveat as for fonts applies with regard to data<br />
duplication.<br />
<br />
Complex images might however be best left to a multiplexed OggSpots or OggMNG stream, unless the<br />
images mesh with the text (eg, graphical exclamation points, custom fonts, (see next<br />
paragraph), etc).<br />
<br />
There is support for simple paletted bitmap images, with a variable length palette of up<br />
to 256 colors (in fact, sized in powers of 2 up to 256) and matching pixel data in as<br />
many bits per pixel as can address the palette. Palettes and images are stored separately,<br />
so can be used with one another with no fixed assignment.<br />
<br />
Palettes and bitmaps are put in two separate header for later use by reference, but can<br />
also be placed in data packets, as with motions, etc, if they are not going to be reused.<br />
<br />
PNG bitmaps can also be embedded in a Kate stream. These do not have associated palettes<br />
(but the PNGs themselves may or may not be paletted). There is no support for decoding PNG<br />
images in libkate itself, so a program will have to use libpng (or similar code) to decode<br />
the PNG image. For instance, the libtiger rendering library uses Cairo to decode and render<br />
PNG images in Kate streams.<br />
<br />
This can be used to have custom fonts, so that raw text is still available if the stream<br />
creator wants a custom look.<br />
<br />
I expect that the need for more than 256 colors in a bitmap, or non palette bitmap data,<br />
would be best handled by another codec, eg OggMNG or OggSpots. The goal of images in a<br />
Kate stream is to mesh the images with the text, not to have large images by themselves.<br />
<br />
On the other hand, interesting Karaoke effects could be achieved by having MNG images<br />
instead of simple paletted bitmaps in a Kate streams. Comments would be most welcome on<br />
whether this is going too far, however.<br />
<br />
I am also investigating SVG images. These allow for very small footprint images for simple<br />
vector drawings, and could be very useful for things like background gradients below text.<br />
<br />
A possible solution to the duplication issue is to have another stream in the container<br />
stream, which would hold the shared data (eg, fonts), which the user program could load,<br />
and which could then be used by any Kate (and other) stream. Typically, this type of stream<br />
would be a degenerate stream with only header packets (so it is fully processed before any<br />
other stream presents data packets that might make use of that shared data), and all payload<br />
such as fonts being contained within the headers. Thinking about it, it has parallels with<br />
the way Vorbis stores its codebooks within a header packet, or even the way Kate stores the<br />
list of styles within a header packet.<br />
<br />
==== Fonts ====<br />
<br />
Custom fonts are merely a set of ranges mapping unicode code points to bitmaps. As this implies,<br />
fonts are bitmap fonts, not vector fonts, so scaling, if supported by the rendering client,<br />
may not look as good as with a vector font.<br />
<br />
A style may also refer to a font name to use (eg, "Tahoma"). These fonts may or may not be<br />
available on the playing system, however, since the font data is not included in the stream,<br />
just referenced by name. For this reason, it is best to keep to widely known fonts.<br />
<br />
== Reference encoder/decoder ==<br />
<br />
A encoder (kateenc) and a decoder (katedec) are included in the tools directory.<br />
The encoder supports input from several different formats:<br />
* a custom text based file format (see [[#The Kate file format|The Kate file format]]), which is by no means meant to be part of the Kate bitstream specification itself<br />
* SubRip (.srt), the most common subtitle format I found<br />
* LRC lyrics format.<br />
<br />
As an example for the widely used SRT subtitles format, the following command line<br />
create a Kate subtitles stream from an SRT file:<br />
<br />
kateenc -l en -c subtitles -t srt -o subtites.ogg subtitles.srt<br />
<br />
The reverse is possible, to recover an SRT file from a Kate stream, with katedec.<br />
<br />
Note that the subtitles.ogg file should then be multiplexed into the A/V stream,<br />
using either ogg-tools or oggz-tools.<br />
<br />
The Kate bitstreams encoded and decoded by those tools are (supposed to be) correct for this<br />
specification, provided their input is correct.<br />
<br />
== Next steps ==<br />
<br />
=== Continuations ===<br />
<br />
Continuations are a way to add to existing events, and are mostly meant for motions. When streaming<br />
in real time, what motions may be applied to events may not be known in advance (for instance, for a<br />
draw chat program where two programs exchange Kate streams, the drawing motions are only known as<br />
they are drawn. Continuations will allow an event to be extended in time, and motions to be appended<br />
to it. This is only useful for streaming, as when stored in a file, everything is already known in<br />
advance.<br />
<br />
=== A rendering library ===<br />
<br />
This will allow easier integration in other packages (movie players, etc).<br />
I have started working on an implementation using Cairo and Pango, though I'm still at the early stages.<br />
I might add support for embedding vector fonts in a Kate stream if I was going that way. Still need to think about this.<br />
Another point of note is that when this library is available, it would make it easier to add<br />
capabilities such as rotation, scaling, etc, to the bitstream, since this would not cause too<br />
much work for playing programs using the rendering library. It is expected that these additions<br />
would stay backward compatible (eg, an old player would ignore this information but still correctly<br />
decode the information they can work with from a newly encoded stream).<br />
<br />
=== An XML representation ===<br />
<br />
While I purposefully did not write Kate description files in XML due to me finding editing XML such<br />
a chore, it would be nice to be able to losslessly convert between the more user friendly representation<br />
and an XML document, so one can do what one does with XML documents, like transformations.<br />
<br />
And after all, some people might prefer editing the XML version.<br />
<br />
=== Packaging ===<br />
<br />
It would be really nice to have packages for libkate/libtiger for many distros.<br />
<br />
If you're a packager for a distro which doesn't have yet packages for libkate<br />
or libtiger, please consider helping :)<br />
<br />
In particular, packages for Debian would be grand.<br />
<br />
== Matroska mapping ==<br />
<br />
The codec ID is "S_KATE".<br />
<br />
As for Theora and Vorbis, Kate headers are stored in the private data as xiph-laced packets:<br />
<br />
Byte 0: number of packets present, minus 1 (there must be at least one packet) - let this number be NP<br />
Bytes 1..n: lengths of the first NP packets, coded in xiph style lacing<br />
Bytes n+1..end: the data packets themselves concatenated one after the other<br />
<br />
Note that the length of the last packet isn't encoded, it is deduced from the sizes of the other<br />
packets and the total size of the private data.<br />
<br />
This mapping is similar to the Vorbis and Theora mappings, with the caveat that one should not<br />
expect a set number of headers.<br />
<br />
== Downloading ==<br />
<br />
libkate encodes and decodes Kate streams, and is API and ABI stable.<br />
<br />
The libkate source distribution is available at [http://libkate.googlecode.com/ http://libkate.googlecode.com/].<br />
<br />
A public git repository is available at [http://git.xiph.org/?p=users/oggk/kate.git;a=summary http://git.xiph.org/?p=users/oggk/kate.git;a=summary].<br />
<br />
libtiger renders Kate streams using Pango and Cairo, and is alpha, with API changes still possible.<br />
<br />
The libtiger source distribution is available at [http://libtiger.googlecode.com/ http://libtiger.googlecode.com/].<br />
<br />
A public git repository is available at [http://git.xiph.org/?p=users/oggk/tiger.git;a=summary http://git.xiph.org/?p=users/oggk/tiger.git;a=summary].<br />
<br />
== HOWTOs ==<br />
<br />
These paragraphs describe a few ways to use Kate streams:<br />
<br />
=== Text movie subtitles ===<br />
<br />
Kate streams can carry Unicode text (that is, text that can represent<br />
pretty much any existing language/script). If several Kate streams are<br />
multiplexed along with a video, subtitles in various languages can be<br />
made for that movie.<br />
<br />
An easy way to create such subtitles is to use ffmpeg2theora, which<br />
can create Kate streams from SubRip (.srt) format files, a simple but<br />
common text subtitles format. ffmpeg2theora 0.21 or later is needed.<br />
<br />
At its simplest:<br />
<br />
ffmpeg2theora -o video-with-subtitles.ogg --subtitles subtitles.srt<br />
video-without-subtitles.avi<br />
<br />
Several languages may be created and tagged with their language code<br />
for easy selection in a media player:<br />
<br />
ffmpeg2theora -o video-with-subtitles.ogg video-without-subtitles.avi<br />
--subtitles japanese-subtitles.srt --subtitles-language ja<br />
--subtitles welsh-subtitles.srt --subtitles-language cy<br />
--subtitles english-subtitles.srt --subtitles-language en_GB<br />
<br />
Alternatively, kateenc (which comes with the libkate distribution) can<br />
create Kate streams from SubRip files as well. These can then be merged<br />
with a video with oggz-tools:<br />
<br />
kateenc -t srt -c SUB -l it -o subtitles.ogg italian-subtitles.srt<br />
oggz merge -o movie-with-subtitles.ogg movie-without-subtitles.ogg subtitles.ogg<br />
<br />
This second method can also be used to add subtitles to a video which<br />
is already encoded to Theora, as it will not transcode the video again.<br />
<br />
<br />
=== DVD subtitles ===<br />
<br />
DVD subtitles are not text, but images. Thoggen, a DVD ripper program,<br />
can convert these subtitles to Kate streams (at the time of writing,<br />
Thoggen and GStreamer have not applied the necessary patches for this<br />
to be possible out of the box, so patching them will be required).<br />
<br />
When configuring how to rip DVD tracks, any subtitles will be detected<br />
by Thoggen, and selecting them in the GUI will cause them to be saved as<br />
Kate tracks along with the movie.<br />
<br />
<br />
=== Song lyrics ===<br />
<br />
Kate streams carrying song lyrics can be embedded in an Ogg file. The<br />
oggenc Vorbis encoding tool from the Xiph.Org Vorbis tools allows lyrics<br />
to be loaded from a LRC or SRT text file and converted to a Kate stream<br />
multiplexed with the resulting Vorbis audio. At the time of writing,<br />
the patch to oggenc was not applied yet, so it will have to be patched<br />
manually with the patch found in the diffs directory.<br />
<br />
oggenc -o song-with-lyrics.ogg --lyrics lyrics.lrc --lyrics-language en_US song.wav<br />
<br />
So called 'enhanced LRC' files (containing extra karaoke timing information)<br />
are supported, and a simple karaoke color change scheme will be saved<br />
out for these files. For more complex karaoke effects (such as more <br />
complex style changes, or sprite animation), kateenc should be used with<br />
a Kate description file to create a separate Kate stream, which can then<br />
be merged with a Vorbis only song with oggz-tools:<br />
<br />
oggenc -o song.ogg song.wav<br />
kateenc -t kate -c LRC -l en_US -o lyrics.ogg lyrics-with-karaoke.kate<br />
oggz merge -o song-with-karaoke.ogg lyrics-with-karaoke.ogg song.ogg<br />
<br />
This latter method may also be used if you already have an encoded Vorbis song<br />
with no lyrics, and just want to add the lyrics without reencoding.<br />
<br />
<br />
=== Changing a Kate stream embedded in an Ogg stream ===<br />
<br />
If you need to change a Kate stream already embedded in an Ogg stream (eg, you have a movie with subtitles, and you want to fix a spelling mistake, or want to bring one of the subtitles forward in time, etc), you can do this easily with KateDJ, a tool that will extract Kate streams, decode them to a temporary location, and rebuild the original stream after you've made whatever changes you want.<br />
<br />
KateDJ (included with the libkate distribution) is a GUI program using wxPython, a Python module for the wxWidgets GUI library, and the oggz tools (both needing installing separately if they are not already).<br />
<br />
The procedure consists of:<br />
<br />
* Run KateDJ<br />
* Click 'Load Ogg stream' and select the file to load<br />
* Click 'Demux file' to decode Kate streams in a temporary location<br />
* Edit the Kate streams (a message box tells you where they are placed)<br />
* When done, click 'Remux file from parts'<br />
* If any errors are reported, continue editing until the remux step succeeds<br />
<br />
== Frequently Asked Questions ==<br />
<br />
=== Does libkate work on other plaforms than Linux ? ===<br />
<br />
Yes, libkate is not Linux specific in any way. It optionally relies on libogg<br />
and libpng, two libraries widely ported to various platforms.<br />
It has been reported to work on Windows and MacOS X as well as UNIX platforms.<br />
<br />
However, libtiger, a rendering library for Kate streams, relies on Pango and Cairo,<br />
which are not easy to build on Windows, though they can be.<br />
The Tiger renderer is however completely separate from libkate, and is not needed<br />
for full encoding and decoding of Kate streams.<br />
<br />
=== Where can I find some example files ? ===<br />
<br />
The libkate distribution can generate various examples, but already built files<br />
can be found there:<br />
[http://people.xiph.org/~oggk/elephants_dream/elephantsdream-with-subtitles.ogg]<br />
[http://stallman.org/fry/Stephen_Fry-Happy_Birthday_GNU-nq_600px_425kbit.ogv]<br />
<br />
These files use raw text only.<br />
<br />
<br />
<br />
[[Category:Drafts]]<br />
[[Category:Ogg Mappings]]</div>J^https://wiki.xiph.org/index.php?title=Speex&diff=12875Speex2011-07-03T16:24:19Z<p>J^: Reverted edits by WikiAdmin (talk) to last revision by Jmspeex</p>
<hr />
<div>= Website =<br />
<br />
The [http://www.speex.org/ Speex homepage] has all the project info.<br />
<br />
== Hardware ==<br />
<br />
See [[Speex hardware]] for a partial list of supported hardware<br />
<br />
== Tasks ==<br />
<br />
These are some improvements that could be made to Speex. Let [mailto:speex-dev@xiph.org us] know if you'd like to work on one of them.<br />
<br />
* Speech/signal processing (DSP design)<br />
** Improve noise suppression (get rid of musical noise) and residual echo suppression<br />
** Improve packet-loss concealment (PLC)<br />
** Re-write the built-in voice activity detector (VAD)<br />
** Improve the 2.15 kbps vocoder mode (there are even 4 unused bits left to use)<br />
** Algorithmic optimizations (see if some searches can be simplified/approximated)<br />
<br />
* Complete fixed-point (DSP development)<br />
** Wideband<br />
** VBR<br />
** Rest of the narrowband modes<br />
** Preprocessor (noise suppression, AGC)<br />
** Jitter buffer<br />
** Arch-specific optimization<br />
** More...<br />
<br />
* Tune (playing with parameters)<br />
** Noise weighting filter<br />
** Perceptual enhancement<br />
<br />
* Features (plain C programming)<br />
** Implement maximum VBR bit-rate<br />
** Implement peeling (write functions to strip some of the bits)<br />
*** Peel high-band (wideband -> narrowband)<br />
*** Transform 24.6 kbps mode to 15 kbps mode<br />
<br />
* Documentation<br />
** Use questions from the mailing list to create a better FAQ on the wiki<br />
** Update the Speex manual based on recent papers<br />
** Improve libspeex documentation<br />
** Write good example code<br />
<br />
== External links ==<br />
<br />
* [[Wikipedia: Speex]]<br />
<br />
[[Category:Speex]]</div>J^https://wiki.xiph.org/index.php?title=FLAC&diff=12874FLAC2011-07-03T16:23:56Z<p>J^: Reverted edits by WikiAdmin (talk) to last revision by Ogg.k.ogg.k</p>
<hr />
<div>'''FLAC''' stands for '''Free Lossless Audio Codec'''. FLAC is an [[wikipedia:audio compression|audio compression]] [[wikipedia:codec|codec]] that is [[wikipedia:lossless data compression|lossless]]. Unlike [[wikipedia:lossy data compression|lossy]] codecs such as [[Vorbis]] and [[wikipedia:MP3|MP3]], it does not remove any information from the audio stream.<br />
<br />
On 2003 January 29th, the [[Xiph.Org Foundation]] announced the incorporation of FLAC under their flag, to go along with Vorbis, [[Theora]], and [[Speex]].<br />
<br />
== The Project ==<br />
<br />
The FLAC project consists of: <br />
* the stream format <br />
* libFLAC, a library of reference encoders and decoders, and a metadata interface <br />
* libFLAC++, an object wrapper around libFLAC <br />
* flac, a command-line wrapper around libFLAC to encode and decode .flac files <br />
* metaflac, a command-line metadata editor for .flac files <br />
* input plugins for various music players ([[wikipedia:Winamp|Winamp]], [[wikipedia:XMMS|XMMS]], [[wikipedia:Foobar2000|foobar2000]], and more in the works)<br />
<br />
"Free" means that the specification of the stream format is in the [[wikipedia:public domain|public domain]] (the FLAC project reserves the right to set the FLAC specification and certify compliance), and that neither the FLAC format nor any of the implemented encoding/decoding methods are covered by any patent. It also means that the sources for libFLAC and libFLAC++ are available under The New BSD license and the sources for flac and metaflac applications, and the plugins are available under the [[wikipedia:GPL|GPL]].<br />
<br />
== Comparisons ==<br />
<br />
FLAC is distinguished from general lossless algorithms such as ZIP and gzip in that it is specifically designed for the efficient packing of audio data; while ZIP may compress a CD-quality audio file 20&ndash;40%, FLAC achieves compression rates of 30&ndash;70%. <br />
<br />
While lossy codecs can achieve ratios of 80&ndash;90+%, they do this at the expense of discarding data from the original stream. Though FLAC uses a similar technique in its encoding process, it also adds "residual" data to allow the decoder to restore the original waveform flawlessly.<br />
<br />
FLAC has become the preferred lossless format for trading live music online. It has a smaller file size than Shorten, and unlike MP3, it's lossless, which ensures the highest fidelity to the source material, which is important to live music traders. It has recently become a favorite trading format of non-live lossless audio traders as well.<br />
<br />
There are other lostless audio codecs, however: WAVPACK (marginally better compression, slower), TAK, Monkey's audio and some more. <br />
<br />
FLAC compiles on many platforms: most Unices (including Linux, *BSD, Solaris, and Mac OS X), DOS, Windows, BeOS, and OS/2. There are build systems for autoconf/automake, MSVC, Watcom C, and Project Builder.<br />
<br />
== More information ==<br />
<br />
* [[FLACDecoders]]: List of decoders<br />
* [[FLACEncoders]]: List of encoders<br />
<br />
== Non-PC playback support ==<br />
<br />
FLAC is supported by a wide range of devices. The [[PortablePlayers#Portable Vorbis Native Support Table|portable players Vorbis support matrix]] also contains information about FLAC support. Other examples of FLAC supporting devices are:<br />
<br />
* [[PortablePlayers/Flash#Cowon.2FiAudio_D2.2C_F2.2C_T2.2C_U3.2C_U2.2C_G3.2C_5.2C_G2.2C_U5.2C_7|iAudio]]: http://www.iaudio.com<br />
* Kenwood Music Keg<br />
* Naim HDX: http://www.naim-audio.com/products/hdx.html<br />
* PhatNoise Home Media Player<br />
* PhatNoise Phatbox<br />
* [[PortablePlayers/Harddisk#Rio Karma|Rio Karma]]: http://www.digitalnetworksna.com/rioaudio/<br />
* [[StaticPlayers#Slim_Devices_Squeezebox.2C_Squeezebox2.2C_Squeezebox3.2C_Transporter|SlimDevices Squeezebox]]: http://www.slimdevices.com<br />
<br />
FLAC is supported by the following chips and/or chipsets:<br />
<br />
* VLSI Solution OY's [http://www.vlsi.fi/en/products/vs1053.html VS1053b] decodes FLAC<br />
<br />
== External links ==<br />
<br />
*[http://flac.sourceforge.net/ Project homepage]<br />
*[http://mikewren.com/flac/ Unofficial FLAC installer for Windows]<br />
*[http://www.danrules.com/macflac/ MacFLAC] [[GUI]] frontend to encode/decode FLAC on [[Mac OS X]]<br />
*[[Wikipedia: FLAC]]<br />
*[http://www.losslessaudioblog.com/ The Lossless Audio Blog] Lossless Audio News & Information Site.<br />
<br />
[[Category:Xiph core projects]]</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=12333TheoraTestsuite2010-09-19T12:24:08Z<p>J^: /* some samples to test your theora decoder */</p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simplest example<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton Stream'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton and CMML Stream'''; decoders should read the Skeleton stream to identify the other streams in Ogg and ignore those that are not supported by the application<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] [1.8 MB] <br />
<br />
* '''Aspect Ratio defined in header''' to 1.82/1 , it also has a theora '''comment header''' <br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] [422K]<br />
<br />
* '''Aspect Ratio defined in header''' to 1.33/1 (PAL DVD format)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* '''both dimensions not divisible by 16''' but still even - if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
<br />
[...]<br />
<br />
* '''one dimension divisible by 16 while the other one isn't'''<br />
<br />
<br />
[...]<br />
<br />
* '''odd dimensions'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a '''chained stream'''. (see Spec/A.3.1 on page 157)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg multi2.ogg] [171 K]<br />
<br />
* another '''chained''' file<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* '''4:2:2''' pixel format, in the original spec and supported by the mainline decoder since alpha8 and the mainline encoder since 1.1.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video '''4:4:4''' pixel format, 1280x720 pixels, 25 fps, 213 frames<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* '''Hybrid 24fps/30fps''' clip encoded as 120fps with dropped frames.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv offset_test.ogv] [0.2 MB] (10 frames, 1 fps, no visible movement, visible frame 512 x 512) <br />
<br />
* Ogg Theora video with '''large offset''', output should look like [http://v2v.cc/~j/theora_testsuite/offset_test.pass.png offset_test.pass.png], but not like [http://v2v.cc/~j/theora_testsuite/offset_test.fail.png offset_test.fail.png].<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using '''3qi (adaptive quantization)'''.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chroma_siting_test.ogv chroma_siting_test.ogv] [25K]<br />
<br />
* Ogg Theora video chroma siting test for 4:2:0. No motion, 1 fps, 20 seconds, 1 frame + 19 repetitions. If the player's conversion to RGB uses correct chroma subsample positioning, then the top and bottom halves should be the same color. If the top and bottom halves are different colors, then the player's chroma siting is wrong. Note that many players delegate YUV to RGB conversion to the graphics hardware or driver, which are then responsible for the chroma siting. [http://img260.imageshack.us/img260/1198/cromatest.png This image] shows a correct decode.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/0byteframes.ogv 0byteframes.ogv] [31k]<br />
<br />
* Ogg Theora video 25fps 10seconds long, frame only changes every second.<br />
<br />
== Player compliance ==<br />
<br />
* Firefox (3.6)<br />
** Seems to pass all tests (not sure about the 322x242 "not divisible by 16" - there is a black line ...)<br />
** But high requirements to play (especially large) videos, behaves badly if hardware is insufficient to play in real-time<br />
<br />
* MPLAYER (r30886 2010-03-13)<br />
** OGG and Theora support has been inferior for years (but mostly worked with encoders from given era), improved at beginning of 2010<br />
** Recently fixed issues:<br />
*** 4:2:2 and 4:4:4 support (in previous versions they did "play", but looking "strangely") [http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-February/thread.html List discussion] [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1487 BUG #1487]<br />
*** Some videos encoded with recent (1.1) encoders complaining about "invalid frames" or hanging [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1664 BUG #1664]<br />
** Remaining issues: <br />
*** Offset test fails, shows what shouldn't be visible [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1492 BUG #1492, open since 2009-06-14]<br />
*** Output to YUV4MPEG always downsampled to 4:2:0 (flaw, no Bugzilla entry exists)<br />
<br />
* VLC 1.0.5<br />
** Theora decoder seems fully compliant, tiny problems specific to some videos or systems (fixing in progress)<br />
** Video duration is reported badly or not at all<br />
<br />
* DUGL Player 0.44<br />
** Theora decoder seems fully compliant, but no sound yet<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=12332TheoraTestsuite2010-09-19T12:13:43Z<p>J^: /* some samples to test your theora decoder */</p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simplest example<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton Stream'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton and CMML Stream'''; decoders should read the Skeleton stream to identify the other streams in Ogg and ignore those that are not supported by the application<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] [1.8 MB] <br />
<br />
* '''Aspect Ratio defined in header''' to 1.82/1 , it also has a theora '''comment header''' <br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] [422K]<br />
<br />
* '''Aspect Ratio defined in header''' to 1.33/1 (PAL DVD format)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* '''both dimensions not divisible by 16''' but still even - if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
<br />
[...]<br />
<br />
* '''one dimension divisible by 16 while the other one isn't'''<br />
<br />
<br />
[...]<br />
<br />
* '''odd dimensions'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a '''chained stream'''. (see Spec/A.3.1 on page 157)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg multi2.ogg] [171 K]<br />
<br />
* another '''chained''' file<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* '''4:2:2''' pixel format, in the original spec and supported by the mainline decoder since alpha8 and the mainline encoder since 1.1.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video '''4:4:4''' pixel format, 1280x720 pixels, 25 fps, 213 frames<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* '''Hybrid 24fps/30fps''' clip encoded as 120fps with dropped frames.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv offset_test.ogv] [0.2 MB] (10 frames, 1 fps, no visible movement, visible frame 512 x 512) <br />
<br />
* Ogg Theora video with '''large offset''', output should look like [http://v2v.cc/~j/theora_testsuite/offset_test.pass.png offset_test.pass.png], but not like [http://v2v.cc/~j/theora_testsuite/offset_test.fail.png offset_test.fail.png].<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using '''3qi (adaptive quantization)'''.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chroma_siting_test.ogv chroma_siting_test.ogv] [25K]<br />
<br />
* Ogg Theora video chroma siting test for 4:2:0. No motion, 1 fps, 20 seconds, 1 frame + 19 repetitions. If the player's conversion to RGB uses correct chroma subsample positioning, then the top and bottom halves should be the same color. If the top and bottom halves are different colors, then the player's chroma siting is wrong. Note that many players delegate YUV to RGB conversion to the graphics hardware or driver, which are then responsible for the chroma siting. [http://img260.imageshack.us/img260/1198/cromatest.png This image] shows a correct decode.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/0byteframes.ogv 0byteframes.ogv] [31k MB]<br />
<br />
* Ogg Theora video 25fps 10seconds long, frame only changes every second.<br />
<br />
== Player compliance ==<br />
<br />
* Firefox (3.6)<br />
** Seems to pass all tests (not sure about the 322x242 "not divisible by 16" - there is a black line ...)<br />
** But high requirements to play (especially large) videos, behaves badly if hardware is insufficient to play in real-time<br />
<br />
* MPLAYER (r30886 2010-03-13)<br />
** OGG and Theora support has been inferior for years (but mostly worked with encoders from given era), improved at beginning of 2010<br />
** Recently fixed issues:<br />
*** 4:2:2 and 4:4:4 support (in previous versions they did "play", but looking "strangely") [http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-February/thread.html List discussion] [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1487 BUG #1487]<br />
*** Some videos encoded with recent (1.1) encoders complaining about "invalid frames" or hanging [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1664 BUG #1664]<br />
** Remaining issues: <br />
*** Offset test fails, shows what shouldn't be visible [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1492 BUG #1492, open since 2009-06-14]<br />
*** Output to YUV4MPEG always downsampled to 4:2:0 (flaw, no Bugzilla entry exists)<br />
<br />
* VLC 1.0.5<br />
** Theora decoder seems fully compliant, tiny problems specific to some videos or systems (fixing in progress)<br />
** Video duration is reported badly or not at all<br />
<br />
* DUGL Player 0.44<br />
** Theora decoder seems fully compliant, but no sound yet<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=Theora&diff=12273Theora2010-07-07T23:12:12Z<p>J^: Reverted edits by ArcangelaGallo (Talk) to last revision by Ogg.k.ogg.k</p>
<hr />
<div>'''Theora''' is a video codec, based on the [[VP3]] codec donated by [[On2 Technologies]]. We've refined and extended it, giving it the same future scope for encoder improvement [[Vorbis]] has. See http://theora.org/ for more information.<br />
<br />
== Features ==<br />
<br />
Features available in the Theora format (and a comparison to VP3 and MPEG-4 ASP):<br />
<br />
* 8x8 Type-II Discrete Cosine Transform<br />
* block-based motion compensation<br />
* free-form variable bit rates (VBR)<br />
* adaptive in-loop deblocking applied to the edges of the coded blocks (not existing in MPEG-4 ASP)<br />
* block sizes down to 8x8 (MPEG-4 ASP supports 8x8 only with 4MV)<br />
* 384 8x8 custom quantization matrices: intra/inter, luma/chroma and even each quant (more than VP3 and MPEG-4 ASP/AVC)<br />
* flexible entropy encoding (Theora supports 80 VLC tables selectable per-frame, MPEG-4 ASP has just one)<br />
* 4:2:0, 4:2:2, and 4:4:4 chroma subsampling formats (VP3 and MPEG-4 ASP only support 4:2:0)<br />
* 8 bits per pixel per color channel<br />
* multiple reference frames (not possible in MPEG-4 ASP)<br />
* pixel aspect ratio (eg for anamorphic signalling/playback)<br />
* non-multiple of 16 picture sizes (as possible in ASP, but not in VP3)<br />
* non-linear scaling of quants values (as done in MPEG-4 AVC)<br />
* adaptive quantization down to the block level (as possible in MPEG-4 ASP/AVC, but not in VP3)<br />
* intra frames (I-Frames in MPEG), inter frames (P-Frames), but no B-Frames (as supported in MPEG-4 ASP/AVC)<br />
* HalfPixel Motion Search Precision (MPEG-4 ASP/AVC supports HalfPixel or QuarterPixel)<br />
* technologies used already in Vorbis (decoder setup configuration, bitstream headers...) not available in VP3<br />
<br />
== Status ==<br />
* '''1.1.1''' is the latest stable release (2009-10-01). <br />
* The bitstream format was frozen in 1.0 Alpha 3 on 2004-08-04: every file created with this encoder (and, of course, later encoders) will be playable by any compliant Theora decoder.<br />
* The decoder in 1.0 Alpha 8 implemented all features of the [http://theora.org/doc/Theora.pdf Theora Format Specification]: every file created by any compliant Theora encoder will be playable by the decoder in 1.0 Alpha 8 (and, of course, later decoders).<br />
<br />
== Development ==<br />
<br />
* [[OggTheora|Mapping in Ogg]]<br />
* [[TheoraTodo|ToDo list for development]]<br />
* [[Cortado/release|Release checklist for the Cortado java applet]]<br />
<br />
== More information ==<br />
{{Template:Theora}}<br />
<br />
It's possible to convert VP3 video to Theora. See [[vp3toTheora]].<br />
<br />
== External links ==<br />
<br />
* [http://www.theora.org/ Theora homepage]<br />
* [http://www.annodex.net/software/theora/ Theora documentation daily builds]<br />
* [[Wikipedia: Theora]]<br />
* [http://www.vp3.com VP3 homepage]: The homepage of the codec Theora is based on<br />
* [http://www.on2.com On2 Technologies]: The authors of VP3<br />
* [http://forum.doom9.org/showthread.php?s=&threadid=77314 Ogg Theora Information on Doom9 Forum]<br />
* [http://www.parrishtech.com/content/view/16/1/ HOWTO: Rip DVD to Theora using Linux]<br />
* [http://www.doom9.org/index.html?/codecs-quali-105-1.htm Codec shoot-out 2005] Comparison of many video codecs, including Theora<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=10935TheoraTestsuite2010-03-22T15:35:38Z<p>J^: /* some samples to test your theora decoder */</p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simplest example<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton Stream'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton and CMML Stream'''; decoders should read the Skeleton stream to identify the other streams in Ogg and ignore those that are not supported by the application<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] [1.8 MB] <br />
<br />
* '''Aspect Ratio defined in header''' to 1.82/1 , it also has a theora '''comment header''' <br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] [422K]<br />
<br />
* '''Aspect Ratio defined in header''' to 1.33/1 (PAL DVD format)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* '''both dimensions not divisible by 16''' but still even - if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
<br />
[...]<br />
<br />
* '''one dimension divisible by 16 while the other one isn't'''<br />
<br />
<br />
[...]<br />
<br />
* '''odd dimensions'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a '''chained stream'''. (see Spec/A.3.1 on page 157)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg multi2.ogg] [171 K]<br />
<br />
* another '''chained''' file<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* '''4:2:2''' pixel format, in the original spec and supported by the mainline decoder since alpha8 and the mainline encoder since 1.1.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video '''4:4:4''' pixel format, 1280x720 pixels, 25 fps, 213 frames<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* '''Hybrid 24fps/30fps''' clip encoded as 120fps with dropped frames.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv offset_test.ogv] [0.2 MB] (10 frames, 1 fps, no visible movement, visible frame 512 x 512) <br />
<br />
* Ogg Theora video with '''large offset''', output should look like [http://v2v.cc/~j/theora_testsuite/offset_test.pass.png offset_test.pass.png], but not like [http://v2v.cc/~j/theora_testsuite/offset_test.fail.png offset_test.fail.png].<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using '''3qi (adaptive quantization)'''.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chroma_siting_test.ogv chroma_siting_test.ogv] [25K]<br />
<br />
* Ogg Theora video chroma siting test.<br />
<br />
== Player compliance ==<br />
<br />
* Firefox (3.6)<br />
** Seems to pass all tests (not sure about the 322x242 "not divisible by 16" - there is a black line ...)<br />
** But high requirements to play (especially large) videos, behaves badly if hardware is insufficient to play in real-time<br />
<br />
* MPLAYER (r30886 2010-03-13)<br />
** OGG and Theora support has been inferior for years (but mostly worked with encoders from given era), improved at beginning of 2010<br />
** Recently fixed issues:<br />
*** 4:2:2 and 4:4:4 support (in previous versions they did "play", but looking "strangely") [http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-February/thread.html List discussion] [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1487 BUG #1487]<br />
*** Some videos encoded with recent (1.1) encoders complaining about "invalid frames" or hanging [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1664 BUG #1664]<br />
** Remaining issues: <br />
*** Offset test fails, shows what shouldn't be visible [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1492 BUG #1492, open since 2009-06-14]<br />
*** Output to YUV4MPEG always downsampled to 4:2:0 (flaw, no Bugzilla entry exists)<br />
<br />
* VLC 1.0.5<br />
** Theora decoder seems fully compliant, tiny problems specific to some videos or systems (fixing in progress)<br />
** Video duration is reported badly or not at all<br />
<br />
* DUGL Player 0.44<br />
** Theora decoder seems fully compliant, but no sound yet<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=10934TheoraTestsuite2010-03-22T15:34:27Z<p>J^: /* some samples to test your theora decoder */ fix link</p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simplest example<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton Stream'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton and CMML Stream'''; decoders should read the Skeleton stream to identify the other streams in Ogg and ignore those that are not supported by the application<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] [1.8 MB] <br />
<br />
* '''Aspect Ratio defined in header''' to 1.82/1 , it also has a theora '''comment header''' <br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] [422K]<br />
<br />
* '''Aspect Ratio defined in header''' to 1.33/1 (PAL DVD format)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* '''both dimensions not divisible by 16''' but still even - if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
<br />
[...]<br />
<br />
* '''one dimension divisible by 16 while the other one isn't'''<br />
<br />
<br />
[...]<br />
<br />
* '''odd dimensions'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a '''chained stream'''. (see Spec/A.3.1 on page 157)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg multi2.ogg] [171 K]<br />
<br />
* another '''chained''' file<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* '''4:2:2''' pixel format, in the original spec and supported by the mainline decoder since alpha8 and the mainline encoder since 1.1.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video '''4:4:4''' pixel format, 1280x720 pixels, 25 fps, 213 frames<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* '''Hybrid 24fps/30fps''' clip encoded as 120fps with dropped frames.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv offset_test.ogv] [0.2 MB] (10 frames, 1 fps, no visible movement, visible frame 512 x 512) <br />
<br />
* Ogg Theora video with '''large offset''', output should look like [http://v2v.cc/~j/theora_testsuite/offset_test.pass.png offset_test.pass.png], but not like [http://v2v.cc/~j/theora_testsuite/offset_test.fail.png offset_test.fail.png].<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using '''3qi (adaptive quantization)'''.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chroma_siting_test.ogv chroma_siting_test.ogv] [25K]<br />
<br />
* Ogg Theora video chroma siting test.<br />
<br />
== Player compliance ==<br />
<br />
* Firefox (3.6)<br />
** Seems to pass all tests (not sure about the 322x242 "not divisible by 16" - there is a black line ...)<br />
** But high requirements to play (especially large) videos, behaves badly if hardware is insufficient to play in real-time<br />
<br />
* MPLAYER (r30886 2010-03-13)<br />
** OGG and Theora support has been inferior for years (but mostly worked with encoders from given era), improved at beginning of 2010<br />
** Recently fixed issues:<br />
*** 4:2:2 and 4:4:4 support (in previous versions they did "play", but looking "strangely") [http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-February/thread.html List discussion] [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1487 BUG #1487]<br />
*** Some videos encoded with recent (1.1) encoders complaining about "invalid frames" or hanging [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1664 BUG #1664]<br />
** Remaining issues: <br />
*** Offset test fails, shows what shouldn't be visible [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1492 BUG #1492, open since 2009-06-14]<br />
*** Output to YUV4MPEG always downsampled to 4:2:0 (flaw, no Bugzilla entry exists)<br />
<br />
* VLC 1.0.5<br />
** Theora decoder seems fully compliant, tiny problems specific to some videos or systems (fixing in progress)<br />
** Video duration is reported badly or not at all<br />
<br />
* DUGL Player 0.44<br />
** Theora decoder seems fully compliant, but no sound yet<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=10933TheoraTestsuite2010-03-22T15:33:54Z<p>J^: /* some samples to test your theora decoder */ add chroma_siting_test.ogv</p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simplest example<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton Stream'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with '''Skeleton and CMML Stream'''; decoders should read the Skeleton stream to identify the other streams in Ogg and ignore those that are not supported by the application<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] [1.8 MB] <br />
<br />
* '''Aspect Ratio defined in header''' to 1.82/1 , it also has a theora '''comment header''' <br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] [422K]<br />
<br />
* '''Aspect Ratio defined in header''' to 1.33/1 (PAL DVD format)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* '''both dimensions not divisible by 16''' but still even - if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
<br />
[...]<br />
<br />
* '''one dimension divisible by 16 while the other one isn't'''<br />
<br />
<br />
[...]<br />
<br />
* '''odd dimensions'''<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a '''chained stream'''. (see Spec/A.3.1 on page 157)<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg multi2.ogg] [171 K]<br />
<br />
* another '''chained''' file<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* '''4:2:2''' pixel format, in the original spec and supported by the mainline decoder since alpha8 and the mainline encoder since 1.1.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video '''4:4:4''' pixel format, 1280x720 pixels, 25 fps, 213 frames<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* '''Hybrid 24fps/30fps''' clip encoded as 120fps with dropped frames.<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv offset_test.ogv] [0.2 MB] (10 frames, 1 fps, no visible movement, visible frame 512 x 512) <br />
<br />
* Ogg Theora video with '''large offset''', output should look like [http://v2v.cc/~j/theora_testsuite/offset_test.pass.png offset_test.pass.png], but not like [http://v2v.cc/~j/theora_testsuite/offset_test.fail.png offset_test.fail.png].<br />
<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using '''3qi (adaptive quantization)'''.<br />
<br />
[http://bemasc.net/~bens/chroma_siting_test.ogv chroma_siting_test.ogv] [25K]<br />
<br />
* Ogg Theora video chroma siting test.<br />
<br />
== Player compliance ==<br />
<br />
* Firefox (3.6)<br />
** Seems to pass all tests (not sure about the 322x242 "not divisible by 16" - there is a black line ...)<br />
** But high requirements to play (especially large) videos, behaves badly if hardware is insufficient to play in real-time<br />
<br />
* MPLAYER (r30886 2010-03-13)<br />
** OGG and Theora support has been inferior for years (but mostly worked with encoders from given era), improved at beginning of 2010<br />
** Recently fixed issues:<br />
*** 4:2:2 and 4:4:4 support (in previous versions they did "play", but looking "strangely") [http://lists.mplayerhq.hu/pipermail/mplayer-users/2010-February/thread.html List discussion] [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1487 BUG #1487]<br />
*** Some videos encoded with recent (1.1) encoders complaining about "invalid frames" or hanging [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1664 BUG #1664]<br />
** Remaining issues: <br />
*** Offset test fails, shows what shouldn't be visible [http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1492 BUG #1492, open since 2009-06-14]<br />
*** Output to YUV4MPEG always downsampled to 4:2:0 (flaw, no Bugzilla entry exists)<br />
<br />
* VLC 1.0.5<br />
** Theora decoder seems fully compliant, tiny problems specific to some videos or systems (fixing in progress)<br />
** Video duration is reported badly or not at all<br />
<br />
* DUGL Player 0.44<br />
** Theora decoder seems fully compliant, but no sound yet<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=OggIndex&diff=10849OggIndex2010-03-06T09:11:50Z<p>J^: Redirected page to Ogg Index</p>
<hr />
<div>#REDIRECT [[Ogg_Index]]</div>J^https://wiki.xiph.org/index.php?title=OggIndex-Migration&diff=10790OggIndex-Migration2010-01-16T17:18:24Z<p>J^: /* oggz-chop */</p>
<hr />
<div>This page is for collecting patches related to the [[Ogg Index]] introduction.<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the OggIndex.<br />
<br />
=== Encoders ===<br />
<br />
* ffmpeg2theora supports creating indexes<br />
<br />
* what about other encoders? VLC, GStreamer<br />
<br />
* oggz-chop support on output<br />
<br />
=== Decoders ===<br />
<br />
==== oggz-chop ====<br />
<br />
* files with index can be chopped, output will not include an index<br />
* should use index for seeking and include an index in output<br />
<br />
==== GStreamer ====<br />
<br />
* support missing, opening files in totem it askes to search for a plugin, after that one can press play again and it plays but does not allow you to seek.<br />
<br />
* Needs indexing added to the Ogg mux?<br />
<br />
==== MPlayer ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== VLC ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== XiphQT ====<br />
<br />
* support missing, not tested<br />
<br />
<br />
==== FFMpeg ====<br />
<br />
* support missing, not tested</div>J^https://wiki.xiph.org/index.php?title=OggIndex-Migration&diff=10789OggIndex-Migration2010-01-16T17:14:13Z<p>J^: /* GStreamer */</p>
<hr />
<div>This page is for collecting patches related to the [[Ogg Index]] introduction.<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the OggIndex.<br />
<br />
=== Encoders ===<br />
<br />
* ffmpeg2theora supports creating indexes<br />
<br />
* what about other encoders? VLC, GStreamer<br />
<br />
* oggz-chop support on output<br />
<br />
=== Decoders ===<br />
<br />
==== oggz-chop ====<br />
<br />
* untested<br />
<br />
<br />
==== GStreamer ====<br />
<br />
* support missing, opening files in totem it askes to search for a plugin, after that one can press play again and it plays but does not allow you to seek.<br />
<br />
* Needs indexing added to the Ogg mux?<br />
<br />
==== MPlayer ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== VLC ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== XiphQT ====<br />
<br />
* support missing, not tested<br />
<br />
<br />
==== FFMpeg ====<br />
<br />
* support missing, not tested</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=10783TheoraTestsuite2010-01-15T03:52:44Z<p>J^: fix png link</p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simple example<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with Skeleton Stream<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with Skeleton and CMML Stream<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] - Frame Aspect Ratio: 1.82/1 [1.8 MB]<br />
<br />
* defined pixel aspect ratio in header, it also has a theora comment header<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] - PAL DVD format / Frame Aspect Ratio: 1.33/1 [422K]<br />
<br />
* defined pixel aspect ratio in header<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a chained stream. (see Spec/A.3.1 on page 157)<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg multi2.ogg] [171 K]<br />
<br />
* another chained file<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* 4:2:2 pixel format, mainline encoder does not support this right now, but its allowed in the spec and libtheora's decoder can decode it(since alpha8).<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* Hybrid 24fps/30fps clip encoded as 120fps with dropped frames.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv offset_test.ogv] [0.2 MB]<br />
<br />
* Ogg Theora video with large offset, output should look like [http://v2v.cc/~j/theora_testsuite/offset_test.pass.png offset_test.pass.png], but not like [http://v2v.cc/~j/theora_testsuite/offset_test.fail.png offset_test.fail.png].<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video 4:4:4 pixel format.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using 3qi (adapative quantization).</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=10782TheoraTestsuite2010-01-15T03:42:28Z<p>J^: </p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simple example<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with Skeleton Stream<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with Skeleton and CMML Stream<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] - Frame Aspect Ratio: 1.82/1 [1.8 MB]<br />
<br />
* defined pixel aspect ratio in header, it also has a theora comment header<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] - PAL DVD format / Frame Aspect Ratio: 1.33/1 [422K]<br />
<br />
* defined pixel aspect ratio in header<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a chained stream. (see Spec/A.3.1 on page 157)<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg multi2.ogg] [171 K]<br />
<br />
* another chained file<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* 4:2:2 pixel format, mainline encoder does not support this right now, but its allowed in the spec and libtheora's decoder can decode it(since alpha8).<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* Hybrid 24fps/30fps clip encoded as 120fps with dropped frames.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv offset_test.ogv] [0.2 MB]<br />
<br />
* Ogg Theora video with large offset, output should look like offset_test.pass.png, but not like offset_test.fail.png.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video 4:4:4 pixel format.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using 3qi (adapative quantization).</div>J^https://wiki.xiph.org/index.php?title=TheoraTestsuite&diff=10781TheoraTestsuite2010-01-15T03:39:40Z<p>J^: Created page with '== some samples to test your theora decoder == a decoder must play all these files without problems to comply with the theora specification. [http://v2v.cc/~j/theora_testsuite/…'</p>
<hr />
<div>== some samples to test your theora decoder ==<br />
<br />
a decoder must play all these files without problems to comply with the theora specification.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogg 320x240.ogg] [0.3 MB]<br />
<br />
* simple example<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.ogv 320x240.ogv] [0.3 MB]<br />
<br />
* simple example with Skeleton Stream<br />
<br />
[http://v2v.cc/~j/theora_testsuite/320x240.skeleton+cmml.ogv 320x240.skeleton+cmml.ogv] [0.3 MB]<br />
<br />
* simple example with Skeleton and CMML Stream<br />
<br />
[http://v2v.cc/~j/theora_testsuite/pixel_aspect_ratio.ogg pixel_aspect_ratio.ogg] - Frame Aspect Ratio: 1.82/1 [1.8 MB]<br />
<br />
* defined pixel aspect ratio in header,<br />
it also has a theora comment header<br />
<br />
[http://v2v.cc/~j/theora_testsuite/videotestsrc-720x576-16-15.ogg videotestsrc-720x576-16-15.ogg] - PAL DVD format / Frame Aspect Ratio: 1.33/1 [422K]<br />
<br />
* defined pixel aspect ratio in header<br />
<br />
[http://v2v.cc/~j/theora_testsuite/322x242_not-divisible-by-sixteen-framesize.ogg 322x242_not-divisible-by-sixteen-framesize.ogg] [0.3 MB]<br />
<br />
* if you see a black border around the testimage you should have a look at the Spec/2.2 on page 22, to see how to use: ti.width, ti.height, ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y<br />
<br />
[http://v2v.cc/~j/theora_testsuite/chained_streams.ogg chained_streams.ogg] [2.4 MB]<br />
<br />
* all other samples as a chained stream. (see Spec/A.3.1 on page 157)<br />
<br />
[http://v2v.cc/~j/theora_testsuite/multi2.ogg [171 K]<br />
<br />
* another chained file<br />
<br />
[http://v2v.cc/~j/theora_testsuite/mobile_itu601_i_422.ogg mobile_itu601_i_422.ogg] [8 MB]<br />
<br />
* 4:2:2 pixel format, mainline encoder does not support this right now, but its allowed in the spec and libtheora's decoder can decode it(since alpha8).<br />
<br />
[http://v2v.cc/~j/theora_testsuite/stockholm-vfr.ogg stockholm-vfr.ogg] [1.8 MB]<br />
<br />
* Hybrid 24fps/30fps clip encoded as 120fps with dropped frames.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/offset_test.ogv [0.2 MB]<br />
<br />
* Ogg Theora video with large offset, output should look like offset_test.pass.png, but not like offset_test.fail.png.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/ducks_take_off_444_720p25.ogg ducks_take_off_444_720p25.ogg] [7.2 MB]<br />
<br />
* Ogg Theora video 4:4:4 pixel format.<br />
<br />
[http://v2v.cc/~j/theora_testsuite/sign_irene_cif-3qi-b.ogg sign_irene_cif-3qi-b.ogg] [1.3 MB]<br />
<br />
* Ogg Theora video using 3qi (adapative quantization).</div>J^https://wiki.xiph.org/index.php?title=OggIndex-Migration&diff=10778OggIndex-Migration2010-01-13T04:50:56Z<p>J^: </p>
<hr />
<div>This page is for collecting patches related to the [[Ogg Index]] introduction.<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the OggIndex.<br />
<br />
=== Encoders ===<br />
<br />
* ffmpeg2theora supports creating indexes<br />
<br />
* what about other encoders? VLC, GStreamer<br />
<br />
* oggz-chop support on output<br />
<br />
=== Decoders ===<br />
<br />
==== oggz-chop ====<br />
<br />
* untested<br />
<br />
<br />
==== GStreamer ====<br />
<br />
* support missing, gives error<br />
<br />
<br />
==== MPlayer ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== VLC ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== XiphQT ====<br />
<br />
* support missing, not tested<br />
<br />
<br />
==== FFMpeg ====<br />
<br />
* support missing, not tested</div>J^https://wiki.xiph.org/index.php?title=OggIndex-Migration&diff=10777OggIndex-Migration2010-01-13T04:50:10Z<p>J^: /* Encoders */</p>
<hr />
<div>This page is for collecting patches related to the [[Ogg Index]] introduction.<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the OggIndex.<br />
<br />
=== Encoders ===<br />
<br />
* ffmpeg2theora supports creating indexes<br />
<br />
* what about other encoders? VLC, GStreamer<br />
<br />
* oggz-chop support on output<br />
<br />
=== Decoders ===<br />
<br />
==== oggz-chop ====<br />
<br />
* support error<br />
<br />
<br />
==== GStreamer ====<br />
<br />
* support missing, gives error<br />
<br />
<br />
==== MPlayer ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== VLC ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== XiphQT ====<br />
<br />
* support missing, not tested<br />
<br />
<br />
==== FFMpeg ====<br />
<br />
* support missing, not tested</div>J^https://wiki.xiph.org/index.php?title=OggIndex-Migration&diff=10776OggIndex-Migration2010-01-13T04:49:00Z<p>J^: </p>
<hr />
<div>This page is for collecting patches related to the [[Ogg Index]] introduction.<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the OggIndex.<br />
<br />
=== Encoders ===<br />
<br />
* ffmpeg2theora supports creating indexes<br />
<br />
* what about other encoders? VLC, GStreamer<br />
<br />
=== Decoders ===<br />
<br />
==== oggz-chop ====<br />
<br />
* support error<br />
<br />
<br />
==== GStreamer ====<br />
<br />
* support missing, gives error<br />
<br />
<br />
==== MPlayer ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== VLC ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== XiphQT ====<br />
<br />
* support missing, not tested<br />
<br />
<br />
==== FFMpeg ====<br />
<br />
* support missing, not tested</div>J^https://wiki.xiph.org/index.php?title=OggIndex-Migration&diff=10774OggIndex-Migration2010-01-13T04:35:37Z<p>J^: Created page with 'This page is for collecting patches related to the OggIndex introduction. Please add links and information about your favorite applications to this page! Applications which rea…'</p>
<hr />
<div>This page is for collecting patches related to the OggIndex introduction.<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the OggIndex.<br />
<br />
=== Encoders ===<br />
<br />
* ffmpeg2theora supports creating indexes<br />
<br />
* what about other encoders? VLC, GStreamer<br />
<br />
<br />
=== oggz-chop ===<br />
<br />
* support error<br />
<br />
<br />
==== GStreamer ====<br />
<br />
* support missing, gives error<br />
<br />
<br />
==== MPlayer ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== VLC ====<br />
<br />
* support missing, no error<br />
<br />
<br />
==== XiphQT ====<br />
<br />
* support missing, not tested<br />
<br />
<br />
==== FFMpeg ====<br />
<br />
* support missing, not tested</div>J^https://wiki.xiph.org/index.php?title=HTML5&diff=10608HTML52009-10-27T10:30:24Z<p>J^: fix link</p>
<hr />
<div>The HTML5 specification includes support for &lt;video&gt; and &lt;audio&gt;.<br />
This page outlines use of HTML5 syntax with Xiph.Org codecs, particularly Ogg [[Theora]] and Ogg [[Vorbis]]. It is also a place to collect ideas for [http://ogg.org/ ogg.org].<br />
<br />
See also the [http://en.flossmanuals.net/theoracookbook Theora Cookbook] for a guide to streaming and working with Ogg Theora.<br />
<br />
== Browser Support ==<br />
<br />
Our list of [[TheoraSoftwarePlayers]] lists many general-purpose media players that support Ogg Theora.<br />
<br />
These web browsers support HTML5 with Ogg video:<br />
<br />
=== Mozilla Firefox ===<br />
<br />
[http://www.mozilla.com/en-US/firefox/firefox.html Firefox 3.5]<br />
includes "support for the HTML5 <video> and <audio> elements including native support for Ogg Theora encoded video and Vorbis encoded audio." See [https://developer.mozilla.org/en/Using_audio_and_video_in_Firefox Using audio and video in Firefox] at the Mozilla Developer Center for more info.<br />
<br />
=== Opera ===<br />
<br />
In [http://dev.opera.com/articles/view/a-call-for-video-on-the-web-opera-vid/ A call for video on the web - Opera <video> release on Labs], Opera announce that they "have created an experimental build of our browser for Windows, Mac and Linux with ... support for the <video> element/Ogg Theora built in".<br />
<br />
The article contains links to experimental builds of Opera 9.52, and provides some simple examples of HTML5 <video> markup.<br />
<br />
=== Google Chrome ===<br />
<br />
Unstable builds are available from the<br />
[http://dev.chromium.org/getting-involved/dev-channel dev-channel].<br />
The first version supporting Ogg Theora was chrome 3.0.182.2.<br />
<br />
=== Apple Safari ===<br />
<br />
Install [[XiphQT]]<br />
<br />
=== Microsoft Internet Explorer ===<br />
<br />
* The default install of [http://www.videolan.org/vlc/ VLC] includes the activeX extension that enables inline ogg theora playback. <br />
* You can also install the [http://www.xiph.org/dshow/ direct show filters] for windows media player.<br />
<br />
=== Plugins ===<br />
<br />
[http://itheora.org/?p=screens Compatibility]<br />
<br />
== Web Video sites ==<br />
<br />
For more examples of Ogg Theora video, see<br />
[[List of Theora videos]].<br />
<br />
The following web sites support HTML5 with Ogg Theora.<br />
<br />
=== Community upload sites ===<br />
<br />
These sites allow anyone to upload video, and provide transcoding<br />
to Ogg:<br />
<br />
* [http://www.dailymotion.com DailyMotion]. See also DailyMotion's [http://www.dailymotion.com/openvideodemo Open Video Demo] (restricted to Firefox 3.5)<br />
* Chris Double's [http://tinyvid.tv Tinyvid] (transcoding via Firefogg)<br />
<br />
=== Archival and Reference ===<br />
<br />
Sites that curate video for general archival and reference purposes,<br />
and allow anyone to upload relevant material:<br />
<br />
* [http://www.archive.org/details/movies Archive.org’s videos]<br />
* [http://commons.wikimedia.org/wiki/Category:Videos_by_format Wikipedia’s videos]<br />
<br />
=== Projects ===<br />
<br />
* [http://metavid.org metavid]: The Open Video archive of the US Congress<br />
* [http://pad.ma pad.ma]: Public Access Digital Media Archive is an online archive of densely text-annotated video material, primarily footage and not finished films.<br />
<br />
=== Conferences ===<br />
<br />
* [http://mirror.linux.org.au/linux.conf.au/ linux.conf.au]<br />
* DebConf: on the individual conference pages, e.g. [http://wiki.debconf.org/wiki/DebConf8/Streams]<br />
* The [http://www.foms-workshop.org/foms2009/pmwiki.php/Main/Proceedings FOMS workshop videos]: proceedings from a workshop on free and open multimedia software.<br />
<br />
== Technology for setting up your own site ==<br />
<br />
=== HTML5 &lt;video&gt; embedding ===<br />
<br />
There are various ways to provide HTML5 video content with fallbacks for older browsers and non-free codecs.<br />
<br />
You can include one of the scripts below, or modify source from an existing page such as the HTML of<br />
[http://www.celt-codec.org/presentations/ CELT presentations].<br />
<br />
==== mv_embed ====<br />
<br />
[http://metavid.org/w/index.php/Mv_embed Mv_embed] is "a javascript library for easy embedding of ogg theora/vorbis media with the html5 tag. Once the script is included you can include an inline ogg theora clip with:<br />
<br />
<video src="mymovie.ogg"><br />
<br />
"Mv_embed will then rewrite the video tag to whatever playback method is available on the client be it native support, java cortado, mplayer or vlc".<br />
<br />
* [http://firefogg.org/make/mwEmbed/example_usage/Player_Simple_Themable.html Demo and sample HTML].<br />
<br />
See also [http://www.mediawiki.org/wiki/Media_Projects_Overview#MwEmbed mv_embed on MediaWiki].<br />
<br />
==== iTheora ====<br />
<br />
[http://itheora.org/ iTheora]<br />
<br />
Example sites using iTheora:<br />
* [http://theorasea.org]<br />
<br />
<br />
==== video4all ====<br />
<br />
[http://code.google.com/p/video4all/ video4all at Google Code]<br />
<br />
Uses browser specific technology (.htc, .xbl, or plain .js) to rewrite video tags to fall back to H.264 in Flash for legacy browsers, while providing H.264 natively to Safari and Theora for Mozilla. Roughly speaking a script version of Kroc Camen's pure HTML Video For Everybody solution. Doesn't (currently) use any Theora based fallbacks.<br />
<br />
==== Video for Everybody ====<br />
<br />
[http://camendesign.com/code/video_for_everybody Video for Everybody] is<br />
"a chunk of HTML code that embeds a video into a website<br />
using the HTML5 <video> element."<br />
<br />
:*Comment: We really shouldn't be plugging a solution which eschews cortado as a fall back in favor of FLV. A pure HTML triple check video/java/youtube would be better, but no pure HTML solution perform a canplaytype so it will break for safari users without xiphqt. Is "possible to add raw HTML but no JS" a common enough situation that a JS free solution is really needed? --[[User:Gmaxwell|Gmaxwell]] 22:58, 30 June 2009 (PDT)<br />
<br />
:*Comment: It's clear that this solution makes a few compromises in order to be JS-free. The code is both fragile and frightening for reasons that make sense with regard to the original author's goals but aren't relevant if e.g. promoting Theora adoption takes precedence over a distaste for Java and/or Javascript. --[[User:Bod|Bod]] 06:03, 6 July 2009 (PDT)<br />
<br />
=== HTML5 &lt;audio&gt; embedding ===<br />
<br />
There are various ways to provide HTML5 audio content in Vorbis and there are Java and Flash fallbacks for older browsers (and non-free codecs though this is even less necessary than it is in the case of Theora video).<br />
<br />
==== Vorbis via Flash 10 ====<br />
<br />
[http://barelyfocused.net/blog/2008/10/03/flash-vorbis-player/ fogg (aka FVorbis)], [[Jorbis]] code automatically ported to Haxe and then compiled to AS3<br />
<br />
[http://labs.adobe.com/wiki/index.php/Alchemy:Libraries Alchemy Vorbis], Adobe's Alchemy allows compiling C and C++ plus to AS3. Vorbis is one of the demo libraries they ported.<br />
<br />
[http://flash.j-ogg.de/10/ flash.j-ogg], haxe and actionscript3 translation of j-ogg<br />
<br />
==== Vorbis via Java ====<br />
<br />
[http://www.jcraft.com/jorbis/ JorbisPlayer]<br />
<br />
[http://www.j-ogg.de/core/main?/index-vorbis.html J-Ogg]<br />
<br />
==== Vorbis via Javascript and &lt;audio&gt; tag ====<br />
<br />
[http://alpha.libre.fm/listen/?tag=rock web radio interface]<br />
<br />
<br />
=== Encoding, transcoding ===<br />
<br />
==== Firefogg ====<br />
<br />
[http://firefogg.org/ Firefogg] provides "video encoding and uploading for Firefox". This includes a Firefox extension that allows users to encode video to Ogg Theora on their own computer while uploading it to your site. This simplifies the upload for users as they can simply choose from their existing video files, and simplifies your web site by allowing you to deal with only one video format, and offloading the CPU cycles required for encoding to the user.<br />
<br />
=== Content management ===<br />
<br />
* The [http://www.mediawiki.org/wiki/Extension:OggHandler OggHandler extension] for MediaWiki provides video and audio support with automatic fallback and thumbnailing. <br />
* [http://metavid.org/wiki/MetaVidWiki_Software MetaVidWiki]<br />
<br />
=== Backend servers ===<br />
<br />
* [http://www.xiph.org/oggz/ oggz-chop] allows you to serve time ranges of Ogg media over HTTP by any web server that supports CGI. Examples of such time range requests are http://www.example.com/video.ogv?t=200/600 which serves the segment of video.ogv from 200s-600s. This allows users to instantly jump to any point in a video, and you can put links in your web application to play arbitrary scenes.</div>J^https://wiki.xiph.org/index.php?title=List_of_Theora_videos&diff=10448List of Theora videos2009-07-21T09:16:40Z<p>J^: /* Uncatergorized videos */</p>
<hr />
<div>This is a list of sites where you can download videos encoded with [[Theora]].<br />
<br />
=== Serial and Episodic ===<br />
;[http://electrovid.blip.tv/ ElectroVid]: Learn basic electronics from a electrical engineering student attending University of York.<br />
;[http://www.internautas.tv/ Iternautas Television]: Spanish website with clips from the Andaluzian station. Content licensed under CC-BY-NC.<br />
;[http://www.high-density.org/category/episodes-ogg-theora/ High Density]: A show about technology and politics, with a focus on simple explanations for interesting innovations. Hosted by Ramon Cahenzli and Shane Coughlan.<br />
;[http://www.jupiterbroadcasting.com/?cat=4 Linux Action Show]: Video broadcast of the Linux Action Show during live recording. Audio podcasts are vorbis-encoded.<br />
;[http://www.linuxjournal.com/video Linux Journal]: Linux related tips and tricks, in-depth tutorials, product reviews, and insights.<br />
;[http://metavid.org Metavid]: Archive of the House of Representatives and Senate (USA) floor footage.<br />
;[http://dekku.nofatclips.com/ No Fat Clips!!!]: Short films, music videos, hip commercials, and other kinds of short visual entertainment. Updated daily. (English and Italian language)<br />
;[http://video.indypgh.org Rustbelt TV]: [http://pittsburgh.indypgh.org Pittsburgh Indymedia's] TV program based on [http://radio.indypgh.org Rustbelt Radio] (audio available as ogg vorbis).<br />
;[http://ryanishungry.com RyanIsHungry]: Features the stories of individuals hacking everyday life, with environmental sustainability.<br />
;[http://revision3.com/thebroken/ thebroken]: Four technology episodes, from 2003 to 2006, that look at the computer hacker mentality.<br />
;[http://www.thesourceshow.org/ the_source]: A video show providing news, reviews, and general discussion about open source initiatives, since 2006.<br />
;[http://www.uncensoredinterview.com/ Uncensored Interview]: Thousands of musician interviews available under a creative commons license and as a Theora-encoded file. Look for the "Download Clip" link above the embedded Flash Player on many of the webpages.<br />
;[http://wftlbytes.com/ WFTL Bytes]: An "''occasiodaily''" FOSS and Linux News Show. Theora-formatted since October 2008.<br />
<br />
=== Video Sharing Services ===<br />
;[http://blip.tv/search?q=ogg Blip.tv]: A video sharing website which allows the upload and the download of ''Ogg Theora'' files.<br />
;[http://olpc.dailymotion.com/ Dailymotion OLPC Group]: A dedicated space to save the videos created by XO users.<br />
;[http://www.engagemedia.org/Members/okvideo/ogg-videos/ Engage Media]: A video sharing website which focuses on social justice and environmental issues in South East Asia.<br />
;[http://giss.tv/ G.I.S.S. TV]: Global Independent Streaming Support. Free streaming services for free media. Free as in cost, free as in software. Individual videos are shared on the [http://giss.tv/dmmdb/ Distributed Media Database] webpage.<br />
;[http://omploader.org/ Omploader]: A streamlined video sharing website for ''Ogg Theora'' encoded files up to one gigabyte in size.<br />
;[http://theorasea.org/ Theora Sea]: A directory of online and free videos using [http://menguy.aymeric.free.fr/theora/ ITheora].<br />
;[http://tinyvid.tv/ TinyVid]: An experimental Ogg video uploading site, which exists to test out usage of the HTML 5 video and audio elements with the Ogg codecs. You'll need a web browser that can playback Ogg media using ''video'' and ''audio'' tags, to display this video media.<br />
;[http://v2v.cc/ V2V]: A video syndication network which uses only open source software, in order to provide free and equal access to the video source.<br />
;[http://commons.wikimedia.org/ Wikimedia Commons]: An archive database of [http://commons.wikimedia.org/wiki/Special:Statistics more than 4'000'000] media files ([http://commons.wikimedia.org/wiki/Commons:MIME_type_statistics over 2500 of them] are video), to which anyone can contribute.<br />
Note: A list of video sharing websites which support the ''upload'' of Ogg files can be found on [http://en.wikipedia.org/wiki/Comparison_of_video_services#Upload_file_formats Wikipedia], all of them however will force-convert all incoming videos into a "flash" format, thus apply a "free and lossy into proprietary and lossy" conversion. The page ''doesn't'' contain any information about video services allowing to ''host'' files in OGG format.<br />
<br />
=== Short Films ===<br />
;[http://intanto.org/cgi-bin/lala.sh?video 11200 Undo]: A short movie about computer, religion, sex, glue and so on...<br />
;[http://www.bigbuckbunny.org/index.php/download/ Big Buck Bunny] (2008): An open content, short animated film by the Blender Institute. Also known as by the project codename, Peach. Available in 720p and smaller sizes.<br />
;[http://wiki.xiph.org/index.php/Elephants_Dream Elephants Dream] (2006): An open content, short animated film by the Blender Institute. Also known as by the project codename, Orange. [http://orange.blender.org/background More about the project...]<br />
;[http://internetarchive.wordpress.com/2008/11/25/rederiving-our-movies-to-ogg-theora-and-more/ Internet Archive]: Thousands of digital movies which range from classic full-length films, to daily alternative news broadcasts, to videos of every genre.<br />
;[http://www.polycrystal.org/lego/movies.html Lego Movies]: Two short movies: ''A New Computer'' and ''Swim''.<br />
;[http://www.flashingtwelve.brickfilms.com/Website/films.html More Lego Movies]: Submissions from an animation contest. Also available as [http://flashingtwelve.brickfilms.com/Website/OperaDemo.html HTML-5 video tag elements] on a separate page.<br />
;[http://www.naomiklein.org/shock-doctrine/short-film Shock Doctrine]: A short film by Alfonso Cuarón and Naomi Klein, directed by Jonás Cuarón.<br />
;[http://www.sitasingstheblues.com/wiki/index.php?title=SitaSites Sita Sings the Blues] (2009): Acclaimed, animated film by Nina Paley.<br />
;[http://footage.stealthisfilm.com/ Steal This Film 2] (2007): Video archive of the numerous interviews used, and not used, in the documentary.<br />
;[http://www.valkaama.com/ Valkaama]: A collaborative, "open source" movie project, under a creative commons license.<br />
;[http://www.archive.org/details/VoyagetothePlanetofPrehistoricWomen Voyage to the Planet of Prehistoric Women] (1967) and [http://www.archive.org/details/TheSnowCreature The Snow Creature] (1954): Full-length public domain movies from the Internet Archive's [http://www.archive.org/details/feature_films collection].<br />
<br />
=== Scientific Demonstrations ===<br />
;[http://ptaff.ca/orage_montreal/?lang=en_CA 1696 Lightnings]: Visual and audible demonstration of a lightning storm in Montreal.<br />
;[http://www.deepvision.ca/tech_example4.php Deep Vision]: Technical demonstrations of the features of Deep Vision's ''Machine Perception''.<br />
;[http://www.rethaw.com/wp/category/videos/ Rethaw]: Conceptual resonance with ice, by David Steinberg.<br />
;[http://selectparks.net/~julian/index.php?entry=entry060602-125815 SysBlog]: Two videos on computer graphic engines: ''fijuu2'' and ''q3apd''.<br />
<br />
=== Streaming Media ===<br />
;[http://gwolf.org/blog/ogg-stream-ecsl ECSL]: El Software Libre 2009 conference streamed a live broadcast of presentations live June 18-21. (Spanish language)<br />
;[http://www.editingarchive.com/eatv/ Editing Archive TV]: Streams unlicensed Japanese anime, amateur machinima films, and video game captures.<br />
;[http://webcam.firestorm.cx/ Phil's Nest Box]: Live video from nest boxes in the UK.<br />
;[http://www.live-radio.ru:8111/video.ogg Rare Music Live]: Rare international contemporary indie rock music videos. (Russian language)<br />
;[http://iptv.okto.tv:8080/okto.ogg.m3u Theora Livestream]: from Vienna based community TV station [http://okto.tv Okto]<br />
;[http://www.lodzkie.pl/lodzkie/sesjaSejmikuWL_online.html Transmisje Sejmiku Województwa Łódzkiego]: A live broadcast of the Sejmik of the Łódź Voivodship in Poland (regional parliament). (available only when meetings take place, in polish)<br />
;[http://tvmallorca.net/pages/tv_online TV Mallorca]: Streams the ''Mallorca'' television station content through streaming online. (Spanish language)<br />
;[http://www.vaguetv.com/ VagueTV]: A spring-off project from Radio Vague, and distributed under the GNU Free Document License.<br />
;[http://www.visonair.tv/ Visonair.tv]: Provides video producers open-access to online media streaming, in a format stylized after a television channel.<br />
;[http://modulix.org/ WebTV]: Télévision libre - Contenu Libre. (French language)<br />
<br />
=== GNU/Linux Philosophical ===<br />
;[http://computerworld.co.nz/news.nsf/news/1461E04FC8D3293FCC2574A500173A09 Computerworld]: Recording of a speech on copyright, at Auckland University, New Zealand.<br />
;[http://support.creativecommons.org/videos/ Creative Commons]: Informational videos about Creative Commons, a charitable corporation which promotes alternative copyright licenses.<br />
;[http://free-electrons.com/community/videos/conferences/en Free Electrons Conferences]: Technical talks given at conferences about free software.<br />
;[http://www.gnu.org/fry/ Freedom Fry]: Short film celebrating the 25th anniversary of the GNU operating system, starting Stephen Fry, entitled ''Happy birthday to GNU''.<br />
;[http://audio-video.gnu.org/ GNU and FSF Audio and Video Repository]: Collection of audio and video content, primarily speeches on Free Software.<br />
;[http://gplv3.fsf.org/av GPLv3 Conference, January 16-17 2006]: Speeches by Peter Brown, Eben Moglen and Richard Stallman.<br />
;[http://www.initmarketing.tv/ InitMarketing.tv]: Open source software marketing videos.<br />
;[http://www.gnu.org/philosophy/audio/audio.html GNU Project's Philosophy Speeches]: Featuring Richard Stallman and others.<br />
;[http://punkcast.com/905/ PUNKCAST#905]: Two speeches by Richard Stallman: ''What's GNU?'' and ''St. IGNUcius''.<br />
;[http://www.gulix.cl/wiki/Spot_Publicitario_FLISOL_2009 Reunión 2009]: A two part performance illustrating the virtues of free software.<br />
;[http://www.chtlj.org/ Santa Clara Computer and High Technology Journal]: Several lecture videos including the 2008 Symposium.<br />
;[http://www.opensourcetv.tv/ Utah Open Source Conference 2008]: Week-long conference to discuss Novell, GNOME, and other topics related to the open source community in the state of Utah of USA.<br />
<br />
=== GNU/Linux Technical ===<br />
;[http://wiki.debconf.org/wiki/Videoteam Debian Videos]: the annual Debian developers meeting, an event filled with discussions and workshops. <br />
;[http://fedoraproject.org/wiki/RenderingProject/aiglx AIGLX]: Demonstration videos for AIGLX, a project that aims to enable GL-accelerated effects on a standard desktop.<br />
;[http://dimitris.glezos.com/weblog/2008/03/26/fosscomm-recap/ Community ''foo'']: A speech by Dimitris Glezos, from the Fedora Project, at FOSSComm 2008. (Greek language)<br />
;[http://linux.dell.com/vlogs/ Dell Linux Engineering Vlogs]: Recordings of interviews from Dell's Linux team, from 2006.<br />
;[http://linmagazine.co.il/fedora/2008/02/06/fedora-9-alpha Fedora 9]: Video demonstration of Resizing feature in Fedora 9. (Hebrew language)<br />
;[http://video.fosdem.org/ FOSDEM Speeches]: Video recordings of ''Free and Open Source'' developer talks held at FOSDEM editions from 2005 and onward.<br />
;[http://www.kde.org/announcements/4.2/ KDE 4.2]: Announcement of the new KDE free desktop solution uses several videos to demonstrate the new features.<br />
;[http://dot.kde.org/1213190021/ KDE Day]: Video recordings of technical talks at a conference commemorating the release of KDE 4, in Toulouse, France.<br />
;[http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-April/022845.html Linux Audio Conference]: Video recordings of technical talks at the 2009 conference. <br />
;[http://www.linuxgamingworld.com/ Linux Gaming World]: Website focusing on commercial GNU/Linux games, with many video trailers in ''Ogg Theora'' format.<br />
;[http://macslow.thepimp.net/ MacSlow Blog]: A few videos demonstrating GUI elements, linked from a developer's blog.<br />
;[http://www.novell.com/brainshare/keynotes.html Novell Brainshare]: The three keynote speeches which were presented at Novell's Brainshare, in 2006.<br />
;[http://blog.boucault.net/ Omphaloskeptical]: Blog about GStreamer and Elisa with many screencast tutorials.<br />
;[http://www.opensourcetv.tv/ Open Source TV]: A collection of open source related videos.<br />
;[http://www.ramin.com.au/linux/acs-os-sig.html Open Source Video]: Presentation and lecture notes on video editing and publication using open source tools and ''Ogg Theora'' video.<br />
;[http://www.opensourceworldconference.com/oswc/programme Open Source World Conference]: Video recordings of technical talks, held October 2008. (Spanish language)<br />
;[http://www.redhat.com/solutions/info/videos/ Red Hat Videos]: Videos about the GNU/Linux vendor's customers and solutions.<br />
;[http://ozlabs.org/~rusty/index.cgi/tech/2009-01-14.html Rusty's]: Video demonstration of libantithread 0.1, on Rusty's Bleeding Edge Page.<br />
;[http://tube.opensuse.org/ tube.openSUSE.org]: The official repository of videos by the openSUSE people, such as software developer interviews, instructional screencasts, and conference speeches.<br />
;[http://www.twistedlincoln.com/linuxclass Twisted Lincoln]: Two instructional videos on the use of the GNU/Linux operating system.<br />
;[http://screencasts.ubuntu.com/ Ubuntu Screencasts] and [http://videos.ubuntu.com/ Ubuntu Videos]: Video tutorials and graphical demonstrations on how to use the Ubuntu operating system.<br />
;[http://blog.eracc.com/2009/02/04/windows-98-linux-and-virtualbox-maybe/ VirtualBox Demonstration]: The ERACC Web Log discusses running the Windows 98 operating system with VirtualBox.<br />
;[http://www.yofrankie.org/?p=514 Yo Frankie!]: A technology demonstration of an open source, 3D video game, created by the Blender Institute. Code named ''Apricot''.<br />
<br />
=== Web/Internet Technical ===<br />
;[http://media.annodex.net/cmmlwiki/Special:ListHTML Annodex]: Combination of ''Theora'' video examples, from Open Source Forum 2005 and other events. Annodex applies open standards in annotating and indexing networked media. Software, produced by Annodex, is [http://www.linuxworld.com.au/article/274174/wikipedia_video_gets_boost_100_000_mozilla_grant used by Wikipedia to host ''Theora'' media] online<br />
;[http://welcomebackstage.com/2009/04/rd-tv-a-collaborative-project-between-bbc-backstage-rad/ BBC R&DTV]: A pilot project made up of interviews from knowledgeable BBC developers, BBC project experts and external experts from around the world, which includes uncut footage under a creative commons non-commercial attribution v2 license. Also see their [http://welcomebackstage.com/2009/06/rdtv-episode-2/ Episode Two] of R&DTV.<br />
;[http://www.unix-ag.uni-kl.de/~fischer/blog/20071230_Ogg_Theora_Applet_instead_of_Flash/ Cortado Demonstration]: A Java applet by GStreamer that can stream Ogg Theora files, so video media can be embedded into webpages. This site also provides instructions on using the applet.<br />
;[http://szeged2008.drupalcon.org/ Drupalcon 2008]: Recordings of conference speeches in ''Ogg Theora'' format. Drupal is an website framework and ''Free Software''.<br />
;[http://envycasts.com/ Envy Casts]: Tutorials available for download in ''Ogg Theora'' after purchase. Instructor led training for Ruby on Rails computer programming.<br />
;[http://www.mozilla.com/en-US/firefox/video/ Firefox 3 Screencast]: Firefox 3 screenshot and advertising video<br />
;[http://www.double.co.nz/video_test/ Firefox] and [http://dev.opera.com/articles/view/a-call-for-video-on-the-web-opera-vid/ Opera] HTML5 Tests: Implementation examples of the HTML "video tag", using ''Theora'' video formats.<br />
;[http://annevankesteren.nl/2008/09/fronteers-html5-video HTML5 Demonstration]: Anne van Kesteren's Fronteers HTML 5 presentation which has ''video'' tags embedded in the presentation itself.<br />
;[http://www.niallkennedy.com/blog/ Naill Kennedy Blog]: Web journal that explores how syndication and new business are changing life on the web, including insight into [http://www.niallkennedy.com/blog/2006/10/video-search.html video technologies]. Presentations are encoded into ''Theora'' format.<br />
;[http://peepcode.com/ PeepCode Screencasts]: Hour-long instruction videos that teach Ruby on Rails website development.<br />
;[http://realeyes.sourceforge.net/technology.html Realeyes Demonstration]: A [http://www.gnu.org/licenses/gpl.html GPL-licensed] ''C'' library of functions that maintain state information and analysis results about streams of data. These instructional videos walkthrough a network Intrusion Detection System application, based on this library.<br />
;[http://www.rumblingedge.com/2009/03/10/nus-cs3108-mid-way-presentations-on-video/ Thunderbird Presentations]: University students presenting information about their experiences within the Thunderbird project. Thunderbird is an open source email client, for desktop computers.<br />
;[http://www.qdh.org.uk/wordpress/?p=261 Timeline Widget]: A visual introduction to a simple web widget, which illustrates scaling, zooming, and panning.<br />
;[http://transparencycamp.org/videos/ Transparency Camp]: Interviews with keynote speakers at the 2009 Transparency Camp conference. The conference addressed using computer technology for a more open and accountable governance.<br />
;[http://lachy.id.au/log/2007/06/webjam3 WebJam 3]: Short video highlight of the WebJam 3, held in 2007. Media is free of copyright restrictions (public domain).<br />
<br />
=== Uncatergorized videos ===<br />
;[http://events.ccc.de/congress/2008/wiki/Conference_Recordings 25C3 Recordings]: Computer-security conference speeches.<br />
;[http://www.bitlet.org/video Bitlet]: A prototype for a P2P video sharing and video hosting service.<br />
;[http://www.wesnoth.org/wiki/Trailer Battle of Wesnoth Trailer]: The Battle for Wesnoth is a free, turn-based strategy computer game with a fantasy theme. Video licensed under GNU Free Documentation License.<br />
;[http://vancouver.ca/ctyclerk/archives/webpubhtml/qbes/MovingImages/MovingImageHighlights.htm City of Vancouver Archives]: A historical preservation society in Canada that specializes in images and film-based moving images.<br />
;[http://www.dictionaryofwar.org Dictionary of war]: is a collaborative platform for creating concepts on the topic of "war", to be invented, arranged and presented at a public, two-day event. The aim is to introduce a series of concepts that either play an important role in the contemporary discourse of war, have so far been neglected, or have yet to be created.<br />
;[http://www.geekentertainment.tv Geek Entertainment TV]: A weekly video-cast covering technology topics, in an interview format. Many ''Ogg Theora'' format videos in the 2007 and prior archives. <br />
;[http://lessig.org/content/av/ Lawrence Lessig Videos]: Video recordings of speeches and presentations given by Lawrence Lessig on such topics as copyright ''fair use'' and the Creative Commons License. Various media formats, including Theora-encoded.<br />
;[http://open-government.us/ Open Government Petition]: Lawrence Lessig and the Mozilla Foundation have created an online petition for a technologically open (USA) federal government. The video on the web site is in three formats, including ''Theora''.<br />
;[http://pad.ma/about Public Access Digital Media Archive]: Online archive of densely text-annotated video material, primarily footage and not finished films. The entire collection is searchable and viewable online, and is free to download for non- commercial use. <br />
;[http://www.pragprog.com/screencasts Pragmatic Programmer]: Technical tutorial screencasts for sale. Some screencasts and screencast previews are available in ''Ogg Vorbis'' format, including ''The Ruby Object Model and Metaprogramming'', ''Erlang by Example'', and ''Everyday Active Record''.<br />
;[http://wiki.scribus.net/index.php/Scribus_Video_Tutorials Scribus Tutorials]: Several video tutorials for Scribus, a desktop publishing application, for various skill ranges.<br />
;[http://ulm.ccc.de/ChaosSeminar Ulm CCC Chaosseminar]: Computer-security conference speeches. (German language)<br />
;[http://networkcultures.org/wpmu/wintercamp/videos/ Wintercamp]: Video interviews with participants of the 2009 Institute of Network Cultures conference.<br />
<br />
== See also== <br />
{{Template:Theora}}<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=Ogg_Skeleton_3&diff=10252Ogg Skeleton 32009-06-09T18:04:36Z<p>J^: /* Development */</p>
<hr />
<div>'''Ogg Skeleton''' provides structuring information for multitrack [[Ogg]] files. It is compatible with Ogg [[Theora]] and provides extra clues for synchronization and content negotiation such as language selection.<br />
<br />
Ogg is a generic container format for time-continuous data streams, enabling interleaving of several tracks of frame-wise encoded content in a time-multiplexed manner. As an example, an Ogg physical bitstream could encapsulate several tracks of video encoded in Theora and multiple tracks of audio encoded in Speex or Vorbis or FLAC at the same time. A player that decodes such a bitstream could then, for example, play one video channel as the main video playback, alpha-blend another one on top of it (e.g. a caption track), play a main Vorbis audio together with several FLAC audio tracks simultaneously (e.g. as sound effects), and provide a choice of Speex channels (e.g. providing commentary in different languages). Such a file is generally possible to create with Ogg, it is however not possible to generically parse such a file, seek on it, understand what codecs are contained in such a file, and dynamically handle and play back such content. <br />
<br />
Ogg does not know anything about the content it carries and leaves it to the media mapping of each codec to declare and describe itself. There is no meta information available at the Ogg level about the content tracks encapsulated within an Ogg physical bitstream. This is particularly a problem if you don't have all the decoder libraries available and just want to parse an Ogg file to find out what type of data it encapsulates (such as the "file" command under *nix to determine what file it is through magic numbers), or want to seek to a temporal offset without having to decode the data (such as on a Web server that just serves out Ogg files and parts thereof).<br />
<br />
Ogg Skeleton is being designed to overcome these problems. Ogg Skeleton is a logical bitstream within an Ogg stream that contains information about the other encapsulated logical bitstreams. For each logical bitstream it provides information such as its media type, and explains the way the granulepos field in Ogg pages is mapped to time. <br />
<br />
Ogg Skeleton is also designed to allow the creation of substreams from Ogg physical bitstreams that retain the original timing information. For example, when cutting out the segment between the 7th and the 59th second of an Ogg file, it would be nice to continue to start this cut out file with a playback time of 7 seconds and not of 0. This is of particular interest if you're streaming this file from a Web server after a query for a temporal subpart such as in http://example.com/video.ogv?t=7-59 .<br />
<br />
== Specification ==<br />
<br />
This is a motivation and design sketch.<br />
'''For the current specification see http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt'''<br />
<br />
=== How to describe the logical bitstreams within an Ogg container? ===<br />
<br />
The following information about a logical bitstream is of interest to contain as meta information in the Skeleton:<br />
* the serial number: it identifies a content track<br />
* the mime type: it identifies the content type<br />
* other generic name-value fields that can provide meta information such as the language of a track or the video height and width<br />
* the number of header packets: this informs a parser about the number of actual header packets in an Ogg logical bitstream<br />
* the granule rate: the granule rate represents the data rate in Hz at which content is sampled for the particular logical bitstream. Note that when using this to interpret timestamps, the granulepos of a data page must first be parsed to extract a granule value using the method described in [[GranulePosAndSeeking]]. This value can then be mapped to time by calculating "granules / granulerate".<br />
* the preroll: the number of past content packets to take into account when decoding the current Ogg page, which is necessary for seeking (vorbis has generally 2, speex 3)<br />
* the granuleshift: the number of lower bits from the granulepos field that are used to provide position information for sub-seekable units (like the keyframe shift in theora)<br />
* a basetime: it provides a mapping for granule position 0 (for all logical bitstreams) to a playback time; an example use: most content in professional analog video creation actually starts at a time of 1 hour and thus adding this additional field allows them retain this mapping on digitizing their content<br />
* a UTC time: it provides a mapping for granule position 0 (for all logical bitstreams) to a real-world clock time allowing to remember e.g. the recording or broadcast time of some content<br />
<br />
=== How to allow the creation of substreams from an Ogg physical bitstream? ===<br />
<br />
When cutting out a subpart of an Ogg physical bitstream, the aim is to keep all the content pages intact (including the framing and granule positions) and just change some information in the Skeleton that allows reconstruction of the accurate time mapping. When remultiplexing such a bitstream, it is necessary to take into account all the different contained logical bitstreams. A given cut-in time maps to several different byte positions in the Ogg physical bitstream because each logical bitstream has its relevant information for that time at a different location. In addition, the resolution of each logical bitstream may not be high enough to accommodate for the given cut-in time and thus there may be some surplus information necessary to be remuxed into the new bitstream.<br />
<br />
The following information is necessary to be added to the Skeleton to allow a correct presentation of a subpart of an Ogg bitstream:<br />
* the presentation time: this is the actual cut-in time and all logical bitstreams are meant to start presenting from this time onwards, not from the time their data starts, which may be some time before that (because this time may have mapped right into the middle of a packet, or because the logical bitstream has a preroll or a keyframe shift)<br />
* the basegranule: this represents the granule number with which this logical bitstream starts in the remuxed stream and provides for each logical bitstream the accurate start time of its data stream; this information is necessary to allow correct decoding and timing of the first data packets contained in a logcial bitstream of a remuxed Ogg stream<br />
<br />
=== Ogg Skeleton version 3.0 Format Specification ===<br />
<br />
Adding the above information into an Ogg bitstream without breaking existing Ogg functionality and code requires the use of a logical bitstream for Ogg Skeleton. This logical bitstream may be ignored on decoding such that existing players can still continue to play back Ogg files that have a Skeleton bitstream. Skeleton enriches the Ogg bitstream to provide meta information about structure and content of the Ogg bitstream.<br />
<br />
The Skeleton logical bitstream starts with an ident header that contains information about all of the logical bitstreams and is mapped into the Skeleton bos page.<br />
The first 8 bytes provide the magic identifier "fishead\0".<br />
After the fishead follows a set of secondary header packets, each of which contains information about one logical bitstream. These secondary header packets are identified by an 8 byte code of "fisbone\0". The Skeleton logical bitstream has no actual content packets. Its eos page is included into the stream before any data pages of the other logical bitstreams appear and contains a packet of length 0.<br />
<br />
The fishead ident header looks as follows ([http://annodex.org/w/images/3/39/FishHeads.JPG inspiration]):<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Identifier 'fishead\0' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Version major | Version minor | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Presentationtime numerator | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Presentationtime denominator | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Basetime numerator | 28-31<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 32-35<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Basetime denominator | 36-39<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 40-43<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| UTC | 44-47<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 48-51<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 52-55<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 56-59<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 60-63<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
The version fields provide version information for the Skeleton track, currently being 3.0 (the number having evolved within the Annodex project).<br />
Presentation time and basetime are specified as a rational number, the denominator providing the temporal resolution at which the time is given (e.g. to specify time in milliseconds, provide a denominator of 1000).<br />
<br />
<br />
The fisbone secondary header packet looks as follows:<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Identifier 'fisbone\0' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Offset to message header fields | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Serial number | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Number of header packets | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granulerate numerator | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granulerate denominator | 28-31<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 32-35<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Basegranule | 36-39<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 40-43<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Preroll | 44-47<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granuleshift | Padding/future use | 48-51<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Message header fields ... | 52-<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
The mime type is provided as a message header field specified in the same way that HTTP header fields are given (e.g. "Content-Type: audio/vorbis"). Further meta information (such as language and screen size) are also included as message header fields. The offset to the message header fields at the beginning of a fisbone packet is included for forward compatibility - to allow further fields to be included into the packet without disrupting the message header field parsing.<br />
The granule rate is again given as a rational number in the same way that presentation time and basetime were provided above.<br />
<br />
A further restriction on how to encapsulate Skeleton into Ogg is proposed to allow for easier parsing:<br />
* there can only be one Skeleton logical bitstream in a Ogg bitstream.<br />
* the Skeleton bos page is the very first bos page in the Ogg stream such that it can be identified straight away and decoders don't get confused about it being e.g. Ogg Vorbis without this meta information<br />
* the bos pages of all the other logical bistreams come next (a requirement of Ogg)<br />
* the secondary header pages of all logical bitstreams come next, including Skeleton's secondary header packets<br />
* the Skeleton eos page end the control section of the Ogg stream before any content pages of any of the other logical bitstreams appear<br />
<br />
== Development ==<br />
<br />
Ogg Skeleton is being supported by the following projects:<br />
* the Ogg Directshow filters: see [http://www.illiminable.com/ogg/ illiminable]<br />
* liboggz: [http://svn.annodex.net/liboggz/ liboggz svn] or [http://annodex.net/software/liboggz/ liboggz]<br />
* the Annodex technology: [http://www.annodex.net/ annodex.net]<br />
* [http://www.kfish.org/software/hogg/ HOgg] (Haskell)<br />
* ffmpeg2theora (with --skeleton) <br />
* speexenc (with --skeleton) & speexdec<br />
* many more ...<br />
<br />
== External links ==<br />
<br />
* Ogg Skeleton is described in more detail in the [http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt Skeleton I-D in svn]<br />
* Ogg Skeleton was originally specified in Annodex v3: [http://svn.annodex.net/standards/ I-D in svn] or [http://annodex.net/specifications.html I-D]<br />
<br />
<br />
[[Category:Ogg]]</div>J^https://wiki.xiph.org/index.php?title=Git&diff=10153Git2009-04-03T08:05:49Z<p>J^: </p>
<hr />
<div>==git.xiph.org==<br />
at [https://git.xiph.org git.xiph.org] you find a list of projects that are using git as VCS.<br />
you can clone those repositories and hack away.<br />
<br />
someone needs to document how one can push changes to the official repository.</div>J^https://wiki.xiph.org/index.php?title=List_of_Theora_videos&diff=9586List of Theora videos2008-11-07T19:19:03Z<p>J^: /* Web/Internet Technical */ remove dead link</p>
<hr />
<div>This is a list of sites where you can download videos encoded with [[Theora]].<br />
<br />
=== Serial and Episodic ===<br />
;[http://www.geekentertainment.tv Geek Entertainment TV]: A weekly video-cast covering technology topics, in an interview format. Many ''Ogg Theora'' format videos in the 2007 and prior archives.<br />
;[http://www.internautas.tv/ INTERNAUTAS TELEVÍSION]: Spanish website with clips from Andaluzian tv station. Content licensed under CC-BY-NC.<br />
;[http://www.linux.com/ Linux.com]: All videos, after late-2007, are in ''Ogg Theora'' format. There is an RSS feed available to be alerted to new videos, as they become available.<br />
;[http://nikosapi.org/video/LAS/ Linux Action Show]: Video broadcast of the Linux Action Show during live recording.<br />
;[http://metavid.org Metavid]: Archive of the House of Representatives and Senate (USA) floor footage. <br />
;[http://video.indypgh.org Rustbelt TV]: [http://pittsburgh.indypgh.org Pittsburgh Indymedia's] TV program based on [http://radio.indypgh.org Rustbelt Radio] (audio available as ogg vorbis).<br />
;[http://ryanishungry.com RyanIsHungry]: Features the stories of individuals hacking everyday life, with environmental sustainability.<br />
;[http://revision3.com/thebroken/ thebroken]: Four technology episodes, from 2003 to 2006, that look at the computer hacker mentality.<br />
;[http://www.thesourceshow.org/ the_source]: A video show providing news, reviews, and general discussion about open source initiatives, since 2006.<br />
<br />
=== Video Sharing Services ===<br />
A list of video sharing websites which support the ''upload'' of Ogg files can be found on [http://en.wikipedia.org/wiki/Comparison_of_video_services#Upload_file_formats Wikipedia]. Below is a shorter list of video sharing websites which support the ''download'' of Ogg files.<br />
;[http://blip.tv/search?q=ogg Blip.tv]: A video sharing website which allows the upload and the download of ''Ogg Theora'' files.<br />
;[http://www.engagemedia.org/Members/okvideo/ogg-videos/ Engage Media]: A video sharing website which focuses on social justice and environmental issues in South East Asia.<br />
;[http://theorasea.org/ Theora Sea]: A directory of online and free videos using [http://menguy.aymeric.free.fr/theora/ ITheora].<br />
;[http://tinyvid.tv/ TinyVid]: An experimental Ogg video uploading site, which exists to test out usage of the HTML 5 video and audio elements with the Ogg codecs. You'll need a web browser that can playback Ogg media using ''video'' and ''audio'' tags, to display this video media.<br />
;[http://v2v.cc/ V2V]: A video syndication network which uses only open source software, in order to provide free and equal access to the video source.<br />
;[http://commons.wikimedia.org/ Wikimedia Commons]: An archive database of [http://commons.wikimedia.org/wiki/Special:Statistics more than 3,000,000] media files, to which anyone can contribute.<br />
<br />
=== Short Films ===<br />
;[http://intanto.org/cgi-bin/lala.sh?video 11200 Undo]: A short movie about computer, religion, sex, glue and so on...<br />
;[http://www.bigbuckbunny.org/index.php/download/ Big Buck Bunny]: An open content, short animated film by the Blender Institute. Also known as by the project codename, Peach. Available in 720p and smaller sizes.<br />
;[http://wiki.xiph.org/index.php/Elephants_Dream Elephants Dream]: An open content, short animated film by the Blender Institute. Also known as by the project codename, Orange. [http://orange.blender.org/background More about the project...]<br />
;[http://www.polycrystal.org/lego/movies.html Lego Movies]: Two short movies: ''A New Computer'' and ''Swim''.<br />
;[http://www.flashingtwelve.brickfilms.com/Website/films.html More Lego Movies]: Submissions from a Theora-only animation contest.<br />
;[http://dekku.blogspot.com/ No Fat Clips!!!]: Short films, music videos, hip commercials, and other kinds of short visual entertainment. Updated daily. (English and Italian language) <br />
;[http://www.naomiklein.org/shock-doctrine/short-film Shock Doctrine]: A short film by Alfonso Cuarón and Naomi Klein, directed by Jonás Cuarón.<br />
;[http://www.archive.org/details/VoyagetothePlanetofPrehistoricWomen Voyage to the Planet of Prehistoric Women] (1967) and [http://www.archive.org/details/TheSnowCreature The Snow Creature] (1954): Full-length public domain movies from the Internet Archive's [http://www.archive.org/details/feature_films collection].<br />
<br />
=== Scientific Demonstrations ===<br />
;[http://ptaff.ca/orage_montreal/?lang=en_CA 1696 Lightnings]: Visual and audible demonstration of a lightning storm in Montreal.<br />
;[http://www.deepvision.ca/tech_example4.php Deep Vision]: Technical demonstrations of the features of Deep Vision's ''Machine Perception''.<br />
;[http://www.rethaw.com/wp/category/videos/ Rethaw]: Conceptual resonance with ice, by David Steinberg.<br />
;[http://selectparks.net/~julian/index.php?entry=entry060602-125815 SysBlog]: Two videos on computer graphic engines: ''fijuu2'' and ''q3apd''.<br />
<br />
=== Streaming Media ===<br />
;[http://www.editingarchive.com/eatv/ Editing Archive TV]: Streams unlicensed Japanese anime, amateur machinima films, and video game captures.<br />
;[http://tvmallorca.net/pages/tv_online TV Mallorca]: Streams the ''Mallorca'' television station content through streaming online. (Spanish language)<br />
;[http://www.visonair.tv/ Visonair.tv]: Provides video producers open-access to online media streaming, in a format stylized after a television channel.<br />
;[http://iptv.okto.tv:8080/okto.ogg.m3u Theora Livestream]: from Vienna based community TV station [http://okto.tv Okto]<br />
;[http://modulix.org/ WebTV]: Télévision libre - Contenu Libre. (French language)<br />
<br />
=== GNU/Linux Philosophical ===<br />
;[http://computerworld.co.nz/news.nsf/news/1461E04FC8D3293FCC2574A500173A09 Computerworld]: Recording of a speech on copyright, at Auckland University, New Zealand.<br />
;[http://support.creativecommons.org/videos/ Creative Commons]: Informational videos about Creative Commons, a charitable corporation which promotes alternative copyright licenses.<br />
;[http://free-electrons.com/community/videos/conferences/en Free Electrons Conferences]: technical talks given at conferences about free software.<br />
;[http://www.gnu.org/fry/ Freedom Fry]: Short film celebrating the 25th anniversary of the GNU operating system, starting Stephen Fry, entitled ''Happy birthday to GNU''.<br />
;[http://audio-video.gnu.org/ GNU and FSF Audio and Video Repository]: Collection of audio and video content, primarily speeches on Free Software.<br />
;[http://gplv3.fsf.org/av GPLv3 Conference, January 16-17 2006]: Speeches by Peter Brown, Eben Moglen and Richard Stallman.<br />
;[http://www.gnu.org/philosophy/audio/audio.html GNU Project's Philosophy Speeches]: Featuring Richard Stallman and others.<br />
;[http://punkcast.com/905/ PUNKCAST#905]: Two speeches by Richard Stallman: ''What's GNU?'' and ''St. IGNUcius''.<br />
<br />
=== GNU/Linux Technical ===<br />
;[http://wiki.debconf.org/wiki/Videoteam Debian Videos]: the annual Debian developers meeting, an event filled with discussions and workshops. <br />
;[http://fedoraproject.org/wiki/RenderingProject/aiglx AIGLX]: Demonstration videos for AIGLX, a project that aims to enable GL-accelerated effects on a standard desktop.<br />
;[http://dimitris.glezos.com/weblog/2008/03/26/fosscomm-recap/ Community ''foo'']: A speech by Dimitris Glezos, from the Fedora Project, at FOSSComm 2008. (Greek language)<br />
;[http://linux.dell.com/vlogs/ Dell Linux Engineering Vlogs]: Recordings of interviews from Dell's Linux team, from 2006.<br />
;[http://linmagazine.co.il/fedora/2008/02/06/fedora-9-alpha Fedora 9]: Video demonstration of Resizing feature in Fedora 9. (Hebrew language)<br />
;[http://video.fosdem.org/ FOSDEM Speeches]: Video recordings of ''Free and Open Source'' developer talks held at FOSDEM editions from 2005 and onward.<br />
;[http://dot.kde.org/1213190021/ KDE Day]: Video recordings of technical talks at a conference commemorating the release of KDE 4, in Toulouse, France.<br />
;[http://macslow.thepimp.net/ MacSlow Blog]: A few videos demonstrating GUI elements, linked from a developer's blog.<br />
;[http://www.novell.com/brainshare/keynotes.html Novell Brainshare]: The three keynote speeches which were presented at Novell's Brainshare, in 2006.<br />
;[http://www.redhat.com/solutions/info/videos/ Red Hat Videos]: Videos about the GNU/Linux vendor's customers and solutions.<br />
;[http://tube.opensuse.org/ tube.openSUSE.org]: The official repository of videos by the openSUSE people, such as software developer interviews, instructional screencasts, and conference speeches.<br />
;[http://www.twistedlincoln.com/linuxclass Twisted Lincoln]: Two instructional videos on the use of the GNU/Linux operating system.<br />
;[http://screencasts.ubuntu.com/ Ubuntu Screencasts] and [http://videos.ubuntu.com/ Ubuntu Videos]: Video tutorials and graphical demonstrations on how to use the Ubuntu operating system.<br />
<br />
=== Web/Internet Technical ===<br />
;[http://media.annodex.net/cmmlwiki/Special:ListHTML Annodex]: Combination of ''Theora'' video examples, from Open Source Forum 2005 and other events. Annodex applies open standards in annotating and indexing networked media.<br />
;[http://backstage.bbc.co.uk/news/archives/2008/11/george_wright_r.html BBC Backstage Blog]: George Wright responds to ''Backstage'' questions in a video available in ''Theora'' format.<br />
;[http://envycasts.com/ Envy Casts]: Tutorials available for download in ''Ogg Theora'' after purchase. Instructor led training for Ruby on Rails computer programming.<br />
;[http://www.double.co.nz/video_test/ Firefox] and [http://dev.opera.com/articles/view/a-call-for-video-on-the-web-opera-vid/ Opera] HTML5 Tests: Implementation examples of the HTML "video tag", using ''Theora'' video formats.<br />
;[http://annevankesteren.nl/2008/09/fronteers-html5-video HTML5 Demonstration]: Anne van Kesteren's Fronteers HTML 5 presentation which has ''video'' tags embedded in the presentation itself.<br />
;[http://lachy.id.au/log/2007/06/webjam3 WebJam 3]: Short video highlight of the WebJam 3, held in 2007. Media is free of copyright restrictions (public domain).<br />
<br />
=== Uncatergorized videos ===<br />
;[http://www.wesnoth.org/wiki/Trailer Battle of Wesnoth Trailer]: The Battle for Wesnoth is a free, turn-based strategy computer game with a fantasy theme. Video licensed under GNU Free Documentation License.<br />
;[http://www.pragprog.com/screencasts Pragmatic Programmer]: Technical tutorial screencasts for sale. Some screencasts and screencast previews are available in ''Ogg Vorbis'' format, including ''The Ruby Object Model and Metaprogramming'', ''Erlang by Example'', and ''Everyday Active Record''.<br />
;[http://ulm.ccc.de/ChaosSeminar Ulm CCC Chaosseminar]: Computer-security conference speeches. (German language)<br />
<br />
== See also== <br />
{{Template:Theora}}<br />
<br />
[[Category:Theora]]</div>J^https://wiki.xiph.org/index.php?title=MIMETypesCodecs&diff=9217MIMETypesCodecs2008-07-29T10:48:31Z<p>J^: /* Codecs Parameter */ undo until i find out whats what</p>
<hr />
<div>== Specification of MIME types and respective codecs parameter ==<br />
<br />
=== MIME Types ===<br />
<br />
The following MIME types are now officially registered with IANA (well, almost,<br />
see [[https://datatracker.ietf.org/idtracker/draft-goncalves-rfc3534bis/]]):<br />
<br />
* application/ogg - for complex, multitrack, multiplexed files encapsulated in Ogg<br />
** requires a Skeleton logical bitstream<br />
** .ogx file extension<br />
** Macintosh File Type Code: OggX<br />
<br />
* video/ogg - for video encapsulated in Ogg<br />
** recommends a Skeleton logical bitstrem<br />
** .ogv file extension<br />
** Macintosh File Type Code: OggV<br />
<br />
* audio/ogg - for audio encapsulated in Ogg<br />
** recommends a Skeleton logical bitstrem<br />
** .oga file extension, .ogg for Vorbis I, .spx for Speex<br />
** Macintosh File Type Code: OggA<br />
<br />
<br />
[[MIME_Types_and_File_Extensions|Other MIME types]] are still in the process.<br />
<br />
<br />
=== Codecs Parameter ===<br />
<br />
[http://www.rfc-editor.org/rfc/rfc4281.txt Typically], MIME types of media encapsulation formats use the optional "codecs" parameter to specify which codes are being used in a particular file.<br />
<br />
Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page to identify the encapsulated codecs. The following table contains the identifiers for existing Xiph codecs and the codecs parameter names used for */ogg MIME types (in alphabetical order):<br />
<br />
{| class="codecstable" border="1"<br />
|-<br />
! Codecs Parameter Name<br />
! Codec Identifier<br />
(decimal, hex, octal)<br />
! Version Field (if available)<br />
|-<br />
| [http://wiki.xiph.org/index.php/OggDirac dirac]<br />
| char[0,5]: <tt>'BBCD\0'</tt><br />
hex: <tt>'0x42 0x42 0x43 0x44 00'</tt><br />
<br />
oct: <tt>'0102 0102 0103 0104 0000'</tt><br />
| ??<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h celt]<br />
| char[0,8]: <tt>'CELT\ \ \ \ '</tt><br />
hex: <tt>'0x43 0x45 0x4c 0x54 0x20 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0103 0105 0114 0124 0040 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h cmml]<br />
| char[0,8]: <tt>'CMML\0\0\0\0'</tt><br />
hex: <tt>'0x43 0x4d 0x4d 0x4c 0x00 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0103 0115 0115 0114 0000 0000 0000 0000'</tt><br />
| char[8,2]: major version number,<br />
char[10,2]: minor version number<br />
|-<br />
| [http://flac.sourceforge.net/ogg_mapping.html flac]<br />
| char[0,5]: <tt>'\177FLAC'</tt><br />
hex: <tt>'0x7F 0x46 0x4C 0x41 0x43'</tt><br />
<br />
oct: <tt>'0177 0106 0114 0101 0103'</tt><br />
| char[5,1]: binary major version number, <br />
char[6,1]: binary minor version number of mapping<br />
|-<br />
| [[OggMNG|jng]]<br />
| char[0,8]: <tt>'\213JNG\r\n\032\n'</tt><br />
hex: <tt>'0x8b 0x4a 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0213 0112 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggKate|kate]]<br />
| char[0,8]: <tt>'\x80kate\0\0\0'</tt><br />
hex: <tt>'0x80 0x6b 0x61 0x74 0x65 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0200 0153 0141 0164 0145 0000 0000 0000'</tt><br />
| char[9,1]: major version number,<br />
char[10,1]: minor version number<br />
|-<br />
| [http://lists.xiph.org/pipermail/vorbis-dev/2001-August/004501.html midi]<br />
| char[0,8]: <tt>'OggMIDI\0'</tt><br />
hex: <tt>'0x4f 0x67 0x67 0x4d 0x49 0x44 0x49 0x00'</tt><br />
<br />
oct: <tt>'0117 0147 0147 0115 0111 0104 0111 0000'</tt><br />
| char[8,1]: version field<br />
|-<br />
| [[OggMNG|mng]]<br />
| char[0,8]: <tt>'\212MNG\r\n\032\n'</tt><br />
hex: <tt>'0x8a 0x4d 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0212 0115 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggPCM|pcm]]<br />
| char[0,8]: <tt>'PCM\ \ \ \ \ '</tt><br />
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt><br />
| char[8,2]: version major field,<br />
char[10,2]: version minor field<br />
|-<br />
| [[OggMNG|png]]<br />
| char[0,8]: <tt>'\211PNG\r\n\032\n'</tt><br />
hex: <tt>'0x89 0x50 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0211 0120 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h speex]<br />
| char[0,8]: <tt>'Speex\ \ \ '</tt><br />
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h theora]<br />
| char[0,7]: <tt>'\x80theora'</tt><br />
hex: <tt>'0x80 0x74 0x68 0x65 0x6f 0x72 0x61'</tt><br />
<br />
oct: <tt>'0180 0164 0150 0145 0157 0162 0141'</tt><br />
| char[7,1]: major version number,<br />
char[8,1]: minor version number,<br />
<br />
char[9,1]: version revision number<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h vorbis]<br />
| char[0,7]: <tt>'\x01vorbis'</tt><br />
hex: <tt>'0x01 0x76 0x6f 0x72 0x62 0x69 0x73'</tt><br />
<br />
oct: <tt>'0001 0166 0157 0162 0142 0151 0163'</tt><br />
| char[7,4]: version field<br />
|-<br />
| yuv4mpeg<br />
| char[0,9]: <tt>'YUV4MPEG2'</tt><br />
hex: <tt>'0x59 0x55 0x56 0x34 0x4d 0x50 0x45 0x47 0x32'</tt><br />
<br />
oct: <tt>'0131 0125 0126 0064 0115 0120 0105 0107 0062'</tt><br />
| ?? <br />
|}<br />
<br />
The "char[x,y]" fields mean here: start at byte number x (counting from 0) for a length of y bytes.<br />
<br />
[[Category:Ogg]]</div>J^https://wiki.xiph.org/index.php?title=MIMETypesCodecs&diff=9216MIMETypesCodecs2008-07-29T10:03:45Z<p>J^: /* Codecs Parameter */</p>
<hr />
<div>== Specification of MIME types and respective codecs parameter ==<br />
<br />
=== MIME Types ===<br />
<br />
The following MIME types are now officially registered with IANA (well, almost,<br />
see [[https://datatracker.ietf.org/idtracker/draft-goncalves-rfc3534bis/]]):<br />
<br />
* application/ogg - for complex, multitrack, multiplexed files encapsulated in Ogg<br />
** requires a Skeleton logical bitstream<br />
** .ogx file extension<br />
** Macintosh File Type Code: OggX<br />
<br />
* video/ogg - for video encapsulated in Ogg<br />
** recommends a Skeleton logical bitstrem<br />
** .ogv file extension<br />
** Macintosh File Type Code: OggV<br />
<br />
* audio/ogg - for audio encapsulated in Ogg<br />
** recommends a Skeleton logical bitstrem<br />
** .oga file extension, .ogg for Vorbis I, .spx for Speex<br />
** Macintosh File Type Code: OggA<br />
<br />
<br />
[[MIME_Types_and_File_Extensions|Other MIME types]] are still in the process.<br />
<br />
<br />
=== Codecs Parameter ===<br />
<br />
[http://www.rfc-editor.org/rfc/rfc4281.txt Typically], MIME types of media encapsulation formats use the optional "codecs" parameter to specify which codes are being used in a particular file.<br />
<br />
Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page to identify the encapsulated codecs. The following table contains the identifiers for existing Xiph codecs and the codecs parameter names used for */ogg MIME types (in alphabetical order):<br />
<br />
{| class="codecstable" border="1"<br />
|-<br />
! Codecs Parameter Name<br />
! Codec Identifier<br />
(decimal, hex, octal)<br />
! Version Field (if available)<br />
|-<br />
| [http://wiki.xiph.org/index.php/OggDirac dirac]<br />
| char[0,6]: <tt>'BBCD\ \0'</tt><br />
hex: <tt>'0x42 0x42 0x43 0x44 0x20 00'</tt><br />
<br />
oct: <tt>'0102 0102 0103 0104 0040 0000'</tt><br />
| ??<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h celt]<br />
| char[0,8]: <tt>'CELT\ \ \ \ '</tt><br />
hex: <tt>'0x43 0x45 0x4c 0x54 0x20 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0103 0105 0114 0124 0040 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h cmml]<br />
| char[0,8]: <tt>'CMML\0\0\0\0'</tt><br />
hex: <tt>'0x43 0x4d 0x4d 0x4c 0x00 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0103 0115 0115 0114 0000 0000 0000 0000'</tt><br />
| char[8,2]: major version number,<br />
char[10,2]: minor version number<br />
|-<br />
| [http://flac.sourceforge.net/ogg_mapping.html flac]<br />
| char[0,5]: <tt>'\177FLAC'</tt><br />
hex: <tt>'0x7F 0x46 0x4C 0x41 0x43'</tt><br />
<br />
oct: <tt>'0177 0106 0114 0101 0103'</tt><br />
| char[5,1]: binary major version number, <br />
char[6,1]: binary minor version number of mapping<br />
|-<br />
| [[OggMNG|jng]]<br />
| char[0,8]: <tt>'\213JNG\r\n\032\n'</tt><br />
hex: <tt>'0x8b 0x4a 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0213 0112 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggKate|kate]]<br />
| char[0,8]: <tt>'\x80kate\0\0\0'</tt><br />
hex: <tt>'0x80 0x6b 0x61 0x74 0x65 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0200 0153 0141 0164 0145 0000 0000 0000'</tt><br />
| char[9,1]: major version number,<br />
char[10,1]: minor version number<br />
|-<br />
| [http://lists.xiph.org/pipermail/vorbis-dev/2001-August/004501.html midi]<br />
| char[0,8]: <tt>'OggMIDI\0'</tt><br />
hex: <tt>'0x4f 0x67 0x67 0x4d 0x49 0x44 0x49 0x00'</tt><br />
<br />
oct: <tt>'0117 0147 0147 0115 0111 0104 0111 0000'</tt><br />
| char[8,1]: version field<br />
|-<br />
| [[OggMNG|mng]]<br />
| char[0,8]: <tt>'\212MNG\r\n\032\n'</tt><br />
hex: <tt>'0x8a 0x4d 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0212 0115 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggPCM|pcm]]<br />
| char[0,8]: <tt>'PCM\ \ \ \ \ '</tt><br />
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt><br />
| char[8,2]: version major field,<br />
char[10,2]: version minor field<br />
|-<br />
| [[OggMNG|png]]<br />
| char[0,8]: <tt>'\211PNG\r\n\032\n'</tt><br />
hex: <tt>'0x89 0x50 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0211 0120 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h speex]<br />
| char[0,8]: <tt>'Speex\ \ \ '</tt><br />
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h theora]<br />
| char[0,7]: <tt>'\x80theora'</tt><br />
hex: <tt>'0x80 0x74 0x68 0x65 0x6f 0x72 0x61'</tt><br />
<br />
oct: <tt>'0180 0164 0150 0145 0157 0162 0141'</tt><br />
| char[7,1]: major version number,<br />
char[8,1]: minor version number,<br />
<br />
char[9,1]: version revision number<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h vorbis]<br />
| char[0,7]: <tt>'\x01vorbis'</tt><br />
hex: <tt>'0x01 0x76 0x6f 0x72 0x62 0x69 0x73'</tt><br />
<br />
oct: <tt>'0001 0166 0157 0162 0142 0151 0163'</tt><br />
| char[7,4]: version field<br />
|-<br />
| yuv4mpeg<br />
| char[0,9]: <tt>'YUV4MPEG2'</tt><br />
hex: <tt>'0x59 0x55 0x56 0x34 0x4d 0x50 0x45 0x47 0x32'</tt><br />
<br />
oct: <tt>'0131 0125 0126 0064 0115 0120 0105 0107 0062'</tt><br />
| ?? <br />
|}<br />
<br />
The "char[x,y]" fields mean here: start at byte number x (counting from 0) for a length of y bytes.<br />
<br />
[[Category:Ogg]]</div>J^https://wiki.xiph.org/index.php?title=MIMETypesCodecs&diff=9215MIMETypesCodecs2008-07-29T10:03:30Z<p>J^: /* Codecs Parameter */ schrodinger makes dirac files with an extra space in the header</p>
<hr />
<div>== Specification of MIME types and respective codecs parameter ==<br />
<br />
=== MIME Types ===<br />
<br />
The following MIME types are now officially registered with IANA (well, almost,<br />
see [[https://datatracker.ietf.org/idtracker/draft-goncalves-rfc3534bis/]]):<br />
<br />
* application/ogg - for complex, multitrack, multiplexed files encapsulated in Ogg<br />
** requires a Skeleton logical bitstream<br />
** .ogx file extension<br />
** Macintosh File Type Code: OggX<br />
<br />
* video/ogg - for video encapsulated in Ogg<br />
** recommends a Skeleton logical bitstrem<br />
** .ogv file extension<br />
** Macintosh File Type Code: OggV<br />
<br />
* audio/ogg - for audio encapsulated in Ogg<br />
** recommends a Skeleton logical bitstrem<br />
** .oga file extension, .ogg for Vorbis I, .spx for Speex<br />
** Macintosh File Type Code: OggA<br />
<br />
<br />
[[MIME_Types_and_File_Extensions|Other MIME types]] are still in the process.<br />
<br />
<br />
=== Codecs Parameter ===<br />
<br />
[http://www.rfc-editor.org/rfc/rfc4281.txt Typically], MIME types of media encapsulation formats use the optional "codecs" parameter to specify which codes are being used in a particular file.<br />
<br />
Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page to identify the encapsulated codecs. The following table contains the identifiers for existing Xiph codecs and the codecs parameter names used for */ogg MIME types (in alphabetical order):<br />
<br />
{| class="codecstable" border="1"<br />
|-<br />
! Codecs Parameter Name<br />
! Codec Identifier<br />
(decimal, hex, octal)<br />
! Version Field (if available)<br />
|-<br />
| [http://wiki.xiph.org/index.php/OggDirac dirac]<br />
| char[0,5]: <tt>'BBCD\ \0'</tt><br />
hex: <tt>'0x42 0x42 0x43 0x44 0x20 00'</tt><br />
<br />
oct: <tt>'0102 0102 0103 0104 0040 0000'</tt><br />
| ??<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h celt]<br />
| char[0,8]: <tt>'CELT\ \ \ \ '</tt><br />
hex: <tt>'0x43 0x45 0x4c 0x54 0x20 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0103 0105 0114 0124 0040 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h cmml]<br />
| char[0,8]: <tt>'CMML\0\0\0\0'</tt><br />
hex: <tt>'0x43 0x4d 0x4d 0x4c 0x00 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0103 0115 0115 0114 0000 0000 0000 0000'</tt><br />
| char[8,2]: major version number,<br />
char[10,2]: minor version number<br />
|-<br />
| [http://flac.sourceforge.net/ogg_mapping.html flac]<br />
| char[0,5]: <tt>'\177FLAC'</tt><br />
hex: <tt>'0x7F 0x46 0x4C 0x41 0x43'</tt><br />
<br />
oct: <tt>'0177 0106 0114 0101 0103'</tt><br />
| char[5,1]: binary major version number, <br />
char[6,1]: binary minor version number of mapping<br />
|-<br />
| [[OggMNG|jng]]<br />
| char[0,8]: <tt>'\213JNG\r\n\032\n'</tt><br />
hex: <tt>'0x8b 0x4a 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0213 0112 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggKate|kate]]<br />
| char[0,8]: <tt>'\x80kate\0\0\0'</tt><br />
hex: <tt>'0x80 0x6b 0x61 0x74 0x65 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0200 0153 0141 0164 0145 0000 0000 0000'</tt><br />
| char[9,1]: major version number,<br />
char[10,1]: minor version number<br />
|-<br />
| [http://lists.xiph.org/pipermail/vorbis-dev/2001-August/004501.html midi]<br />
| char[0,8]: <tt>'OggMIDI\0'</tt><br />
hex: <tt>'0x4f 0x67 0x67 0x4d 0x49 0x44 0x49 0x00'</tt><br />
<br />
oct: <tt>'0117 0147 0147 0115 0111 0104 0111 0000'</tt><br />
| char[8,1]: version field<br />
|-<br />
| [[OggMNG|mng]]<br />
| char[0,8]: <tt>'\212MNG\r\n\032\n'</tt><br />
hex: <tt>'0x8a 0x4d 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0212 0115 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggPCM|pcm]]<br />
| char[0,8]: <tt>'PCM\ \ \ \ \ '</tt><br />
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt><br />
| char[8,2]: version major field,<br />
char[10,2]: version minor field<br />
|-<br />
| [[OggMNG|png]]<br />
| char[0,8]: <tt>'\211PNG\r\n\032\n'</tt><br />
hex: <tt>'0x89 0x50 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0211 0120 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h speex]<br />
| char[0,8]: <tt>'Speex\ \ \ '</tt><br />
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h theora]<br />
| char[0,7]: <tt>'\x80theora'</tt><br />
hex: <tt>'0x80 0x74 0x68 0x65 0x6f 0x72 0x61'</tt><br />
<br />
oct: <tt>'0180 0164 0150 0145 0157 0162 0141'</tt><br />
| char[7,1]: major version number,<br />
char[8,1]: minor version number,<br />
<br />
char[9,1]: version revision number<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h vorbis]<br />
| char[0,7]: <tt>'\x01vorbis'</tt><br />
hex: <tt>'0x01 0x76 0x6f 0x72 0x62 0x69 0x73'</tt><br />
<br />
oct: <tt>'0001 0166 0157 0162 0142 0151 0163'</tt><br />
| char[7,4]: version field<br />
|-<br />
| yuv4mpeg<br />
| char[0,9]: <tt>'YUV4MPEG2'</tt><br />
hex: <tt>'0x59 0x55 0x56 0x34 0x4d 0x50 0x45 0x47 0x32'</tt><br />
<br />
oct: <tt>'0131 0125 0126 0064 0115 0120 0105 0107 0062'</tt><br />
| ?? <br />
|}<br />
<br />
The "char[x,y]" fields mean here: start at byte number x (counting from 0) for a length of y bytes.<br />
<br />
[[Category:Ogg]]</div>J^https://wiki.xiph.org/index.php?title=Summer_of_Code_2008&diff=8737Summer of Code 20082008-03-18T17:51:41Z<p>J^: /* Dirac support in liboggplay and liboggz */</p>
<hr />
<div>This is our ideas page for [http://code.google.com/soc/ Google Summer of Code] projects with [http://xiph.org Xiph.org] and [http://annodex.org/ Annodex]. The two projects participate jointly this year under Xiph's name.<br />
<br />
'''Students''' please use the template at [[Summer of Code Applications]] when applying for a GSoC position.<br />
<br />
'''Mentors''' please visit [[Summer of Code Mentoring]] and help us prepare our application as a mentoring organization.<br />
<br />
== Current Ideas ==<br />
<br />
We need a primary and backup mentor volunteer for any project that is to become an official proposal, but submit something and we'll see who we can round up. :)<br />
<br />
''Project ideas go here''<br />
* Transcode/Tag/Upload tool for Theora et al. (ideally as a firefox extension so web cms integration is easy) '''OggPusher''' details below:<br />
* Theora encoding support in GIMP<br />
* Theora Java port directly (semi)automatically derived from the reference sources<br />
* Optimisations for Oggenc and Co. as done by Lancer (http://homepage3.nifty.com/blacksword/) which gives around 3x more speed. If one fears quality lose, make it ./configure option. Lancers diffs only work for Windows.<br />
* Speex support in IceS<br />
* Better stream source gui for dvswitch<br />
* Multiplexing support (so one can play audio from video files) in ogg123<br />
:Isn't this already done with the vorbisfile support in 1.2.0?<br />
::At first, I thought it wasn't but that's because I tested with a 2.3 GB film and it didn't work. Smaller files work just fine, which makes me believe there's a bug somewhere that needs to be found. Anyway, we can remove this entry.--Ivo<br />
:::2.3 GB is just above what can be represented as bytes on a signed 32 bit int - clue to the bug ? --[[User:Ogg.k.ogg.k|Ogg.k.ogg.k]]<br />
* XSPF support in ogg123 and oggenc (playlist creation)<br />
* Initial support for OggPCM in some of our tools<br />
* OggMNG tools<br />
:Is this really necessary? I mean, OggMNG seems to have gone nowhere and serve no niche.--Ivo<br />
::We still keep getting asked for a format where speex and images together make up a movie.--Silvia<br />
* ROE implementation for network: using ROE in a client-server negotiation to dynamically request a specific multi-track ogg file using skeleton (Silvia)<br />
* create Ogg caption support for vlc using CMML<br />
* ffmpeg improvements for Xiph.Org codecs:<br />
** add Speex support<br />
** add Ogg Skeleton support<br />
** fix seeking bugs involving Ogg Theora<br />
** fix bugs in Ogg Theora decoder<br />
** improve ogg muxer<br />
* Ogg Cutter, a GUI to cut out segments from Ogg Videos, this could be based on oggz-chop (part of oggz-tools) or done with Gstreamer (starting with [http://webcvs.freedesktop.org/gstreamer/gst-python/examples/remuxer.py?content-type=text%2Fplain&view=co remuxer.py]<br />
<br />
==Detailed Project Description==<br />
<br />
===Mv_Embed: Accessibility and [re]usability:===<br />
'''Mentor:''' Michael Dale, Anna (EngageMedia) <br/><br />
'''Existing Feature Set:''' [http://metavid.ucsc.edu/wiki/index.php/Mv_Embed Mv_Embed] is an existing javascript library that takes html5 <video> tag and rewrites the video tag for to support in-page ogg theora playback in contemporary browsers. MV_embed supports may browsers and plugins including: native browser support such as firefox 3 video builds, oggplay plugin for firefox2 in win, mac, linux ; VLC activX/plugin for win IE, firefox, and mac, linux firefox; mplayer & totem for linux; and java cortado for microsoft, sun, apple java VM for IE, firefox & safari. Mv_embed maps all these plugin javascript systems to a ~near~ html5 spec api enabling web application developers to take advantage of a uniform javascript API for video control and interaction without having to worry about the underling plugin systems. Mv_Embed is used as part of the metavidWiki Project (screen cast).<br />
<br />
'''Proposed Development:''' Mv_Embed will be enhanced around two goals integration into prominent open source Content Management Systems and better accessibility of close captions and associative video metadata.<br />
<br />
Mv_Embed will integrate into existing CMS video extensions for quick "one-off" ogg theora support.<br />
* FilmForge (Drupal)<br />
* ShowInABox (Wordpress)<br />
* Plumi (Plone)<br />
<br />
Additional server side components like transcoding to theora, generating thumbnails, and exporting metadata will also be developed. Where time / resources permit server side hooks into ffmepg2theora (for transcoding) and mplayer (for generating thumbnails) will be developed for the CMS systems as well. As OggPusher matures simple hooks will be added to the CMS's to support direct ogg theora clip uploads.<br />
<br />
'''Accessibility & CMML'''<br />
Accessible components of mv_embed consist of obtaining the metadata and putting it into the dom as a child of the video element. Mv_Embed will offer a reference javascript interface for client interactions with that metadata. The metadata will be structured in Continues Media Markup Language (CMML). CMML is a part of the annodex technology set and can either be muxed into the ogg stream or be requested separately via XML. Mv_Embed will negotiate a transport method for the metadata that will work for the given plugin type.(Currently only oggplay plugin supports ogg-skeleton and exposing muxed CMML tracks in the ogg stream).<br />
<br />
Mv_Embed is part of [http://metavid.ucsc.edu/wiki/index.php/MetaVidWiki MetavidWiki] enables community authored transcripts and exposes these multiple layers in CMML. Proposed work on Mv_Embed will generalize these development efforts taking place in the metavid project for other CMS's and improve the usability and accessibility of these metadata layers in javascript based interfaces and mutil-plugin playback environment.<br />
<br />
=== Theora Java port directly (semi)automatically derived from the reference sources ===<br />
<br />
The current Java decoder port (jheora) is rapidly heading towards becoming obsolete. It was based on the C reference implementation during alpha development stages, which means it cannot decode advanced Theora streams using non-VP3 features. Current Theora mainline features a completely new decoder, implementing all bitstream features, and a new encoder needing these advanced decoder capabilities is expected to arrive soon. jheora, however, appears to be unmaintainable for very same reasons the original alpha decoder was dropped. To make matters worse there's a very very noticable lack of someone being at least moderately skilled in Java AND being skilled in video coding AND writing Java code with acceptable speed (video decoding should be realtime). Any conventional manual Java source port may quickly bitrot to an unmaintainable state.<br />
<br />
Thankfully there *are* technologies to get C code to execute in the Java Virtual Machine. The obvious idea would be to translate the actual source code to Java using an automated process, but no reliable tools exist doing this (and given the concept-clash in some areas between C and Java it's unlikely something really nice will emerge). Projects like NestedVM (http://nestedvm.ibex.org/) and Cibyl (http://spel.bth.se/index.php/Cibyl) are doing '''language agnostic translations to Java bytecode''', using the GCC toolchain.<br />
<br />
In the first step the code to be ported is compiled to MIPS ELF binaries. Those are then converted to Java bytecode. This works pretty well because MIPS is pretty similar to Java bytecode and most instructions can be mapped directly.<br />
<br />
Crazyness? Work of mad men, living in nuclear families, fighting rampaging robots with nuclear missiles? Does this actually work? Yup, it does work, and some Xiph encoders/decoders have been successfully converted with NestedVM already (http://groups.google.com/group/nestedvm/browse_thread/thread/df96ef7337f390e4/a45fdd66534e7641?#a45fdd66534e7641) and figures provided by the Cibyl project indicate that the MIPS-to-Java approach isn't actually slower than a "real" Java port (http://spel.bth.se/index.php/Cibyl_performance) - it's sometimes faster, sometimes slower.<br />
<br />
The problem with NestedVM is that there appears to be no means to generate a Java interface from the converted binaries - which means that while the converted binaries work fine on Java there's no way to call the functionality of the converted code by other Java classes, which would be necessary to e.g. write a player applet.<br />
<br />
Cibyl, on the other hand, does provide means to generate Java interfaces, given the binary and the header files. Cibyl, however, needs to link some helper symbols into the MIPS binary, which apparently requires some tricks to work in the usual autoconf setup (http://groups.google.com/group/cibyl-devel/browse_thread/thread/584e5fc3b9bc7e2c). So for the Cibyl port to work some autoconf magic may be necessary.<br />
<br />
So what should this project do:<br />
<br />
* Create and document a working setup for doing language-agnostic Java conversions<br />
* Demonstrate this for Theora<br />
* Find a way to generate a Java interface in a way being automated as much as possible<br />
<br />
This project most likely is directly bound to progress made with either NestedVM or Cibyl. The upside of this is that any results may be directly applied to other projects, too<br />
<br />
--[[User:Maikmerten|Maikmerten]] 03:43, 12 March 2008 (PDT)<br />
<br />
<br />
===OggPusher===<br />
'''Mentor:''' Michael Dale ... or anyone else with more experience with firefox extensions/ffmpeg2theora ? <br><br />
'''Abstract:''' OggPusher is a proposed cross platform packaging of ffmpeg2theora as a browser extension. This exposes JavaScript hooks to web applications enabling easy client side transcodes from high quality source originals such as DV or MPEG2 and uploading into web based content management systems.<br><br />
'''Sample Application Flow:''' is as follows: A user visits a oggPusher enabled web service. The firefox user is prompted to install a browser extension via firefox's .xpi extension framework. Once enabled, the web service upload interface does a call to the oggPusher to expose a "open file" dialog box on the client. The websevice access the oggPusher api to set the requested transcode bitrate and other transcode options (such as interlace, number of audio channels, resolution etc). The client selects the high quality local file and begins transcoding to a temporary location on local disk. If there is an error in transcoding the upload is aborted and an error is exposed to web application. Once the file is done transcoding, the web interface has the client issue a POST of the transcoded file.(if the server supports more efficient PUT than that can be used). The amount of the file that has been transcoded and the amount uploaded are exposed via javascript hooks so that web application javascript interface can update the client on upload progress. If the the upload connection is reset a ajax request on the client can request "bytes upload so far" from the server and have oggPusher begin uploading from that point in the temporary local ogg file. A local file hash could be rechecked to insure the local file has not changed. The server can then do a simple join on the uploaded pieces, enabling reusable uploads over existing http protocol. If the server does not support resumes the file will be uploaded from the start.<br />
<br />
'''Features for initial Release:'''<br />
* A .xpi extension based on ffmpeg2theoa that supports uploading of local files of any type that ffmpeg accepts.<br />
* Supports two modes of operation<br />
** zero server side config where oggPusher just gives the option of uploading theora video where it finds a form file input type.<br />
** server side config where the server/service hooks into oggPusher for extra functionality, like resuming transferrer and status updates integrated with the web application.<br />
* A simple javascript api for controlling ffmpeg2theora encoding options. These options will be pre-demerited and javascript input will be scrubbed to avoid client side security risks.<br />
* A set of javascript hooks for oggPusher that expose upload progress, encoding progress and transcoding errors.<br />
* A sample server side implementation using php/html/javascript for grabbing ogg files from oggPusher.<br />
<br />
<br />
'''Future Feature RoadMap:'''<br />
Once the basic implementation has been deployed the following features will be targeted for future versions:<br />
<br />
* Integration with popular open source CMS's first target is mediaWiki.<br />
* Hooks for connecting into "live" interfaces such as firewire digital video input or USB web cams.<br />
** Extend oggfwd and server side components for in browser live streaming to web services.<br />
* Extend to support ffmpeg2Dirac and future open source media codecs.<br />
* Enable javascript hooks for grabbing highquality jpg or png screen grabs from the original source to be uploaded alongside the encoded video.<br />
* Enable Bittorrent uploads<br />
<br />
===XSPF support in oggenc and ogg123 applications===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: oggenc and ogg123 are part of a toolset named vorbis-tools, where oggenc is a Vorbis encoder and ogg123 an audio player. XSPF is a XML-based playlist format, extensible, but simple and efficient.<br />
<br />
Proposed Development: this project would extend those two applications (oggenc and ogg123) to support XSPF. Namely, oggenc would be able to generate a playlist from the encoded files, and ogg123 would be able to parse a playlist for supported media for playback. This is a C project, with the intention of using code from or actually linking to the BSD-licensed libSpiff, which is a C++ XSPF library.<br />
<br />
<br />
===php_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... or anyone else with an a php background e.g. Michael Dale<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. php_annodex can e.g. be used to extend Drupal, MediaWiki and other php-based applications with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through php_annodex.<br />
<br />
'''What is the project?'''<br />
An initial version of [http://annodex.net/software/phpannodex/index.html php_annodex exists], but it is incomplete and not up-to-date. This is in comparison with such support in python through [http://annodex.net/taxonomy_menu/1/19 pyannodex]. A GSoC student would be expected to bring the support for Xiph and Annodex technology in php_annodex up-to-date. In addition, he/she could extend this work by also implementing media support in a plugin, e.g. the Drupal module [http://annodex.net/software/phpannodex/index.html Acidfree]. php_annodex is simply a php wrapper around the C-libraries libannodex and liboggz. It may suffice to just focus on liboggz.<br />
<br />
<br />
===ruby_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. ruby_annodex can e.g. be used to extend rails with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through ruby_annodex.<br />
<br />
'''What is the project?'''<br />
A python wrapper of similar type called [http://annodex.net/taxonomy_menu/1/19 pyannodex] exists. The ruby_annodex wrapper should provide similar functionality to ruby, in particular with a view of using it from within rails for the development of Web applications. Development of an example application in ruby on rails would be part of this. Extension of this project to include media support into a ruby-based CMS is possible.<br />
<br />
<br />
===Using ROE to create multi-track Ogg files===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... and anyone else interested in ROE, e.g. Ralph Giles, Conrad Parker, Michael Dale, Shane Stephens<br/><br />
<br />
'''What is it?'''<br />
[http://trac.annodex.net/wiki/MovieDescriptionLanguage ROE] is a small XML description language for multi-track media files. It can be used for authoring multi-track media files from separate physical files on disk. It can also be used on a Web server to dynamically create multi-track media resources where the tracks are selected through the request from the client.<br />
<br />
'''What is the project?'''<br />
In this project, we only implement and experiment with the file multiplexing side of things. The ROE specification is very new and potentially incomplete, so part of the project will be to validate this specification. The other part will be to create an authoring tool that can take a ROE file, parse it, pull in all the input audio, video, text etc files and create an Ogg file with a Skeleton that contains the equivalent of ROE inside the binary file. The project will start with a focus on multiplexing vorbis audio and theora video, but also include speex, FLAC, CMML, and possibly MNG data. If this is achieved in a short time frame, the project can continue onto developing support for these multi-track files in e.g. vlc or ffmpeg. This can even extend to providing a full tool-chain from authoring captions for a video file, to creating the respective multitrack Ogg file, and finally to playing them back inside vlc where the captions are shown as overlays.<br />
<br />
<br />
===SHARE application for the Spread Open Media project===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: Spread Open Media is a community project to promote the different free formats for multimedia and otherwise. SHARE is a pratical step to build on this community and spread more files.<br />
<br />
Proposed Development: SHARE is intended to be a PHP project. We do not discard the possibility of using Rails or Python, but the current SOM server does not support these. SHARE will be a WebJay-like clone, as in users will be able to register, vote, comment and upload their own XSPF playlists. Basically, it is a playlist sharing application. Using OpenID for registration and Cortado (an existing Java applet) for playback would be welcome additions.<br />
<br />
===Dirac support in liboggplay and liboggz===<br />
<br />
'''Mentor:''' ??<br />
<br />
Right now [http://wiki.xiph.org/index.php/OggPlay liboggplay] only support Theora video. <br />
Your aim for this project is to add support for [http://dirac.sourceforge.net/ Dirac],<br />
this should be done using [http://www.diracvideo.org/ libschrodinger].<br />
Doing this, you will add OggDirac support to the OggPlay Browser Plugin and the upcoming <video> tag support in Firefox.<br />
<br />
== Guidelines for Applying ==<br />
<br />
Remember that many people will apply to work on the Summer of Code.<br />
<br />
Keep in mind that those of us evaluating your application do not know you, we do not know what kind of <br />
experience you have, we do not know what you have done in the past and we have to pick the best people <br />
suited for a particular task.<br />
<br />
Hence, it is very important that you tell us in your email why you should be considered to implement a <br />
particular project. Please use the application template at [[Summer of Code Applications]] as a starting point.<br />
<br />
== See Also ==<br />
*[[CodingGuidelines]]<br />
*[[MIT approach to design and implementation]]<br />
*[[How to do a release]]<br />
*[[Summer of Code 2007]]<br />
*[[Summer of Code 2006]]</div>J^https://wiki.xiph.org/index.php?title=Summer_of_Code_2008&diff=8733Summer of Code 20082008-03-18T12:37:39Z<p>J^: /* Current Ideas */</p>
<hr />
<div>This is our ideas page for [http://code.google.com/soc/ Google Summer of Code] projects with [http://xiph.org Xiph.org] and [http://annodex.org/ Annodex]. The two projects participate jointly this year under Xiph's name.<br />
<br />
'''Students''' please use the template at [[Summer of Code Applications]] when applying for a GSoC position.<br />
<br />
'''Mentors''' please visit [[Summer of Code Mentoring]] and help us prepare our application as a mentoring organization.<br />
<br />
== Current Ideas ==<br />
<br />
We need a primary and backup mentor volunteer for any project that is to become an official proposal, but submit something and we'll see who we can round up. :)<br />
<br />
''Project ideas go here''<br />
* Transcode/Tag/Upload tool for Theora et al. (ideally as a firefox extension so web cms integration is easy) '''OggPusher''' details below:<br />
* Theora encoding support in GIMP<br />
* Theora Java port directly (semi)automatically derived from the reference sources<br />
* Speex support in IceS<br />
* Better stream source gui for dvswitch<br />
* Multiplexing support (so one can play audio from video files) in ogg123<br />
:Isn't this already done with the vorbisfile support in 1.2.0?<br />
::At first, I thought it wasn't but that's because I tested with a 2.3 GB film and it didn't work. Smaller files work just fine, which makes me believe there's a bug somewhere that needs to be found. Anyway, we can remove this entry.--Ivo<br />
:::2.3 GB is just above what can be represented as bytes on a signed 32 bit int - clue to the bug ? --[[User:Ogg.k.ogg.k|Ogg.k.ogg.k]]<br />
* XSPF support in ogg123 and oggenc (playlist creation)<br />
* Initial support for OggPCM in some of our tools<br />
* OggMNG tools<br />
:Is this really necessary? I mean, OggMNG seems to have gone nowhere and serve no niche.--Ivo<br />
::We still keep getting asked for a format where speex and images together make up a movie.--Silvia<br />
* ROE implementation for network: using ROE in a client-server negotiation to dynamically request a specific multi-track ogg file using skeleton (Silvia)<br />
* create Ogg caption support for vlc using CMML<br />
* ffmpeg improvements for Xiph.Org codecs:<br />
** add Speex support<br />
** add Ogg Skeleton support<br />
** fix seeking bugs involving Ogg Theora<br />
** fix bugs in Ogg Theora decoder<br />
** improve ogg muxer<br />
* Ogg Cutter, a GUI to cut out segments from Ogg Videos, this could be based on oggz-chop (part of oggz-tools) or done with Gstreamer (starting with [http://webcvs.freedesktop.org/gstreamer/gst-python/examples/remuxer.py?content-type=text%2Fplain&view=co remuxer.py]<br />
<br />
==Detailed Project Description==<br />
<br />
===Mv_Embed: Accessibility and [re]usability:===<br />
'''Mentor:''' Michael Dale, Anna (EngageMedia) <br/><br />
'''Existing Feature Set:''' [http://metavid.ucsc.edu/wiki/index.php/Mv_Embed Mv_Embed] is an existing javascript library that takes html5 <video> tag and rewrites the video tag for to support in-page ogg theora playback in contemporary browsers. MV_embed supports may browsers and plugins including: native browser support such as firefox 3 video builds, oggplay plugin for firefox2 in win, mac, linux ; VLC activX/plugin for win IE, firefox, and mac, linux firefox; mplayer & totem for linux; and java cortado for microsoft, sun, apple java VM for IE, firefox & safari. Mv_embed maps all these plugin javascript systems to a ~near~ html5 spec api enabling web application developers to take advantage of a uniform javascript API for video control and interaction without having to worry about the underling plugin systems. Mv_Embed is used as part of the metavidWiki Project (screen cast).<br />
<br />
'''Proposed Development:''' Mv_Embed will be enhanced around two goals integration into prominent open source Content Management Systems and better accessibility of close captions and associative video metadata.<br />
<br />
Mv_Embed will integrate into existing CMS video extensions for quick "one-off" ogg theora support.<br />
* FilmForge (Drupal)<br />
* ShowInABox (Wordpress)<br />
* Plumi (Plone)<br />
<br />
Additional server side components like transcoding to theora, generating thumbnails, and exporting metadata will also be developed. Where time / resources permit server side hooks into ffmepg2theora (for transcoding) and mplayer (for generating thumbnails) will be developed for the CMS systems as well. As OggPusher matures simple hooks will be added to the CMS's to support direct ogg theora clip uploads.<br />
<br />
'''Accessibility & CMML'''<br />
Accessible components of mv_embed consist of obtaining the metadata and putting it into the dom as a child of the video element. Mv_Embed will offer a reference javascript interface for client interactions with that metadata. The metadata will be structured in Continues Media Markup Language (CMML). CMML is a part of the annodex technology set and can either be muxed into the ogg stream or be requested separately via XML. Mv_Embed will negotiate a transport method for the metadata that will work for the given plugin type.(Currently only oggplay plugin supports ogg-skeleton and exposing muxed CMML tracks in the ogg stream).<br />
<br />
Mv_Embed is part of [http://metavid.ucsc.edu/wiki/index.php/MetaVidWiki MetavidWiki] enables community authored transcripts and exposes these multiple layers in CMML. Proposed work on Mv_Embed will generalize these development efforts taking place in the metavid project for other CMS's and improve the usability and accessibility of these metadata layers in javascript based interfaces and mutil-plugin playback environment.<br />
<br />
=== Theora Java port directly (semi)automatically derived from the reference sources ===<br />
<br />
The current Java decoder port (jheora) is rapidly heading towards becoming obsolete. It was based on the C reference implementation during alpha development stages, which means it cannot decode advanced Theora streams using non-VP3 features. Current Theora mainline features a completely new decoder, implementing all bitstream features, and a new encoder needing these advanced decoder capabilities is expected to arrive soon. jheora, however, appears to be unmaintainable for very same reasons the original alpha decoder was dropped. To make matters worse there's a very very noticable lack of someone being at least moderately skilled in Java AND being skilled in video coding AND writing Java code with acceptable speed (video decoding should be realtime). Any conventional manual Java source port may quickly bitrot to an unmaintainable state.<br />
<br />
Thankfully there *are* technologies to get C code to execute in the Java Virtual Machine. The obvious idea would be to translate the actual source code to Java using an automated process, but no reliable tools exist doing this (and given the concept-clash in some areas between C and Java it's unlikely something really nice will emerge). Projects like NestedVM (http://nestedvm.ibex.org/) and Cibyl (http://spel.bth.se/index.php/Cibyl) are doing '''language agnostic translations to Java bytecode''', using the GCC toolchain.<br />
<br />
In the first step the code to be ported is compiled to MIPS ELF binaries. Those are then converted to Java bytecode. This works pretty well because MIPS is pretty similar to Java bytecode and most instructions can be mapped directly.<br />
<br />
Crazyness? Work of mad men, living in nuclear families, fighting rampaging robots with nuclear missiles? Does this actually work? Yup, it does work, and some Xiph encoders/decoders have been successfully converted with NestedVM already (http://groups.google.com/group/nestedvm/browse_thread/thread/df96ef7337f390e4/a45fdd66534e7641?#a45fdd66534e7641) and figures provided by the Cibyl project indicate that the MIPS-to-Java approach isn't actually slower than a "real" Java port (http://spel.bth.se/index.php/Cibyl_performance) - it's sometimes faster, sometimes slower.<br />
<br />
The problem with NestedVM is that there appears to be no means to generate a Java interface from the converted binaries - which means that while the converted binaries work fine on Java there's no way to call the functionality of the converted code by other Java classes, which would be necessary to e.g. write a player applet.<br />
<br />
Cibyl, on the other hand, does provide means to generate Java interfaces, given the binary and the header files. Cibyl, however, needs to link some helper symbols into the MIPS binary, which apparently requires some tricks to work in the usual autoconf setup (http://groups.google.com/group/cibyl-devel/browse_thread/thread/584e5fc3b9bc7e2c). So for the Cibyl port to work some autoconf magic may be necessary.<br />
<br />
So what should this project do:<br />
<br />
* Create and document a working setup for doing language-agnostic Java conversions<br />
* Demonstrate this for Theora<br />
* Find a way to generate a Java interface in a way being automated as much as possible<br />
<br />
This project most likely is directly bound to progress made with either NestedVM or Cibyl. The upside of this is that any results may be directly applied to other projects, too<br />
<br />
--[[User:Maikmerten|Maikmerten]] 03:43, 12 March 2008 (PDT)<br />
<br />
<br />
===OggPusher===<br />
'''Mentor:''' Michael Dale ... or anyone else with more experience with firefox extensions/ffmpeg2theora ? <br><br />
'''Abstract:''' OggPusher is a proposed cross platform packaging of ffmpeg2theora as a browser extension. This exposes JavaScript hooks to web applications enabling easy client side transcodes from high quality source originals such as DV or MPEG2 and uploading into web based content management systems.<br><br />
'''Sample Application Flow:''' is as follows: A user visits a oggPusher enabled web service. The firefox user is prompted to install a browser extension via firefox's .xpi extension framework. Once enabled, the web service upload interface does a call to the oggPusher to expose a "open file" dialog box on the client. The websevice access the oggPusher api to set the requested transcode bitrate and other transcode options (such as interlace, number of audio channels, resolution etc). The client selects the high quality local file and begins transcoding to a temporary location on local disk. If there is an error in transcoding the upload is aborted and an error is exposed to web application. Once the file is done transcoding, the web interface has the client issue a POST of the transcoded file.(if the server supports more efficient PUT than that can be used). The amount of the file that has been transcoded and the amount uploaded are exposed via javascript hooks so that web application javascript interface can update the client on upload progress. If the the upload connection is reset a ajax request on the client can request "bytes upload so far" from the server and have oggPusher begin uploading from that point in the temporary local ogg file. A local file hash could be rechecked to insure the local file has not changed. The server can then do a simple join on the uploaded pieces, enabling reusable uploads over existing http protocol. If the server does not support resumes the file will be uploaded from the start.<br />
<br />
'''Features for initial Release:'''<br />
* A .xpi extension based on ffmpeg2theoa that supports uploading of local files of any type that ffmpeg accepts.<br />
* Supports two modes of operation<br />
** zero server side config where oggPusher just gives the option of uploading theora video where it finds a form file input type.<br />
** server side config where the server/service hooks into oggPusher for extra functionality, like resuming transferrer and status updates integrated with the web application.<br />
* A simple javascript api for controlling ffmpeg2theora encoding options. These options will be pre-demerited and javascript input will be scrubbed to avoid client side security risks.<br />
* A set of javascript hooks for oggPusher that expose upload progress, encoding progress and transcoding errors.<br />
* A sample server side implementation using php/html/javascript for grabbing ogg files from oggPusher.<br />
<br />
<br />
'''Future Feature RoadMap:'''<br />
Once the basic implementation has been deployed the following features will be targeted for future versions:<br />
<br />
* Integration with popular open source CMS's first target is mediaWiki.<br />
* Hooks for connecting into "live" interfaces such as firewire digital video input or USB web cams.<br />
** Extend oggfwd and server side components for in browser live streaming to web services.<br />
* Extend to support ffmpeg2Dirac and future open source media codecs.<br />
* Enable javascript hooks for grabbing highquality jpg or png screen grabs from the original source to be uploaded alongside the encoded video.<br />
* Enable Bittorrent uploads<br />
<br />
===XSPF support in oggenc and ogg123 applications===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: oggenc and ogg123 are part of a toolset named vorbis-tools, where oggenc is a Vorbis encoder and ogg123 an audio player. XSPF is a XML-based playlist format, extensible, but simple and efficient.<br />
<br />
Proposed Development: this project would extend those two applications (oggenc and ogg123) to support XSPF. Namely, oggenc would be able to generate a playlist from the encoded files, and ogg123 would be able to parse a playlist for supported media for playback. This is a C project, with the intention of using code from or actually linking to the BSD-licensed libSpiff, which is a C++ XSPF library.<br />
<br />
<br />
===php_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... or anyone else with an a php background e.g. Michael Dale<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. php_annodex can e.g. be used to extend Drupal, MediaWiki and other php-based applications with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through php_annodex.<br />
<br />
'''What is the project?'''<br />
An initial version of [http://annodex.net/software/phpannodex/index.html php_annodex exists], but it is incomplete and not up-to-date. This is in comparison with such support in python through [http://annodex.net/taxonomy_menu/1/19 pyannodex]. A GSoC student would be expected to bring the support for Xiph and Annodex technology in php_annodex up-to-date. In addition, he/she could extend this work by also implementing media support in a plugin, e.g. the Drupal module [http://annodex.net/software/phpannodex/index.html Acidfree]. php_annodex is simply a php wrapper around the C-libraries libannodex and liboggz. It may suffice to just focus on liboggz.<br />
<br />
<br />
===ruby_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. ruby_annodex can e.g. be used to extend rails with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through ruby_annodex.<br />
<br />
'''What is the project?'''<br />
A python wrapper of similar type called [http://annodex.net/taxonomy_menu/1/19 pyannodex] exists. The ruby_annodex wrapper should provide similar functionality to ruby, in particular with a view of using it from within rails for the development of Web applications. Development of an example application in ruby on rails would be part of this. Extension of this project to include media support into a ruby-based CMS is possible.<br />
<br />
<br />
===Using ROE to create multi-track Ogg files===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... and anyone else interested in ROE, e.g. Ralph Giles, Conrad Parker, Michael Dale, Shane Stephens<br/><br />
<br />
'''What is it?'''<br />
[http://trac.annodex.net/wiki/MovieDescriptionLanguage ROE] is a small XML description language for multi-track media files. It can be used for authoring multi-track media files from separate physical files on disk. It can also be used on a Web server to dynamically create multi-track media resources where the tracks are selected through the request from the client.<br />
<br />
'''What is the project?'''<br />
In this project, we only implement and experiment with the file multiplexing side of things. The ROE specification is very new and potentially incomplete, so part of the project will be to validate this specification. The other part will be to create an authoring tool that can take a ROE file, parse it, pull in all the input audio, video, text etc files and create an Ogg file with a Skeleton that contains the equivalent of ROE inside the binary file. The project will start with a focus on multiplexing vorbis audio and theora video, but also include speex, FLAC, CMML, and possibly MNG data. If this is achieved in a short time frame, the project can continue onto developing support for these multi-track files in e.g. vlc or ffmpeg. This can even extend to providing a full tool-chain from authoring captions for a video file, to creating the respective multitrack Ogg file, and finally to playing them back inside vlc where the captions are shown as overlays.<br />
<br />
<br />
===SHARE application for the Spread Open Media project===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: Spread Open Media is a community project to promote the different free formats for multimedia and otherwise. SHARE is a pratical step to build on this community and spread more files.<br />
<br />
Proposed Development: SHARE is intended to be a PHP project. We do not discard the possibility of using Rails or Python, but the current SOM server does not support these. SHARE will be a WebJay-like clone, as in users will be able to register, vote, comment and upload their own XSPF playlists. Basically, it is a playlist sharing application. Using OpenID for registration and Cortado (an existing Java applet) for playback would be welcome additions.<br />
<br />
===Dirac support in liboggplay and liboggz===<br />
<br />
'''Mentor:''' ??<br />
<br />
Right now [http://wiki.xiph.org/index.php/OggPlay liboggplay] only support Theora video. <br />
Your aim for this project is to add support for [http://dirac.sourceforge.net/ Dirac],<br />
this should be done using [http://schrodinger.sourceforge.net/ libschrodinger].<br />
Doing this, you will add OggDirac support to the OggPlay Browser Plugin and the upcoming <video> tag support in Firefox.<br />
<br />
<br />
== Guidelines for Applying ==<br />
<br />
Remember that many people will apply to work on the Summer of Code.<br />
<br />
Keep in mind that those of us evaluating your application do not know you, we do not know what kind of <br />
experience you have, we do not know what you have done in the past and we have to pick the best people <br />
suited for a particular task.<br />
<br />
Hence, it is very important that you tell us in your email why you should be considered to implement a <br />
particular project. Please use the application template at [[Summer of Code Applications]] as a starting point.<br />
<br />
== See Also ==<br />
*[[CodingGuidelines]]<br />
*[[MIT approach to design and implementation]]<br />
*[[How to do a release]]<br />
*[[Summer of Code 2007]]<br />
*[[Summer of Code 2006]]</div>J^https://wiki.xiph.org/index.php?title=Summer_of_Code_2008&diff=8732Summer of Code 20082008-03-18T12:29:57Z<p>J^: /* Current Ideas */</p>
<hr />
<div>This is our ideas page for [http://code.google.com/soc/ Google Summer of Code] projects with [http://xiph.org Xiph.org] and [http://annodex.org/ Annodex]. The two projects participate jointly this year under Xiph's name.<br />
<br />
'''Students''' please use the template at [[Summer of Code Applications]] when applying for a GSoC position.<br />
<br />
'''Mentors''' please visit [[Summer of Code Mentoring]] and help us prepare our application as a mentoring organization.<br />
<br />
== Current Ideas ==<br />
<br />
We need a primary and backup mentor volunteer for any project that is to become an official proposal, but submit something and we'll see who we can round up. :)<br />
<br />
''Project ideas go here''<br />
* Transcode/Tag/Upload tool for Theora et al. (ideally as a firefox extension so web cms integration is easy) '''OggPusher''' details below:<br />
* Theora encoding support in GIMP<br />
* Theora Java port directly (semi)automatically derived from the reference sources<br />
* Speex support in IceS<br />
* Better stream source gui for dvswitch<br />
* Multiplexing support (so one can play audio from video files) in ogg123<br />
:Isn't this already done with the vorbisfile support in 1.2.0?<br />
::At first, I thought it wasn't but that's because I tested with a 2.3 GB film and it didn't work. Smaller files work just fine, which makes me believe there's a bug somewhere that needs to be found. Anyway, we can remove this entry.--Ivo<br />
:::2.3 GB is just above what can be represented as bytes on a signed 32 bit int - clue to the bug ? --[[User:Ogg.k.ogg.k|Ogg.k.ogg.k]]<br />
* XSPF support in ogg123 and oggenc (playlist creation)<br />
* Initial support for OggPCM in some of our tools<br />
* OggMNG tools<br />
:Is this really necessary? I mean, OggMNG seems to have gone nowhere and serve no niche.--Ivo<br />
::We still keep getting asked for a format where speex and images together make up a movie.--Silvia<br />
* ROE implementation for network: using ROE in a client-server negotiation to dynamically request a specific multi-track ogg file using skeleton (Silvia)<br />
* create Ogg caption support for vlc using CMML<br />
* ffmpeg improvements for Xiph.Org codecs:<br />
** add Speex support<br />
** add Ogg Skeleton support<br />
** fix seeking bugs involving Ogg Theora<br />
** fix bugs in Ogg Theora decoder<br />
** improve ogg muxer<br />
<br />
==Detailed Project Description==<br />
<br />
===Mv_Embed: Accessibility and [re]usability:===<br />
'''Mentor:''' Michael Dale, Anna (EngageMedia) <br/><br />
'''Existing Feature Set:''' [http://metavid.ucsc.edu/wiki/index.php/Mv_Embed Mv_Embed] is an existing javascript library that takes html5 <video> tag and rewrites the video tag for to support in-page ogg theora playback in contemporary browsers. MV_embed supports may browsers and plugins including: native browser support such as firefox 3 video builds, oggplay plugin for firefox2 in win, mac, linux ; VLC activX/plugin for win IE, firefox, and mac, linux firefox; mplayer & totem for linux; and java cortado for microsoft, sun, apple java VM for IE, firefox & safari. Mv_embed maps all these plugin javascript systems to a ~near~ html5 spec api enabling web application developers to take advantage of a uniform javascript API for video control and interaction without having to worry about the underling plugin systems. Mv_Embed is used as part of the metavidWiki Project (screen cast).<br />
<br />
'''Proposed Development:''' Mv_Embed will be enhanced around two goals integration into prominent open source Content Management Systems and better accessibility of close captions and associative video metadata.<br />
<br />
Mv_Embed will integrate into existing CMS video extensions for quick "one-off" ogg theora support.<br />
* FilmForge (Drupal)<br />
* ShowInABox (Wordpress)<br />
* Plumi (Plone)<br />
<br />
Additional server side components like transcoding to theora, generating thumbnails, and exporting metadata will also be developed. Where time / resources permit server side hooks into ffmepg2theora (for transcoding) and mplayer (for generating thumbnails) will be developed for the CMS systems as well. As OggPusher matures simple hooks will be added to the CMS's to support direct ogg theora clip uploads.<br />
<br />
'''Accessibility & CMML'''<br />
Accessible components of mv_embed consist of obtaining the metadata and putting it into the dom as a child of the video element. Mv_Embed will offer a reference javascript interface for client interactions with that metadata. The metadata will be structured in Continues Media Markup Language (CMML). CMML is a part of the annodex technology set and can either be muxed into the ogg stream or be requested separately via XML. Mv_Embed will negotiate a transport method for the metadata that will work for the given plugin type.(Currently only oggplay plugin supports ogg-skeleton and exposing muxed CMML tracks in the ogg stream).<br />
<br />
Mv_Embed is part of [http://metavid.ucsc.edu/wiki/index.php/MetaVidWiki MetavidWiki] enables community authored transcripts and exposes these multiple layers in CMML. Proposed work on Mv_Embed will generalize these development efforts taking place in the metavid project for other CMS's and improve the usability and accessibility of these metadata layers in javascript based interfaces and mutil-plugin playback environment.<br />
<br />
=== Theora Java port directly (semi)automatically derived from the reference sources ===<br />
<br />
The current Java decoder port (jheora) is rapidly heading towards becoming obsolete. It was based on the C reference implementation during alpha development stages, which means it cannot decode advanced Theora streams using non-VP3 features. Current Theora mainline features a completely new decoder, implementing all bitstream features, and a new encoder needing these advanced decoder capabilities is expected to arrive soon. jheora, however, appears to be unmaintainable for very same reasons the original alpha decoder was dropped. To make matters worse there's a very very noticable lack of someone being at least moderately skilled in Java AND being skilled in video coding AND writing Java code with acceptable speed (video decoding should be realtime). Any conventional manual Java source port may quickly bitrot to an unmaintainable state.<br />
<br />
Thankfully there *are* technologies to get C code to execute in the Java Virtual Machine. The obvious idea would be to translate the actual source code to Java using an automated process, but no reliable tools exist doing this (and given the concept-clash in some areas between C and Java it's unlikely something really nice will emerge). Projects like NestedVM (http://nestedvm.ibex.org/) and Cibyl (http://spel.bth.se/index.php/Cibyl) are doing '''language agnostic translations to Java bytecode''', using the GCC toolchain.<br />
<br />
In the first step the code to be ported is compiled to MIPS ELF binaries. Those are then converted to Java bytecode. This works pretty well because MIPS is pretty similar to Java bytecode and most instructions can be mapped directly.<br />
<br />
Crazyness? Work of mad men, living in nuclear families, fighting rampaging robots with nuclear missiles? Does this actually work? Yup, it does work, and some Xiph encoders/decoders have been successfully converted with NestedVM already (http://groups.google.com/group/nestedvm/browse_thread/thread/df96ef7337f390e4/a45fdd66534e7641?#a45fdd66534e7641) and figures provided by the Cibyl project indicate that the MIPS-to-Java approach isn't actually slower than a "real" Java port (http://spel.bth.se/index.php/Cibyl_performance) - it's sometimes faster, sometimes slower.<br />
<br />
The problem with NestedVM is that there appears to be no means to generate a Java interface from the converted binaries - which means that while the converted binaries work fine on Java there's no way to call the functionality of the converted code by other Java classes, which would be necessary to e.g. write a player applet.<br />
<br />
Cibyl, on the other hand, does provide means to generate Java interfaces, given the binary and the header files. Cibyl, however, needs to link some helper symbols into the MIPS binary, which apparently requires some tricks to work in the usual autoconf setup (http://groups.google.com/group/cibyl-devel/browse_thread/thread/584e5fc3b9bc7e2c). So for the Cibyl port to work some autoconf magic may be necessary.<br />
<br />
So what should this project do:<br />
<br />
* Create and document a working setup for doing language-agnostic Java conversions<br />
* Demonstrate this for Theora<br />
* Find a way to generate a Java interface in a way being automated as much as possible<br />
<br />
This project most likely is directly bound to progress made with either NestedVM or Cibyl. The upside of this is that any results may be directly applied to other projects, too<br />
<br />
--[[User:Maikmerten|Maikmerten]] 03:43, 12 March 2008 (PDT)<br />
<br />
<br />
===OggPusher===<br />
'''Mentor:''' Michael Dale ... or anyone else with more experience with firefox extensions/ffmpeg2theora ? <br><br />
'''Abstract:''' OggPusher is a proposed cross platform packaging of ffmpeg2theora as a browser extension. This exposes JavaScript hooks to web applications enabling easy client side transcodes from high quality source originals such as DV or MPEG2 and uploading into web based content management systems.<br><br />
'''Sample Application Flow:''' is as follows: A user visits a oggPusher enabled web service. The firefox user is prompted to install a browser extension via firefox's .xpi extension framework. Once enabled, the web service upload interface does a call to the oggPusher to expose a "open file" dialog box on the client. The websevice access the oggPusher api to set the requested transcode bitrate and other transcode options (such as interlace, number of audio channels, resolution etc). The client selects the high quality local file and begins transcoding to a temporary location on local disk. If there is an error in transcoding the upload is aborted and an error is exposed to web application. Once the file is done transcoding, the web interface has the client issue a POST of the transcoded file.(if the server supports more efficient PUT than that can be used). The amount of the file that has been transcoded and the amount uploaded are exposed via javascript hooks so that web application javascript interface can update the client on upload progress. If the the upload connection is reset a ajax request on the client can request "bytes upload so far" from the server and have oggPusher begin uploading from that point in the temporary local ogg file. A local file hash could be rechecked to insure the local file has not changed. The server can then do a simple join on the uploaded pieces, enabling reusable uploads over existing http protocol. If the server does not support resumes the file will be uploaded from the start.<br />
<br />
'''Features for initial Release:'''<br />
* A .xpi extension based on ffmpeg2theoa that supports uploading of local files of any type that ffmpeg accepts.<br />
* Supports two modes of operation<br />
** zero server side config where oggPusher just gives the option of uploading theora video where it finds a form file input type.<br />
** server side config where the server/service hooks into oggPusher for extra functionality, like resuming transferrer and status updates integrated with the web application.<br />
* A simple javascript api for controlling ffmpeg2theora encoding options. These options will be pre-demerited and javascript input will be scrubbed to avoid client side security risks.<br />
* A set of javascript hooks for oggPusher that expose upload progress, encoding progress and transcoding errors.<br />
* A sample server side implementation using php/html/javascript for grabbing ogg files from oggPusher.<br />
<br />
<br />
'''Future Feature RoadMap:'''<br />
Once the basic implementation has been deployed the following features will be targeted for future versions:<br />
<br />
* Integration with popular open source CMS's first target is mediaWiki.<br />
* Hooks for connecting into "live" interfaces such as firewire digital video input or USB web cams.<br />
** Extend oggfwd and server side components for in browser live streaming to web services.<br />
* Extend to support ffmpeg2Dirac and future open source media codecs.<br />
* Enable javascript hooks for grabbing highquality jpg or png screen grabs from the original source to be uploaded alongside the encoded video.<br />
* Enable Bittorrent uploads<br />
<br />
===XSPF support in oggenc and ogg123 applications===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: oggenc and ogg123 are part of a toolset named vorbis-tools, where oggenc is a Vorbis encoder and ogg123 an audio player. XSPF is a XML-based playlist format, extensible, but simple and efficient.<br />
<br />
Proposed Development: this project would extend those two applications (oggenc and ogg123) to support XSPF. Namely, oggenc would be able to generate a playlist from the encoded files, and ogg123 would be able to parse a playlist for supported media for playback. This is a C project, with the intention of using code from or actually linking to the BSD-licensed libSpiff, which is a C++ XSPF library.<br />
<br />
<br />
===php_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... or anyone else with an a php background e.g. Michael Dale<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. php_annodex can e.g. be used to extend Drupal, MediaWiki and other php-based applications with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through php_annodex.<br />
<br />
'''What is the project?'''<br />
An initial version of [http://annodex.net/software/phpannodex/index.html php_annodex exists], but it is incomplete and not up-to-date. This is in comparison with such support in python through [http://annodex.net/taxonomy_menu/1/19 pyannodex]. A GSoC student would be expected to bring the support for Xiph and Annodex technology in php_annodex up-to-date. In addition, he/she could extend this work by also implementing media support in a plugin, e.g. the Drupal module [http://annodex.net/software/phpannodex/index.html Acidfree]. php_annodex is simply a php wrapper around the C-libraries libannodex and liboggz. It may suffice to just focus on liboggz.<br />
<br />
<br />
===ruby_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. ruby_annodex can e.g. be used to extend rails with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through ruby_annodex.<br />
<br />
'''What is the project?'''<br />
A python wrapper of similar type called [http://annodex.net/taxonomy_menu/1/19 pyannodex] exists. The ruby_annodex wrapper should provide similar functionality to ruby, in particular with a view of using it from within rails for the development of Web applications. Development of an example application in ruby on rails would be part of this. Extension of this project to include media support into a ruby-based CMS is possible.<br />
<br />
<br />
===Using ROE to create multi-track Ogg files===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... and anyone else interested in ROE, e.g. Ralph Giles, Conrad Parker, Michael Dale, Shane Stephens<br/><br />
<br />
'''What is it?'''<br />
[http://trac.annodex.net/wiki/MovieDescriptionLanguage ROE] is a small XML description language for multi-track media files. It can be used for authoring multi-track media files from separate physical files on disk. It can also be used on a Web server to dynamically create multi-track media resources where the tracks are selected through the request from the client.<br />
<br />
'''What is the project?'''<br />
In this project, we only implement and experiment with the file multiplexing side of things. The ROE specification is very new and potentially incomplete, so part of the project will be to validate this specification. The other part will be to create an authoring tool that can take a ROE file, parse it, pull in all the input audio, video, text etc files and create an Ogg file with a Skeleton that contains the equivalent of ROE inside the binary file. The project will start with a focus on multiplexing vorbis audio and theora video, but also include speex, FLAC, CMML, and possibly MNG data. If this is achieved in a short time frame, the project can continue onto developing support for these multi-track files in e.g. vlc or ffmpeg. This can even extend to providing a full tool-chain from authoring captions for a video file, to creating the respective multitrack Ogg file, and finally to playing them back inside vlc where the captions are shown as overlays.<br />
<br />
<br />
===SHARE application for the Spread Open Media project===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: Spread Open Media is a community project to promote the different free formats for multimedia and otherwise. SHARE is a pratical step to build on this community and spread more files.<br />
<br />
Proposed Development: SHARE is intended to be a PHP project. We do not discard the possibility of using Rails or Python, but the current SOM server does not support these. SHARE will be a WebJay-like clone, as in users will be able to register, vote, comment and upload their own XSPF playlists. Basically, it is a playlist sharing application. Using OpenID for registration and Cortado (an existing Java applet) for playback would be welcome additions.<br />
<br />
===Dirac support in liboggplay and liboggz===<br />
<br />
'''Mentor:''' ??<br />
<br />
Right now [http://wiki.xiph.org/index.php/OggPlay liboggplay] only support Theora video. <br />
Your aim for this project is to add support for [http://dirac.sourceforge.net/ Dirac],<br />
this should be done using [http://schrodinger.sourceforge.net/ libschrodinger].<br />
Doing this, you will add OggDirac support to the OggPlay Browser Plugin and the upcoming <video> tag support in Firefox.<br />
<br />
<br />
== Guidelines for Applying ==<br />
<br />
Remember that many people will apply to work on the Summer of Code.<br />
<br />
Keep in mind that those of us evaluating your application do not know you, we do not know what kind of <br />
experience you have, we do not know what you have done in the past and we have to pick the best people <br />
suited for a particular task.<br />
<br />
Hence, it is very important that you tell us in your email why you should be considered to implement a <br />
particular project. Please use the application template at [[Summer of Code Applications]] as a starting point.<br />
<br />
== See Also ==<br />
*[[CodingGuidelines]]<br />
*[[MIT approach to design and implementation]]<br />
*[[How to do a release]]<br />
*[[Summer of Code 2007]]<br />
*[[Summer of Code 2006]]</div>J^https://wiki.xiph.org/index.php?title=Summer_of_Code_2008&diff=8731Summer of Code 20082008-03-18T12:23:55Z<p>J^: </p>
<hr />
<div>This is our ideas page for [http://code.google.com/soc/ Google Summer of Code] projects with [http://xiph.org Xiph.org] and [http://annodex.org/ Annodex]. The two projects participate jointly this year under Xiph's name.<br />
<br />
'''Students''' please use the template at [[Summer of Code Applications]] when applying for a GSoC position.<br />
<br />
'''Mentors''' please visit [[Summer of Code Mentoring]] and help us prepare our application as a mentoring organization.<br />
<br />
== Current Ideas ==<br />
<br />
We need a primary and backup mentor volunteer for any project that is to become an official proposal, but submit something and we'll see who we can round up. :)<br />
<br />
''Project ideas go here''<br />
* Transcode/Tag/Upload tool for Theora et al. (ideally as a firefox extension so web cms integration is easy) '''OggPusher''' details below:<br />
* Theora encoding support in GIMP<br />
* Theora Java port directly (semi)automatically derived from the reference sources<br />
* Speex support in IceS<br />
* Better stream source gui for dvswitch<br />
* Multiplexing support (so one can play audio from video files) in ogg123<br />
:Isn't this already done with the vorbisfile support in 1.2.0?<br />
::At first, I thought it wasn't but that's because I tested with a 2.3 GB film and it didn't work. Smaller files work just fine, which makes me believe there's a bug somewhere that needs to be found. Anyway, we can remove this entry.--Ivo<br />
:::2.3 GB is just above what can be represented as bytes on a signed 32 bit int - clue to the bug ? --[[User:Ogg.k.ogg.k|Ogg.k.ogg.k]]<br />
* XSPF support in ogg123 and oggenc (playlist creation)<br />
* Initial support for OggPCM in some of our tools<br />
* OggMNG tools<br />
:Is this really necessary? I mean, OggMNG seems to have gone nowhere and serve no niche.--Ivo<br />
::We still keep getting asked for a format where speex and images together make up a movie.--Silvia<br />
* ROE implementation for network: using ROE in a client-server negotiation to dynamically request a specific multi-track ogg file using skeleton (Silvia)<br />
* create Ogg caption support for vlc using CMML<br />
* ffmpeg improvements for Xiph.Org codecs:<br />
** add Speex support<br />
** add Ogg Skeleton support<br />
** fix seeking bugs involving Ogg Theora<br />
<br />
==Detailed Project Description==<br />
<br />
===Mv_Embed: Accessibility and [re]usability:===<br />
'''Mentor:''' Michael Dale, Anna (EngageMedia) <br/><br />
'''Existing Feature Set:''' [http://metavid.ucsc.edu/wiki/index.php/Mv_Embed Mv_Embed] is an existing javascript library that takes html5 <video> tag and rewrites the video tag for to support in-page ogg theora playback in contemporary browsers. MV_embed supports may browsers and plugins including: native browser support such as firefox 3 video builds, oggplay plugin for firefox2 in win, mac, linux ; VLC activX/plugin for win IE, firefox, and mac, linux firefox; mplayer & totem for linux; and java cortado for microsoft, sun, apple java VM for IE, firefox & safari. Mv_embed maps all these plugin javascript systems to a ~near~ html5 spec api enabling web application developers to take advantage of a uniform javascript API for video control and interaction without having to worry about the underling plugin systems. Mv_Embed is used as part of the metavidWiki Project (screen cast).<br />
<br />
'''Proposed Development:''' Mv_Embed will be enhanced around two goals integration into prominent open source Content Management Systems and better accessibility of close captions and associative video metadata.<br />
<br />
Mv_Embed will integrate into existing CMS video extensions for quick "one-off" ogg theora support.<br />
* FilmForge (Drupal)<br />
* ShowInABox (Wordpress)<br />
* Plumi (Plone)<br />
<br />
Additional server side components like transcoding to theora, generating thumbnails, and exporting metadata will also be developed. Where time / resources permit server side hooks into ffmepg2theora (for transcoding) and mplayer (for generating thumbnails) will be developed for the CMS systems as well. As OggPusher matures simple hooks will be added to the CMS's to support direct ogg theora clip uploads.<br />
<br />
'''Accessibility & CMML'''<br />
Accessible components of mv_embed consist of obtaining the metadata and putting it into the dom as a child of the video element. Mv_Embed will offer a reference javascript interface for client interactions with that metadata. The metadata will be structured in Continues Media Markup Language (CMML). CMML is a part of the annodex technology set and can either be muxed into the ogg stream or be requested separately via XML. Mv_Embed will negotiate a transport method for the metadata that will work for the given plugin type.(Currently only oggplay plugin supports ogg-skeleton and exposing muxed CMML tracks in the ogg stream).<br />
<br />
Mv_Embed is part of [http://metavid.ucsc.edu/wiki/index.php/MetaVidWiki MetavidWiki] enables community authored transcripts and exposes these multiple layers in CMML. Proposed work on Mv_Embed will generalize these development efforts taking place in the metavid project for other CMS's and improve the usability and accessibility of these metadata layers in javascript based interfaces and mutil-plugin playback environment.<br />
<br />
=== Theora Java port directly (semi)automatically derived from the reference sources ===<br />
<br />
The current Java decoder port (jheora) is rapidly heading towards becoming obsolete. It was based on the C reference implementation during alpha development stages, which means it cannot decode advanced Theora streams using non-VP3 features. Current Theora mainline features a completely new decoder, implementing all bitstream features, and a new encoder needing these advanced decoder capabilities is expected to arrive soon. jheora, however, appears to be unmaintainable for very same reasons the original alpha decoder was dropped. To make matters worse there's a very very noticable lack of someone being at least moderately skilled in Java AND being skilled in video coding AND writing Java code with acceptable speed (video decoding should be realtime). Any conventional manual Java source port may quickly bitrot to an unmaintainable state.<br />
<br />
Thankfully there *are* technologies to get C code to execute in the Java Virtual Machine. The obvious idea would be to translate the actual source code to Java using an automated process, but no reliable tools exist doing this (and given the concept-clash in some areas between C and Java it's unlikely something really nice will emerge). Projects like NestedVM (http://nestedvm.ibex.org/) and Cibyl (http://spel.bth.se/index.php/Cibyl) are doing '''language agnostic translations to Java bytecode''', using the GCC toolchain.<br />
<br />
In the first step the code to be ported is compiled to MIPS ELF binaries. Those are then converted to Java bytecode. This works pretty well because MIPS is pretty similar to Java bytecode and most instructions can be mapped directly.<br />
<br />
Crazyness? Work of mad men, living in nuclear families, fighting rampaging robots with nuclear missiles? Does this actually work? Yup, it does work, and some Xiph encoders/decoders have been successfully converted with NestedVM already (http://groups.google.com/group/nestedvm/browse_thread/thread/df96ef7337f390e4/a45fdd66534e7641?#a45fdd66534e7641) and figures provided by the Cibyl project indicate that the MIPS-to-Java approach isn't actually slower than a "real" Java port (http://spel.bth.se/index.php/Cibyl_performance) - it's sometimes faster, sometimes slower.<br />
<br />
The problem with NestedVM is that there appears to be no means to generate a Java interface from the converted binaries - which means that while the converted binaries work fine on Java there's no way to call the functionality of the converted code by other Java classes, which would be necessary to e.g. write a player applet.<br />
<br />
Cibyl, on the other hand, does provide means to generate Java interfaces, given the binary and the header files. Cibyl, however, needs to link some helper symbols into the MIPS binary, which apparently requires some tricks to work in the usual autoconf setup (http://groups.google.com/group/cibyl-devel/browse_thread/thread/584e5fc3b9bc7e2c). So for the Cibyl port to work some autoconf magic may be necessary.<br />
<br />
So what should this project do:<br />
<br />
* Create and document a working setup for doing language-agnostic Java conversions<br />
* Demonstrate this for Theora<br />
* Find a way to generate a Java interface in a way being automated as much as possible<br />
<br />
This project most likely is directly bound to progress made with either NestedVM or Cibyl. The upside of this is that any results may be directly applied to other projects, too<br />
<br />
--[[User:Maikmerten|Maikmerten]] 03:43, 12 March 2008 (PDT)<br />
<br />
<br />
===OggPusher===<br />
'''Mentor:''' Michael Dale ... or anyone else with more experience with firefox extensions/ffmpeg2theora ? <br><br />
'''Abstract:''' OggPusher is a proposed cross platform packaging of ffmpeg2theora as a browser extension. This exposes JavaScript hooks to web applications enabling easy client side transcodes from high quality source originals such as DV or MPEG2 and uploading into web based content management systems.<br><br />
'''Sample Application Flow:''' is as follows: A user visits a oggPusher enabled web service. The firefox user is prompted to install a browser extension via firefox's .xpi extension framework. Once enabled, the web service upload interface does a call to the oggPusher to expose a "open file" dialog box on the client. The websevice access the oggPusher api to set the requested transcode bitrate and other transcode options (such as interlace, number of audio channels, resolution etc). The client selects the high quality local file and begins transcoding to a temporary location on local disk. If there is an error in transcoding the upload is aborted and an error is exposed to web application. Once the file is done transcoding, the web interface has the client issue a POST of the transcoded file.(if the server supports more efficient PUT than that can be used). The amount of the file that has been transcoded and the amount uploaded are exposed via javascript hooks so that web application javascript interface can update the client on upload progress. If the the upload connection is reset a ajax request on the client can request "bytes upload so far" from the server and have oggPusher begin uploading from that point in the temporary local ogg file. A local file hash could be rechecked to insure the local file has not changed. The server can then do a simple join on the uploaded pieces, enabling reusable uploads over existing http protocol. If the server does not support resumes the file will be uploaded from the start.<br />
<br />
'''Features for initial Release:'''<br />
* A .xpi extension based on ffmpeg2theoa that supports uploading of local files of any type that ffmpeg accepts.<br />
* Supports two modes of operation<br />
** zero server side config where oggPusher just gives the option of uploading theora video where it finds a form file input type.<br />
** server side config where the server/service hooks into oggPusher for extra functionality, like resuming transferrer and status updates integrated with the web application.<br />
* A simple javascript api for controlling ffmpeg2theora encoding options. These options will be pre-demerited and javascript input will be scrubbed to avoid client side security risks.<br />
* A set of javascript hooks for oggPusher that expose upload progress, encoding progress and transcoding errors.<br />
* A sample server side implementation using php/html/javascript for grabbing ogg files from oggPusher.<br />
<br />
<br />
'''Future Feature RoadMap:'''<br />
Once the basic implementation has been deployed the following features will be targeted for future versions:<br />
<br />
* Integration with popular open source CMS's first target is mediaWiki.<br />
* Hooks for connecting into "live" interfaces such as firewire digital video input or USB web cams.<br />
** Extend oggfwd and server side components for in browser live streaming to web services.<br />
* Extend to support ffmpeg2Dirac and future open source media codecs.<br />
* Enable javascript hooks for grabbing highquality jpg or png screen grabs from the original source to be uploaded alongside the encoded video.<br />
* Enable Bittorrent uploads<br />
<br />
===XSPF support in oggenc and ogg123 applications===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: oggenc and ogg123 are part of a toolset named vorbis-tools, where oggenc is a Vorbis encoder and ogg123 an audio player. XSPF is a XML-based playlist format, extensible, but simple and efficient.<br />
<br />
Proposed Development: this project would extend those two applications (oggenc and ogg123) to support XSPF. Namely, oggenc would be able to generate a playlist from the encoded files, and ogg123 would be able to parse a playlist for supported media for playback. This is a C project, with the intention of using code from or actually linking to the BSD-licensed libSpiff, which is a C++ XSPF library.<br />
<br />
<br />
===php_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... or anyone else with an a php background e.g. Michael Dale<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. php_annodex can e.g. be used to extend Drupal, MediaWiki and other php-based applications with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through php_annodex.<br />
<br />
'''What is the project?'''<br />
An initial version of [http://annodex.net/software/phpannodex/index.html php_annodex exists], but it is incomplete and not up-to-date. This is in comparison with such support in python through [http://annodex.net/taxonomy_menu/1/19 pyannodex]. A GSoC student would be expected to bring the support for Xiph and Annodex technology in php_annodex up-to-date. In addition, he/she could extend this work by also implementing media support in a plugin, e.g. the Drupal module [http://annodex.net/software/phpannodex/index.html Acidfree]. php_annodex is simply a php wrapper around the C-libraries libannodex and liboggz. It may suffice to just focus on liboggz.<br />
<br />
<br />
===ruby_annodex: wrapper to libannodex or liboggz for doing media stuff===<br />
<br />
'''Mentor:''' Silvia Pfeiffer<br/><br />
<br />
'''What is it?'''<br />
Direct interaction with Ogg video and audio files from within a Web scripting language is key to providing further support to existing and new Web media applications. ruby_annodex can e.g. be used to extend rails with function calls to control opening, closing, seeking, playing, pausing, telling position and similar interactions with audio/video. Further, since Annodex has CMML for time-aligned annotations, hyperlinks to other places, and textual descriptions (such as captions) can be accessed and used through ruby_annodex.<br />
<br />
'''What is the project?'''<br />
A python wrapper of similar type called [http://annodex.net/taxonomy_menu/1/19 pyannodex] exists. The ruby_annodex wrapper should provide similar functionality to ruby, in particular with a view of using it from within rails for the development of Web applications. Development of an example application in ruby on rails would be part of this. Extension of this project to include media support into a ruby-based CMS is possible.<br />
<br />
<br />
===Using ROE to create multi-track Ogg files===<br />
<br />
'''Mentor:''' Silvia Pfeiffer ... and anyone else interested in ROE, e.g. Ralph Giles, Conrad Parker, Michael Dale, Shane Stephens<br/><br />
<br />
'''What is it?'''<br />
[http://trac.annodex.net/wiki/MovieDescriptionLanguage ROE] is a small XML description language for multi-track media files. It can be used for authoring multi-track media files from separate physical files on disk. It can also be used on a Web server to dynamically create multi-track media resources where the tracks are selected through the request from the client.<br />
<br />
'''What is the project?'''<br />
In this project, we only implement and experiment with the file multiplexing side of things. The ROE specification is very new and potentially incomplete, so part of the project will be to validate this specification. The other part will be to create an authoring tool that can take a ROE file, parse it, pull in all the input audio, video, text etc files and create an Ogg file with a Skeleton that contains the equivalent of ROE inside the binary file. The project will start with a focus on multiplexing vorbis audio and theora video, but also include speex, FLAC, CMML, and possibly MNG data. If this is achieved in a short time frame, the project can continue onto developing support for these multi-track files in e.g. vlc or ffmpeg. This can even extend to providing a full tool-chain from authoring captions for a video file, to creating the respective multitrack Ogg file, and finally to playing them back inside vlc where the captions are shown as overlays.<br />
<br />
<br />
===SHARE application for the Spread Open Media project===<br />
<br />
Mentor: Ivo Emanuel Gonçalves<br/><br />
Existing Feature Set: Spread Open Media is a community project to promote the different free formats for multimedia and otherwise. SHARE is a pratical step to build on this community and spread more files.<br />
<br />
Proposed Development: SHARE is intended to be a PHP project. We do not discard the possibility of using Rails or Python, but the current SOM server does not support these. SHARE will be a WebJay-like clone, as in users will be able to register, vote, comment and upload their own XSPF playlists. Basically, it is a playlist sharing application. Using OpenID for registration and Cortado (an existing Java applet) for playback would be welcome additions.<br />
<br />
===Dirac support in liboggplay and liboggz===<br />
<br />
'''Mentor:''' ??<br />
<br />
Right now [http://wiki.xiph.org/index.php/OggPlay liboggplay] only support Theora video. <br />
Your aim for this project is to add support for [http://dirac.sourceforge.net/ Dirac],<br />
this should be done using [http://schrodinger.sourceforge.net/ libschrodinger].<br />
Doing this, you will add OggDirac support to the OggPlay Browser Plugin and the upcoming <video> tag support in Firefox.<br />
<br />
<br />
== Guidelines for Applying ==<br />
<br />
Remember that many people will apply to work on the Summer of Code.<br />
<br />
Keep in mind that those of us evaluating your application do not know you, we do not know what kind of <br />
experience you have, we do not know what you have done in the past and we have to pick the best people <br />
suited for a particular task.<br />
<br />
Hence, it is very important that you tell us in your email why you should be considered to implement a <br />
particular project. Please use the application template at [[Summer of Code Applications]] as a starting point.<br />
<br />
== See Also ==<br />
*[[CodingGuidelines]]<br />
*[[MIT approach to design and implementation]]<br />
*[[How to do a release]]<br />
*[[Summer of Code 2007]]<br />
*[[Summer of Code 2006]]</div>J^https://wiki.xiph.org/index.php?title=OggVorbis&diff=8272OggVorbis2008-02-03T06:49:51Z<p>J^: </p>
<hr />
<div>== Ogg Vorbis ==<br />
<br />
Default field type: LITTLE ENDIAN unsigned integer<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| packtype | Identifier char[6]: 'vorbis' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | version | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | channels | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| rate | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| bitrate_upper | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| bitrate_nominal | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| bitrate_lower | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| l2bs0 | l2bs1 |e| 28-31<br />
+-+-+-+-+-+-+-+-+-+</div>J^https://wiki.xiph.org/index.php?title=OggTheora&diff=8271OggTheora2008-02-03T06:49:16Z<p>J^: </p>
<hr />
<div>== Ogg Theora ==<br />
<br />
Default field type: BIG ENDIAN unsigned integer<br />
<br />
Field names in full caps refer to fields described in the Theora I<br />
specification. Lowercase refers to theora_info struct members from<br />
libtheora.<br />
<br />
This is the Theora header for theora-alpha3:<br />
<br />
(VMAJ=3, VMIN=2, VREV=0)<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| packtype | Identifier char[6]: 'theora' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | VMAJ | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| VMIN | VREV | FMBW: width >> 4 | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| FMBH: height >> 4 | PICW: frame_width | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | PICH: frame_height | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| PICX: offset_x| PICY: offset_y| FRN: fps_numerator | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | FRD: fps_denominator | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | PARN: aspect_numerator | 28-31<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | PARD: aspect_denominator | 32-35<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| CS: colorspace| NOMBR: target_bitrate | 36-39<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| QUAL | KFGSHIFT| PF| resv| 40-43<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</div>J^https://wiki.xiph.org/index.php?title=OggSpeex&diff=8270OggSpeex2008-02-03T06:48:12Z<p>J^: </p>
<hr />
<div>== Ogg Speex ==<br />
<br />
Default field type: LITTLE ENDIAN unsigned integer<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| speex_string: Identifier char[8]: 'Speex ' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| speex_version: char[20] | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| speex_version_id | 28-31<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| header_size | 32-35<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| rate | 36-39<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| mode | 40-43<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| mode_bitstream_version | 44-47<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| nb_channels | 48-51<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| bitrate | 52-55<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| frame_size | 56-59<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| vbr | 60-63<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| frames_per_packet | 64-67<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| extra_headers | 68-71<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved1 | 72-75<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved2 | 76-79<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</div>J^https://wiki.xiph.org/index.php?title=MIME-Migration&diff=8086MIME-Migration2007-12-30T08:39:24Z<p>J^: /* Applications */</p>
<hr />
<div>''We need an RFC registering the mime types and patches for apache ready to go upstream and to all the distros if we're going to do this.'' -- rillian<br />
<br />
''Apache patch should be a priority. Is anyone available to create it?''--[[User:Saoshyant|Ivo]]<br />
<br />
''Annodex has apache patches for skeleton - is that what you're after?''--[User:silvia|Silvia]]<br />
<br />
This page is for collecting patches related to the MIME type and file extension changes outlined in [[MIME_Types_and_File_Extensions]].<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
== Standards ==<br />
<br />
These Media Types must eventually be registered with the Internet Assigned Numbers Authority; however this is not a prerequisite for implementation -- on the contrary, the IETF prefers demonstrable interoperability prior to registration.<br />
<br />
(Silvia:) It is my understanding that you cannot use a official "standards" MIME type without prior approval of the IETF/IESG and thus while the documentation has not been approved, we will have to use "x-" extensions on the MIME types.<br />
<br />
Please read the [http://www.iana.org/cgi-bin/mediatypes.pl IANA Application for Media Type] for details of the registration procedure.<br />
<br />
== Recommendations ==<br />
<br />
=== Players, File managers etc. ===<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the file extensions .ogv, .oga, .ogx as outlined in [[MIME_Types_and_File_Extensions]].<br />
<br />
.ogg and .spx are kept for backwards compatibility for Vorbis and Speex respectively. Nevertheless, .oga should be considered an alternative extension by all programs.<br />
<br />
Programs that deal with media types, should recognize video/ogg, audio/ogg, and application/ogg.<br />
<br />
=== Encoders ===<br />
<br />
Applications which create Ogg Theora files should be modified to default to the extension .ogv rather than .ogg.<br />
<br />
Applications which create Ogg Vorbis or Ogg Speex files should be modified to allow use of the extension .oga, but should continue to default to the extensions .ogg and .spx respectively. Ogg FLAC applications must be modified to support the .oga extension only.<br />
<br />
== Applications ==<br />
<br />
=== Players ===<br />
<br />
==== GStreamer ====<br />
<br />
A GStreamer hacker writes: ''gstreamer more or less doesn't need anything. There's one tiny thing that could be changed, but it's in API that nothing currently uses, so it doesn't matter.''<br />
<br />
==== MPlayer ====<br />
Mplayer successfuly plays .oga files such as those at [[XMLEmbedding]]. The mplayer<br />
Firefox plugin on Linux loads to play audio/ogg.<br />
<br />
==== VLC ====<br />
mime type associations have to be updated so VLC knows that it supports new extensions<br />
[https://trac.videolan.org/vlc/ticket/1279 VLC ticket]<br />
<br />
==== xine ====<br />
<br />
* xine ignores file extensions on loading, so it can already play files with the new extension .ogv.<br />
<br />
* xine implements a generic demuxer, so it can already play Ogg Audio (.oga) files containing additional bitstreams, ie. its Ogg Audio support is not limited to Ogg Vorbis I (Vorbis-only) files.<br />
<br />
* xine support for Ogg Skeleton bitstreams.<br />
<br />
Nevertheless, this<br />
[http://sourceforge.net/tracker/index.php?func=detail&aid=1726821&group_id=9655&atid=359655 PATCH] adds metadata for the new filename extensions and MIME types to xine's Ogg demuxer, which is useful in reporting xine-lib's capabilities.<br />
<br />
==== Songbird ====<br />
<br />
==== Amarok ====<br />
Amarok developer [http://bugs.kde.org/show_bug.cgi?id=149460 reports]: We get the list of supported filetypes from the engine, and the engine gets it from the backend (e.g. xinelib). Amarok itself doesn't distinguish between formats at all.<br />
<br />
==== XiphQT ====<br />
Arek released a new version, stating it does support the new MIME types and file extensions.<br />
<br />
==== FFMpeg ====<br />
FFMpeg is not able to play ogv files with Skeleton stream since it treated as a video stream with a higher importance than the Theora stream.<br />
<br />
=== File managers, servers etc. ===<br />
<br />
==== Apache ====<br />
Test files on [[XMLEmbedding]] are now .oga served as audio/ogg using<br />
<code><pre>AddType audio/ogg .oga</pre></code> in <code><pre>.htaccess</pre></code>,<br />
implies upstream change is probably simple once new types are approved.<br />
<br />
==== Konqueror ====<br />
<br />
==== Nautilus ====<br />
Nautilus (and the whole of GNOME) uses the f.d.o shared-mime-info package.<br />
Patch: https://bugs.freedesktop.org/show_bug.cgi?id=12890 (please check)<br />
<br />
=== Encoders ===<br />
<br />
==== ffmpeg2theora ====<br />
svn uses .ogv, will be released as 0.21</div>J^https://wiki.xiph.org/index.php?title=MIME-Migration&diff=8073MIME-Migration2007-12-27T06:20:30Z<p>J^: /* ffmpeg2theora */</p>
<hr />
<div>''We need an RFC registering the mime types and patches for apache ready to go upstream and to all the distros if we're going to do this.'' -- rillian<br />
<br />
''Apache patch should be a priority. Is anyone available to create it?''--[[User:Saoshyant|Ivo]]<br />
<br />
''Annodex has apache patches for skeleton - is that what you're after?''--[User:silvia|Silvia]]<br />
<br />
This page is for collecting patches related to the MIME type and file extension changes outlined in [[MIME_Types_and_File_Extensions]].<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
== Standards ==<br />
<br />
These Media Types must eventually be registered with the Internet Assigned Numbers Authority; however this is not a prerequisite for implementation -- on the contrary, the IETF prefers demonstrable interoperability prior to registration.<br />
<br />
(Silvia:) It is my understanding that you cannot use a official "standards" MIME type without prior approval of the IETF/IESG and thus while the documentation has not been approved, we will have to use "x-" extensions on the MIME types.<br />
<br />
Please read the [http://www.iana.org/cgi-bin/mediatypes.pl IANA Application for Media Type] for details of the registration procedure.<br />
<br />
== Recommendations ==<br />
<br />
=== Players, File managers etc. ===<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the file extensions .ogv, .oga, .ogx as outlined in [[MIME_Types_and_File_Extensions]].<br />
<br />
.ogg and .spx are kept for backwards compatibility for Vorbis and Speex respectively. Nevertheless, .oga should be considered an alternative extension by all programs.<br />
<br />
Programs that deal with media types, should recognize video/ogg, audio/ogg, and application/ogg.<br />
<br />
=== Encoders ===<br />
<br />
Applications which create Ogg Theora files should be modified to default to the extension .ogv rather than .ogg.<br />
<br />
Applications which create Ogg Vorbis or Ogg Speex files should be modified to allow use of the extension .oga, but should continue to default to the extensions .ogg and .spx respectively. Ogg FLAC applications must be modified to support the .oga extension only.<br />
<br />
== Applications ==<br />
<br />
=== Players ===<br />
<br />
==== GStreamer ====<br />
<br />
A GStreamer hacker writes: ''gstreamer more or less doesn't need anything. There's one tiny thing that could be changed, but it's in API that nothing currently uses, so it doesn't matter.''<br />
<br />
==== MPlayer ====<br />
Mplayer successfuly plays .oga files such as those at [[XMLEmbedding]]. The mplayer<br />
Firefox plugin on Linux loads to play audio/ogg.<br />
<br />
==== VLC ====<br />
mime type associations have to be updated so VLC knows that it supports new extensions<br />
[https://trac.videolan.org/vlc/ticket/1279 VLC ticket]<br />
<br />
==== xine ====<br />
<br />
* xine ignores file extensions on loading, so it can already play files with the new extension .ogv.<br />
<br />
* xine implements a generic demuxer, so it can already play Ogg Audio (.oga) files containing additional bitstreams, ie. its Ogg Audio support is not limited to Ogg Vorbis I (Vorbis-only) files.<br />
<br />
* xine support for Ogg Skeleton bitstreams.<br />
<br />
Nevertheless, this<br />
[http://sourceforge.net/tracker/index.php?func=detail&aid=1726821&group_id=9655&atid=359655 PATCH] adds metadata for the new filename extensions and MIME types to xine's Ogg demuxer, which is useful in reporting xine-lib's capabilities.<br />
<br />
==== Songbird ====<br />
<br />
==== Amarok ====<br />
Amarok developer [http://bugs.kde.org/show_bug.cgi?id=149460 reports]: We get the list of supported filetypes from the engine, and the engine gets it from the backend (e.g. xinelib). Amarok itself doesn't distinguish between formats at all.<br />
<br />
==== XiphQT ====<br />
Arek released a new version, stating it does support the new MIME types and file extensions.<br />
<br />
=== File managers, servers etc. ===<br />
<br />
==== Apache ====<br />
Test files on [[XMLEmbedding]] are now .oga served as audio/ogg using<br />
<code><pre>AddType audio/ogg .oga</pre></code> in <code><pre>.htaccess</pre></code>,<br />
implies upstream change is probably simple once new types are approved.<br />
<br />
==== Konqueror ====<br />
<br />
==== Nautilus ====<br />
Nautilus (and the whole of GNOME) uses the f.d.o shared-mime-info package.<br />
Patch: https://bugs.freedesktop.org/show_bug.cgi?id=12890 (please check)<br />
<br />
=== Encoders ===<br />
<br />
==== ffmpeg2theora ====<br />
svn uses .ogv, will be released as 0.21</div>J^https://wiki.xiph.org/index.php?title=TheoraSoftwareEncoders&diff=7583TheoraSoftwareEncoders2007-10-10T16:38:38Z<p>J^: /* Linux/BSD */</p>
<hr />
<div>== Multi-platform ==<br />
*[http://www.v2v.cc/~j/ffmpeg2theora/ ffmpeg2theora] a commandline encoder from any format read by ffmpeg to Ogg Theora/Vorbis: [http://svn.xiph.org/trunk/ffmpeg2theora/ svn], [http://www.v2v.cc/~j/ffmpeg2theora/download.html latest releases].<br />
*[http://www.videolan.org/ VLC Media Player] Can transcode from any source it supports into Ogg/Theora. WARNING: Apparently creates broken Ogg streams.<br />
*[http://gstreamer.freedesktop.org/ GStreamer] GStreamer is a library that allows the construction of graphs of media-handling components, ranging from simple Ogg/Vorbis playback to complex audio (mixing) and video (non-linear editing) processing.<br />
<br />
== Windows ==<br />
*[http://dir.visonair.tv/streamer.php Visonair.tv Ogg Streamer] A windows application to stream directly from a webcam to an Icecast server.<br />
*[http://www.visonair.tv/ Visonair.tv Virtual Stage] Includes an application to encode to Ogg Theora, forces fixed size and encoding parameters though. Registration required.<br />
*[http://www.freewarefiles.com/program_6_227_33306.html GFrontend ffmpeg2theora] GUI Frontend for ffmpeg2theora<br />
*[http://mediacoder.sourceforge.net/ MediaCoder] Application to encode media files into many target formats, including Ogg Theora.<br />
*[http://www.erightsoft.com/ SUPER] General purpose converter application, also serves as a frontend to ffmpeg2theora.<br />
<br />
== Linux/BSD ==<br />
*[http://thoggen.net/ Thoggen] is a DVD backup utility ('DVD ripper') for Linux, based on GStreamer and Gtk+.<br />
*[http://freej.org/ Freej] Freej is a realtime video mixer. It can stream ogg theora vorbis live to [http://icecast.org icecast]. Check [http://lab.dyne.org/FreejStreaming here] for more info.<br />
* [http://oggconvert.tristanb.net/ OggConvert] is a small Gnome utility which uses GStreamer to convert (almost) any media file to Ogg Vorbis, Theora and Dirac.<br />
<br />
== Mac OS X ==<br />
*[http://xiph.org/quicktime XiphQT] allows you to export from Quicktime, or any application supporting Quicktime (i.e. Final Cut Pro), to Ogg Theora/Vorbis.<br />
*[http://v2v.cc/~j/SimpleTheoraEncoder/ Simple Theora Encoder] an ffmpeg2theora frontend<br />
<br />
== See also== <br />
{{Template:Theora}}</div>J^https://wiki.xiph.org/index.php?title=MIME-Migration&diff=7286MIME-Migration2007-09-01T16:41:50Z<p>J^: /* VLC */</p>
<hr />
<div>''We need an RFC registering the mime types and patches for apache ready to go upstream and to all the distros if we're going to do this.'' -- rillian<br />
<br />
This page is for collecting patches related to the MIME type and file extension changes outlined in [[MIME_Types_and_File_Extensions]].<br />
<br />
Please add links and information about your favorite applications to this page!<br />
<br />
== Standards ==<br />
<br />
These Media Types must eventually be registered with the Internet Assigned Numbers Authority; however this is not a prerequisite for implementation -- on the contrary, the IETF prefers demonstrable interoperability prior to registration.<br />
<br />
Please read the [http://www.iana.org/cgi-bin/mediatypes.pl IANA Application for Media Type] for details of the registration procedure.<br />
<br />
== Recommendations ==<br />
<br />
=== Players, File managers etc. ===<br />
<br />
Applications which read (decode) Ogg files should be extended to additionally recognize the file extensions .ogv, .oga, .ogx as outlined in [[MIME_Types_and_File_Extensions]].<br />
<br />
=== Encoders ===<br />
<br />
Applications which create Ogg Theora files should be modified to default to the extension .ogv rather than .ogg.<br />
<br />
Applications which create Ogg Vorbis or Ogg Speex files should be modified to allow use of the extension .oga, but may continue to default to the extensions .ogg and .spx respectively.<br />
<br />
== Applications ==<br />
<br />
=== Players ===<br />
<br />
==== GStreamer ====<br />
<br />
A GStreamer hacker writes: ''gstreamer more or less doesn't need anything. There's one tiny thing that could be changed, but it's in API that nothing currently uses, so it doesn't matter.''<br />
<br />
==== MPlayer ====<br />
<br />
==== VLC ====<br />
mime type associations have to be updated so VLC knows that it supports new extensions<br />
[https://trac.videolan.org/vlc/ticket/1279 VLC ticket]<br />
<br />
==== xine ====<br />
<br />
* xine ignores file extensions on loading, so it can already play files with the new extension .ogv.<br />
<br />
* xine implements a generic demuxer, so it can already play Ogg Audio (.oga) files containing additional bitstreams, ie. its Ogg Audio support is not limited to Ogg Vorbis I (Vorbis-only) files.<br />
<br />
* xine support for Ogg Skeleton bitstreams.<br />
<br />
Nevertheless, this<br />
[http://sourceforge.net/tracker/index.php?func=detail&aid=1726821&group_id=9655&atid=359655 PATCH] adds metadata for the new filename extensions and MIME types to xine's Ogg demuxer, which is useful in reporting xine-lib's capabilities.<br />
<br />
==== Songbird ====<br />
<br />
==== Amarok ====<br />
<br />
==== XiphQT ====<br />
<br />
=== File managers, servers etc. ===<br />
<br />
==== Apache ====<br />
<br />
==== Konqueror ====<br />
<br />
==== Nautilus ====<br />
<br />
=== Encoders ===<br />
<br />
==== ffmpeg2theora ====<br />
<br />
[https://trac.xiph.org/attachment/ticket/1189/ffmpeg2theora-ogv.diff?format=raw PATCH] attached to [https://trac.xiph.org/ticket/1189 ticket:1189] changes default output extension to .ogv.</div>J^