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>
While quality is bad, PAL8 support is needed to allow testing some
encoders that only support PAL8 input.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* qatar/master:
id3v2: fix doxy comment - 'machine byte order' makes no sense on char arrays
VC1: restore mistakenly removed code
twinvq: check output buffer size before decoding
twinvq: return an error when the packet size is too small
lavf: export some forgotten symbols with non-av prefixes.
swscale: update altivec yuv2planeX asm to new per-plane API.
swscale: make yuv2yuvX_10_sse2/avx 8/9/16-bits aware.
yuv2planeX10 SIMD
swscale: decide whether to use yuv2plane1/X on a per-plane basis.
swscale: reintroduce full precision in 16-bit output.
Split up yuv2yuvX functions
Split out yuv2yuv1 luma and chroma in order to make them generic DSP functions
lavc: replace references to deprecated AVCodecContext.error_recognition to use AVCodecContext.err_recognition
lavc: translate non-flag-based er options into flag-based ef options at codec open
add -err_filter AVOptions to access flag-based error recognition
h264_weight: initialize "height" function argument properly.
presets: spelling error in libvpx 1080p50_60
avplay: fix fullscreen behaviour with SDL 1.2.14 on Mac OS X
Conflicts:
ffplay.c
libavformat/libavformat.v
libswscale/swscale.c
libswscale/x86/swscale_template.c
tests/ref/lavfi/pixfmts_scale
Merged-by: Michael Niedermayer <michaelni@gmx.at>
We operated on 31-bits, but with e.g. lanczos scaling, values can
add up to beyond 0x80000000, thus leading to output of zeroes. Drop
one bit of precision fixes this.
