Opus and Matroska

[Mierastor]

Is support for Opus in Matroska being actively developed? It has been mentioned in several places but there seems to be no activity for several months now.

http://wiki.xiph.org/MatroskaOpus
http://lists.matroska.org/pipermail/matroska-devel/2011-December/thread.html#4153
http://lists.matroska.org/pipermail/matroska-devel/2012-September/thread.html#4252

It would be great if one could use x264 + Opus which I think is not currently possible?

[Kurtnoise]

mkvmerge: implement experimental Opus support (https://github.com/mbunkus/mkvtoolnix/commit/98a580978fb500b13ff806e481b4a6b1f742baa5)...4 days ago

It would be great if one could use x264 + Opus which I think is not currently possible?
You should try latest FFmpeg or avconv builds...

[Mierastor]

mkvmerge: implement experimental Opus support (https://github.com/mbunkus/mkvtoolnix/commit/98a580978fb500b13ff806e481b4a6b1f742baa5)...4 days ago


You should try latest FFmpeg or avconv builds...
Thanks! Good to see that something is happening! But I guess that since it is marked as experimental and there is still no official Matroska specification it is of limited use outside experimentation.

x264 + Opus seem to be a very good combination so I hope that there will eventually be an official method for combining them.

[Kurtnoise]

Google has announced that WebM will support VP9 + Opus as audio codec (http://forum.doom9.org/showthread.php?p=1606810#post1606810)...

I think that using a pre-build from mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) you should be able to mux x264 stream within Opus.

[nevcairiel]

Using an experimental build for anything more then testing may not be a good idea, as it may happen that somethings change, and the file won't be readable with the final spec for Opus in MKV.

[sneaker_ger]

Yes. Currently the CodecID is even explicitly marked "EXPERIMENTAL", so this is almost guaranteed to happen.

[Kurtnoise]

Agreed...I never said the contrary but it could be fun to test it though.

the CodecID will not change I think unless there will be a good reason...might be change is the storage of Opus stream into the container.

[sneaker_ger]

The CodecID is "A_OPUS/EXPERIMENTAL", so it will definitely change, even if there are no other changes to the way Opus is stored.

[Kurtnoise]

The CodecID is "A_OPUS/EXPERIMENTAL", so it will definitely change, even if there are no other changes to the way Opus is stored.
Where did you see this ?

Reading the commit (https://github.com/mbunkus/mkvtoolnix/commit/98a580978fb500b13ff806e481b4a6b1f742baa5), it's :
+#define MKV_A_OPUS "A_OPUS"

[sneaker_ger]

It seems to be added dynamically, see p_opus.cpp line 44.

[Mosu]

Looks like this thread needs an official answer ;)

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 (http://wiki.xiph.org/MatroskaOpus) is NOT up to date.

[Mosu]

Using an experimental build for anything more then testing may not be a good idea, as it may happen that somethings change, and the file won't be readable with the final spec for Opus in MKV.

My experimental builds (those in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) are usually as stable as the releases.If the data storage format is still unstable/unfinished then I usually modify the CodecID that mkvmerge outputs for the corresponding format to make that very clear (as with A_OPUS/EXPERIMENTAL).

Of course some of my pre-builds might experiment with newly introduced Matroska elements that are removed again later. However, that's rather rare.

[XeoneR]

*
Does anybody aware how to split & playback an mkv with opus?

[the_weirdo]

*
Does anybody aware how to split & playback an mkv with opus?

LAV Filters (http://forum.doom9.org/showthread.php?t=156191) can do that.

[bugmen0t]

Bump.

Mosu, is there any news on the process of getting opus into matroska? Are you guys any closer to finishing the specs?







Villa Palmar Cancun Timeshare (http://www.beach-rentals.org/what-are-the-advantages-of-trading-power/)

[sneaker_ger]

It has been finalized and already been implemented in mkvtoolnix git, so it should be in the very next stable version.

[Mosu]

What sneaker_ger said. However, the code is still untested. Only my own eyes have looked at the resulting files so far, and that means that there may still be bugs (things that aren't implemented 100% the way the specs say it should be done/how we discussed on matroska-devel how it should be done).

[raine]

Looks like this thread needs an official answer ;)

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 (http://wiki.xiph.org/MatroskaOpus) is NOT up to date.

What is the status on this? The changelog (https://raw.githubusercontent.com/mbunkus/mkvtoolnix/master/ChangeLog) suggests that it is now OK?

[Mosu]

In mkvmerge it is, yes. I cannot comment on ffmpeg's muxer.

[Kurtnoise]

It's well supported in FFmpeg since the release 2.1...

[Mosu]

In the _muxer_ as well? That's good to hear.