avvidenc: discard input frame upon encoding error
Update to libav v10
avcodecmap: Add mapping for Apple Intermediate Codec

https://bugzilla.gnome.org/show_bug.cgi?id=727673
codecmap: Add missing break

CID #1139752
avdemux: Remove unused variable

CID #1139943
avaudenc: Fix compile without gst debug

We can just re-use the encoder variable
avvidenc: Fix leak of AVBufferRef

AVPacket contains AVBufferRef which may leak unless unreffed properly.

https://bugzilla.gnome.org/show_bug.cgi?id=726814
avaudenc: Fix leak of AVBufferRef

AVPacket contains AVBufferRef which may leak unless unreffed properly.

https://bugzilla.gnome.org/show_bug.cgi?id=726814
avvidenc: guard against division by zero

and other nonsensical time base values while we're at it.

Coverity 1139699
libav: avoid dividing by zero on insane fps/par

While there, fix mixup in num/den with par (copied from fps,
apparently, and fps inverts fps to time base).

Coverity 1139696
Automatic update of common submodule

From bcb1518 to 211fa5f
Release 1.3.1
Back to development
videodec: Don't use non-growable pool

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
Update to libav 10.1
gstavviddec: Sanitize and fix qos handling.

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
avvidenc: Add thread-count parameter for libav encoders

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
Automatic update of common submodule

From 211fa5f to 1f5d3c3
Release 1.3.2
Back to development