It is not supposed to be done outside lavc.
This is basically a revert of 818062f2f3.
It is unclear what issue this was supposed to fix, if it reappears again
it will have to be fixed in a more proper place.
The wtv-demux test change is because the sample starts with a B-frame.
According to unofficial documentation, the video rate is locked to the audio
sample rate. This results in proper synchronization of audio and video
timestamps from the demuxer. This only works if the first audio packet occurs
before the first video packet or the audio sample rate is the default rate of
11111 Hz, both of which are true for all samples in our archive.
Update FATE reference to account for now non-existent palette packet.
This also fixes the FATE test if frame data is not initialized in
get_buffer(), so update comment in avconv accordingly.
This changes a number of FATE results, since before this commit, the
timestamps in all tests using rawenc were made up by lavf.
In most cases, the previous timestamps were completely bogus.
In some other cases -- raw formats, mostly h264 -- the new timestamps
are bogus as well. The only difference is that timestamps invented by
the muxer are replaced by timestamps invented by the demuxer.
cscd -- avconv sets output codec timebase from r_frame_rate
and r_frame_rate is in this case some guessed number 31.42 (377/12),
which is not accurate enough to represent all timestamps. This results
in some frames having duplicate pts. Therefore, vsync 0 needs to be
changed to vsync 2 and avconv drops two frames. A proper fix in the
future would be to set output timebase to something saner in avconv.
nuv -- previous timestamps for video were wrong AND the cscd
comment applies, one frame is dropped.
vp8-signbias -- the file contains two frames with identical timestamps,
so -vsync 0 needs to be removed/changed to -vsync 2 and avconv drops one
frame.
vc1-ism -- apparrently either the demuxer lies about timestamps or the
file is broken, since dts == pts on all packets, but reordering clearly
takes place.
Current code compares the desired recording time with InputStream.pts,
which has a very unclear meaning. Change the code to use actual
timestamps of the frames passed to the encoder.
In several tests, one less frame is encoded, which is more correct.
In the idroq test one more frame is encoded, which is again more
correct.
Behavior with stream copy should be unchanged.
The output is obviously not supposed to contain video (since only
-acodec copy is specified), but that only happens because of the way -t
handling is implemented currently.
Right now those muxers use the default timebase in all cases(1/90000).
This patch avoid unnecessary rescaling and makes the printed timestamps
more readable.
Also, extend the printed information to include the timebases and packet
pts/duration and align the columns.
Obviously changes the results of all fate tests which use those two
muxers.
Return the correct number of consumed bytes and set *data_size = 0.
Returned size is 1 too small, leading to that 1 byte being read as the next
frame, which results in an extra blank frame at the beginning of the stream.
get_ue_golomb_long() is only tested for values up to 2^15 - 2 since
we can not write larger values.
Silence the test on success and return a non-zero value on error.
Use an heap scratch buffer instead of large stack buffer.
Remove unneeded includes.
This uses the old demuxing code for OP1a and separate demuxing code for OPAtom.
Timestamp output is added to the old demuxing code.
The seeking code is made to seek to the start of the desired EditUnit only,
from which the normal demuxing code takes over (if OP1a). This means we
do not use delta entries or slices, only StreamOffsets. OPAtom seeking
basically works like before.
This also makes D-10 seeking behave the same way as OP1a and OPAtom. In other
words, we allow seeking before the start or past the end for D-10 too.
Based on several patches by Tomas Härdin <tomas.hardin@codemill.se> and
Reimar Döffinger <Reimar.Doeffinger@gmx.de>.
Changed av_calloc to av_mallocz, added overflow checks.
(Does not attempt to decode percetual audio data inside.)
Code coverage: libavformat/xwma.c: 3% -> 75%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(Don't attempt to decode JPEG data.)
Code coverage: libavformat/smjpeg.c: 0% -> 69%
libavcodec/adpcm.c: 0% -> 10% (fresh run); 92.4% -> 93% following a FATE run
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The previous sample used for this test only contained type 0 frames.
Replace it with a sample that also features type 1 frames.
Code coverage:
libavcodec/xxan.c: 72% -> 89%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Palette is as supposed in native endianness. Converting the pal8 output
to rgb24 is thus necessary for identical CRCs on big and little endian
systems.
Some libavifilter tests use NUT as output even if the produced
files were not decodable. The support for 10bit introduced in
432f0e5b7d and 91b1e6f0c changed the hashes.
The sample has an incomplete last frame. Decoding it is pointless.
The garbage produced was changed by the bitstream reader now
protecting against over-reads.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This patch is a generalization of what Michael Niedermayer
fixed in a single case.
The wmv8-drm fate test had been updated accordingly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Use Sound Sample Description Version 2 for all MOV files.
Updated FATE references accordingly.
Note that ADPCM is treated as compressed audio in version 2.
AVFMT_NOTIMESTAMPS for crc, as it ignores the timestamps.
AVFMT_VARIABLE_FPS for framecrc, as it prints dts.
Many FATE changes, because avconv is no longer duplicating frames in
those tests.
Also added -vsync 0 for some tests to prevent avconv from dropping
frames until it can be fixed more properly.
The Zork PCM decoder does not decode the 1 sample we have correctly, therefore
the encoder based on the decoder is also incorrect. There is no good reason to
keep the encoder.
enable CODEC_CAP_DELAY to flush any remaining frames in the buffer.
Stop decoding when the FN_QUIT command is found so that a trailing seek table
isn't decoded as a normal frame.
decode all channels in the same call to avcodec_decode_audio3() so that
decoding will not stop after the first channel of the last frame.
Updated FATE reference. More valid audio is now decoded.
The pixel format is not known until the frame header is parsed.
Guessing it here only causes trouble for the caller if the guess
turns out to be wrong (and actually causes very wrong output by
avconv/avplay).
Signed-off-by: Mans Rullgard <mans@mansr.com>
The cbSize field should be included in all cases, even with PCM where
its value is ignored.
Fixes encoding PCM audio in Matroska for some players which insist on
a full WAVEFORMATEX structure for A_MS/ACM audio.
Since fate uses wav files for the audio test a larger number of tests
has changed checksums or shifted positions due to the 2 byte longer
wave header.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
Makes the code less obfuscated and fixes encoding one video stream to
several outputs.
Also use avcodec_alloc_frame() instead of allocating AVFrame on stack.
Breaks me_threshold in avconv, as motion vectors aren't passed through
lavfi. They could be copied manually, but I don't think this misfeature
is useful enough to justify ugly hacks.
First, container stores only DTS and not PTS as it was believed.
Second, multiple frames in a packet store timestamp instead of position
after the frame length.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Old version divided it wrong, which resulted in chroma drift (visible on FATE
sample too as dirty trails left by clouds).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
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.
These tests create reference files used for psnr calculation in
the other codec tests. Treating them as (mostly) regular tests
simplifies the makefile and makes them visible in the fate reports.
The latter makes errors in these runs easier to identify.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Also remove code that overwrites the C versions of functions in
sws_init_swScale_altivec(), so that it uses the C functions of files
if no altivec-optimized version exists.
Fix handling of input if not in native endianness, and add support for
9/10-bit output. This allows us to force endianness of YUV420P 9/10bit
in the H264/10bit fate tests, which should fix them on big-endian
systems.
This should fix behavior introduced by commit
96573c0d76. Av_rescale_rnd() is not
lossless so if two timestamps are equal after being rescaled they are
not always actually identical. This patch use av_compare_ts() to get
always a correct result.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
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: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 78431098f9)
Tested with mplayer based on this report
http://thread.gmane.org/gmane.comp.video.mplayer.user/66043/focus=66063
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This makes the AC3 encoder use the shared fixed-point MDCT rather
than its own implementation. The checksum changes are due to
different rounding in the MDCT.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This updates the seek test reference to match de11ee9. Before this
change, most of the seeks requested positions before the supposed
start of the file (the preroll time), resulting in the first packet
being returned. With the preroll subtracted, some of these seeks
will land within the file and some beyond the end, thus returning
a different set of packets.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This increases the accuracy of coefficients, leading to improved quality.
Rescaling of the coefficients to full 25-bit accuracy is done rather than
offsetting the exponent values. This requires coefficient scaling to be done
before determining the rematrixing strategy. Also, the rematrixing strategy
calculation must use 64-bit math to prevent overflow due to the higher
precision coefficients.
The rematrixing strategy reuse flags are not reset between frames, so they
need to be initialized for all blocks, not just block 0.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This is to match the value in every (E-)AC-3 file from commercial sources.
It has a negligible effect on audio quality.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This patch changes the exponent difference threshold in the exponent
strategy decision function of the AC-3 encoder. I tested lowering in
increments of 100. From 1000 down to 500 generally increased in quality
with each step, but 400 was generally much worse.
Signed-off-by: Mans Rullgard <mans@mansr.com>
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.
This improves the audio quality significantly for stereo source with both the
fixed-point and floating-point AC-3 encoders.
Update acodec-ac3_fixed and seek-ac3_rm test references.
Originally committed as revision 26271 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixed-point AC-3 encoder renamed to ac3_fixed.
Regression test acodec-ac3 renamed to acodec-ac3_fixed.
Regression test lavf-rm changed to use ac3_fixed encoder.
Originally committed as revision 26209 to svn://svn.ffmpeg.org/ffmpeg/trunk
This gives slightly better quality in PEAQ tests.
Code 3 gives a dBpb value of 2816 = -132dB (128 psd units = -6dB), which
corresponds to 22 bits. Since the exponents have an offset applied, the
16-bit source looks like 24-bit source to the bit allocation routine.
So using dBpb code=3 is a closer match to the exponent range.
Regression test refs updated for acodec-ac3, lavf-rm, and seek-ac3_rm.
Originally committed as revision 26144 to svn://svn.ffmpeg.org/ffmpeg/trunk
This avoids a 16-bit overflow in mdct512() due to a -32768 value in costab.
References updated for acodec-ac3, lavf-rm, and seek-ac3_rm tests.
Thanks to Måns Rullgård for finding the bug.
Originally committed as revision 26071 to svn://svn.ffmpeg.org/ffmpeg/trunk
Turn it into 2 macros, and use av_clip_int16() and lrintf().
This matches the int16 to float sample conversion in audioconvert.c.
The regression test output is different due to lrintf() rounding.
Originally committed as revision 25956 to svn://svn.ffmpeg.org/ffmpeg/trunk
Seek test reference updated because FLAC seeking now works properly.
Fixes roundup issue 1150.
Patch by Michael Chinen [mchinen at gmail]
Originally committed as revision 25914 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes a scr issue reported with dvdauthor ([FFmpeg-user] FFMPEG encoded MPEG-2 video causes error in DVDAuthor)
Originally committed as revision 25512 to svn://svn.ffmpeg.org/ffmpeg/trunk
The rm demuxer has timestamp bugs, so this test is sensitive to changes in
timestamp correction. The previous commit did not make output any better or worse
on this test, just different.
See https://roundup.ffmpeg.org/issue2288 for details.
Originally committed as revision 25432 to svn://svn.ffmpeg.org/ffmpeg/trunk
and add a test for regular GSM as fate-gsm.
Fixes a 8kHz sample from issue 113.
Originally committed as revision 25313 to svn://svn.ffmpeg.org/ffmpeg/trunk
Increase readability and robustness, as the test result is not going
to differ if the order of the pixfmts codes changes.
Originally committed as revision 24665 to svn://svn.ffmpeg.org/ffmpeg/trunk
The corresponding lavfi-pixfmts BE tests are not yet added, as there
are some bugs in the scaler (scaling rgba, argb, bgra, abgr, yuva420p)
which result in differences with the LE reference, and I cannot
visually check the generated files on BE.
Originally committed as revision 24657 to svn://svn.ffmpeg.org/ffmpeg/trunk
This test verifies the pixdesc code by comparing the output with and
without a filter which should have no effect on the image. Since the
available pixel formats depend on the byte order of the machine, a
simple reference checksum is not possible.
The test originally tried to solve this by generating a reference file
on the fly. The problem with this is that the test framework expects
the reference file in the source tree, and writing to the source tree
is not allowed.
To avoid complicating the test framework, we instead provide two
reference files and select which to use based on the byte order.
Originally committed as revision 24330 to svn://svn.ffmpeg.org/ffmpeg/trunk
Log:
Add msmpeg4v1 regtest
Added:
trunk/tests/ref/fate/msmpeg4v1
Modified:
trunk/tests/fate2.mak
According to Mans, "make test" tests already msmpeg4v1.
Originally committed as revision 24260 to svn://svn.ffmpeg.org/ffmpeg/trunk
The byte count printed excludes the header, and offsets are applied
after the the headers are skipped.
Reference files updated to reflect new output. Some stddev/psnr values
have changed slightly due to headers no longer being compared.
Originally committed as revision 24143 to svn://svn.ffmpeg.org/ffmpeg/trunk
Regression test reference updates are due to the extra output
from tiny_psnr.
Patch by Vitor Sessak
Originally committed as revision 24132 to svn://svn.ffmpeg.org/ffmpeg/trunk
Author: bcoudurier
Date: Sat Jul 3 03:11:04 2010 +0000
Set graph swscale opts before parsing it, that way opts are available
when auto-adding scalers.
It changed the swscale flags used by the auto-added scalers, and so
the output video.
Originally committed as revision 24065 to svn://svn.ffmpeg.org/ffmpeg/trunk
Start them on keyframes when reasonable, and delay writing audio packets
to help ensure that there's audio samples available for the first frame in
clusters.
Patch by James Zern <jzern at google>
Originally committed as revision 23473 to svn://svn.ffmpeg.org/ffmpeg/trunk
This isn't exactly semantically equivalent, but the field has already been
long abused to mean this, and writing it helps in determining a decent cfr
time base when transcoding from a mkv where the video codec stores none (VP8).
Originally committed as revision 23284 to svn://svn.ffmpeg.org/ffmpeg/trunk
A patched version of ffmpeg supporting video filters is required for
getting this working; thus make lavfitest is supposed to work only in
the libavfilter repository for now.
Originally committed as revision 22586 to svn://svn.ffmpeg.org/ffmpeg/trunk
This adds a "fate" make target which runs the full FATE test suite.
Individual tests can be run with "make fate-$testname".
The location of the FATE test samples must be specified with the
--samples=PATH option to configure.
The tests/fate-update.sh script regenerates the references files and
test list from the online FATE database. These are checked in since
generating them requires non-standard tools.
Originally committed as revision 22552 to svn://svn.ffmpeg.org/ffmpeg/trunk
This takes into account whether the granule defines the start or end times
of packets, and sets the correct file offset of the associated page.
Originally committed as revision 22462 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise it gets set automatically to a page midstream and prevents seeking
to the first page.
Originally committed as revision 22454 to svn://svn.ffmpeg.org/ffmpeg/trunk
Seeking on image sequences doesn't actually work, so this
test isn't very useful until that capability is added.
Originally committed as revision 22286 to svn://svn.ffmpeg.org/ffmpeg/trunk
This test generates many output files, and keeping them separate
is convenient.
Originally committed as revision 22157 to svn://svn.ffmpeg.org/ffmpeg/trunk
This correct the stop point for demuxing with -vcodec copy and -t as well as
packet interleaving. (we already diddrop packets but kept demuxing them
for too long due to opts being wrong)
the change to ffm is due to 2 packets with timestamp 0 being stored
in different order.
Originally committed as revision 21626 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes at least ogg encoding with -t where the file was slightly too long.
Originally committed as revision 21598 to svn://svn.ffmpeg.org/ffmpeg/trunk
With this change, the output is checked immediately after each test
has run. This means commands like "make regtest-mpeg2" can now be
used to run a single test and get meaningful results.
By default, make will abort if any test fails. To run all tests
regardless, use make -k.
Originally committed as revision 21254 to svn://svn.ffmpeg.org/ffmpeg/trunk
