It is only used for error resilience. This allows building the
h264 decoder without dsputil, if error resilience is disabled.
Signed-off-by: Martin Storsjö <martin@martin.st>
The non-intra-pcm branch in hl_decode_mb (simple, 8bpp) goes from 700
to 672 cycles, and the complete loop of decode_mb_cabac and hl_decode_mb
(in the decode_slice loop) goes from 1759 to 1733 cycles on the clip
tested (cathedral), i.e. almost 30 cycles per mb faster.
Signed-off-by: Martin Storsjö <martin@martin.st>
Put a copy of the 8bit functions only in dsputil, where they are
used for some other things (e.g. mpeg4qpel, mspel, cavsqpel).
Signed-off-by: Martin Storsjö <martin@martin.st>
The EC code does not support fields currently thus it makes no
sense to wait for these cases (which also the check doesnt handle
correctly)
Fixes Ticket 2454
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The pointers that get assigned ff_cropTbl were made const in
9e0f14f1, but other variables that transitively are assigned
based on these variables were missed.
Signed-off-by: Martin Storsjö <martin@martin.st>
These are widely used throughout libavcodec, nothing dsputil-specific.
Change ff_cropTbl to a statically initialized table, to avoid
initializing it with a function call.
Signed-off-by: Martin Storsjö <martin@martin.st>
This way, they can be shared between mpeg4qpel and h264qpel without
requiring either one to be compiled unconditionally.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes the vp3 decoder less dependent on dsputil, and will aid
in making it (eventually) dsputil-independent.
Signed-off-by: Martin Storsjö <martin@martin.st>
In the non-bitexact mode, vp3 currently decodes to the same
frame crcs as before 28f9ab702 (and the output visually looks
correct).
Signed-off-by: Martin Storsjö <martin@martin.st>
From 312 to 89/68 (sse/sse2) cycles on Arrandale and Win64.
Sandybridge: 68/47 cycles.
Having a loop counter is a 7 cycle gain.
Unrolling is another 7 cycle gain.
Working in reverse scan is another 6 cycles.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Text subtitles packets are not 0-terminated (and if they are,
it is handled by the recoding process since 0 is a valid
Unicode code point). The terminating 0 would overwrite the
last payload octet.
OTOH, packets must be 0-padded.
Fix a problem reported in trac ticket #2431.
This patch can be controversial, by assuming floats are IEEE-754 and
particular behaviour of the FPU will get in the way.
Timing on Arrandale and Win32 (thus, x87 FPU is used in the reference).
sbr_qmf_pre_shuffle_c: 115 to 76
sbr_neg_odd_64_c: 84 to 55
sbr_qmf_post_shuffle_c: 112 to 83
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Timing on Arrandale:
C SSE
Win32: 57 44
Win64: 47 38
Unrolling and not storing mask both save some cycles.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Timing on Arrandale:
C SSE
Win32: 57 44
Win64: 47 38
Unrolling and not storing mask both save some cycles.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It can be 0 or -1 for invalid files, which may result in invalid memory
access.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
This can happen when the number of skipped lines is not consistent with
the number of coded lines.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org