Such files can be created using the --bff x264 option.
Sample-Id: h264_direct_temporal_mvs_bff.mkv
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Most of the changes are just trivial are just trivial replacements of
fields from MpegEncContext with equivalent fields in H264Context.
Everything in h264* other than h264.c are those trivial changes.
The nontrivial parts are:
1) extracting a simplified version of the frame management code from
mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
its own more complex system already and those were set only to appease
the mpegvideo parts.
2) some tables that need to be allocated/freed in appropriate places.
3) hwaccels -- mostly trivial replacements.
for dxva, the draw_horiz_band() call is moved from
ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
because it's now different for h264 and MpegEncContext-based
decoders.
4) svq3 -- it does not use h264 complex reference system, so I just
added some very simplistic frame management instead and dropped the
use of ff_h264_frame_start(). Because of this I also had to move some
initialization code to svq3.
Additional fixes for chroma format and bit depth changes by
Janne Grunau <janne-libav@jannau.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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>
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.
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
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
is closer at the top.
50-130 cpu cycles faster depending on which kind of direct MBs are meassured.
Originally committed as revision 21788 to svn://svn.ffmpeg.org/ffmpeg/trunk
A little faster and needed for future optimizations.
This sadly leads to some code duplication (which i hope i can factor out
again after the optimizations on the direcr mv code are done)
Originally committed as revision 21787 to svn://svn.ffmpeg.org/ffmpeg/trunk
as 16x16 (except ones changing interlacing relative to the colocated MB).
20 cycles slower during MV generation
175 cycles faster during MC
Originally committed as revision 21690 to svn://svn.ffmpeg.org/ffmpeg/trunk
Ronald S. Bultje
Luca Barbato
Diego Biurrun
Vittorio Giovara
Anton Khirnov
Michael Niedermayer
Janne Grunau
Steven Walters
Alexander Strange
Stefano Sabatini
Mans Rullgard