If the same instance of the plugin is asked to be initialised more that once,
instances after the first one do not register the elements properly and the
elements become not usable.
For example, if you call gst_update_registry (), is not possible to create
elements after the call since the plugin is asked to be initialised again and
does not register the elements.
Fixes#584291
The patch from Bug #580796 hacked around existing infrastructure to handle
timestamps as DTS (as in all AVI files) causing the logic to be disabled.
Properly hook the timestamp handling into the existing infrastructure to handle
these cases too, partially reverting a26b94d92c
and moving some stuff around.
Refixes #580796.
If the set of caps for either audio or video is completely empty, skip
adding that pad template to the class. Some muxers only support audio-only
or video-only and otherwise end up with EMPTY caps in the pad template.
Rewrite the audio encoders to use the right API functions of ffmpeg. Also get
rid of the handrolled cache and use adapter instead for formats that require
fixed frame_size as input.
We don't need to set a default frame_size, ffmpeg has set this value to 0 to
inform us that there is a fixed relation between the amount of input samples
and output samples. Now we only need to implement handling that fact.
ffmpeg only tells us on a per-decoded-buffer basis if the stream is
interlaced or not. When we see a change, we force negotiation.
We can't detect that in our get_buffer() (when doing downstream allocation),
because at that point the interlaced flags aren't set on the outgoing
buffer.
Add a new function new_aligned_buffer() which creates a GstBuffer of
the requested size/caps, with the memory being allocated/freed by ffmpeg's
av_malloc/av_free which guarantees properly aligned memory.
Added a can_allocate_aligned internal property which we use to figure out
whether downstream can provide us with 128bit aligned buffers.
Without a frame_size configured in the context, the ffmpeg encoders do nothing.
Since the G726 does not configure a size itself, we set ourselves a frame_size
that corresponds to 20ms of audio, which is a reasonable default.
We do this, because the demuxer is initialized in the loop function. If it's not
initialized yet, that means the loop hasn't been entered... and therefore the
PIPE GCond will never be signalled.