[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

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at coaxion.net

--- Comment #1 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-09-27 13:27:23 UTC ---
Some random comments...

Option 0)
 - You seem to assume here that there's a different keyframe every seek (which
might not be true if you use 500ms segments, play 2x rate and there's only a
keyframe every 1+ seconds). If that is not the case you would play the same
segment multiple times, each time a bit longer. Also KEYUNIT flag says nearest
keyframe. There needs to be some logic in the application to prevent the above,
and I don't see how the application can properly prevent that

 - With every seek I think you add an error to the actual playback rate that is
the time between receiving SEGMENT_DONE and the pipeline being prerolled again
after the next seek. The pipeline will go to PAUSED after SEGMENT_DONE, and
then offset the base time by the time it stayed in PAUSED.

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



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)

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

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

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



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.

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