| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Do not rely on get_buffer initializing them.
Changes yadif tests (off by one in one border pixel), because yadif
reads from those uninitialized lines.
|
|
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
It does not help as an abstraction and adds dsputil dependencies.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
The loop condition `x = ex' is incorrect. It should be `x <= ex'.
This bug was introduced in commit c65dfac4 "mpegvideo.c: K&R formatting
and cosmetics."
CC:libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
Fixes decoding of 9/10 bit per pixel h264 videos as reported in
https://bugzilla.libav.org/show_bug.cgi?id=404 .
|
|
Move some functions from dsputil. The idea is that videodsp contains
functions that are useful for a large and varied set of video decoders.
Currently, it contains emulated_edge_mc() and prefetch().
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
The VC1 decoder uses edge_emu_buffer simultaneously for luma and chroma
and needs more space. That was not a problem before f1d8763a02b5fce
since the size for edge_emu_buffer was always calculated with 2 byte per
pixel since the linesize was not known.
Fixes occasionally fate errors in vc1_sa10143.
|
|
Since we can't know which stride a custom get_buffer() implementation is
going to use we have to allocate this scratch buffers after the linesize
is known. It was pretty safe for 8 bit per pixel pixel formats since we
always allocated memory for up to 16 bits per pixel. It broke hoever
with cmdutis.c's alloc_buffer() and high pixel bit depth since it
allocated larger edges than mpegvideo expected.
Fixes fuzzed sample nasa-8s2.ts_s244342.
|
|
This requires to move the avcodec_default_free_buffers() call to
ff_MPV_common_end() since otherwise delayed pictures would get freed
during a size change.
|
|
|
|
This does not seem to have an effect currently. Fate-h264 passes with
THREADS=1..16 and both threading types as before. It fixes however a
segfault during error resilience with my adaptive-frame-mt patchset.
A picture in use during error resilience gets realloced in another
thread in the fuzzed sample sample_varPAR.avi_s226019.
|
|
Deprecate avcodec_get_chroma_sub_sample.
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
The code fails to compile and is broken beyond repair.
|
|
|
|
|
|
|
|
|
|
AVFrame.extended_data has to reset to the AVFrame.data of the current
thread context after copying the frame contents.
Fixes crashes with frame-threading after 2bc0de38584.
|
|
|
|
|
|
Adds a flag context_reinit to MpegEncContext to relieable keep track
of frame parameter changes which require a context reinitialization.
This is required for broken inputs which change the frame size but
error out before the context can be reinitialized.
|
|
|
|
Fixes triggering an assert in avcodec_default_release_buffer()
introduced in 1b3439b30.
|
|
This is mainly required for frame parameter changes during frame based
multithreading but single threaded usage profits too from avoiding
ff_MPV_common_end()/ff_MPV_common_init() cycles.
|
|
This is a preparation for supporting frame size changes during
frame-based multithreading.
|
|
Prevents dangling pointers and makes access after free more obvious.
Setting AVFrame.qscale_table to NULL is required for successfully
allocating a previously freed Picture with ff_alloc_picture().
|
|
This assert is no longer true since h264 error concealment needs
last_picture_ptr to be set.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>
|
|
|
|
This file defines a single, huge function, MPV_motion(), which
although being declared inline is not actually inlined by the
compiler (for good reason). There is thus no sense in defining
this function in a header file, resulting in multiple copies of
it in the final library.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
This feature is complex, of questionable utility, and slows down
normal decoding.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
fails
|
|
If the dummy frame are not created from a reference frame they could
be deleted untimely resulting in multithreaded decoder waiting on
the current frame to finish.
Noticed by Ronald S. Bultje in the RV34 decoder with a broken file.
|
|
Prevents hangs on corrupt input.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
|
|
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
It is obscure, most likely unused and not bit-exact compared to
libavcodec due to a different IDCT transform algorithm.
|
|
When either video dimension is only one macroblock, subtractions
based on v_edge_pos and the macroblock size may be negative. In
that situation, an unsigned comparison isn't sufficent to test for
MV overruns, because a limit of (unsigned)-1 will let any other
value pass.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
Under certain conditions pictures could be released before they were
returned with frame-threading. Broken mv computation in the upcoming
rv34 frame-threading patch was caused by this.
To prevent contexts from running out of available pictures the loop
releasing "unused" pictures has to be run for B frames too.
|
|
|
