I dont know if this is the best way to handle it. But it fixes http://kuwatan.jp/temp/n-02b.3gp
Fixes issue 2373.
Originally committed as revision 25875 to svn://svn.ffmpeg.org/ffmpeg/trunk
Wraparound in ssd is mainly avoided by subtracting the ssd of the
best node from all the others once it has grown large enough.
If using very large trellis sizes (e.g. -trellis 15), the frontier
is so large that the difference between the best and the worst is
large enough to cause wraparound, even if the ssd of the best one
is subtracted regularly.
When using -trellis 10 on a 30 second sample, this causes only a slight
slowdown, from 61 to 64 seconds.
Originally committed as revision 25858 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Mark Goodman [mark goodman gmail com] with some modifications by me.
Originally committed as revision 25796 to svn://svn.ffmpeg.org/ffmpeg/trunk
The new implementation is more compact, more correct and doesn't hurt
the eyes.
Originally committed as revision 25792 to svn://svn.ffmpeg.org/ffmpeg/trunk
so extend decoder to output only one channel for it.
This fixes issue 2368.
Originally committed as revision 25790 to svn://svn.ffmpeg.org/ffmpeg/trunk
This also allows to remove a linking dependency of libavfilter on
libavcodec.
Originally committed as revision 25789 to svn://svn.ffmpeg.org/ffmpeg/trunk
const char *avcodec_get_channel_name(int channel_id)
which was never implemented.
Originally committed as revision 25788 to svn://svn.ffmpeg.org/ffmpeg/trunk
PaletteControl.
This also fixes playback of some files with ffplay (images were
corrupted for a short time after a palette change).
Originally committed as revision 25778 to svn://svn.ffmpeg.org/ffmpeg/trunk
This makes the wording consistent with how people usually talk about heaps.
Originally committed as revision 25775 to svn://svn.ffmpeg.org/ffmpeg/trunk
This increases the PSNR slightly (about 0.1 dB) for trellis sizes
below 8, and gives equal PSNR for sizes above that.
Originally committed as revision 25769 to svn://svn.ffmpeg.org/ffmpeg/trunk
This lowers the run time from 158 to 21 seconds, for -trellis 8
with a 30 second sample on my machine.
This requires 64 KB additional memory.
Originally committed as revision 25768 to svn://svn.ffmpeg.org/ffmpeg/trunk
beginning of the frame, so make it use skip_bits_long() instead of
skip_bits() for that.
Originally committed as revision 25754 to svn://svn.ffmpeg.org/ffmpeg/trunk
By not looking for the exactly largest node, we avoid an O(n) seek through
the leaf nodes. Just pick one (not the same one every time) and try replacing
that node with the new one.
For -trellis 8, this lowers the run time from 190 to 158 seconds,
for a 30 second 44 kHz mono sample, on my machine.
Originally committed as revision 25733 to svn://svn.ffmpeg.org/ffmpeg/trunk
This avoids having to memmove the large parts of the array when inserting into
it.
For -trellis 8, this lowers the run time from 245 seconds to 190 seconds,
for a 30 second 44 kHz mono sample, on my machine.
Originally committed as revision 25731 to svn://svn.ffmpeg.org/ffmpeg/trunk
An intermediate value in the floor 1 linear interpolation was
overflowing
resulting in obvious artifacts on some files.
e.g.
http://upload.wikimedia.org/wikipedia/commons/7/79/Big_Buck_Bunny_small.ogv
Prior to this fix 87 out of 128 64kbit/s mono files decoded with ffmpeg
have
lower PEAQ ODG values than the same files decoded with libvorbis. With
this
fix none of that set have significantly worse ODG values than libvorbis.
Fixes issue 2352
Patch by Gregory Maxwell <greg@xiph.org>
Originally committed as revision 25724 to svn://svn.ffmpeg.org/ffmpeg/trunk
Nobody ever uses it correctly, and ffmpeg sets it incorrectly, so we'll just
leave it out.
Originally committed as revision 25720 to svn://svn.ffmpeg.org/ffmpeg/trunk
descriptors for printing the number of channels/components.
Also replace the term "nb_channels" with "nb_components" which is more
consistent with the FFmpeg internal terminology, and is somehow
different with respect to the current definition of nb_channels in
PixFmtInfo.
See thread:
Subject: [FFmpeg-devel] [PATCH 6/8] Make avcodec_pix_fmt_string() use the
information in the pixel format descriptors for printing the
number of planes. Also replace the term "nb_channels" with
"nb_planes" which is more correct.
Date: Fri, 5 Nov 2010 12:01:38 +0100
Originally committed as revision 25717 to svn://svn.ffmpeg.org/ffmpeg/trunk
eval API.
More grep-friendly and more consistent with the rest of the FFmpeg
API.
Originally committed as revision 25708 to svn://svn.ffmpeg.org/ffmpeg/trunk
Muxlength does not include the 3 bytes of AudioSyncStream() before the
AudioMuxElement(). If these three bytes are not accounted for the last three
bytes of the LATM packet are sent back to the decoder again.
Fixes issue244/mux2.share.ts
Originally committed as revision 25685 to svn://svn.ffmpeg.org/ffmpeg/trunk
the object number is, it determines whether we should continue
parsing the presentation description and whether we should
clear the subtitles on the next display command.
Based on patch by Mark Goodman [mark goodman gmail com]
Originally committed as revision 25682 to svn://svn.ffmpeg.org/ffmpeg/trunk
Previously it was releasing the buffer which was returned to the user,
which was resulting in a crash in case of direct rendering.
Originally committed as revision 25678 to svn://svn.ffmpeg.org/ffmpeg/trunk
Spotted by Alex after Carl Eugen found errors some samples. There no errors or
noticeable artifacts in the samples I used during development.
Originally committed as revision 25676 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
av_get_sample_fmt_name()
av_get_sample_fmt()
av_get_sample_fmt_string()
in libavcore, and deprecate the corresponding libavcodec/audioconvert.h functions:
avcodec_get_sample_fmt_name()
avcodec_get_sample_fmt()
avcodec_sample_fmt_string()
Originally committed as revision 25653 to svn://svn.ffmpeg.org/ffmpeg/trunk
The decoder is just a wrapper around the AAC decoder.
based on patch by Paul Kendall { paul <ät> kcbbs gen nz }
Originally committed as revision 25642 to svn://svn.ffmpeg.org/ffmpeg/trunk
Use avctx in all called functions. This allows passing a NULL AACContext
for LATM since the AACContext is only used in output_configure() which
is skipped for LATM parsing.
Originally committed as revision 25641 to svn://svn.ffmpeg.org/ffmpeg/trunk
aac_decode_frame() remains as AVPacket handling a wrapper. The actual
decoding function takes a GetBitContext as input and will be used be the
AAC LATM decoder to avoid copying the unaligned AAC bitstream.
Originally committed as revision 25640 to svn://svn.ffmpeg.org/ffmpeg/trunk
This will be used by the latm decoder to avoid AACContext changes during
audio specific config parsing.
Originally committed as revision 25638 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes compilation with the latest clang trunk version.
Patch by İsmail Dönmez, ismail at namtrac dot org
Originally committed as revision 25628 to svn://svn.ffmpeg.org/ffmpeg/trunk
The 3GPP spec uses the following calculation for high spreading:
thr'_spr = max(thr_scaled, s_h(n) * thr_scaled(n-1))
where, n is defined as the current band, and s_h() is defined as "[...] the
distance of adjacent bands in Bark and a constant slope that is 15 dB/Bark
[...]". This is a little ambiguous as you would assume you want the Bark
width of the previous band for this calculation. However, this assumption
appears to be incorrect, and you really want the Bark width of the current
band. Coincidentally this is exactly what the spec calls for! =P
This noticeably improves Tom's Diner at low bitrates (I tested at 64kbps,
with mid/side disabled).
Patch by: Nathan Caldwell <saintdev@gmail.com>
Originally committed as revision 25622 to svn://svn.ffmpeg.org/ffmpeg/trunk
These blocks depended on the compiler keeping xmm registers untouched between
them.
Originally committed as revision 25619 to svn://svn.ffmpeg.org/ffmpeg/trunk
suncc does not like the leading commas inside the macro, but it has no problem
with trailing commas.
Originally committed as revision 25615 to svn://svn.ffmpeg.org/ffmpeg/trunk
This greatly improves bitrate handling. You will now get within a few
kbps of your requested bitrate instead of 20-40kbps higher.
There is absolutely no analog to this line in the 3GPP spec, that I
can find.
patch by Nathan Caldwell saintdev (at) gmail
Originally committed as revision 25589 to svn://svn.ffmpeg.org/ffmpeg/trunk
Removing the modification vastly improves quality (at a slight bitrate
cost) for some samples. castanets.wav is a good example. The closest
equivalent I see to the modification in the 3GPP spec is a similar
modification (over a specific frequency range) when TNS is used.
This also changes the threshold-in-quiet calculation to match the
3GPP spec.
patch by Nathan Caldwell saintdev (at) gmail
Originally committed as revision 25588 to svn://svn.ffmpeg.org/ffmpeg/trunk
According to the 3GPP spec:
"Thus the pre-echo control is inactive for the first short window (but
not all short windows in a short frame) after a start block and for
all frames with a stop window sequence."
Currently, pre-echo control is only run when the current frame is not
a short frame, and the previous frame is not a short frame.
patch by Nathan Caldwell saintdev (at) gmail
Originally committed as revision 25587 to svn://svn.ffmpeg.org/ffmpeg/trunk
Reading 7 bits as an unsigned int can't result in a value exceeding 127.
Accordingly, remove error message (as it'll never be reached).
Originally committed as revision 25575 to svn://svn.ffmpeg.org/ffmpeg/trunk
Bug caused by the fact that get_bits(gb, 0) is undefined.
Doesn't affect any streams generated by the official Theora encoder, but such
streams are nevertheless valid.
Fixes decoding of CELT-933dd833-nmr-bandt.ogv.
Originally committed as revision 25573 to svn://svn.ffmpeg.org/ffmpeg/trunk
Do decode init in the init function instead of at the first frame.
Fix some possible crash cases.
Originally committed as revision 25572 to svn://svn.ffmpeg.org/ffmpeg/trunk
Some code was initializing some xmm registers in one asm block and using them
in the following block, assuming they wouldn't be changed in between blocks.
Originally committed as revision 25568 to svn://svn.ffmpeg.org/ffmpeg/trunk
thus making forced key frames work.
Patch by Nicolas George, nicolas d george a normalesup d org
Originally committed as revision 25567 to svn://svn.ffmpeg.org/ffmpeg/trunk
I used the same loop counter for the inner and outer initalization loops.
This caused initalization to only run for the first channel. This in turn lead
to any channel other than the first using only short blocks.
Patch by Nathan Caldwell, saintdev at gmail
Originally committed as revision 25566 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes a possibly exploitable buffer overflow and it will likely also be needed for future overreading fixes.
Originally committed as revision 25546 to svn://svn.ffmpeg.org/ffmpeg/trunk
The 8 bits offset (nal unit type) should not be added, as the spec says:
"This bit offset is the offset within the RBSP data for the slice, relative
to the starting position of the slice_header() in the RBSP"
This fixes DXVA2 support for intel GPU.
Patch by Rafaël Carré (funman _AT_ videolan _DOT_ org).
Originally committed as revision 25538 to svn://svn.ffmpeg.org/ffmpeg/trunk
prediction (plus some with different rounding for svq3/rv40). Speedup (for
SSSE3) about ~6-fold, 3.6% faster overall with cathedral sample.
Originally committed as revision 25361 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes compilation with clang's builtin assembler
Patch by İsmail Dönmez, ismail at namtrac dot org
Originally committed as revision 25331 to svn://svn.ffmpeg.org/ffmpeg/trunk
that flag to the dca codec. This capability when set
will make sure the codec will initialize the channel
configuration instead of trusting the container. This
fixes issue 2137 and issue 850.
Originally committed as revision 25320 to svn://svn.ffmpeg.org/ffmpeg/trunk
bitstream endianness, so they cannot reuse the same code
without a lot of function call overhead.
Thus use templating to compile two different binaries.
Originally committed as revision 25312 to svn://svn.ffmpeg.org/ffmpeg/trunk
FRAPS appears to output PC range streams. I can't guarantee this is true of
all versions.
Originally committed as revision 25308 to svn://svn.ffmpeg.org/ffmpeg/trunk
(576i50 25Mbps 4:1:1 special case was wrong).
Fixes issue2211
Patch by Niobos, niobos dest-unreach be
Originally committed as revision 25269 to svn://svn.ffmpeg.org/ffmpeg/trunk
inline asm works for gcc-3.x also (hopefully). Should fix gcc-3.x FATE
breakage after r25254.
Originally committed as revision 25262 to svn://svn.ffmpeg.org/ffmpeg/trunk
increase to e.g. vc1, snow and mpeg decoding.
Patch by Eli Friedman <eli dot friedman gmail com>.
Originally committed as revision 25259 to svn://svn.ffmpeg.org/ffmpeg/trunk
That way the user app can set codec specific parameters in the private context
before opening it.
Originally committed as revision 25257 to svn://svn.ffmpeg.org/ffmpeg/trunk
from memory locations/offsets depending on b_idx plus constants, rather than
having gcc do this. This saves several lea calls and together saves about
10 cycles in h264_loop_filter_strength_mmx2().
Originally committed as revision 25256 to svn://svn.ffmpeg.org/ffmpeg/trunk
a pxor, or remove the instruction alltogether. Altogether, this saves 1
instruction.
Originally committed as revision 25255 to svn://svn.ffmpeg.org/ffmpeg/trunk
This has no measurable speed effect because the surrounding code doesn't
take advantage of this yet.
Originally committed as revision 25254 to svn://svn.ffmpeg.org/ffmpeg/trunk
of the d_idx variable and therefore allows for future optimizations. No speed
difference by this commit itself.
Originally committed as revision 25253 to svn://svn.ffmpeg.org/ffmpeg/trunk
inlining various constants within the loop code. 20 cycles faster on
cathedral sample.
Originally committed as revision 25252 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
It was being set wrong for files with data_offset > 0
Patch by Michael Chinen, mchinen gmail
Originally committed as revision 25239 to svn://svn.ffmpeg.org/ffmpeg/trunk
inlines scan8[] and removes loop setup. 15% faster, 0.4% overall.
See "[PATCH] unroll loop in h264_idct_add8_sse2()" thread on ML.
Originally committed as revision 25172 to svn://svn.ffmpeg.org/ffmpeg/trunk
code directly also and remove loop setup. 20% faster in function, 0.8% overall.
See "[PATCH] unroll loop in h264_idct_add8_sse2()" thread on ML.
Originally committed as revision 25171 to svn://svn.ffmpeg.org/ffmpeg/trunk
but it used to do it only for h264 codec.
Allow it for other codecs, as mpeg2 and mpeg4 also set this flag.
Originally committed as revision 25156 to svn://svn.ffmpeg.org/ffmpeg/trunk
Apparently Apple platforms do not handle movw/movt relocations
properly, leading to runtime crashes in code using them.
Originally committed as revision 25150 to svn://svn.ffmpeg.org/ffmpeg/trunk
which will hopefully solve the Win64/FATE failures caused by these functions.
Originally committed as revision 25137 to svn://svn.ffmpeg.org/ffmpeg/trunk
have been accepted before).
Also do not fail if they are invalid but instead override them to 0.
This allows decoding e.g. MPEG video when only the container values are corrupted.
For encoding a value of 0,0 of course makes no sense, but was allowed
through before and will be caught by an extra check in the encode function.
Originally committed as revision 25124 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
Original patch by Zhou Zongyi, zhouzy A os pku edu cn, resubmitted by
James Darnley, james.darnley gmail, changes by me.
Originally committed as revision 25115 to svn://svn.ffmpeg.org/ffmpeg/trunk
For a PCE based configuration map the channels solely based on tags.
For an indexed configuration map the channels solely based on position.
This works with all known exotic samples including al17, elem_id0, bad_concat,
and lfe_is_sce.
Originally committed as revision 25098 to svn://svn.ffmpeg.org/ffmpeg/trunk
case the stride must be aligned to a multiple of 4.
The original CSCD encoder just compresses bitmaps it gets via Windows
API functions as-is, thus it uses exactly those alignment rules.
Originally committed as revision 25096 to svn://svn.ffmpeg.org/ffmpeg/trunk
mm_support instead.
Fix compilation if altivec is present and libxvidff.c is compiled.
Originally committed as revision 25075 to svn://svn.ffmpeg.org/ffmpeg/trunk
mm_support() instead.
Reduce complexity and simplify pending move to libavutil.
Originally committed as revision 25074 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes a black line in non-swapped, non-mod-16-height Theora videos
when vp3_draw_horiz_band is used.
Originally committed as revision 25073 to svn://svn.ffmpeg.org/ffmpeg/trunk
Using floating-point here can cause erroneous rejection of
parameters due to rounding errors leading to a slightly too
large result.
This fixes the mxf regression test with gcc 4.5 on x86_32.
Originally committed as revision 25060 to svn://svn.ffmpeg.org/ffmpeg/trunk
that result in overdrawing areas again and again if s->flipped_image
is false.
Originally committed as revision 25051 to svn://svn.ffmpeg.org/ffmpeg/trunk
The #ifndef is required to allow for example some automated regression
tests by simply configuring with: --extra-cflags="-DFF_API_FOO=0".
Originally committed as revision 25043 to svn://svn.ffmpeg.org/ffmpeg/trunk
This increases compatibilty with nasm and is also more consistent,
e.g. with h264_intrapred.asm and h264_chromamc.asm that already
do it that way.
Originally committed as revision 25042 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes building with --disable-everything --enable-muxer=rtp, closing
issue 2159.
Originally committed as revision 25036 to svn://svn.ffmpeg.org/ffmpeg/trunk
format), LGPL'ed with permission from Jason and Loren. This includes mmx2
code, so remove inline asm from h264dsp_mmx.c accordingly.
Originally committed as revision 25031 to svn://svn.ffmpeg.org/ffmpeg/trunk
biweight code to sse2/ssse3; add sse2 weight code; and use that same code to
create mmx2 functions also, so that the inline asm in h264dsp_mmx.c can be
removed. OK'ed by Jason on IRC.
Originally committed as revision 25019 to svn://svn.ffmpeg.org/ffmpeg/trunk
still #included in dsputil_mmx.c and is part of DSPContext, and h264dsp_mmx.c,
which represents H264DSPContext and is now compiled on its own.
Originally committed as revision 25018 to svn://svn.ffmpeg.org/ffmpeg/trunk
uint16_fast_t is unsigned int (or long) on Linux, which when compared
with int results in an unsigned compare.
Originally committed as revision 24994 to svn://svn.ffmpeg.org/ffmpeg/trunk
into its own file, it doesn't belong in h264dsp_mmx.c (much less so in
dsputil_mmx.c).
Originally committed as revision 24990 to svn://svn.ffmpeg.org/ffmpeg/trunk
This removes duplicated definitions of 8x8 and 16x16 fullpel MC
functions with various names reducing dsputil.o by 8k on x86_64.
Originally committed as revision 24933 to svn://svn.ffmpeg.org/ffmpeg/trunk
The stride can be negative and must be sign extended before being
used in pointer arithmetic.
Originally committed as revision 24926 to svn://svn.ffmpeg.org/ffmpeg/trunk
Because the order of evaluation of subexpressions is undefined, two
get_bits() calls may not be part of the same expression.
See also r24902.
Originally committed as revision 24906 to svn://svn.ffmpeg.org/ffmpeg/trunk
Because the order of evaluation of subexpressions is undefined, two
get_bits() calls may not be part of the same expression. In this
specific case, using get_bits_long() is simpler.
This fixes msmpeg4v1 decoding with armcc.
Originally committed as revision 24902 to svn://svn.ffmpeg.org/ffmpeg/trunk
This performs quite a bit better than the current 3GPP-inspired window decision
on all the samples I have tested. On the castanets.wav sample it performs very
similar to iTunes window selection, and seems to perform better than Nero.
On fatboy.wav, it seems to perform at least as good as iTunes, if not better.
Nero performs horribly on this sample.
Patch by: Nathan Caldwell <saintdev@gmail.com>
Originally committed as revision 24892 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows cleaner implementation of other psymodels using the existing
structs. It also will make it easier to interchange individual parts of
the psymodel to create hybrid models.
Patch by: Nathan Caldwell <saintdev@gmail.com>
Originally committed as revision 24890 to svn://svn.ffmpeg.org/ffmpeg/trunk
This is to avoid split asm sections that attempt to preserve some
registers between sections.
Originally committed as revision 24869 to svn://svn.ffmpeg.org/ffmpeg/trunk
since all of it ends up in a single 32-bit pixel.
This seems likely to be wrong though, since it is different
from the 15 and 16 bit modes and might explain the half-width
issue for 24 bit truemotion.
Originally committed as revision 24864 to svn://svn.ffmpeg.org/ffmpeg/trunk
BGR32 and not BGR24, do not swap red and blue on big-endian
for this format as well.
Originally committed as revision 24863 to svn://svn.ffmpeg.org/ffmpeg/trunk
The relevent extract of the iso 13818-2 about the value of the syntaxical
element top_field_first of the Picture Coding Extension is:
"top_field_first -- The meaning of this element depends upon picture_structure,
progressive_sequence and repeat_first_field.
[...]
In a field picture top_field_first shall have the value '0', and the only field
output by the decoding process is the decoded field picture."
Originally committed as revision 24853 to svn://svn.ffmpeg.org/ffmpeg/trunk
Conversion of an out of range float to int is undefined. Clipping to
the final range first avoids such problems. This fixes decoding on
MIPS, which handles these conversions differently from many other CPUs.
Originally committed as revision 24838 to svn://svn.ffmpeg.org/ffmpeg/trunk
ff_get_plane_bytewidth().
The new implementation is more generic, more compact and more correct.
Originally committed as revision 24786 to svn://svn.ffmpeg.org/ffmpeg/trunk
Grab from the bitstream in 16-bit chunks instead of 8-bit chunks.
TODO: grab in 32-bit chunks on 64-bit systems.
Originally committed as revision 24783 to svn://svn.ffmpeg.org/ffmpeg/trunk
wrapper of it.
The new function is more generic, and does not depend on the
definition of the AVPicture struct.
Patch by S.N. Hemanth Meenakshisundaram s + "meenakshisundaram".substr(0, 7) + "@ucsd.edu".
Originally committed as revision 24768 to svn://svn.ffmpeg.org/ffmpeg/trunk
correct mb_xy to use mb_width.
tighten allocations.
reduce the amount of zeroing.
Originally committed as revision 24760 to svn://svn.ffmpeg.org/ffmpeg/trunk
two padding zeroes before it. Should fix fate failures on openBSD and crashes
on MacOSX (that I cannot reproduce).
Originally committed as revision 24750 to svn://svn.ffmpeg.org/ffmpeg/trunk
Many H.264 derivatives, like RV40 and VP8, use the H.264 prediction functions
but not the weight/loopfilter functions.
This should reduce the size of builds with one of these derivatives but without
H.264 decoding itself.
Originally committed as revision 24741 to svn://svn.ffmpeg.org/ffmpeg/trunk
including libavcore/imgutils.h, which was required since the recent
avcodec_check_dimensions() -> av_check_image_size() transition.
Originally committed as revision 24734 to svn://svn.ffmpeg.org/ffmpeg/trunk
When sizeof(uint_fast8_t) >= sizeof(int) there are unintended size effects.
Originally committed as revision 24716 to svn://svn.ffmpeg.org/ffmpeg/trunk
Create a custom table for VP5/6/8's renorm to avoid depending on H.264's.
Saves one instruction in the arithmetic decoder as well.
Originally committed as revision 24701 to svn://svn.ffmpeg.org/ffmpeg/trunk
This reverts rev 24674 - the VP8 decoder actually depends on cabac.o.
vp8.c includes vp56.h, which includes cabac.h, which has inline functions
that reference tables from cabac.c.
This fixes compilation with --disable-everything --enable-decoder=vp8.
Originally committed as revision 24692 to svn://svn.ffmpeg.org/ffmpeg/trunk
Always inline the arithmetic coder, except in the case of header-parsing stuff,
in which case don't inline it at all to save code size.
Originally committed as revision 24677 to svn://svn.ffmpeg.org/ffmpeg/trunk
If sizeof uint_fast8_t > 1 and sizeof size_t <= 4, the expression that mallocs
classifs is susceptible to integer overflow.
Originally committed as revision 24675 to svn://svn.ffmpeg.org/ffmpeg/trunk
A lot of the time the DC block is empty: don't do the WHT in this case.
A lot of the rest of the time, there's only one coefficient: make a special
DC-only transform for that case.
When the block is empty, don't incorrectly mark luma DCT blocks as having DC
coefficients.
Originally committed as revision 24670 to svn://svn.ffmpeg.org/ffmpeg/trunk
Lets us do the zeroing in asm instead of C.
Also makes it consistent with the way the regular iDCT code does it.
Originally committed as revision 24668 to svn://svn.ffmpeg.org/ffmpeg/trunk
