[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 #3 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-09-29 08:25:00 UTC ---
(In reply to comment #2)

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

Understood, but unrelated to my comment :) What I just mean is that the stream
time is going to behave weird. Either you'll have jumps (e.g. 1s, 1.1s, 1.2s,
5s, 5.1s, ...) or you have wrong position reporting (e.g. 1s, 2s actually being
1.05s, 3s actually being 1.1s, ..., 5s being 5s, ...)

We should consciously choose which kind of behaviour we want here for the
stream time and document that so it's implemented the same in every demuxer.

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

Ack

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

Because segments are confusing for everybody :)

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

Keyframe-only or disable-audio could maybe also be controlled via QoS, but
maybe it should be an application decision in the end.

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