r_frame_rate should in theory have something to do with input framerate,
but in practice it is often made up from thin air by lavf. So unless we
are targeting a constant output framerate, it's better to just use input
stream timebase.
Brings back dropped frames in nuv and cscd tests introduced in
cd1ad18a65
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.
(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.
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>
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.
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.
Anton Khirnov
Paul B Mahol
Justin Ruggles
Aneesh Dogra
Janne Grunau
Diego Biurrun
Alex Converse
Mike Melanson
Oana Stratulat
Mans Rullgard
Derek Buitenhuis
Luca Barbato
Martin Storsjö