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>
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 f1d8763a02
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.
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 2bc0de3858.
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.
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 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>
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.
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.
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>
Add AV_NUM_DATA_POINTERS to simplify the bump transition.
This will allow for supporting more planar audio channels without having to
allocate separate pointer arrays.
A new field, AVCodecContext.internal is used to hold a new struct
AVCodecInternal, which has private fields that are not codec-specific and are
used by general libavcodec functions.
Moved internal_buffer, internal_buffer_count, and is_copy.
Replace our incomplete w32threads implementation with x264's pthreads
w32threads wrapper.
Relicensed to LGPL with kind permission by Pegasys Inc.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
The functions and tables initialised in this function rely on an
initialised DSPContext. Make sure they always have one.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Mpegvideo would free frames as soon as they're not the next or prev
picture. This is fine for a single-threading model, but fails miserably
in a system where pictures can be referenced (as e.g. last/prev pic)
in other threads. Keeping track of ownership of pictures keeps image
references (e.g. motion vectors, or the reference of a motion vector)
alive as long as the picture data itself is alive.
This also happens to fix make THREADS=[3-16] fate-vsynth[12]-error.
FF_COMMON_FRAME holds the contents of the AVFrame structure and is also copied
to struct Picture. Replace by an embedded AVFrame structure in struct Picture.
This allows the values to be used without changing C code and is closer to how
the other DEBUG flags work.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It is pretty hopeless that other considerable projects will adopt
libavutil alone in other projects. Projects that need small footprint
are better off with more specialized libraries such as gnulib or rather
just copy the necessary parts that they need. With this in mind, nobody
is helped by having libavutil and libavcore split. In order to ease
maintenance inside and around FFmpeg and to reduce confusion where to
put common code, avcore's functionality is merged (back) to avutil.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
Contrary to progressive, just being able to crop up to 14/15 pixels
is not enough to encode all supported resolutions, and the new
behaviour is also consistent with e.g. MPEG-2 etc.
Originally committed as revision 25669 to svn://svn.ffmpeg.org/ffmpeg/trunk
but it used to do it only for h264 codec.
Allow it for other codecs, as mpeg2 and mpeg4 also set this flag.
Originally committed as revision 25156 to svn://svn.ffmpeg.org/ffmpeg/trunk
The relevent extract of the iso 13818-2 about the value of the syntaxical
element top_field_first of the Picture Coding Extension is:
"top_field_first -- The meaning of this element depends upon picture_structure,
progressive_sequence and repeat_first_field.
[...]
In a field picture top_field_first shall have the value '0', and the only field
output by the decoding process is the decoded field picture."
Originally committed as revision 24853 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allocates per-thread copies of some MpegEncContext.ac_val which
is used concurrently from the encoding threads.
Originally committed as revision 23933 to svn://svn.ffmpeg.org/ffmpeg/trunk
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
It allows VLD H264 decoding using DXVA2 (GPU assisted decoding API under
VISTA and Windows 7).
It is implemented by using AVHWAccel API. It has been tested successfully
for some time in VLC using an nvidia card on Windows 7.
To compile it, you need to have the system header dxva2api.h (either from
microsoft or using http://downloads.videolan.org/pub/videolan/testing/contrib/dxva2api.h)
The generated libavcodec.dll does not depend directly on any new lib as
the necessary objects are given by the application using FFmpeg.
Originally committed as revision 21353 to svn://svn.ffmpeg.org/ffmpeg/trunk
in mpegvideo.h to avoid including mpegvideo_common.h in mpeg12.c,
because it contains motion code.
Originally committed as revision 18968 to svn://svn.ffmpeg.org/ffmpeg/trunk
This correctly fixes issue961, thanks to steven warren for spotting my mistake.
Originally committed as revision 18381 to svn://svn.ffmpeg.org/ffmpeg/trunk
pointers to array of 64 DCTELEM, similarly to other block fields.
This also get rid of some casts and fixes a warning.
Originally committed as revision 17517 to svn://svn.ffmpeg.org/ffmpeg/trunk
statements by merging the CONFIG_MPEG_XVMC_DECODER check into the if condition.
Originally committed as revision 17369 to svn://svn.ffmpeg.org/ffmpeg/trunk
libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function ‘MPV_frame_start’:
libavcodec/mpegvideo.c:944: warning: implicit declaration of function ‘ff_xvmc_field_start’
libavcodec/mpegvideo.c: In function ‘MPV_frame_end’:
libavcodec/mpegvideo.c:957: warning: implicit declaration of function ‘ff_xvmc_field_end’
Originally committed as revision 17258 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
