When switching playback modes, like from TRICKMODE or TRICKMODE_KEY_UNITS
back to regular playback, we need to make sure we set the skip mode
back to the default setting.
While this field would be properly reset when we *have* feedback from
downstream (i.e. diff != G_MAXINT64), it would not be reset during
the initial phase (i.e. when the decoder hasn't pushed a buffer yet,
and therefore the sink hasn't sent back QoS information).
This avoids dropping plenty of frames when going back to regular playback
Several decoders will only be able to report a real latency (has_b_frames)
once they're actually initialized (i.e. when they return their first frame).
Doing it earlier (in set_format) doesn't guarantee that the AVCodecContext
has_b_frames has been properly initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=766362
Otherwise we will consider them as one frame of raw audio that is still
pending, and shift all timestamps by the amount of time spent with header
buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=765797
Various functions in libavcodec need them, like the format, sample rate, etc.
and just having them in the context is not enough.
This fixes draining for codecs like MP2 that require a fixed frame size and
require libav to pad the last frame if required.
The GObject macros either for GstFFMpegVidDec and GstFFMpegVidEnc can
break the compilation because they are not GTypes, since each av video
elements are registered in runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=764162
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
It has its own allocator that is not necessarily doing the same as malloc and
will then usually crash. E.g. on Windows or when memalign() is available.
In ffmpeg this is the same as FRONT_CENTER, but we distinguish between
FRONT_CENTER and MONO in GStreamer. Add an explicit mapping for this special
case in the translations functions.
https://bugzilla.gnome.org/show_bug.cgi?id=759846
Handling slice_offset in avviddec is resulting in invalid memory read.
Since rv decoders anyways handle slice_offset, removing the same to fix
memory mishandlings
https://bugzilla.gnome.org/show_bug.cgi?id=758726
Error out if system's libav* libraries are not
provided by FFmpeg. Libav-incompatible changes
were introduced to support the latter so we
can no longer support both.
https://bugzilla.gnome.org/show_bug.cgi?id=758183
If downstream does not provide a (usable) pool, we would use our internal
pool. But the internal pool might be configured with a different width/height
because of padding, which then will cause problems if we push buffers from it
directly downstream.
Instead create a new pool if the width/height is different.
This prevents crashes with vaapisink and d3dvideosink for example.
Based on the debugging results and discussions with
Nicolas Dufresne <nicolas.dufresne@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758344
... since they handle separate cases in video decoder with different requirements.
Consider e.g. x264enc ! rtph264pay ! identity drop-probability=0.1 ! rtph264depay
to illustrate a need for such separation.
Multithreaded encoders are going to free this dummy codec data twice, e.g.
with this pipeline
gst-launch-1.0 videotestsrc num-buffers=40 ! \
videoconvert ! avenc_mjpeg ! fakesink
Since gst_buffer_pool_set_config() takes ownership of the config structure,
it is only necessary to free the structure before using it when the true
branch of if (gst_buffer_pool_config_validate_params) hasn't run.
gst_buffer_pool_set_config() always takes ownership of the structure
regardless of success or failure. Which means the return, checked with
if (!working_pool), has no relation to the state of the structure.
Change default alignment from 16 to 32 bytes, which fixes crashes
when decoding H.265 using AVX2-based decoder code paths and when
using ximagesink/glimagesink.
https://bugzilla.gnome.org/show_bug.cgi?id=754120
Make sure the alignment requirement in GstAllocationParams
matches the GstVideoAlignment requirements. This fixes
issues with avdec_h265 crashing in the avx2 code path when
used with playbin and ximagesink/glimagesink as videosink.
The internal video pool would allocate buffers with an
alignment of 15 even though GstVideoAlignment specified
a stride_align requirement of 31 (which comes from ffmpeg).
https://bugzilla.gnome.org/show_bug.cgi?id=754120
Add the codec name and bitrate into the output for informational
purposes. Bitrate in particular is now used by flvmux to set
videodatarate and audiodatarate in the resulting stream
Some check where incorect and also unsafe. The only reliable information
in get_buffer2 is the picture width/height really. The side effect is
that the width/height of the internal pool endup padded, so when we
switch we also need to switch to the a new width/height, hence we save
the pool info.
https://bugzilla.gnome.org/show_bug.cgi?id=753869
The size in the AVFrame in get_buffer2 don't match the output size,
instead they match ffmpeg's memory requirements, so we can't compare
them from the values of the output AVFrame. Those are comparable to
the values in the passed AVCodecContext.
ffmpeg doesn't provide the final's image width & height in the get_buffer2()
callback, so it's not possible to create an output state for GstVideoDecoder
at this stage. So only try to do direct rendering if the buffer pool has already
been negotiated based on the final decoded size.
This partially reverts the effects of 2e621f8dbhttps://bugzilla.gnome.org/show_bug.cgi?id=752802
If it is created earlier and the stride is invalid, then the frame
will be freed and it won't be possible to use it in the fallback path.
Not doing this causes a segfault because it will try to use
already freed memory.
ffmpeg seems to be the one of the two forks, which is most widely used by
Linux distributions and in general. Also Google is using it for e.g. Chrome
and has engineers working on finding and fixing security issues in it.
https://bugzilla.gnome.org/show_bug.cgi?id=751607
gstavvidenc.c: In function 'gst_ffmpegvidenc_flush_buffers':
gstavvidenc.c:733:7: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
GstFFMpegVidEncClass *oclass =
^
cc1: all warnings being treated as errors
libav always uses planar audio formats nowadays, not much use in
us trying to allocate anything here until we add support for planar
aka non-interleaved audio formats at least in audioconvert.
The context contains the information from the latest input frame, we're
however interested in the information from the latest output frame. As we have
to negotiate for the buffer that is about to come next.
This should fix some crashes that happened when both information got out of
sync. If that happens now, we will do fallback allocation until the output
is renegotiated too.
https://bugzilla.gnome.org/show_bug.cgi?id=750865
There exist few formats (deprecated though) used by mjpeg decoder
and encoder that maps to the same GStreamer format. To properly
pick the right format, also lookup each Codec list before accepting
the format. This fixes error when trying to use mjpeg encoder.
Note that this may results in faded colors. In fact, these special
format are meant to specify that this is full range YUV. Colorimetry
in gst-libav is not yet implemented, hence is ignored in general. So
I think it's fine to first fix the issue before addressing the missing
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=750398
finish() is called at EOS, drain() is called at all other times
when the decoder should be drained out. gst-libav decoder behaviour
is the same in both cases, so use the same implementation
See https://bugzilla.gnome.org/show_bug.cgi?id=734617
We use have_data (that comes from libav), instead of only trying 10
times, to know if there are more samples available. The old code was
machine dependent as different amount of samples could be decoded by
different type of (more powerful) machines, and 10 times was not always
sufficient.
https://bugzilla.gnome.org/show_bug.cgi?id=737144
We use have_data (that comes from libav), instead of only trying 10 times,
to know if there are more frames available. The old code was machine
dependant as different amount of frames could be decoded by different
type of (more powerful) machines, and 10 times was not always sufficient.
https://bugzilla.gnome.org/show_bug.cgi?id=736515
have_data is not propagated from gst_ffmpegviddec_video_frame to
gst_ffmpegviddec_frame. have_data is only set to 1 in
gst_ffmpegviddec_frame if a frame pointer is passed. However, this is
not true while draining, which means that have_data from libav will be
ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=734608
After the recent addition of negotiation support for MPEG4 part 2
profiles via caps it can happen that the generated caps at this
point still contain multiple profiles. For example if downstream
does not care. Just fixate anything here and use those caps.
Remove x-xvid and x-3ivx. The last place where they were used are
in the srcpad caps of the decoder but since the decoder will never
actually output those caps we can safely remove them.
If audio_in is NULL, we'll send a NULL frame to libav, to flush
the codec. In that case, we won't know how many samples the codec
will have used, so we use -1 (for don't know) when letting the
base class know about the buffer.
Coverity 1195177
Always enable 4MV flag for MPEG4
Pare the profile property and enable more features for advanced-simple
profile.
video/x-xvid is advanced-simple profile so enable more features.
We now also support encoding of video/x-xvid so add this to the caps.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=651320
We first want to complete negotiation before opening the encoder.
Negotiation might configure flags and other things that might be needed
when opening the encoder.
The 'no_buffer' error case is from the 0.10 era when a pad_alloc was
made before decoding the data and avdemuxer could check again the
flow returns for a not-linked. This isn't a valid use case anymore in
1.0
As some libav encoders (such as MPEG2) use a thread_count parameter to control
how many threads to use, and since it was always being set to 0 (which uses
the default), suboptimal threading can sometimes be chosen. This extends the
libav encoders to allow for a max-threads parameter which is passed into
the internal structure to control this knob if applicable to the encoder.
https://bugzilla.gnome.org/show_bug.cgi?id=726612
gst_video_decoder_get_max_decding_time doesn't return a GstClockTime
but a GstClockTimeDiff, and thus one needs to compare it against
G_MAXINT_64.
The returning of a boolean and the extra subsequent code in _video_frame
was uselessly complicated.
The previous behaviour led to artefacts when the decoder tried to
hurry up.
https://bugzilla.gnome.org/show_bug.cgi?id=730075
As we don't know how many output buffers we need to operate, we need to
avoid pool that can't grow. Otherwise the pipeline may stall, waiting
for buffers. For now, we require it to be able to grow to at least
32 buffers, which I think is a fair amount of buffers for decoders.
https://bugzilla.gnome.org/show_bug.cgi?id=726299
Fixes crash on EOS when no buffers have been received for some
reason, e.g. because the parser didn't output any.
fakesrc num-buffers=0 format=time ! avdec_h264 ! fakesink
* @param[in] frame AVFrame containing the raw audio data to be encoded.
* May be NULL when flushing an encoder that has the
* CODEC_CAP_DELAY capability set.
The AVFrame itself should be null, not the frame.data pointer
https://bugzilla.gnome.org/show_bug.cgi?id=724536
The output-corrupt property will set the CODEC_FLAG_OUTPUT_CORRUPT flag
in the codec context. The user can now decide whether libav outputs
corrupt frames or not.
Previous libav versions had this flag always set.
https://bugzilla.gnome.org/show_bug.cgi?id=722453
A AVCodecContext needs cleaning up before being freed.
Go through all of the allocations/setups to ensure none of them
can leak a context or its contents.
New libav will not call the release_buffer callback anymore when
avcodec_default_get_buffer() is called from get_buffer. Releasing of the
memory in a picture should now be done by registering a callback to the
avbuffer objects in the picture. There is some compatibility code to
wrap the memory we provide in get_buffer in avbuffer with a callback to
release_buffer but that is not done when avcodec_default_get_buffer()
is called.
Work around this by adding a dummy avbuffer object to the picture that
will release the frame.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721077
The VC-1 decoder should handle that. Before avdec_wmv3 handled
it, but then we added format=WMV3 to its sink pad template
caps, at which point nothing handled WMVA any longer.
https://bugzilla.gnome.org/show_bug.cgi?id=697665
... so as to focus on providing *a* buffer rather than one (too) tied
to a frame, in particular allowing multiple allocations related to a frame.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=697806
... by also removing it from the pending list of frames,
where it may still be in if it has never been submitted to _finish.
This could happen if is a decode-only frame, or in skipped decoding
situation, ...
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=693772
Actually avdec_mjpeg does not deal well with incomplete buffers and try
to decode incomplete frames. A parser which will also acts as
an accumulator needs to be inserted before it.
https://bugzilla.gnome.org/show_bug.cgi?id=709352
It can happen that negotiation fails during get_buffer(), but then
we don't retry later and never return NOT_NEGOTIATED upstream...
and instead run into assertions.
It can happen that negotiation fails during get_buffer(), but then
we don't retry later and never return NOT_NEGOTIATED upstream...
and instead run into assertions.
https://bugzilla.gnome.org/show_bug.cgi?id=708769
As part of the changes to support the "avc3" variant of the ISO-BMFF
(see bug #702004) a new stream-format has been created
(video/x-h264, stream-format="avc3", alignment="au") that requires
changes to gstavcodecmap to exclude this format because avdec_h264
expects the SPS and PPS to be in the codec_data.
Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation data
(e.g. SPS, PPS). In AVC1 this data is placed in the initial MOOV box
(moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data goes in the
first sample of every fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=702004
