* qatar/master:
x86: Move some conditional code around to avoid unused variable warnings
Conflicts:
libavcodec/x86/dsputil_mmx.c
libavfilter/x86/vf_yadif_init.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '94660c35249e11c53b9a9f0c2f85c4335b21eda7':
threads: always call thread_finish_setup for intra codecs
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
avcodec: Bump minor for JPEG 2000 decoder
JPEG 2000 decoder for DCinema
The mqc code is merged, the rest is added independent of
the existing jpeg2000 decoder and encoder.
Conflicts:
Changelog
doc/general.texi
libavcodec/Makefile
libavcodec/allcodecs.c
libavcodec/mqc.c
libavcodec/mqc.h
libavcodec/mqcdec.c
libavcodec/version.h
tests/fate/video.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0c15a9aa7e1654a19144eb594f9639a57fd47482':
sh4: Remove dubious aligned dsputil code
Conflicts:
libavcodec/sh4/dsputil_align.c
libavcodec/sh4/h264chroma_init.c
libavcodec/sh4/hpeldsp.c
libavcodec/sh4/qpel.c
If someone wants to maintain the sh4 code in ffmpeg, wants to
add more optimizations, or volunteers to maintain any of
what is removed here and can confirm that they are faster.
Then please contact us!
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '78fa0bd0f7067868943c0899907e313414492426':
x86: cavs: Put mmx-specific code into its own init function
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Intra codecs do not need an update_thread_context() function and never
call ff_thread_finish_setup(). They rely on ff_thread_get_buffer()
calling it. So call it even if the get_buffer2 function pointer is
avcodec_default_get_buffer2 and it has not been called before.
Based on the 2007 GSoC project from Kamil Nowosad <k.nowosad@students.mimuw.edu.pl>
Updated to current programming standards, style and many more small
fixes by Diego Biurrun <diego@biurrun.de>.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The code represents a considerable maintenance burden and it is not
clear that it gives a noticeable benefit to outweigh this after 10
years of improvements in compiler technology since its creation.
The value of coeff_per_sb_select depends on the bit rate, not on
sub_sampling.
Also remove the calculation of tmp, no longer needed.
Fixes tickets #1868 and #742 (only audio part)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '287c8db39e71af7047e551bbfd1264d771cccbc9':
cosmetics: bfin: Fix indentation in the dsputil init function
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '28bc406c84b04a5f1458b90ff52ddbec73e46202':
mjpeg: Use hpeldsp instead of dsputil for half-pel functions
svq1enc: Use hpeldsp instead of dsputil for half-pel functions
Conflicts:
configure
libavcodec/mjpegdec.c
libavcodec/svq1enc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2f6bc5f7c193477c2ebc0acce8f2d5551445e129':
svq3: Use hpeldsp instead of dsputil for half-pel functions
mpegvideo: Use hpeldsp instead of dsputil for half-pel functions
svq1: Use hpeldsp instead of dsputil for half-pel functions
mimic: Use hpeldsp instead of dsputil for half-pel functions
Conflicts:
configure
libavcodec/motion_est.c
libavcodec/mpegvideo.c
libavcodec/mpegvideo.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8071264f2196d71ff49c3944c33f8d3d83f548f1':
interplayvideo: Use hpeldsp instead of dsputil for half-pel functions
bink: Use hpeldsp instead of dsputil for half-pel functions
indeo3: Use hpeldsp instead of dsputil for half-pel functions
vp56: Use hpeldsp instead of dsputil for half-pel functions
vp3: Use hpeldsp instead of dsputil for half-pel functions
Conflicts:
libavcodec/bink.c
libavcodec/indeo3.c
libavcodec/vp56.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previously, if dct_bits was set to 32, we used separate 32-bit
versions of these functions. Since dct_bits now is removed,
remove the unused 32-bit versions of the functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'a7f46586bf47174b5fa00a905b767b1781ec8b72':
ff_get_buffer(): allocate the frame for max(coded,display) dimensions
Merged-by: Michael Niedermayer <michaelni@gmx.at>
233 to 105 cycles on Arrandale and Win64.
Replacing the multiplication by s_m[m] by a pand and a pxor with
appropriate vectors is slower. Unrolling is a 15 cycles win.
A SSE version was 4 cycles slower.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The encoder now doesn't produce any extra graphic control extension
block anymore. Only the image is encoded, and the muxer writing
its own GCE containing notably the timing information now includes the
optional palette transmitted through packet side data.
This commit avoid setting clashes between the two GCE, and reduce the
size of the generated file with pal8 output.
Regression since c10d498bfd.
Unfortunately ff_thread_get_format can only be called from
a separate decode thread, running it during init will fail.
Fixes for that are welcome, for now just revert back to
calling avctx->get_format directly, which is correct
but having to decide on a case-by-case basis which approach
to use is a bit messy.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Currently, we have a AV_CODEC_ID_SSA, which matches the way the ASS/SSA
markup is muxed in a standalone .ass/.ssa file. This means the AVPacket
data starts with a "Dialogue:" string, followed by a timing information
(start and end of the event as string) and a trailing CRLF after each
line. One packet can contain several lines. We'll refer to this layout
as "SSA" or "SSA lines".
In matroska, this markup is not stored as such: it has no "Dialogue:"
prefix, it contains a ReadOrder field, the timing information is not in
the payload, and it doesn't contain the trailing CRLF. See [1] for more
info. We'll refer to this layout as "ASS".
Since we have only one common codec for both formats, the matroska
demuxer is constructing an AVPacket following the "SSA lines" format.
This causes several problems, so it was decided to change this into
clean ASS packets.
Some insight about what is changed or unchanged in this commit:
CODECS
------
- the decoding process still writes "SSA lines" markup inside the ass
fields of the subtitles rectangles (sub->rects[n]->ass), which is
still the current common way of representing decoded subtitles
markup. It is meant to change later.
- new ASS codec id: AV_CODEC_ID_ASS (which is different from the
legacy AV_CODEC_ID_SSA)
- lavc/assdec: the "ass" decoder is renamed into "ssa" (instead of
"ass") for consistency with the codec id and allows to add a real
ass decoder. This ass decoder receives clean ASS lines (so it starts
with a ReadOrder, is followed by the Layer, etc). We make sure this
is decoded properly in a new ass-line rectangle of the decoded
subtitles (the ssa decoder OTOH is doing a simple straightforward
copy). Using the packet timing instead of data string makes sure the
ass-line now contains the appropriate timing.
- lavc/assenc: just like the ass decoder, the "ssa" encoder is renamed
into "ssa" (instead of "ass") for consistency with the codec id, and
allows to add a real "ass" encoder.
One important thing about this encoder is that it only supports one
ass rectangle: we could have put several dialogue events in the
AVPacket (separated by a \0 for instance) but this would have cause
trouble for the muxer which needs not only the start time, but also
the duration: typically, you have merged events with the same start
time (stored in the AVPacket->pts) but a different duration. At the
moment, only the matroska do the merge with the SSA-line codec.
We will need to make sure all the decoders in the future can't add
more than one rectangle (and only one Dialogue line in it
obviously).
FORMATS
-------
- lavf/assenc: the .ass/.ssa muxer can take both SSA and ASS packets.
In the case of ASS packets as input, it adds the timing based on the
AVPacket pts and duration, and mux it with "Dialogue:", trailing
CRLF, etc.
- lavf/assdec: unchanged; it currently still only outputs SSA-lines
packets.
- lavf/mkv: the demuxer can now output ASS packets without the need of
any "SSA-lines" reconstruction hack. It will become the default at
next libavformat bump, and the SSA support will be dropped from the
demuxer. The muxer can take ASS packets since it's muxed normally,
and still supports the old SSA packets. All the SSA support and
hacks in Matroska code will be dropped at next lavf bump.
[1]: http://www.matroska.org/technical/specs/subtitles/ssa.html
If a reference is unavailable use a field from the current
picture
Fixes null pointer dereference
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This commit removes the badly duplicated code between the encoder and
the muxer. That may sound surprising, but the encoder is now responsible
from the encoding of the picture when muxing to a .gif file. It also
does not require anymore a manual user intervention such as a -pix_fmt
rgb24 to work properly. To summarize, output gif are now easier to
generate, code is saner and simpler, and files are smaller (thanks to
the lzw encoding which was unused so far with the default .gif output).
We can certainly make things even better, but this is the first step.
FATE is updated because of the output being produced by the encoder and
not the muxer (no lzw in the muxer), and in the seek test only the size
mismatches.
Fixes Ticket #2262
* commit '69f6f03cd16a09e4e848b4e82bae4993bc361cd0':
rv10: cosmetics, reformat
qdm2: check that the FFT size is a power of 2
Conflicts:
libavcodec/rv10.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b1bb8fb860b47e90dd67f0c5740698128fc82dcc':
svq1dec: check that the reference frame has the same dimensions as the current one
Conflicts:
libavcodec/svq1dec.c
See: 3b57bb478f
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The data offsets are relative to the bistream header, which is 16 bytes
after the start of the data.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Also add an additional sanity check to the alt_quant table.
Fixes invalid reads with corrupted files.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
They can be different if the last keyframe failed to decode correctly.
Fixes possible invalid reads in such a case.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
* commit '015821229f96bf7e677f2a711a58dbea3009f574':
vp3: Use full transpose for all IDCTs
Conflicts:
libavcodec/vp3.c
libavcodec/vp3dsp.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c46819f2299c73cd1bfa8ef04d08b0153a5699d3':
x86: Move constants to the only place where they are used
Conflicts:
libavcodec/x86/vp3dsp.asm
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This way, the special IDCT permutations are no longer needed. This
is similar to how H264 does it, and removes the dsputil dependency
imposed by the scantable code.
Also remove the unused type == 0 cases from the plain C version
of the idct.
Signed-off-by: Martin Storsjö <martin@martin.st>
While this change isn't bitexact, the IDCTs weren't bitexact to
start with either.
This simplifies decoupling vp3 from dsputil.
Signed-off-by: Martin Storsjö <martin@martin.st>
Just like get_buffer, get_format should not be called from a different
thread if thread_safe_callbacks is not set.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
With the current code it fails due to running out
of registers.
So code the store offsets manually into the assembler
instead.
Passes "make fate-dts".
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
dsputil_init() is deprecated and not meant to be exported.
ff_dsputil_init() is internal to libavcodec and thus can not be used.
avpriv_dsputil_init() is the version shared between libraries.
This commit fixes 3 unjustified libavfilter deprecated warnings.
* commit 'e027032fc6a49db5a4ce12fc3e09ffb86ff20522':
x86: dsputil: ff_h263_*_loop_filter declarations to a more suitable place
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a89c05500f68d94a0269e68bc522abfd420c5497':
x86: h264qpel: int --> ptrdiff_t for some line_size parameters
Conflicts:
libavcodec/x86/qpelbase.asm
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Using the first names of authors sounds somewhat unprofessional
and might be considered offensive which is not intended.
The new names use the initials of the authors due to simplicity
and the possibility to apply it consistently without the need
to find political correct names for each future case where
alternative codecs might exist. Also its shorter ...
If someone has a better idea, like maybe 2 random letters
and people prefer it then iam happy to switch to that ...
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9de9b828ef005dec37052548c195a6b4f18fc701':
lavc: don't overwrite display dimensions with coded dimensions.
lavc: extend / update the [coded_]{width,height} doxy
Conflicts:
libavcodec/avcodec.h
libavcodec/utils.c
The change to the w/h handling is not merged as it breaks lowres
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '8a776ad90e00ab2b98e8683ac6182d641a383c3a':
h261: Move shared data tables from a header to a proper C file
Conflicts:
libavcodec/Makefile
libavcodec/h261data.c
libavcodec/h261dec.c
libavcodec/h261enc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '85deb51a01f1ecc5ac5faa52ad8ea141c384e23a':
h264: Only initialize dsputil if error resilience is enabled
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e8cafd2773bc56455c8816593cbd9368f2d69a80':
h264: Clear the mb members via memset instead of using dsputil
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6d25c9db11e87ec58652de6588448225137b0c57':
dsputil: Make square put/avg_pixels functions local to h264qpel
Conflicts:
libavcodec/dsputil.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
* qatar/master:
lavc: Move ff_cropTbl and ff_zigzag_direct from dsputil to mathtables
Conflicts:
libavcodec/mathtables.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '610b18e2e3d8ef5eca3e78f33a0625689b8d2bb9':
x86: qpel: Move fullpel and l2 functions to a separate file
bfin: Make vp3 functions static
Conflicts:
libavcodec/bfin/vp3_bfin.c
libavcodec/x86/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'aa8d89536d35af0a0c8d8bac2b452ffe7b82cae5':
bfin: Don't use the vp3 idct functions if bitexact behaviour is expected
Conflicts:
libavcodec/bfin/vp3_bfin.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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.
