[Matroska-devel] problems with AVC in Matroska

Moritz Bunkus moritz at bunkus.org
Wed Jan 12 19:45:07 CET 2005


I have some good and some bad news regarding AVC in Matroska. First the
good news:

Haali had a little chat with one of the Nero developpers. He confirmed
that mkvmerge must use the CTTS atom in a MP4 file when transmuxing from
MP4 to Matroska. Otherwise the timestamps would be out of order, and
Nero's AVC decoder would fall back to FPS mode. And indeed, Haali has
playback working with Nero's AVC decoder now :)

The bad news is something else said developper mentioned:

There is no fixed ordering like in previous standards,
and the decoder uses a combination of frame numbers and picture decding
buffer usage rules to determine the final frame ordering.

Haali also said:

frames are out of order even for files without bframes.
avc can refer to any frame, not only to the neighbor

This means that storage of AVC in Matroska will become a LOT more
difficult. The problem is that MP4 stores neither the frame type nor the
references at the container level. There's only the distinction between
"key frame" and "non-key frame". In order to get all the information (is
it a P or a B frame? Which frames do these frames reference?) every app
putting AVC into Matroska would have to parse the AVC bitstream. This
adds tons of complications and will make AVC-in-Matroska very unpopular
amongst developpers.

There are two solutions for this:

1. Insist on getting the frame type and reference information from the
   AVC bitstream and converting that information into Matroska's
   reference scheme. This is, like I said above, very, very
   complicated. It will push the next mkvtoolnix release far into the
   future, probably right into March. Or the next release will not
   contain AVC support. We also have to think about other applications
   like gstreamer which will have difficulties transporting all
   reference information to the muxers, I fear.

2. Store AVC "the MP4 way". This would mean that we use the proper
   timestamps but do not differentiate between P and B frames. That way
   all the information required can be taken from the MP4 container
   level. This is way easier to implement.

Personally I'm a big fan of "working solutions". Therefore I vote for 2
although I'm pretty sure that most will insist on solution 1. I'm just
warning you that 1. may prove to be a showstopper for AVC in Matroska.



If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds

More information about the Matroska-devel mailing list