After making some blind tests on a small collection of music
samples for home usage. It turned out that the default cutoff
was too low.
The impact of filter_size was not clearly distinguishable (the
results were on the edge) with the music samples but turned out
to be clearly audible in some synthetic samples.
Thanks to Daniel for helping out with the listening tests.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
It is broken, and results will be messed up when seeking.
This also fix duration displayed for streams when using -c copy.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Without this exception files with ".gif" extension by default
recognized as input suitable for image2 demuxer rather than gif.
In order to pass image through gif demuxer it was necessary
to use -f gif option.
This change affected 'make fate' test results because previously
image2 demuxer and gif decoder took only first frame of multiframe
test data, which is no longer true with gif demuxer.
Signed-off-by: Vitaliy E Sugrobov <vsugrob@hotmail.com>
Currently FFM files generated with one versions of ffmpeg generally
cannot be read by another.
By spliting data into chunks, more fields can saftely be appended to
chunks as well as new chunks added.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes playback in some circumstances (like webm in firefox).
Regression after 2c34367b.
It is also matching the Matroska specifications:
http://matroska.org/technical/specs/notes.html, "The quick eye will
notice that if a Cluster's Timecode is set to zero, it is possible to
have Blocks with a negative Raw Timecode. Blocks with a negative Raw
Timecode are not valid."
The timebases before where only guranteed to be 1/fps precisse
and could cause AV sync errors on low fps
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
Also factorize the common options for the different mov-based tests.
Since the header is now on top in the last generated file, the data
offset in the seek test needed some updates as well.
This is consistent with stdio and is what we want to do in all cases.
Fixes a bug in the voc muxer which didn't flush in write_trailer()
previously. This is the cause of the change in the test results.
Rewrite 10 bit dpx decoder to decode into GBRP10 color space
instead of converting to RGB48.
Add 12 bit decoder to decode into GBRP12 color space.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes Ticket1627
The fate change is due to ffmpeg no longer pushing audio timestamps
aggressively up (which is what caused the AV sync issues in the ticket)
but leaving them as they are.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This commit is based on libav's implementation and
makes sure to compare output timestamps together.
It also reduces the differences with avconv.
The changes to the test reference files are caused
by an additional packet at the end, the timestamp
of the frame encoded by this packet is always
strictly below the limit stated by the -t option.
Paul B Mahol
Carl Eugen Hoyos
内田佳久
Michael Niedermayer
Alexander Strasser
Piotr Bandurski
James Almer
Vitaliy E Sugrobov
Matthieu Bouron
Peter Ross
Tomas Härdin
Victor Vasiliev
Clément Bœsch
Justin Ruggles
Anton Khirnov
Georg Lippitsch
Nicolas George
Alex Converse