While a 25 fps stream can in general store frame durations in 1/25
units, this is not true for the timestamps. For example a 25fps
and a 25000/1001 fps stream when they are stored together might have
a matching 0 timestamp point but when for example a chapter from
this is cut the new start is no longer aligned. The issue gets
MUCH worse when the streams are lower fps, like 1 or 2 fps.

This commit thus makes the muxer choose a multiple of the
framerate as timebase that is at least about 20 micro seconds precise
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

With this, when we use a finer timebase than neccessary to store
durations the demuxer still knows what the original timebase was.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This way audio frames can be exactly stored even when they are not
aligned with timestamp 0
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Silence a GCC warning. A leftover of the disabled version is still
available in lavf/isom.c.

This needs to be accessible for libavfilter in the next commit.

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

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

* qatar/master:
  avcodec: Convert some commented-out printf/av_log instances to av_dlog
  avcodec: Drop silly and/or broken printf debug output
  avcodec: Drop some silly commented-out av_log() invocations
  avformat: Convert some commented-out printf/av_log instances to av_dlog
  avformat: Remove non-compiling and/or silly commented-out printf/av_log statements
  Remove some silly disabled code.
  ac3dec: ensure get_buffer() gets a buffer for the correct number of channels

Conflicts:
	libavcodec/dnxhddec.c
	libavcodec/ffv1.c
	libavcodec/h264.c
	libavcodec/h264_parser.c
	libavcodec/mjpegdec.c
	libavcodec/motion_est_template.c
	libavcodec/mpegaudiodec.c
	libavcodec/mpegvideo_enc.c
	libavcodec/put_bits.h
	libavcodec/ratecontrol.c
	libavcodec/wmaenc.c
	libavdevice/timefilter.c
	libavformat/asfdec.c
	libavformat/avidec.c
	libavformat/avienc.c
	libavformat/flvenc.c
	libavformat/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

If there is an error during frame parsing, but AVCodecContext.channels was
changed and AC3DecodeContext.out_channels was set previously, the two may not
match.

Fixes CVE-2012-2802
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind

CC: libav-stable@libav.org

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

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

It never belonged to swscale_unscaled.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

qt-faststart is terribly slow when the input file and the output file
are on a slow disk like a SD card. By increasing the copy_buffer from
1K to 32M I decreased the processing time on a sample file from
1600 seconds to 4 seconds. The timing difference is during 'copying
rest of file'.

S:\SD_VIDEO\PRG001>e:\utils\qt-faststart 00005.mp4 5.mp4
ftyp          0 32
free         32 8
mdat         40 13744391
moov   13744431 141848
 patching stco atom...
 patching stco atom...
 writing ftyp atom...
 writing moov atom...
 copying rest of file...

Execution time: 1576.259 s

S:\SD_VIDEO\PRG001>s:\utils\qt-faststart 00005.mp4 5.mp4
ftyp          0 32
free         32 8
mdat         40 13744391
moov   13744431 141848
 patching stco atom...
 patching stco atom...
 writing ftyp atom...
 writing moov atom...
 copying rest of file...

Execution time: 3.846 s
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

iv decrypt handling code needs to be executed regardless of CONFIG_SMALL
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This fix a bunch of "assignment from incompatible pointer type" warnings
with GCC.

Also fix some dates (use the commit date instead of the author date).

Note that a lavf bump was missing so I'm using 54.28.100 as a reference.

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

this simplifies things are avoids a temporary
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Based on test code by: Giorgio Vazzana <mywing81@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

In CBC mode, when src=dst and we are decrypting a block different
from the first one, we need to save the current block of ciphertext
(which will constitute the initialization vector for the next block)
before we overwrite it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

Found in http://www.makemkv.com/download/ffmpeg/mmffmpeg-1.7.7.patch.gz

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