[Matroska-devel] problems with AVC in Matroska

Moritz Bunkus moritz at bunkus.org
Fri Jan 14 22:41:20 CET 2005


Hey,

Abstract:

We need a way to do the references for method #2 (aka "we do not try to
get frame types and references from the AVC bitstream of its frame BUT
we only store I/P frames like MP4 does"). This is a proposal.

Rationale:

Fact is, Nero needs the proper timecodes. Those are the "normal"
timecodes for MP4 files + the timecode offsets given in the CTTS
atom. An example for a file with B frames:

I frame, timecode 0  
P frame, timecode 167
B frame, timecode 42 
B frame, timecode 83 
B frame, timecode 125
P frame, timecode 292
B frame, timecode 209
B frame, timecode 250
I frame, timecode 334
I frame, timecode 375
P frame, timecode 417
P frame, timecode 501
B frame, timecode 459
P frame, timecode 584

So we HAVE to use those timecodes. Now the question about frame types
and references. If we chose to use only I/P frame markings (like MP4)
does, then this leaves us with

I frame, timecode 0  
P frame, timecode 167
P frame, timecode 42 
P frame, timecode 83 
P frame, timecode 125
P frame, timecode 292
P frame, timecode 209
P frame, timecode 250
I frame, timecode 334
I frame, timecode 375
P frame, timecode 417
P frame, timecode 501
P frame, timecode 459
P frame, timecode 584

My question is -- which timecodes should those reference? They could all
simply reference the previous frame. That's what we do with "normal"
MPEG-4 video. But that would actually leave us with the following refs:

I frame, timecode 0, no ref
P frame, timecode 167, ref -167
P frame, timecode 42, ref +125   (!??)
P frame, timecode 83, ref -41
P frame, timecode 125, ref -42
P frame, timecode 292, ref -167
P frame, timecode 209, ref +83   (!??)
P frame, timecode 250, ref -41
I frame, timecode 334, no ref
I frame, timecode 375, no ref
P frame, timecode 417, ref -42
P frame, timecode 501, ref -84
P frame, timecode 459, ref +50   (!??)
P frame, timecode 584, ref -125

As you can see, this leaves us with a couple of frames who only have a
_forward_ reference. Most parsers would do strange things in this
case. I'd guess that most would interprete that as a key frame (because
there's no backward reference), but the parser might also just abort
parsing or whatever. We should avoid this.

Now let's get back to the first block of frames. In that case I've
assumed that the "traditional" B frame model applies to AVC as well. The
timecodes and references for that example are:

I frame, timecode 0, no ref
P frame, timecode 167, ref -167
B frame, timecode 42, ref -42 and +41
B frame, timecode 83, ref -41 and +42
B frame, timecode 125, ref -42 and +42
P frame, timecode 292, ref -125
B frame, timecode 209, ref -42 and +41
B frame, timecode 250, ref -41 and +42
I frame, timecode 334, no ref
I frame, timecode 375, no ref
P frame, timecode 417, ref -42
P frame, timecode 501, ref -84
B frame, timecode 459, ref -42 and +42
P frame, timecode 584, ref -83

This list can be easily converted to I/P frames only with _sane_
references by simply forgetting about all forward references and
re-labeling the "former" B frames as P frames:

I frame, timecode 0, no ref
P frame, timecode 167, ref -167
P frame, timecode 42, ref -42
P frame, timecode 83, ref -41
P frame, timecode 125, ref -42
P frame, timecode 292, ref -125
P frame, timecode 209, ref -42
P frame, timecode 250, ref -41
I frame, timecode 334, no ref
I frame, timecode 375, no ref
P frame, timecode 417, ref -42
P frame, timecode 501, ref -84
P frame, timecode 459, ref -42
P frame, timecode 584, ref -83

IMHO this is the only good way to timestamp frames and calculate the
references needed for the P frames for our method #2.

Mosu

-- 
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