This option will produce duplicate frames if we get
a frame with GAP flag. This will reduce CPU load and file size.
This option should be disabled for real time applications, because it
collects GAP frames and waits until it gets a non GAP frame to start
encoding.
v30.06.2011: make some spell changes.
v03.07.2011: add handling of EOS and discontinuous for dup-on-gap.
v19.12.2011: fix pointer dangling in theora_timefifo_free
v20.12.2010: fix timestamp bug for dup-on-gap=0
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=627459
Signed-off-by: Oleksij Rempel (Alexey Fisher) <bug-track@fisher-privat.net>
If both quality and bitrate are set, libtheora will try to meet
both constraints, causing it to prefer emitting a smaller number
of good frames, to emitting the full number of frames that would
not meet the requested quality. This causes a slideshow effect
when the bitrate is low and the quality is high. And the default
theoraenc is high (48/63).
So only set quality when it is requested, and leave it unset
otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=658443
The speed-level property, which allows callers to trade of encoding
quality for speed in the libtheora api, has a version-dependent
maximum and default values. Instead of hardcoding the acceptable
range for the theoraenc element's presentation of this setting,
we query the library directly at class initialization time and
set the maximum and default values from that. If the query fails,
we fall back to the previous default setting.
To keep the values reported by gst-inspect (which I'm told use
the spec values from the class) with those available on an\
instantiated element, we remove to setting of enc->speed_level
from the initializer and instead pass G_PARAM_CONSTRUCT to
the property spec flags, asking g_object to set this property
when theoraenc objects are constructed.
NB in theory the maximum speed-level could depend on the actual
video caps. If later versions of libtheoraenc do this, a second
call will need to be made from theora_enc_reset to update the
property, since this function is mostly useful for realtime
adjustment of performance while the pipeline is running.
libtheora has two encoding modes, CBR, where it tries to hit a target
bitrate and VBR where it tries to achieve a target quality.
Internally if the target bitrate is set to anything other then 0 the
encoding-mode is CBR.
This means that the gstreamer element can leave the video_quality
setting alone as long as the user is tweaking the bitrate. Which has the
nice side-effect that if the user explicitely sets the bitrate to 0
(which is actually the default), the quality value doesn't get reset and
one ends up encoding VBR at quality-level 0...
Remove "This property requires libtheora version >= 1.1" qualifiers
from property descriptions. They aren't needed any longer now that
we require libtheora >= 1.1.
Since this is just a debugging feature and libtheora will usually not be
compiled with that option enabled, we should maybe just hide these properties,
since they won't work anyway, and avoid confusing warnings.
Also rename properties to make them less cryptic.
https://bugzilla.gnome.org/show_bug.cgi?id=628488
