[Matroska-devel] problems with AVC in Matroska
steve.lhomme at free.fr
Wed Jan 12 22:46:09 CET 2005
Moritz Bunkus a écrit :
>>Outside of the whole "idealistic editing" application I see little use
>>for references on any MPEG based codec. All of these formats are
>>designed to be container independent and usually the decoder chips
>>take care of buffering etc as needed for decoding without any outside
Hey, this system is not more powerful than our system. We *could* handle
> I totally agree. We can make our lives VERY difficult for VERY little
> gain if we insist on correct references.
>>I don't really know enough about MP4 to comment on whether the CTTS
>>thingy is enough but if it can allow VFR etc. I think it's fine.
> The CTTS atom is a "frame timecode offset" atom. Another atom is used
> for the PTS of all frames, and CTTS gives the differences between the
> PTS and the DTS for each frame. You simply add the two values et voila
> -- you have a proper DTS.
So the CTTS is negative ? (DTS <= PTS)
> For "normal" B frames these timecodes are what we have come to expect
> from e.g. MPEG-1/-2/-4 B frame timestamping.
> Unfortunately, like I've said, that's all the information we have. As
> frames may be out of order *even without B frames* in AVC the CTTS atom
> doesn't give us any hint on frame types themselves.
But I don't think they allow any kind of weird combination. Like have
the first frame, then the last, then whatever frame. There is very
probably some constraints. Just like our MinCache value. If not they're
seriously b0rked and people will assume on their reader and if you're
out of that it won't play.
Another thing to look at is how AVC is stored in MPEG. Since I don't
think MPEG will allow too much weird stuff.
Now on #1 vs #2. Obviously I'd like #1. But apparently AVC is not a
codec made for editing. Only for a finalised encoding (otherwise you
need constraints mentioned above). So either we find constraints and we
"map" them to our reference system. Or we go #2 and decide AVC will
never be editable... BTW for #2 how do you store in Matroska that a
frame is not a frame in the correct order ? Especially for an I frame...
More information about the Matroska-devel