[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

Thibault Saunier <tsaunier> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tsaunier at gnome.org

--- Comment #26 from Thibault Saunier <tsaunier at gnome.org> 2014-03-21 17:35:33 UTC ---
(In reply to comment #24)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > Review of attachment 272448 [details] [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.
This is why we always get the SPS/PPS/SEI placed *before* the keyframe that
will be first pushed.
>   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.

I am not sure what you are saying is wrong with the current behaviour. What is
done right now is the following:

  1 - We get the data from the packetizer computed as previously
  2 - We try to find a PPS/SPS/keyframe in the first chunk of data passed
  3 - if we do not find SPS + PPS + SEI:
     - rewind further in the stream
     - got back to 1

So we end up accumulating the SPS/PPS that are right *before* the wanted
keyframe and the various SEI present  between the SPS/PPS and the wanted
keyframe. We know that the SPS/PPS might be far away from the seeked point and
it  would make sense to actually keep the information about where they are...
etc  somewhere to avoid needing to reparse so often.

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

Yes, this is what is done already with the current seeking code anyway.

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

Apart from SNAP which is not handled, I  think the current patch already
handles the various variants.

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