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.
* qatar/master: (22 commits)
H.264: fix filter_mb_fast with 4:4:4 + 8x8dct
alsa: limit buffer_size to 32768 frames.
alsa: fallback to buffer_size/4 for period_size.
doc: replace @pxref by @ref where appropriate
mpeg1video: don't abort if thread_count is too high.
segafilm: add support for videos with cri adx adpcm
gxf: Fix 25 fps DV material in GXF being misdetected as 50 fps
libxvid: Add const qualifier to silence compiler warning.
H.264: improve qp_thresh check
H.264: use fill_rectangle in CABAC decoding
H.264: Remove redundant hl_motion_16/8 code
H.264: merge fill_rectangle into P-SKIP MV prediction, to match B-SKIP
H.264: faster P-SKIP decoding
H.264: av_always_inline some more functions
H.264: Add x86 assembly for 10-bit H.264 predict functions
swscale: rename uv_off/uv_off2 to uv_off_px/byte.
swscale: implement error dithering in planarCopyWrapper.
swscale: error dithering for 16/9/10-bit to 8-bit.
swscale: fix overflow in 16-bit vertical scaling.
swscale: fix crash in 8-bpc bilinear output without alpha.
...
Conflicts:
doc/developer.texi
libavdevice/alsa-audio.h
libavformat/gxf.c
libswscale/swscale.c
libswscale/swscale_internal.h
libswscale/swscale_unscaled.c
libswscale/x86/swscale_template.c
tests/ref/lavfi/pixdesc
tests/ref/lavfi/pixfmts_copy
tests/ref/lavfi/pixfmts_crop
tests/ref/lavfi/pixfmts_hflip
tests/ref/lavfi/pixfmts_null
tests/ref/lavfi/pixfmts_scale
tests/ref/lavfi/pixfmts_vflip
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master: (40 commits)
H.264: template left MB handling
H.264: faster fill_decode_caches
H.264: faster write_back_*
H.264: faster fill_filter_caches
H.264: make filter_mb_fast support the case of unavailable top mb
Do not include log.h in avutil.h
Do not include pixfmt.h in avutil.h
Do not include rational.h in avutil.h
Do not include mathematics.h in avutil.h
Do not include intfloat_readwrite.h in avutil.h
Remove return statements following infinite loops without break
RTSP: Doxygen comment cleanup
doxygen: Escape '\' in Doxygen documentation.
md5: cosmetics
md5: use AV_WL32 to write result
md5: add fate test
md5: include correct headers
md5: fix test program
doxygen: Drop array size declarations from Doxygen parameter names.
doxygen: Fix parameter names to match the function prototypes.
...
Conflicts:
libavcodec/x86/dsputil_mmx.c
libavformat/flvenc.c
libavformat/oggenc.c
libavformat/wtv.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
ARM: ac3: update ff_ac3_extract_exponents_neon per 8b7b2d6
ARM: NEON optimised vector_clip_int32()
swscale: disable full_chroma_int when converting to non-24/32bpp RGB.
suggest to use av_get_bytes_per_sample() in av_get_bits_per_sample_format() doxy
ffmpeg: use av_get_bytes_per_sample() in place of av_get_bits_per_sample_fmt()
put_bits: remove ALT_BITSTREAM_WRITER
put_bits: always use intreadwrite.h macros
libavformat: Add an example how to use the metadata API
doxygen: Prefer member groups over grouping into modules
doxygen: be more permissive when searching for API examples
avformat: doxify the Metadata API
lavf: restore old behavior for custom AVIOContex with an AVFMT_NOFILE format.
lavf: use the correct pointer in av_open_input_stream().
avidec: infer absolute vs relative index from first packet
Conflicts:
libavformat/Makefile
libavformat/avidec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Before this, almost all module groups have been used for grouping functions
and fields in structures semantically. This causes them to not appear
properly in the file documentation and needlessly clutters up the "Modules"
index.
Additionally, this commit streamlines some spelling and appearances.
* qatar/master:
swscale: remove misplaced comment.
ffmpeg: fix streaming to ffserver.
swscale: split out RGB48 output functions from yuv2packed[12X]_c().
build: move vpath directives to main Makefile
swscale: fix JPEG-range YUV scaling artifacts.
build: move ALLFFLIBS to a more logical place
ARM: factor some repetitive code into macros
Fix SVQ3 after adding 4:4:4 H.264 support
H.264: fix CODEC_FLAG_GRAY
4:4:4 H.264 decoding support
ac3enc: fix allocation of floating point samples.
Conflicts:
ffmpeg.c
libavcodec/dsputil_template.c
libavcodec/h264.c
libavcodec/mpegvideo.c
libavcodec/snow.c
libswscale/swscale.c
libswscale/swscale_internal.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit a50f0bea25.
This has been implemented differently in qatar and its better they
maintain it for me instead of me having to spend an average 5sec more
per merge
Conflicts:
libavcodec/h264.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master: (30 commits)
AVOptions: make default_val a union, as proposed in AVOption2.
arm/h264pred: add missing argument type.
h264dsp_mmx: place bracket outside #if/#endif block.
lavf/utils: fix ff_interleave_compare_dts corner case.
fate: add 10-bit H264 tests.
h264: do not print "too many references" warning for intra-only.
Enable decoding of high bit depth h264.
Adds 8-, 9- and 10-bit versions of some of the functions used by the h264 decoder.
Add support for higher QP values in h264.
Add the notion of pixel size in h264 related functions.
Make the h264 loop filter bit depth aware.
Template dsputil_template.c with respect to pixel size, etc.
Template h264idct_template.c with respect to pixel size, etc.
Preparatory patch for high bit depth h264 decoding support.
Move some functions in dsputil.c into a new file dsputil_template.c.
Move the functions in h264idct into a new file h264idct_template.c.
Move the functions in h264pred.c into a new file h264pred_template.c.
Preparatory patch for high bit depth h264 decoding support.
Add pixel formats for 9- and 10-bit yuv420p.
Choose h264 chroma dc dequant function dynamically.
...
Conflicts:
doc/APIchanges
ffmpeg.c
ffplay.c
libavcodec/alpha/dsputil_alpha.c
libavcodec/arm/dsputil_init_arm.c
libavcodec/arm/dsputil_init_armv6.c
libavcodec/arm/dsputil_init_neon.c
libavcodec/arm/dsputil_iwmmxt.c
libavcodec/arm/h264pred_init_arm.c
libavcodec/bfin/dsputil_bfin.c
libavcodec/dsputil.c
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_loopfilter.c
libavcodec/h264_ps.c
libavcodec/h264_refs.c
libavcodec/h264dsp.c
libavcodec/h264idct.c
libavcodec/h264pred.c
libavcodec/mlib/dsputil_mlib.c
libavcodec/options.c
libavcodec/ppc/dsputil_altivec.c
libavcodec/ppc/dsputil_ppc.c
libavcodec/ppc/h264_altivec.c
libavcodec/ps2/dsputil_mmi.c
libavcodec/sh4/dsputil_align.c
libavcodec/sh4/dsputil_sh4.c
libavcodec/sparc/dsputil_vis.c
libavcodec/utils.c
libavcodec/version.h
libavcodec/x86/dsputil_mmx.c
libavformat/options.c
libavformat/utils.c
libavutil/pixfmt.h
libswscale/swscale.c
libswscale/swscale_internal.h
libswscale/swscale_template.c
tests/ref/seek/lavf_avi
Merged-by: Michael Niedermayer <michaelni@gmx.at>
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
No speed improvement, but necessary for some future stuff.
Also opens up the possibility of asm chroma dc idct/dequant.
Originally committed as revision 26349 to svn://svn.ffmpeg.org/ffmpeg/trunk
Useful so that we don't have to run the hierarchical DC iDCT if there aren't
any coefficients. Opens up some future opportunities for optimization as well.
Originally committed as revision 26337 to svn://svn.ffmpeg.org/ffmpeg/trunk
About 2.5x the speed.
NOTE: the way that the asm code handles large qmuls is a bit suboptimal.
If x264-style dequant was used (separate shift and qmul values), it might
be possible to get some extra speed.
Originally committed as revision 26336 to svn://svn.ffmpeg.org/ffmpeg/trunk
libavcodec/h264.h:1260: warning: ‘decode_mb_skip’ defined but not used
patch by Eli Friedman, eli.friedman gmail com
Originally committed as revision 24069 to svn://svn.ffmpeg.org/ffmpeg/trunk
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
The function is only used within that file, so it makes sense to place
it there. This fixes many warnings of the type:
h264.h:1170: warning: ‘fill_filter_caches’ defined but not used
Originally committed as revision 22876 to svn://svn.ffmpeg.org/ffmpeg/trunk
This moves the H264-specific functions from DSPContext to the new
H264DSPContext. The code is made conditional on CONFIG_H264DSP
which is set by the codecs requiring it.
The qpel and chroma MC functions are not moved as these are used by
non-h264 code.
Originally committed as revision 22565 to svn://svn.ffmpeg.org/ffmpeg/trunk
These macros are redundant. All uses are replaced with the generic
DECLARE_ALIGNED macro instead.
Originally committed as revision 22233 to svn://svn.ffmpeg.org/ffmpeg/trunk
this seems 1 cpu cycle slower even though we practically just remove code.
Speed loss seems caused by the merge of if(left_type), iam commiting this
anyway as i cant imagine this to be anything but compiler messup.
Originally committed as revision 22073 to svn://svn.ffmpeg.org/ffmpeg/trunk
about 5 cpu cycles slower in the local code but should be overall faster
due to reduced cache use. (my sample though has too few intra4x4 blocks
for this to be meassureable easily either way)
Originally committed as revision 22052 to svn://svn.ffmpeg.org/ffmpeg/trunk
The code read/write code itself was 1 cycle faster, overall its
likely more due to cache effects
Originally committed as revision 22048 to svn://svn.ffmpeg.org/ffmpeg/trunk
This eliminates all aliasing violation warnings in h264 code.
No measurable speed difference with gcc-4.4.3 on i7.
Originally committed as revision 21881 to svn://svn.ffmpeg.org/ffmpeg/trunk
the row code. This function would only be needed on a MB basis for MBAFF+FMO
Originally committed as revision 21860 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
h264: Fix pointer warnings by removing redundant [0]
Fixes:
h264.h:1222:38: warning: initialization from incompatible pointer type
h264.h:1299:38: warning: initialization from incompatible pointer type
h264.h:1314:42: warning: initialization from incompatible pointer type
Reason: breaks h264 decoding & fate
Originally committed as revision 21818 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes:
h264.h:1222:38: warning: initialization from incompatible pointer type
h264.h:1299:38: warning: initialization from incompatible pointer type
h264.h:1314:42: warning: initialization from incompatible pointer type
Originally committed as revision 21814 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes:
h264.h: In function 'fill_filter_caches':
h264.h:1216:73: warning: integer overflow in expression
h264.h:1307:81: warning: integer overflow in expression
Originally committed as revision 21813 to svn://svn.ffmpeg.org/ffmpeg/trunk
loop filter. This removes one obstacle of getting ff_h264_filter_mb_fast()
bitexact. code is maybe 0.1% faster
Originally committed as revision 21280 to svn://svn.ffmpeg.org/ffmpeg/trunk
Run loop filter per row instead of per MB, this also should make it
much easier to switch to per frame filtering and also doing so in a
seperate thread in the future if some volunteer wants to try.
Overall decoding speedup of 1.7% (single thread on pentium dual / cathedral sample)
This change also allows some optimizations to be tried that would not have
been possible before.
Originally committed as revision 21270 to svn://svn.ffmpeg.org/ffmpeg/trunk
No benchmark because its just replacing variables with litteral constants
(so no risk for slowdown outside gcc silliness) and i need sleep.
Originally committed as revision 21237 to svn://svn.ffmpeg.org/ffmpeg/trunk
This could have caused the linking failure of pred_pskip_motion() missing if
a compiler included never used static functions.
Originally committed as revision 21221 to svn://svn.ffmpeg.org/ffmpeg/trunk
Seems to speed the code up a little...
The placement of many generic functions between h264.c and h264.h is still open
Currently they are a little randomly placed between them.
Originally committed as revision 21178 to svn://svn.ffmpeg.org/ffmpeg/trunk
called once per MB in worst case and doesnt seem to benefit from static inline.
Actually the code might be a hair faster now (0.1% according to my benchmark but
this could be random noise)
Originally committed as revision 21173 to svn://svn.ffmpeg.org/ffmpeg/trunk
no speedloss meassured, also its really not touching anything that is speed relevant.
Originally committed as revision 21169 to svn://svn.ffmpeg.org/ffmpeg/trunk
No speedloss meassured (its slightly faster here but that may be random fluctuations)
Originally committed as revision 21165 to svn://svn.ffmpeg.org/ffmpeg/trunk
