GTK-Doc specifies that, by default, the caller owns returned objects, so that the caller should free them when it is done. However, in the case of this function, the returned GstAudioInfo is owned by the decoder, so this default choice is incorrect. This creates double free problems when using GStreamer Rust bindings, because they are generated using the information contained in the docs.
Fix this by correctly specifying that the caller does not own the returned object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1032>
For audio we copy metas that have no tags at all, or that only have the
"audio" and/or "audio-channels" tag. Audio codecs don't change the
audio aspect of the stream and in almost all cases don't change the
number of channels. They might however change the sample rate (e.g.
Opus). Subclasses that change the number of channels will have to
override ::transform_meta() accordingly.
For video we copy metas that have no tags at all, or that only have the
"video" and/or "video-size" and/or "video-orientation" tag. Video codecs
don't change the "video" aspect of the stream and in almost all cases
don't change the resolution or orientation. Subclasses that rescale or
change the orientation will have to override ::transform_meta()
accordingly.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/576#note_610581
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/801>
Only adjusting the base_ts might lead to a negative ts and as such integer
overflow into a huge timestamp which then propagates into the granulepos
and so on. Instead, resync to incoming buffer timestamp using both base_ts
and sample count rather than only base_ts.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=785948
Refuse to answer BYTES queries ourselves. The only
time they make sense is on raw elementary streams,
in which case upstream would already have answered.
They especially don't make sense for encoders to answer
based on upstream values - although perhaps later
we could make it do TIME->BYTES conversion on the source
pad based on bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=757631
Since the allocation query caps contains memory size and the pad's caps
contains the display size, an audio encoder or decoder might need to allocate
a different buffer size than the size negotiated in the caps.
This patch splits this logic distinction for audiodecoder and audioencoder.
Thus the user, if needs a different allocation caps, should set it through
gst_audio_{encoder,decoder}_set_allocation_cap() before calling the negotiate()
vmethod. Otherwise the allocation_caps will be the same as the caps in the
src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
It's quite unexpected behaviour that various subclass settings are just
reset before set_format(). Unfortunately changing this now has the risk
of breaking existing code but we should reconsider this for 2.0.
POOL meta just means that this specific instance of the meta is related to a
pool, a copy should be made when reasonable and the flag should just not be
set in the copy.
The same was done already in the decoder, and we cleaned some state just above
manually that would also be taken care of by reset().
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.
Move the assert to the error handling block at the end of the function so the
the logging is still triggered. Reword the logging slightly and add another
comment to hint what went wrong.
Fixes#737138
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
