Talk:MatroskaOpus

From XiphWiki

(Difference between revisions)
Jump to: navigation, search
(ffmpeg vp8&opus in mkv fail to play)
m (Added <blockquote>s to quote (to avoid confusing the reader))
 
Line 6: Line 6:
''found in a forum, written by a matroska developer:''
''found in a forum, written by a matroska developer:''
-
 
+
<blockquote>
-
ffmpeg has an implementation that writes Matroska files with CodecID A_OPUS. However, the way it is stored ignores all the problems surrounding the storage of Opus in Matroska. Add that the we (Matroska team) haven't specified the storage yet, and you can see that you should not use ffmpeg for muxing Opus into Matroska at the moment.
+
ffmpeg has an implementation that writes Matroska files with CodecID A_OPUS. However, the way it is stored ignores all the problems surrounding the storage of Opus in Matroska. Add that the we (Matroska team) haven't specified the storage yet, and you can see that '''you should not use ffmpeg for muxing Opus into Matroska at the moment'''.
-
 
+
<br><br>
-
mkvmerge's support for Opus in Matroska is experimental. It can be read from Ogg and Matroska files (mkvmerge can read its own creation). However, as stated above the Matroska specs regarding Opus are not done yet. And mkvmerge also hasn't solved the remaining problems yet. That's why mkvmerge uses A_OPUS/EXPERIMENTAL. This will change to A_OPUS once the specs have been finalized and mkvmerge has been updated to match them. The storage format itself will not change too much, however, the way timecodes are calculated/offset/adjusted might -- meaning there is a definite chance you won't be able to play back A_OPUS/EXPERIMENTAL files in the future. So this means that you should not throw away the source files after using mkvmerge for muxing Opus at the moment
+
mkvmerge's support for Opus in Matroska is experimental. It can be read from Ogg and Matroska files (mkvmerge can read its own creation). However, as stated above the Matroska specs regarding Opus are not done yet. And mkvmerge also hasn't solved the remaining problems yet. That's why mkvmerge uses A_OPUS/EXPERIMENTAL. This will change to A_OPUS once the specs have been finalized and mkvmerge has been updated to match them. The storage format itself will not change too much, however, the way timecodes are calculated/offset/adjusted might -- meaning there is a definite chance you won't be able to play back A_OPUS/EXPERIMENTAL files in the future. So this means that you '''should not throw away the source files after using mkvmerge for muxing Opus at the moment''' :)
-
 
+
<br><br>
As for the specs: about a week ago I've grilled several guys in the Opus IRC channel about the problematic areas. I have a much better understanding of what is what and how stuff should be handled. However, how that translates into Matroska terms is still work that must be done.
As for the specs: about a week ago I've grilled several guys in the Opus IRC channel about the problematic areas. I have a much better understanding of what is what and how stuff should be handled. However, how that translates into Matroska terms is still work that must be done.
-
 
+
<br><br>
I plan on continueing this work over the next couple of weeks, but I don't have a time frame for that. Nor does anyone else seem to want to help, so there.
I plan on continueing this work over the next couple of weeks, but I don't have a time frame for that. Nor does anyone else seem to want to help, so there.
-
 
+
<br><br>
The areas that no solutions/decisions exist for currently are:
The areas that no solutions/decisions exist for currently are:
-
 
+
<br><br>
* Who is responsible for adjusting the timecodes for pre-skip -- the muxer, the demuxer, the codec? This directly influences the question "Must the pre-skip be stored in the Matroska track headers?".
* Who is responsible for adjusting the timecodes for pre-skip -- the muxer, the demuxer, the codec? This directly influences the question "Must the pre-skip be stored in the Matroska track headers?".
* Sample-accurate trimming in the last packet. For this we need a new element in the Matroska BlockGroup element. However, this can be solved easily (unlike the the pre-skip issue which is much more involved).
* Sample-accurate trimming in the last packet. For this we need a new element in the Matroska BlockGroup element. However, this can be solved easily (unlike the the pre-skip issue which is much more involved).
* The question whether or not we can implement a solution for pre-skip that works for rolling intra video as well is still unresolved (mostly because I have no friggin' clue how rolling intra video is handled).
* The question whether or not we can implement a solution for pre-skip that works for rolling intra video as well is still unresolved (mostly because I have no friggin' clue how rolling intra video is handled).
-
 
+
<br><br>
-
 
+
Areas we do have solutions for:
Areas we do have solutions for:
-
 
+
<br><br>
* Handling of pre-roll (the new cue elements "cue relative position" and "cue duration" can be used for this, both muxers and demuxers must be enabled to make use of them)
* Handling of pre-roll (the new cue elements "cue relative position" and "cue duration" can be used for this, both muxers and demuxers must be enabled to make use of them)
* CodecPrivate data format (simply the format header/first Opus packet in a logical stream -- if I remember correctly)
* CodecPrivate data format (simply the format header/first Opus packet in a logical stream -- if I remember correctly)
-
 
+
<br><br>
-
Note that the Xiph wiki page for Opus in Matroska is NOT up to date.  
+
Note that the [[MatroskaOpus|Xiph wiki page for Opus in Matroska]] is NOT up to date.  
 +
</blockquote>
=== question ===
=== question ===

Latest revision as of 17:19, 13 June 2013

current status question

forum post

http://forum.doom9.org/showthread.php?p=1610364#post1610364

found in a forum, written by a matroska developer:

ffmpeg has an implementation that writes Matroska files with CodecID A_OPUS. However, the way it is stored ignores all the problems surrounding the storage of Opus in Matroska. Add that the we (Matroska team) haven't specified the storage yet, and you can see that you should not use ffmpeg for muxing Opus into Matroska at the moment.

mkvmerge's support for Opus in Matroska is experimental. It can be read from Ogg and Matroska files (mkvmerge can read its own creation). However, as stated above the Matroska specs regarding Opus are not done yet. And mkvmerge also hasn't solved the remaining problems yet. That's why mkvmerge uses A_OPUS/EXPERIMENTAL. This will change to A_OPUS once the specs have been finalized and mkvmerge has been updated to match them. The storage format itself will not change too much, however, the way timecodes are calculated/offset/adjusted might -- meaning there is a definite chance you won't be able to play back A_OPUS/EXPERIMENTAL files in the future. So this means that you should not throw away the source files after using mkvmerge for muxing Opus at the moment :)

As for the specs: about a week ago I've grilled several guys in the Opus IRC channel about the problematic areas. I have a much better understanding of what is what and how stuff should be handled. However, how that translates into Matroska terms is still work that must be done.

I plan on continueing this work over the next couple of weeks, but I don't have a time frame for that. Nor does anyone else seem to want to help, so there.

The areas that no solutions/decisions exist for currently are:

  • Who is responsible for adjusting the timecodes for pre-skip -- the muxer, the demuxer, the codec? This directly influences the question "Must the pre-skip be stored in the Matroska track headers?".
  • Sample-accurate trimming in the last packet. For this we need a new element in the Matroska BlockGroup element. However, this can be solved easily (unlike the the pre-skip issue which is much more involved).
  • The question whether or not we can implement a solution for pre-skip that works for rolling intra video as well is still unresolved (mostly because I have no friggin' clue how rolling intra video is handled).


Areas we do have solutions for:

  • Handling of pre-roll (the new cue elements "cue relative position" and "cue duration" can be used for this, both muxers and demuxers must be enabled to make use of them)
  • CodecPrivate data format (simply the format header/first Opus packet in a logical stream -- if I remember correctly)


Note that the Xiph wiki page for Opus in Matroska is NOT up to date.

question

My question: what's the current status of this?

I've tried packing VP8 and Opus in MKV with ffmpeg, and VLC fails to play the audio stream (video works): "mkv demux error: unknown codec id=`A_OPUS/EXPERIMENTAL'" (got VLC 2.0.6-0-gbe9623c, ffmpeg 1.2.1, opus 1.0.2)

TheJJ 18:27, 12 June 2013 (PDT)

Personal tools


Main Page

Xiph.Org Projects

Audio—

Video—

Text—

Container—

Streaming—