[Bug 663262] theoraenc: spurious encoder resets due to unstable upstream timestamps cause quality issues

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #2 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> 2011-11-03 17:40:21 UTC ---
Created an attachment (id=200620)
 View: https://bugzilla.gnome.org/attachment.cgi?id=200620
 Review: https://bugzilla.gnome.org/review?bug=663262&attachment=200620

theoraenc: emit drop frames instead of resetting decoder

When a buffer is received with a timestamp later than expected
by more than three quarters of a frame duration, theoraenc would
reset the encoder and restart encoding from the new timestamp.
This caused spurious discontinuities, a lot of keyframes, and
rate control restarting from scractch.

Instead, we now resubmit the old buffer enough times to make up
for the "lost" frames, which will allow libtheora to emit drop
frames to fill up the time between last frame and the new one.

Additionally, if caps contain a boolean strict-framerate set
to false, we just copy the incoming timestamp to the outgoing
buffer without doing any drop frames fixup. This allows any
downstream element to ignore the fixed framerate nature of
Theora and use timestamps rather than frame number.

The default is to do the fixup (ie, as if strict-framerate is
true), since this is closest to the nature of Theora (where
timing is determined by frame number and framerate).

This change will also make it easier to do fake VFR streams,
where the nominal framerate is set high (eg, 1000 fps), but
actual frames are emitted way less often, with drop frames to
fill in to 1000 fps.

Since libtheora does not offer an API to tell it that the
previous frame is to be duplicated (the dup frames ctl must
be called before encoding), this requires the previous frame
to be kept, and resubmitted at least once. This causes higher
memory consumption, but the alternative would be to only code
frames when the next one is received (and thus when we know
if a frame needs duplicates), which would introduce arbitrary
extra latency.

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