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
Doesn't help speed as there isn't an asm implementation yet, but consistency
is a good thing.
Originally committed as revision 26348 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
It was an ugly hack to begin with and didn't give any performance.
NOTE: this patch opens up some future simplifications to be made (such as
removing some of the scantables from H264Context) but doesn't take advantage
of them yet.
Originally committed as revision 26329 to svn://svn.ffmpeg.org/ffmpeg/trunk
svq3 still doesn't support multithreading, but it's simpler for clients if
they can enable threading for all codecs by default.
Originally committed as revision 26015 to svn://svn.ffmpeg.org/ffmpeg/trunk
Contrary to progressive, just being able to crop up to 14/15 pixels
is not enough to encode all supported resolutions, and the new
behaviour is also consistent with e.g. MPEG-2 etc.
Originally committed as revision 25669 to svn://svn.ffmpeg.org/ffmpeg/trunk
r25218 made assumptions about the existence of past reference frames that
weren't necessarily true.
Originally committed as revision 25243 to svn://svn.ffmpeg.org/ffmpeg/trunk
h264dsp_mmx.c to h264_idct.asm (as yasm code). Because the loops are now
coded in asm instead of C, this is (depending on the function) up to 50%
faster for cases where gcc didn't do a great job at looping.
Since h264_idct_add8() is now faster than the manual loop setup in h264.c,
in-asm idct calling can now be enabled for chroma as well (see r16207). For
MMX, this is 5% faster. For SSE2 (which isn't done for chroma if h264.c does
the looping), this makes it up to 50% faster. Speed gain overall is ~0.5-1.0%.
Originally committed as revision 25119 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
start of decoding a picture instead of at the end.
Fixes mmco01.264
Patch by Stephen Warren
Originally committed as revision 22728 to svn://svn.ffmpeg.org/ffmpeg/trunk
change, not only size changes.
Patch by Janusz Krzysztofik foo=zyszt <jkr$foo@tis.icnet.pl>.
Originally committed as revision 22597 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
Previously, the area of a lost slice would be left at the slice number of the previous
frame which could occasionally match the number of the next slice and thus a non existing
slice could have been used for prediction leading to additional decoding errors in otherwise
undamaged slices.
Originally committed as revision 22483 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes playback of such streams with ffplay (but does not affect
current ffmpeg).
Patch by Janusz Krzysztofik, jkrzyszt A tis D icnet D pl
Originally committed as revision 22112 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
This should fix a segfault, also it might be faster on systems where the
+52 wasnt free.
Originally committed as revision 21406 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
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
functions called more than per mb are moved into the header, scan8 is also
as it must be known at compiletime.
The code after this patch duplicates h264data.h, this has been done to minimize
the changes in this step and allow more fine grained benchmarking.
Speedwise this is 1% faster on my pentium dual core with diegos cursed cathedral
sample.
Originally committed as revision 21157 to svn://svn.ffmpeg.org/ffmpeg/trunk
decoder which allows their usage without checking profile_idc.
Patch by Laurent Aimar (fenrir (AT) videolan org)
Originally committed as revision 21107 to svn://svn.ffmpeg.org/ffmpeg/trunk
Files with invalid VUI are now rejected like
other invalid SPS are.
Fixes issue1231.
Originally committed as revision 19335 to svn://svn.ffmpeg.org/ffmpeg/trunk
Before, the decoder could interpret a corrupt frame
as a NAL_DPA and NAL_DPC, and then start decoding
even if decode_slice_header() returned an error.
This frequently caused crashes.
Fixes issue1228, issue1229, and partially issue1238.
Originally committed as revision 19328 to svn://svn.ffmpeg.org/ffmpeg/trunk
First, reverted one was r19239.
Patch by Haruhiko Yamagata, h D yamagata A nifty D com
Originally committed as revision 19258 to svn://svn.ffmpeg.org/ffmpeg/trunk
The threads' contexts and rbsp_buffers were not freed at the end
of decoding.
Fixes issue 1581
Originally committed as revision 19207 to svn://svn.ffmpeg.org/ffmpeg/trunk
This ensures that the MMX loop filter is always bitexact with the C version.
Patch by Haruhiko Yamagata <h.yamagata _a_ nifty com>
Originally committed as revision 18923 to svn://svn.ffmpeg.org/ffmpeg/trunk
contexts, this avoids a crash when freeing the H.264 parser context introduced in
r18406, since h->s.avctx is NULL there.
Originally committed as revision 18418 to svn://svn.ffmpeg.org/ffmpeg/trunk
This ensures that the parser will no longer leak memory for all SPS/PPS it encounters.
Originally committed as revision 18406 to svn://svn.ffmpeg.org/ffmpeg/trunk
AVPacket argument rather than a const uint8_t *buf + int buf_size. This allows
passing of packet-specific flags from demuxer to decoder, such as the keyframe
flag, which appears necessary to playback corePNG P-frames.
Patch by Thilo Borgmann thilo.borgmann googlemail com, see also the thread
"Google Summer of Code participation" on the mailinglist.
Originally committed as revision 18351 to svn://svn.ffmpeg.org/ffmpeg/trunk
just saying that a non-existing id is referenced, show the value of the id.
Originally committed as revision 17771 to svn://svn.ffmpeg.org/ffmpeg/trunk
this will be needed once the parser can figure out has_b_frames
in av_find_stream_info().
Originally committed as revision 17673 to svn://svn.ffmpeg.org/ffmpeg/trunk
