For default caps generation when handling gap events that are sent
before any buffer, try to use caps that are closer to what upstream
provided to avoid fixating rate or channels to 1 as default.
So there are the steps:
1) Try to set rate, channels and channel-mask from upstream if provided
2) Fixate the rate and channels to the default rate and channels from
audio lib
3) Fixate the caps just to be sure everything is fixed
4) If no channel-mask was provided and channels > 2, use a default
channel-mask (taken from audioconvert code)
https://bugzilla.gnome.org/show_bug.cgi?id=722144
Before trying to generate a default fixated caps when handling a gap
event, make sure that the same strategy that is used when handling
a buffer has been attempted. Otherwise audiodecoder will ignore
upstream caps settings such as rate and channels and will likely
end with a caps with channels=1 and rate=1.
https://bugzilla.gnome.org/show_bug.cgi?id=722144
If there are no caps from the audio decoder when handling a GAP
event - as when one is received right at the start on a DVD without
initial audio - then choose any default caps for downstream and
then send the GAP, so the audio sink has a configured format in
which to start the ringbuffer.
Also, make the audio sink reject a GAP without caps with a clearer
error message.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=603921
So that it avoids to send an allocation query twice.
One from an early call to gst_audio_encoder_negotiate from a
subclass, then one from gst_audio_encoder_allocate_output_buffer.
Which means that previously gst_audio_encoder_negotiate was not
clearing the GST_PAD_FLAG_NEED_RECONFIGURE even on success.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=719684
Raise an error in case no frames are decoded before EOS and we
have input, meaning that data was received but it was somehow invalid.
Based on the videodecoder change, merged here for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=711094
Allows using -1 to make audiodecoder never post an error message
after decoding errors.
Based on the videodecoder change, merged here for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=711094
This avoids triggering plenty of extra code/methods/overhead downstream when
we can just quickly check whenever we want to set caps whether they are
identical or not
https://bugzilla.gnome.org/show_bug.cgi?id=706600
We have no way of tell the caller of the exact error (e.g. if we're flushing),
so will have to wait until the caller uses API that returns a GstFlowReturn,
for example when pushing this buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=700006
Clamp timestamp interpollation to 0 to avoid going negative. This should not
happen, really, but until the interpolation is improved this seems better.
Sometimes the decoder would use the allocator for something else than just
allocating output buffers, for example, querying different parameters.
This patch expose a getter accessor for the negotiated memory allocator.
The decoder might have been de-activated in the meantime (resulting
in NULL pad caps).
If the decoder really isn't configured, then it will error out further
down when checking whether the GST_AUDIO_INFO_IS_VALID()
https://bugzilla.gnome.org/show_bug.cgi?id=667562
