Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This reverts commit f8bed30d8b. The reason
for this is that the overlap filter, which runs after IDCT, should run
on unclamped values, and thus IDCT and put_pixels() cannot be merged if
we want to attempt to be bitexact.

lowres option crashes with wmv2 files which I have for test,
so I think it's better to remove the support to the time when
lowres will be really supported by this codec

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Many samples will fail because "Output buffer size is too small."

Many samples will fail because "Output buffer size is too small."

Do not use rlelen for buffer size in init_get_bits, it is
only the size of the data for the first field.
Since it is not reliable, just use the size of the whole buffer.
Additional comments add removal of unused rlelen variable by
Reimar Döffinger.

This means it uses full brightness range and brightness
increasing instead of decreasing with index of non-opaque
color.

Based on patch by Alexandre Colucci [alexandre elgato com]

Tested on a Mac Pro, 2 CPUs, 2 cores each, OSX 10.6.6:

time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \
  ~/Downloads/sintel_trailer_1080p_vp8_vorbis.webm \
  -f null -vcodec rawvideo -an -
1: 0m14.630s (89.9 fps)
2: 0m8.056s (163.2 fps)
3: 0m5.882s (223.6 fps)
4: 0m4.952s (265.6 fps)

time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \
  ~/Downloads/Elephants_Dream-720p-Stereo.webm \
  -f null -vcodec rawvideo -an -
1: 1m12.962s (215.1 fps)
2: 0m44.682s (351.2 fps)
3: 0m31.183s (503.2 fps)
4: 0m25.284s (620.6 fps)

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

10l to the one who hasn't checked this.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

int/unsigned is the natural memory access type for CPUs, using sized types
for temporary variables, counters and similar just increases code size and
can possibly cause a slowdown.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

av_assert2().

Although AC-3 allows it, it's not very useful. The encoder uses the same code
for all full-bandwidth channels.

It was only needed at low bitrates, which now already use a low bandwidth, so
the bandwidth reduction is no longer needed.

av_assert2().

This can occur in some very rare cases with low bitrates.

on exponent group sizes.

They use now code identical to the AAC decoder.
The AC3 decoder previously did not check the data_size and
the dca decoder checked against and set wrong values for float.

The sample aspect ratio is a per-frame property, so it makes sense to
define it in AVFrame rather than in the codec/stream context.
Simplify application-level sample aspect ratio information extraction,
and allow further simplifications.

This is similar to what was done with pkt_pts. This simplifies the
operation of extracting the pos information from the AVPacket, and
allows further simplifications.

flac.o implies vorbis_data.o because of flac channel layout.

This possibly fixes issue2679
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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.

This is more consistent with all the other codec names.

Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>

I still don't fully understand the cause but the difference between
the samples that trigger the bug and the samples that don't is
that the former uses delay frames and the later uses drop frames
as placeholders for the packed frame. So, if we see the one type
of frame, we can assume the bug will or won't be present.

Right now, I'm detecting the frame types by size, which may not be
safe in general, but given the specific codec and file type, I
expect any scenario where we encounter these frames where they
aren't being used for b-frame packing won't care one way or
another whether the work around is in effect or not.

Signed-off-by: Philip Langdale <philipl@overt.org>

Fix warning:
libavcodec/utils.c: At top level:
libavcodec/utils.c:714:5: warning: "FF_API_VIDEO_OLD" is not defined

Also fix trac issue #139.