In some cases, the user might want the stream outputted by encodebin to
be in the exact same format during all the stream. We should let the
user specify when this is the case. This commit add some API in the
GstEncodingProfile to determine whether the format can be renegotiated
after the encoding started or not.
API:
gst_encoding_profile_set_allow_dynamic_output
gst_encoding_profile_get_allow_dynamic_output
https://bugzilla.gnome.org/show_bug.cgi?id=740214
It will cause the frame to be initialized with inconsistent values that then
later can cause crashes or any other kind of interesting and hard to debug
bugs.
In cases where we just call orc directly this is somewhat
superfluous, but let's do it anyway for consistency. In
other cases the compiler can hopefully use this to optimise
memory access a little.
Before we were setting them to PAUSED and (much) later connecting to
their source pad caps notify signal.
There was a race where that demuxer was pushing a caps and later a buffer
on its source pad when we were not even connected to its source pad caps notify
signal leading to decodebin missing the information and not keeping on
building the pipeline on CAPS event thus the demuxer was posting an ERROR
(not linked) message on the bus. This need to be done for 'simple
demuxers' because those have one ALWAYS source pad, not like usual demuxers
that have several dynamic source pads.
A "simple demuxer" is a demuxer that has one and only one ALWAYS source
pad.
https://bugzilla.gnome.org/show_bug.cgi?id=740693
There was a race where:
1) we would put the element to PAUSED
2) It would get data sent to it from upstream
3) It would thus send caps
3) caps_notify_cb would continue autoplugging
4) caps would flow downstream, the last pad would get exposed
5) we were still not done sending the sticky events
Taking the stream lock on the new element's sinkpad and only
releasing it when sticky events have all been sent prevents
the caps from reaching the source pad of the element before
we're all set.
https://bugzilla.gnome.org/show_bug.cgi?id=740694
when using variable taps and when we are limiting the number of taps,
recalculate the lanczos parameters to match the clamped value.
Set the max number of taps to 128
Otherwise the following can happen:
1. set mute=true
2. play media1 (Ok)
3. play media without audio (audiochain removed)
4. play media2 (audiochain created, mute=*false*)
https://bugzilla.gnome.org/show_bug.cgi?id=740675
Make a small object to hold a pool of allocated temp lines.
Keep track of how many temp lines each conversion stage needs and use
this to allocate just enough temp lines from the temp lines object. from
the temp lines object.
When dealing with mixed interlaced, setup a scaler and chroma-resampler
for both interlaced and progressive frames and switch between them
depending on the interlace mode of the input frame.
Add an option to limit the number of taps to use in automatic mode. The
problem is that for lanczos, we might use more taps than what we can
handle with the current precision.
Rework the other options a little to make it nicer to set defaults.
There's no reason why we would have to wait for the next buffer to decide
whether to output the current one or not. We just have to check if the
current one is earlier than our expected next time, which is the previous
frame timestamp plus the expected frame duration.
https://bugzilla.gnome.org/show_bug.cgi?id=740018
