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
