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>
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.
Instead of saving huge raw files, use the md5: output pseudo-protocol
to calculate the checksum of the file directly. This is especially
useful when testing on remote targets as it avoids transferring 3.6GB
over the network.
(cherry picked from commit f4b1e21a63)
Instead of saving huge raw files, use the md5: output pseudo-protocol
to calculate the checksum of the file directly. This is especially
useful when testing on remote targets as it avoids transferring 3.6GB
over the network.
Luca Barbato
Michael Niedermayer
Stefano Sabatini
Paul B Mahol
Reimar Döffinger
Ronald S. Bultje
Mans Rullgard
Peter Ross
Stefano Sabatini