Age | Commit message (Collapse) | Author |
|
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>
|
|
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.
|
|
It was wrong in colorspaces where horizontal and vertical chroma
subsampling are not the same, e.g. 422.
|
|
|
|
This fixes build failures with -DDEBUG in CPPFLAGS.
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.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.
|
|
Instead, just decrease it to a valid value and use that.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
filter_mb_fast assumed that qscale_table was padded like many of the other tables.
|
|
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
Needs some ARM/PPC asm modifications.
|
|
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
The MPEG encoding code assumes that n_threads == n_slices, and thus it
should use n_slices even if threading itself is disabled.
|
|
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
It was long ago superseded by msmpeg4_version.
|
|
just via AVFrame.
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>
|
|
Problem description, preliminary review discussion at
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/127731
|
|
|
|
|
|
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
It has been deprecated for about five years, skip_idct/skip_frame should
be used instead.
|
|
|
|
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
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>
|
|
|
|
Originally committed as revision 26090 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
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
|
|
Originally committed as revision 25058 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
|
|
av_check_image_size() instead.
Originally committed as revision 24711 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 23998 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This fixes one Doxygen warning each.
Originally committed as revision 23970 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
|
|
Originally committed as revision 23904 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Patch by Francesco Lavra, francescolavra interfree it
Originally committed as revision 23158 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
|
|
Also revert the related error concealment hotfix.
Originally committed as revision 22640 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22556 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22554 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 22345 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
ones based on mb_stride in h264.
about 20 cpu cycles faster overall per MB
Originally committed as revision 22065 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
|
|
Patch by Anatoliy Nenashev, nenashev_as mail ru
Originally committed as revision 21239 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
Originally committed as revision 20971 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This fixes a infinite loop on a b frame.
Originally committed as revision 20672 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
This fixes -vismv & -debug 16384 with field pictures.
Originally committed as revision 20670 to svn://svn.ffmpeg.org/ffmpeg/trunk
|