Age | Commit message (Collapse) | Author |
|
|
|
Always evaluate to NULL when the source Picture is not located in the
MpegEncContext.picture array. That will only happen for
next/last_picture_ptr when updating the thread context during h264 frame
threaded decoding, where they will point to elements of ref_list. Since
ref_list is not copied during updating the context and is invalid until
it is constructed for the current slice, there is no point in doing
anything complicated with next/last_picture_ptr, as they will get
updated when the ref_list is filled.
|
|
REBASE_PICTURE (more specifically, this half of it) takes a Picture
pointer that points into one larger struct, finds the offset of
that Picture within the struct and finds the corresponding field
within another instance of a similar struct.
The pointer difference "pic - (Picture*)old_ctx" is a value given
in sizeof(Picture) units, and when applied back on
(Picture*)new_ctx gets multiplied back with sizeof(Picture). Many
compilers seem to optimize out this division/multiplication, but
not all do.
GCC 4.2 on OS X doesn't seem to remove the division/multiplication,
therefore the new pointer didn't turn out to point to exactly
the right place in the new struct since it only had sizeof(Picture)
granularity (and the Picture is not aligned on a sizeof(Picture)
boundary within the encompassing struct). This bug has been present
before 47318953d as well - with H264, pointers to h->ref_list[0][0]
pointed to 88 bytes before h->ref_list[0][0] after the rebase. After
shrinking Picture, the difference ended up even larger, making
writes via such a Picture pointer overwrite other fields at random
in H264Context, ending up in crashes later.
This fixes H264 multithreaded decoding on OS X with GCC 4.2.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
It does not help as an abstraction and adds dsputil dependencies.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
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>
|
|
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.
|
|
|
|
The code fails to compile and is broken beyond repair.
|
|
|
|
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.
|
|
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.
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
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: 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>
|
|
Interlaced images can have 32 references (16 per field), so limiting the
array size to 16 leads to invalid writes.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
Deprecate corresponding AVCodecContext field.
|
|
Deprecate corresponding AVCodecContext fields.
|
|
Deprecate CODEC_FLAG_CBP_RD.
|
|
Deprecate CODEC_FLAG_QP_RD.
|
|
Deprecate CODEC_FLAG2_STRICT_GOP.
|
|
Deprecate CODEC_FLAG2_SKIP_RD in favor of the corresponding mpv_flags
flag.
|
|
|
|
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
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.
|
|
Adds a new member to MpegEncContext to hold the number of used slice
contexts. Fixes segfaults with '-threads 17 -thread_type slice' and
fate-vsynth{1,2}-mpeg{2,4}thread{,_ilace} with --disable-pthreads.
|
|
This was intended as an optimisation for skipped blocks in MPEG2
P-frames and never used elsewhere. Removing this "optimisation"
speeds up MPEG2 decoding by 1-2% (ARM Cortex-A9).
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
Simplify a little error resilience calls
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
Add the namespace to {AC_,DC_,MV_}{END,ERROR} macros
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
This reverts commit da22ba7df461c13bf0b0eabc953303803a285d91 since it
broke slice threading. Slice threading just duplicates MpegEncContext
so every value used during mpeg_decode_slice has to be in it.
A second patch will fix the illusion that Mpeg1Context is available
in mpeg_decode_slice.
|
|
It's MPEG-1/2 specific.
|
|
It's MPEG-1 specific.
|
|
|
|
It's used in lavf.
|
|
The way this value is used, it should be an unsigned type.
While the numerical value has no meaning, unsigned wraparound
is relied upon.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
Using the old code, half of it was unused and the other half was too
small for e.g. >8bpp interlaced data, causing random buffer overruns.
|