(There is a small issue that is now being treated differently:
The earlier code would record a position in a buffer that
is being written to via put_bits(), then write data,
then overwrite the byte at the position recorded earlier
and only then flush the PutBitContext. In case there was
no writeout in the meantime, said flush would overwrite
what one has just written. This never happened in my tests,
but maybe it can happen. In this case this commit fixes
this issue by flushing before overwriting the old data.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_square_tab is always used with an offset; if this table
is marked as hidden, the compiler can infer that it and
therefore also ff_square_tab + 256 have a fixed offset
from the code. This allows to avoid performing "+ 256"
at runtime by baking it into the offset from the code to
the table.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This codec uses BswapDSP, BlockDSP and IDCTDSP.
The former never used MMX, the latter does not use it
for idct_put since bfb28b5ce8
and BlockDSP does not use it since commit
ee551a21dd.
Therefore this emms_c() is can be removed.
(It was actually always redundant, because its caller
(decode_simple_internal()) calls emms_c() itself afterwards.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These matrices are only used for MJPEG, not for LJPEG.
So only check them for the former. This is in preparation
for removing said matrices from LJPEG altogether
(i.e. sending NULL matrices).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The codes here have the property that the long codes
are to the left of the tree (each zero bit child node
is by definition to the left of its one bit sibling);
they also have the property that among codes of the same length,
the symbol is ascending from left to right.
These properties can be used to create the codes from
the lengths in only two passes over the array of lengths
(the current code uses one pass for each length, i.e. 32):
First one counts how many nodes of each length there are.
Then one calculates the range of codes of each length
(possible because the codes are ordered by length in the tree).
This enables one to calculate the actual codes with only
one further traversal of the length array.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While the share of elements used by both is quite big, the amount
of code shared between the decoders and encoders is negligible.
Therefore one can easily split the context if one wants to.
The reasons for doing so are that the non-shared elements
are non-negligible: The stats array which is only used by
the encoder takes 524288B of 868904B (on x64); similarly,
pix_bgr_map which is only used by the decoder takes 16KiB.
Furthermore, using a shared context also entails inclusions
of unneeded headers like put_bits.h for the decoder and get_bits.h
for the encoder (and all of these and much more for huffyuv.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These parameters are easily accessible whereever they
are accessed, so using copies from HYuvContext is
unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_pix_fmt_get_chroma_sub_sample() is superfluous if one
already has an AVPixFmtDescriptor.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is nearly unused anyway, so stop use the field altogether.
This is in preparation for splitting HYuvContext into
decoder and encoder contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All codecs here have the FF_CODEC_CAP_INIT_CLEANUP set,
so ff_huffyuv_common_end() will be called automatically
in encode_end() on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The ffvhuff encoder has AVCodec.pix_fmts set and therefore
encode_preinit_video() checks that the used pixel format
is permissible.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avio_seek() is called inside check(). Seeking to 'off' then seeking
to 'off + i' is unefficient, and it can loop 64 * 1024 times in the
worst case. When probe a malformed file over HTTP, it looks like
stucked forvever. ffio_ensure_seekback() doesn't solve the issue
when the stream is seekable but slow.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Add PCR at keyframe can be undesirable when -pcr_period is
specified. Add an flag to disable this behavior.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
There is no MMX code for loop filters since commit
6a551f1405, so use declare_func
instead of declare_func_emms() to also test that we are not
in MMX mode after return.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
PixblockDSP does not use MMX functions any more since
92b5800277 and FDCTDSP
since d402ec6be9.
BswapDSP never used MMX, so that the emms_c() here
is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This also enables the compiler to optimize the implicit
checks performed by the PutBit-API away (Clang does so).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current pbc might be small for an obu frame, so a new pbc is
required then parse this obu frame again. Because
CodedBitstreamAV1Context has already been updated for this obu frame, we
need to restore CodedBitstreamAV1Context, otherwise
CodedBitstreamAV1Context doesn't match this obu frame when parsing obu
frame again, e.g. CodedBitstreamAV1Context.order_hint.
$ ffmpeg -i input.ivf -c:v copy -f null -
[...]
[av1_frame_merge @ 0x558bc3d6f880] ref_order_hint[i] does not match
inferred value: 20, but should be 22.
[av1_frame_merge @ 0x558bc3d6f880] Failed to write unit 1 (type 6).
[av1_frame_merge @ 0x558bc3d6f880] Failed to write packet.
[obu @ 0x558bc3d6e040] av1_frame_merge filter failed to send output
packet
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
It does not require anything that is being set between
the new position where it is called and the old position
where it used to be called; and nothing that it sets
gets overwritten between these two positions.
Doing so allows to remove a check lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not require anything that is being set between
the new position where it is called and the old position
where it used to be called; and nothing that it sets
gets overwritten between these two positions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Thanks, Pierre-Anthony. I've updated the patch to remove the unnecessary UL and it's now using mxf_match_uid() to detect the EKLV packet.
Signed-off-by: Richard Ayres <richard.ayres@bydeluxe.com>
Using unsigned and negative linesizes doesn't really work.
Use ptrdiff_t instead. This fixes the fraps-v0 and fraps-v1
FATE tests with negative linesizes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use ptrdiff_t instead of unsigned for linesizes.
Fixes the armovie-escape124 FATE test with negative linesizes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
c93.c used an int for the stride and an unsigned for the current
linenumber. This does not work when using negative linesizes.
So use ptrdiff_t for stride and int for linenumber.
This fixes the cyberia-c93 FATE test when using negative linesizes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The data in SGI images is stored planar, so exporting
it via planar pixel formats is natural.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SGI is intra-frame only; the decoder therefore does not
maintain any state between frames, so remove
the private context.
Also rename depth to nb_components.
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier code used "p->data[0] + p->linesize[0] * s->height" with
the latter being unsigned, which gives the wrong value for negative
linesizes. There is also a not so obvious problem with this:
In case of negative linesizes, the last line is the start of
the allocated buffer, so using the line after the last line
would involve undefined pointer arithmetic. So don't do it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
