[Bug 735666] design doc : trick mode handling in demuxers (SKIP)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=735666
  GStreamer | gstreamer (core) | unspecified

--- Comment #2 from Edward Hervey <bilboed at bilboed.com> 2014-09-29 07:36:50 UTC ---
(In reply to comment #1)
> Some random comments...
> 
> Option 0)

> Do you mean that with "potentially causes delay" and the "potential issue" in
> the cons? I think these are not just potential but real problems :)

  That's indeed what I meant :) Option 0 is really "what could we do to get
closer to trick modes without any code modification". It's not meant as a
solution, more a discussion/brainstorming.

> 
> Proposal)
>  - I think there's a problem here as you jump from one keyframe to the next all
> the time. If a) the keyframe distance is not similar all the time it will look
> rather weird to the eye as you jump completely different distances, and if b)
> the keyframe distance is too small for the playback rate you could request too
> much data from upstream and just play a fraction of the duration of each
> keyframe. I don't know what to do about a), but for b) the demuxer should
> probably have some logic to skip keyframes based on how many frames it will
> actually output for the current keyframe. If it's less than a frame or N
> frames, maybe it should instead output one frame or N frames and skip the next
> K keyframes to compensate for that.

> (I just saw that you mentioned this at the
> end, but I think this should be considered from the beginning)

  Right. I'll put it at the top. The goal was to simplify the explanation, else
it would have been a tad too complex.

> 
>  - Position reporting will be weird. It would run a bit in real time, then jump
> and run again a bit in real time. The alternative would be to scale the stream
> time by the rate, which would however then report the wrong position for a
> frame. Not sure what is better.

  There are two constraint that maybe weren't 100% clear with this whole
proposal, which is:
  1) Reducing as much as possible upstream bandwith/bitrate. Ideally you want
to end up pulling from upstream (over a certain window of time) at the same
bitrate as the normal playback rate. This is to avoid issues with network
connections (limited bandwidth) but also local storage (limited i/o disks).
  2) Reducing as much as possible seeking/skipping from upstream. Assume
there's a more or less big latency introduced when "skipping" upstream (such as
on HTTP, but also on slow local storage).

> 
>  - For reverse playback I think with your proposal the position would go
> forwards a bit, then jump backwards, and then go forwards a bit. Maybe instead
> the position should go backwards all the time, and the frames in each segment
> should be reordered like with how we currently implement reverse playback?
> (does this happen automatically already if you just set rate=-1.0?)

  The problem with that is the latency (and memory usage) introduced by
reversing all frames (you need to wait for the next beginning of a GOP).

> 
>  - I think the segments are wrong overall. You currently set segment.time to
> the already played duration, but for the running time this has no effect. It
> should be segment.base. segment.time is only an offset for the stream time, but
> I think the stream time would already be good if you keep
> segment.time=segment.start all the time.

  True, I wonder why I got that wrong.

> 
> 
> 
> Possible improvements:
>  - Keyframe-only and disable-audio should probably be new seek flags instead of
> magically doing that. I think the application wants control over that.

  Right, so that's a bigger issue (deciding what technique to use).

  This proposal was discussing *one* way of doing trick mode with various
constraints in mind.

  If you have very fast i/o and low latency, you could use another method.

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