[Bug 675132] tsdemux: implement proper seeking with binary search and keyframe detection

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=675132
  GStreamer | gst-plugins-bad | git

--- Comment #24 from Edward Hervey <bilboed at bilboed.com> 2014-03-21 08:15:07 UTC ---
(In reply to comment #22)
> (In reply to comment #21)
> > Review of attachment 272448 [details] [details]:
> > 
> > This is going in the right direction, but should be rebased in a slightly
> > different way:
> > 
> > * Accumulate buffers that contain SPS and/or PPS and/or SEI (and not use
> > bytewriters) starting from the first SPS you see
> > * Accumulate frames starting from the first keyframe
> > * If you see a new keyframe, flush all previous keyframe/frame
> > * When you see a frame for your target seek time, you can push out the
> > requested seek segment on all streams and push out pending buffers
> > 
> > The advantage of this is that you don't need to rewind back to a previous
> > position. You've already parsed/collected everything you want and can just push
> > it.
> 
> We need to rewind anyway to find the first SPS, why would we want to make a
> second forward pass when we can get everything in the first pass ?

  You *need* to collect everything going forward.
  For a certain frame you need to push the SPS, PPS and SEI that are just
before, and not some misc one you found later on. You're not guaranteed a
SPS/PPS/SEI you saw after the target frame actually applies to that
frame/keyframe.

  From a given position, until you've found a SPS/PPS, you don't collect/store
anything. If you see a frame which is after the requested seek position and you
haven't seen a PPS/SPS, you recalculate another (earlier) offset.

  If you're lucky and you do see/store SPs/PPS/SEI/Keyframe ... you can just
push them.

  If there was too much (multiple keyframes between SPS/PPS and target frame),
you discard the keyframe/frame that you didn't want.

> 
> > 
> > Note that non-h264 streams will also need to have their buffers collected up
> > until the requested seek position. You can use the stream->pending list for
> > that.
> 
> up until the requested seek position but from which point ?

  You'll just have to put some delta before the seek position (2 previous
buffers for audio should be enough, 1 second for video might be required).

> 
> > @@ +817,3 @@
> >    res = GST_FLOW_OK;
> > 
> > +  if (flags & GST_SEEK_FLAG_ACCURATE) {
> > 
> > Would make more sense to just store the segment in a separate field
> > (seek_segment?) and use/adjust it later.
> > 
> 
> What would be the reason for that ?
> 

  To handle all the seek variants that tim explained.


Could you also make it just one updated patch instead of patches over patches ?
Makes reviewing easier.

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