[Bug 700537] theoradec drops frames because it needs a keyframe after a seek (bug in oggdemux from what I gathered)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=700537
  GStreamer | gst-plugins-base | 1.0.6

--- Comment #14 from Sebastian Dröge <slomo at circular-chaos.org> 2013-07-05 07:42:07 UTC ---
(In reply to comment #13)

> > For the second part, your new patch, I think that will cause A/V sync issues.
> > So when doing a seek we will jump to the earliest position that contains the
> > seek position for all streams. This means that all but the earliest stream will
> > have non-keyframe packets for some time, that should be dropped. Which happens
> > because current_granule==-1 after a seek until the packet actually contains a
> > new granule position (which will be the case for a keyframe).
> > 
> > Is there any problem with the packets that are dropped after a seek without
> > your patch? Is it enough to just revert
> > b41cd0428956f3ade9b428149e38be8e788556fe and then everything is fine for this
> > bug here?
> 
> Unfortunately not. Without that patch, we still get the issue, also I don't
> think that would cause stream sync issues afaiu, I can not prove it but from
> testing I can say I didn't experience unsyncing issues, manual testing is
> obviously not enough but it's a good hint nevertheless.

Can you try to understand what exactly is the remaining problem without your
patch after reverting b41cd0428956f3ade9b428149e38be8e788556fe?


The problem I see with your patch is that it makes oggdemux assume that it
currently is at exactly that keyframe granule, and then oggdemux does
interpolations of the granulepos based on that. However oggdemux will be
*before* this keyframe granule for all stream except for the one that has the
earliest keyframe we seeked to.
So for all these streams we would output invalid timestamps until the next
keyframe is read.

(Correct me if I'm wrong, you probably know that code better than me now :) )

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.