There's no need to allocate a new packet for it.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

There's no need to allocate a new packet for it.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

There's no need to allocate a new packet for it.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

There's no need to allocate a new packet for it.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

There's no need to allocate a new packet for it.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

There's no need to allocate a new packet for it.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Fixes seek for files with empty edits and files with negative ctts
(dts_shift > 0). Added fate samples and tests.
Signed-off-by: Sasi Inguva <isasi@isasi.mtv.corp.google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Without direct support of such pix_fmt, content is padded to 16-bit
and it is not possible to know that the source file was with a smaller bit depth
so framemd5 is different
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This commit replaces the huge and impractical LUT which converted coeffs
and a quantizer to bits to encode and instead uses a standard multiplication
and a shift to replace the division and then codes the values using the
regular golomb coding functions.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Fixes: kira-poc
Found-by: Kira <kira_cxy@foxmail.com>
Change suggested by Kira
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: potential signed integer overflow
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

No testcase, this was found during code review
Found-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: shift exponent 48 is too large for 32-bit type 'int'
Fixes: Chromium bug 786793
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 3775922176 * 4278190080 cannot be represented in type 'long'
Fixes: Chromium bug 791237
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Chromium bug 795653
Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long'
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Accepting 'u' suffix for a time specification is neither intuitive nor
consistent (now that we don't accept m). Also there was a bug in the code
accepting an extra 's' even after 'ms'.
Signed-off-by: Marton Balint <cus@passwd.hu>

Some math (e.g: partition binary search) overflows if we have that many
parititions.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Consider edit rate when determining edit_units_per_packet and also make sure
that checks are done in edit rate time base and not in stream time base.

Fixes some errors reported with the sample in ticket #5863.
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

In this loop, |i| is the "index". And the memory allocated should be at
least the current "count", which is |i + 1|.

BUG=801821
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

AVHWAccel.end_frame can run on a worker thread. The assumption of the
frame threading code is that the worker thread will change the AVFrame
image data, not the AVFrame fields. So the AVFrame fields are not synced
back to the main thread. But this breaks videotoolbox due to its special
requirements (everything else is fine). It actually wants to update
AVFrame fields.

The actual videotoolbox frame is now stored in the dummy AVBufferRef, so
it mimics what happens in non-videotoolbox cases. (Changing the
AVBufferRef contents is a bit like changing the image data.) The
post_process callback copies that reference to the proper AVFrame field.

Based on a patch by wm4.
Signed-off-by: Aman Gupta <aman@tmm1.net>

Fixes fate on big-endian.

Since the config_props function now references both the input and output
links, rename the 'link' variable to 'outlink'.

Fix up some mismatching indentation.

Don't bother setting the width and height on the outlink; the filter
framework does that for us.

The old version of the filter had a problem where it would queue up
all of the duplicate frames required to fill a timestamp gap in a
single call to filter_frame. In problematic files - I've hit this in
webcam streams with large gaps due to network issues - this will queue
up a potentially huge number of frames. (I've seen it trigger the Linux
OOM-killer on particularly large pts gaps.)

This revised version of the filter using the activate callback will
generate at most 1 frame each time it is called.

Fixes #7072.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

The underlying driver need not support B frames - since they are enabled
by default for some codecs, it is better to disable them rather than
returning an error in this case.  This makes the default settings usable
for low-power encoding on Intel platforms.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>

The default behavior of the mediacodec decoder before this commit
was to delay flushes until all pending hardware frames were
returned to the decoder. This was useful for certain types of
applications, but was unexpected behavior for others.

The new default behavior with this commit is now to execute
flushes immediately to invalidate all pending frames. The old
behavior can be enabled by setting delay_flush=1.

With the new behavior, video players implementing seek can simply
call flush on the decoder without having to worry about whether
they have one or more mediacodec frames still buffered in their
rendering pipeline. Previously, all these frames had to be
explictly freed (or rendered) before the seek/flush would execute.

The new behavior matches the behavior of all other lavc decoders,
reducing the amount of special casing required when using the
mediacodec decoder.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>

This was originally based on libsbc, and was fully integrated into ffmpeg.

This was originally based on libsbc, and was fully integrated into ffmpeg.

Rough speed test:
C version:    speed= 592x
MMX version:  speed= 785x

This was originally based on libsbc, and was fully integrated into ffmpeg.