For all VLCs here, the number of bits of the VLC is write-only,
because it is hardcoded at the call site. Therefore one can replace
these VLC structures with the only thing that is actually used:
The pointer to the VLCElem table. And in some cases one can even
avoid this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for splitting VC-1 from msmpeg4.
(msmpeg4data.c was originally intended to be just this;
9488b966c7 changed it).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
VC1 shares some VLCs with MSMPEG-4, but vc1_block.c
simply duplicates the defines instead of including
the appropriate headers; furthermore, use a proper
prefix for these defines: DC_VLC_BITS is also used
by other codecs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This e.g. allows compilers to bake the "+ 256" offset
used to access ff_v2_dc_(lum|chroma)_table into
the general offset; for certain arches this is also necessary
in order to avoid building suboptimal code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some of these were made possible by moving several common macros to
libavutil/macros.h.
While just at it, also improve the other headers a bit.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, both the msmpeg4 decoders and encoders initialized several
RLTables common to them (the decoders also initialized the VLCs of these
RLTables). This is an obstacle to making these codecs init-threadsafe.
So move this initialization to ff_msmpeg4_common_init() that already
contains this initialization code. This allows to reuse the AVOnce used
for initializing ff_v2_dc_lum/chroma_table which automatically makes
initializing these RLTables thread-safe.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both motion vector tables have the same number of elements, hence one
can inline said number and remove the field containing the number of
elements from the structure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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
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
Consistently apply this rule: the guard name is obtained from the
filename by stripping the leading "lib", converting '/' and '.' to
'_' and uppercasing the resulting name. Guard names in the root
directory have to be prefixed by "FFMPEG_".
Originally committed as revision 15120 to svn://svn.ffmpeg.org/ffmpeg/trunk
- avctx and gb elements were removed from VC9Context, hence a larger diff
- some code was added to h263dec.c regarding CODEC_ID_WMV3 (should apply to CODEC_ID_VC9 too)
- VLC tables and other related tables were made global whenever this seemed necessary; appropriate changes were therefore made to other parts of the code using those tables
- the change for the bitplane management to a struct (some of them should eventually be mapped to MpegEncContext arrays) wasn't associated with the proper frees; should be fixed now
patch by anonymous
better names for globalized tables by me
Originally committed as revision 3905 to svn://svn.ffmpeg.org/ffmpeg/trunk
4mv+b frames encoding finally fixed
chroma ME
5 comparission functions for ME
b frame encoding speedup
wmv2 codec (unfinished)
user specified diamond size for EPZS
Originally committed as revision 1365 to svn://svn.ffmpeg.org/ffmpeg/trunk
encoding of slice_height != mb_height
1bit shorter wmv1 headers if bit_rate<50 !? ROTFL M$ is even more stupid than i thought
using dc of non intra blocks for dc prediction of wmv1 if bitrate < 129 && res < 320x240
Originally committed as revision 723 to svn://svn.ffmpeg.org/ffmpeg/trunk