[gstreamer-bugs] [Bug 583903] Ogg muxer or theoraparser fails to remux theora video

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=583903

  GStreamer | gst-plugins-base | Ver: 0.10.22

Alessandro Decina changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alessandro.d at gmail.com




------- Comment #2 from Alessandro Decina  2009-05-26 21:06 UTC -------
A bit of context:

   /* If using newer theora, offset the granulepos by +1, see comment
    * in theora_parse_set_streamheader */
   if (!parse->is_old_bitstream)
-    keyframe += 1;
+    iframe = keyframe + 1;
+  else
+    iframe = keyframe;

   g_return_val_if_fail (frame >= keyframe, -1);
   g_return_val_if_fail (frame - keyframe < 1 << parse->shift, -1);

-  return (keyframe << parse->shift) + (frame - keyframe);
+  return (iframe << parse->shift) + (frame - keyframe);


we can't change the keyframe variable directly.
Take as an example when we process the first buffer of a theora stream. The
function is called with keyframe == 0, frame == 0 (which are the values of
parse->prev_keyframe and parse->prev_frame), since we haven't processed any
previous frames.
To produce a granulepos compatible with the new bitstream format, we increment
the keyframe to have the resulting granulepos == 1|0, which is the correct
granulepos for the first frame of a theora stream.
The problem is that if we increment keyframe (the variable) directly, then the
assertion frame >= keyframe == 0 >= 1 is obviously wrong. The assertion is in
fact checking that the _computed_ parse->prev_keyframe and parse->prev_frame
are consistent, regardless of the bitstream version. The second assertion
checks that the bframe value doesn't overflow the lower bits of granulepos, and
is independent of the bitstream format as well.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=583903.