This is mostly straightforward. The major complication is that, as a
result of the 16-bit chunk size limitation, ICC profiles may need to be
split up into multiple chunks.
We also need to make sure to allocate enough extra space in the packet
to fit the ICC profile, so modify both mpegvideo_enc.c and ljpegenc.c to
take into account this extra overhead, failing cleanly if necessary.
Also add a FATE transcode test to ensure that the ICC profile gets
written (and read) correctly. Note that this ICC profile is smaller than
64 kB, so this doesn't test the APP2 chunk re-arranging code at all.
Signed-off-by: Niklas Haas <git@haasn.dev>
In the aforementioned case mpegvideo_enc.c calls
ff_mjpeg_encode_stuffing() at the end of every line which
pads the output to byte-alignment and escapes it;
yet it does not write the restart-markers (and also not
the DRI marker when writing the header) and so the output files
are broken.
Fix this by writing these markers depending upon the number of
slices and not the number of threads in use; this also makes
the output of the encoder reproducible given a slice count
and is therefore important if encoder tests that actually use
-threads auto are added in the future.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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