search

kim42083 / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

IE9 playback of file triggers assert #351

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Steps to reproduce:
1. Playback xxxx.webm in IE9

Assert:
File:..\..\..\libwebm\mkvparser.cpp
Line: 8081

Expression: false

File is here:
http://code.google.com/p/webm/downloads/detail?name=sync_def_PF-0_AF-33-BG_FF-33
.webm&can=1&q=Type%3DWebM#makechanges

Original issue reported on code.google.com by fgalli...@google.com on 15 Jul 2011 at 5:00

GoogleCodeExporter commented 9 years ago 
The parser is asserting because it sees a reference time with the value 0.  

We have always required that frames have strictly increasing timestamps, but I 
think we relaxed that requirement and now allow monotonically increasing 
timestamps, in order to support alt-ref frames.  (As a consequence, this means 
that the frames within a track can now have the same timestamp.)

Can you confirm whether this is an alt-ref frame?

We currently increment negative values as a reference to some past frame, and 
positive values as a reference to some future frame.  It was safe to use 0 as a 
nonce value, since we used to require that all frames within a track have a 
unique timestamp.

If we allow 0 as a reference time value, then I think this means we must 
interpret the reference time as reference to a past frame (the same as we do a 
negative value).

Can you think of any reason why this wouldn't work?

Original comment by matthewj...@google.com on 5 Aug 2011 at 11:38

GoogleCodeExporter commented 9 years ago 
That file has a BlockDuration of 0, and a ReferenceBlock (relative) time also 
equal to 0.  This is very strange.

The fact that there is a ReferenceBlock at all means that this cannot be a 
keyframe, so  therefore it must be an alt-ref frame.

We do allow an alt-ref frame to have a timestamp value equal to the previous 
(key)frame, or equal to the next frame.  However, that imposes constraints on 
the value of the associated BlockDuration.

If the ReferenceBlock has a value of 0 (remember that this is a relative 
value), then the timestamp of the alt-ref frame must match that of the previous 
keyframe.  However, that would mean that the duration of the alt-ref must equal 
the difference between the timestamp of the alt-ref frame and the next frame, 
which must necessarily be positive.

If the ReferenceBlock has a BlockDuration of 0, then this means that the 
timestamp of the alt-ref frame must match that of the next frame.  But in that 
case, the ReferenceBlock value must equal the difference between the timestamp 
of the alt-ref frame and the previous keyframe, which must necessarily be 
negative.

(There is a corner case: if the alt-ref frame is the last frame in the file, 
such that there is no next frame, then in principle the BlockDuration for the 
alt-ref could be 0.  What to do here?)

Yet we have a case whereby the ReferenceBlock and the BlockDuration elements 
both have the value 0.  How can this be?  What am I missing here?

Original comment by matthewj...@google.com on 6 Aug 2011 at 12:11

GoogleCodeExporter commented 9 years ago 
I interpreted the spec wrong. I thought the reference was an absolute timecode 
of the block. I changed the file 
http://code.google.com/p/webm/downloads/detail?name=sync_def_PF-0_AF-33-BG_FF-33
.webm&can=1&q=Type%3DWebM#makechanges to match the reference timecode as 
relative.

I also changed the old file to 
http://code.google.com/p/webm/downloads/detail?name=sync_bad_ref_is_absolute_PF-
0_AF-33-BG_FF-33.webm&can=1&q=Type%3DWebM#makechanges and left it in the 
download area.

Original comment by fgalli...@google.com on 9 Aug 2011 at 4:06

GoogleCodeExporter commented 9 years ago 
I made some parser changes to liberalize the treatment of ReferenceBlock values.

Original comment by matthewj...@google.com on 10 Aug 2011 at 3:07

GoogleCodeExporter commented 9 years ago

Original comment by albe...@google.com on 8 Mar 2012 at 12:10