| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
use AVCodecContext.err_recognition
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
|
| |
This actually causes them to be inlined, leading to a significant
speedup (1-1.5% in my measurements).
|
| |
|
|
|
|
| |
Neon parts by Mans Rullgard <mans@mansr.com>.
|
| |
|
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
|
|
| |
Replace our incomplete w32threads implementation with x264's pthreads
w32threads wrapper.
Relicensed to LGPL with kind permission by Pegasys Inc.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
|
|
|
|
|
|
| |
Unsupported bit depth is certainly an error the user will
want to know about.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
| |
ff_h264_decode_ref_pic_list_reordering()
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
|
|
|
| |
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
slice that contains a start-of-field/frame macroblock
This allows concurrent decoding of the last field/frame, rather than
only the last slice, of data packets with multiple NAL units packed
together.
This will fix the slowdown reported in e.g. bug 52.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
| |
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
This fixes build failures with -DDEBUG in CPPFLAGS.
|
|
|
|
|
|
|
| |
This reverts commit b47904d158709bdec1a9d40e83d1abadf50081dc.
coded_{width, height} overwrites width and height in avcodec_open and
it currently just report the non-lowres size.
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
|
|
|
| |
Correct computation of implicit weight tables when referencing pictures
that are marked for long reference.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
It's more readable and less prone to breakage.
|
|
|
|
|
|
|
|
|
|
| |
High bitdepth H.264 needs 32-bit transform coefficients, whereas
dnxhd does not. This creates a conflict with the templated
functions operating on DCTELEM data. This patch adds a field
allowing the caller to choose the element size in dsputil_init()
and adds the required functions.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|
|
|
|
|
| |
FF_COMMON_FRAME holds the contents of the AVFrame structure and is also copied
to struct Picture. Replace by an embedded AVFrame structure in struct Picture.
|
|
|
|
| |
Eliminate redundant check in filter_mb_fast, consider bit depth in calculating qp_thresh.
|
| |
|
|
|
|
| |
These weren't getting inlined all the time in all gcc versions.
|
|
|
|
| |
Faster H.264 decoding with ALLOW_INTERLACE off.
|
|
|
|
| |
Avoid aliasing, unroll loops, and inline more functions.
|
|
|
|
| |
Reduce aliasing problems and unroll mv/ref loop.
|
|
|
|
|
|
|
| |
These statements cannot be reached and are thus not needed.
This removes a number of compiler warnings.
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
| |
2tap qpel isn't implemented yet for high bit depth, so it just breaks decoding.
|
| |
|
|
|
|
| |
Coefficient test for i16x16 add_pixels4 assumed luma plane.
|
|
|
|
| |
The assert referenced a variable that no longer exists since 4:4:4 support.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
By observation it did not seem to handle prev_frame_num > frame_num.
This does not affect any files I have.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the causes of this bug is that the h264 parser defaults low_delay
to 1, but the h264 codec defaults low_delay to 0. Really Ugly.
After many hours of looking at this, I'm still not sure how has_b_frames
is *intended* to behave, but to me the implementation appears way more
complicated than it ought to be.
My patch relies on the encoder to set an optional field in the SPS. This
works for libx264 streams, but I'm not sure that all h264 encoders will
set it.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
It was broken in 4:4:4, and still did chroma deblocking for no reason in 4:2:0.
|
|
|
|
| |
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
|
|
| |
Needs some ARM/PPC asm modifications.
|
|
|
|
| |
It was broken in 4:4:4, and still did chroma deblocking for no reason in 4:2:0.
|
|
|
|
| |
Note: this is 4:4:4 from the 2007 spec revision, not the previous (now deprecated) 4:4:4 mode in H.264.
|
|
|
|
|
|
|
| |
Fixes issue2517
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
| |
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
|
|
|
|
|
| |
When backing up the top-left border, check that the top-left
(rather than left) MB indeed does belong to our slice. If it
doesn't, backing up has no positive effect but may accidentally
interfere with other threads writing in the same space.
Fixes occasional one-off effects when enabling slice-MT.
|
| |
|
|
|
|
|
| |
Fixes "make THREADS=2 THREAD_TYPE=2
fate-h264-conformance-frext-pph10i3_panasonic_a".
|