This fixes a memory leak occurring when no cue points are defined
since commit 91819763.
Signed-off-by: NMans Rullgard <mans@mansr.com>

This reverts commit f8bed30d. 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.

Add an extra size validity check in asf_read_frame_header(). Without
this asf->packet_size_left may become negative, which triggers an
assertion failure later.
Signed-off-by: NRonald S. Bultje <rsbultje@gmail.com>

Signed-off-by: NRonald S. Bultje <rsbultje@gmail.com>

The patch is the first step to support -dcodec copy

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: NAnton Khirnov <anton@khirnov.net>

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

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

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

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: NMichael 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.

This works around a possibly exploitable crash.
Appearently, vlc can be exploited with a malicous file. This should get
reverted as soon as a proper fix is found.

Reported-at: Thu, 21 Apr 2011 14:38:25 +0000
Reported-by: NDominic Chell <Dominic.Chell@ngssecure.com>
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 89f903b3)
(cherry picked from commit 9b919571e506fbb72b81a35ca1e7c1bd6efc4209)

As per issue2629, most 23.976fps matroska H.264 files are incorrectly
detected as 24fps, as the matroska timestamps usually have only
millisecond precision.

Fix that by doubling the amount of timestamps inspected for frame rate
for streams that have coarse time base. This also fixes 29.970 detection
in matroska.
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 78431098)

Tested with mplayer based on this report
http://thread.gmane.org/gmane.comp.video.mplayer.user/66043/focus=66063Signed-off-by: NReinhard Tartler <siretart@tauware.de>