This lock is taken when activating a group, which could result in
calling the autoplug-continue callback, which also needs this lock
to access the sinks.
See bug #642174.
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.
Don't build merge the caps of all sinks but check them one-by-one
until one supports the caps. Also get reffed caps from the sinkpads
instead of a writable copy and add debug output if a sink claims to
support ANY caps.
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...
Otherwise, having 2 tagdemux in a row followed by an element operating in
pull mode will make the second tagdemux implictly eat the first tagdemux'
tag event(s).
Fixes (part of) #641047.
In case the ogg mapper doesn't handle all the accepted input formats
(although it really should). Saves us error handling for that case
though. Also log caps properly.
https://bugzilla.gnome.org/show_bug.cgi?id=629196
Using the IN_CAPS flag for this is brittle, and will fail if either
vorbisparse or vorbistag (which is itself based on vorbisparse) is
inserted between oggdemux and oggmux. Possibly other elements too
(eg, theoraparse, etc).
Using oggstream ensures we Get It Right More Often Than Not.
https://bugzilla.gnome.org/show_bug.cgi?id=629196
Discontinuities are automatically signalled by oggdemux at the start
of a new stream. When oggmux is yet to output actual data pages,
do not signal these discontinuities in the ogg stream.
This patch may miss some actual discontinuities at the very start of
a stream, but avoids the spurious missing pages when encoding happens
normally.
A better fix might involve finding a way to distinguish between actual
data discontinuities and discontinuities merely marking the start of
a new stream.
Fixes an issue with ogg page numbering (would skip a number for no
reason, which then looks like a packet was lost somewhere) when
re-muxing an ogg stream, e.g. when re-tagging in rhythmbox.
https://bugzilla.gnome.org/show_bug.cgi?id=629196
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.
... as that is the specification and fixes compilation on Cygwin:
gstxmptaag.c: In function 'read_one_tag':
gstxmptag.c:1015: error: array subscript has type 'char'
Variable was being written to and could cause crashes
if multiple elements were parsing xmp at the same time.
Moving it to local scope solves the problem.
