This way we don't require a clearly defined corresponding input stream.
The result for the xwd test changes because rgb24 is now chosen instead
of bgra.
Otherwise for muxers like e.g. latmenc that never call
avio_flush (and do not have a write_trailer function)
a part of the data will always be missing.
Also update references for the voc muxer, which was also
buggy before and did not write out all data.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Decode output must be converted to rgb24 to avoid CRC difference
due to palette being stored in machine endianness.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
With this we can always know if a timestamp is based on added durations
from an unknown origin or if it is based on a correct timestamp (and possibly
added durations)
This should fix some bugs where this distinction was mixed up.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is so that TS fragments produced by
http://code.google.com/p/httpsegmenter/
would be compatible with JW Player.
A new member variable prev_payload_key was added to MpegTSWriteStream
to help detect transition from non-key to key frame, so that
PAT/PMT would not be produced for every keyframe in intra-only videos.
Signed-off-by: Pavel Koshevoy <pkoshevoy@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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.
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.
The qatar implementation makes no sense.
a muxer without timestamps is constant fps thus needs vsync.
the crc/mp5 are special cases that have timestamps yet allow any
nonsensical timestamps.
raw (yuv/rgb) video is constant fps thus needs vsync too.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
Justin Ruggles
Michael Niedermayer
Anton Khirnov
Reimar Döffinger
Ramiro Polla
Vidar Madsen
Paul B Mahol
Derek Buitenhuis
Martin Storsjö
Carl Eugen Hoyos
Pavel Koshevoy
Clément Bœsch
Matthieu Bouron
Diego Biurrun
John Brooks