Currently said list contains only the pixel formats that are always
supported irrespective of the range and the value of
strict_std_compliance. This makes the MJPEG encoder an outlier as all
other codecs put all potentially supported pixel formats into said list
and error out if the chosen pixel format is unsupported. This commit
brings it therefore in line with the other encoders.
The behaviour of fftools/ffmpeg_filter.c has been preserved. A more
informed decision would be possible if colour range were available
at this point, but it isn't.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to make ff_init_uni_ac_vlc static;
ff_mjpeg_encode_picture_frame has also been made static, but it could
always have been made static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Since g2meet.c doesn't use it any more, only encoders use it and
the place for their common code is mjpegenc_common.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This options is only used by huffyuv, ffvhuv, jpegls, mjpeg,
mpegvideoenc, png, utvideo.
It is a very codec-specific options, so deprecate the global variant.
Set proper limits to the maximum allowed values, and update utvideoenc
tests to use the new option name.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Mostly a copy&paste from other hash functions, with changes
where required.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Where necessary use memcpy instead.
Thanks to Giorgio Vazzana [mywing81 gmail] for
spotting this loop as the cause for the bad
performance.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
They are essential to be able to use the utils without av_malloc()
That is for example use with malloc(), memalign(), some other
private allocation function, on the stack or others.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The current API where the plain size is exposed is not of much
use - in most cases it is allocated dynamically anyway.
If allocated e.g. on the stack via an uint8_t array, there's no
guarantee that the struct's members are aligned properly (unless
the array is overallocated and the opaque pointer within it
manually aligned to some unspecified alignment).
Signed-off-by: Martin Storsjö <martin@martin.st>
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
depending on CONFIG_SMALL this can either be compiled to a fully unrolled kernel / rfc reference style md5 routine
or a single loop similar to what mplayer uses
Originally committed as revision 5565 to svn://svn.ffmpeg.org/ffmpeg/trunk