Stop using InputStream.dts for generating missing timestamps for decoded frames, because it contains pre-decoding timestamps and there may be arbitrary amount of delay between input packets and output frames (e.g. dependent on the thread count when frame threading is used). It is also in AV_TIME_BASE (i.e. microseconds), which may introduce unnecessary rounding issues. New code maintains a timebase that is the inverse of the LCM of all the samplerates seen so far, and thus can accurately represent every audio sample. This timebase is used to generate missing timestamps after decoding. Changes the result of the following FATE tests * pcm_dvd-16-5.1-96000 * lavf-smjpeg * adpcm-ima-smjpeg In all of these the timestamps now better correspond to actual frame durations.
Remove now-obsolete code setting packet durations pre-muxing for CFR encoded video. Changes output in the following FATE tests: * numerous adpcm tests * ffmpeg-filter_complex_audio * lavf-asf * lavf-mkv * lavf-mkv_attachment * matroska-encoding-delay All of these change due to the fact that the output duration is now the actual input data duration and does not include padding added by the encoder. * apng-osample: less wrong packet durations are now passed to the muxer. They are not entirely correct, because the first frame duration should be 3 rather than 2. This is caused by the vsync code and should be addressed later, but this change is a step in the right direction. * tscc2-mov: last output frame has a duration of 11 rather than 1 - this corresponds to the duration actually returned by the demuxer. * film-cvid: video frame durations are now 2 rather than 1 - this corresponds to durations actually returned by the demuxer and matches the timestamps. * mpeg2-ticket6677: durations of some video frames are now 2 rather than 1 - this matches the timestamps.
Signed-off-by: James Almer <jamrial@gmail.com>
A non zero value is mandatory for Matroska if the track has blocks with BlockAdditions. Signed-off-by: James Almer <jamrial@gmail.com>
According to MXF specs the Stored Rectangle corresponds to the data which is passed to the compressor and received from the decompressor, so they should contain the width / height extended to the macroblock boundary. In practice however width and height values rounded to the upper 16 multiples are only seen when muxing MPEG formats. Therefore this patch changes stored width and height values to unrounded for all non-MPEG formats, even macroblock based ones. For DNXHD the specs (ST 2019-4) explicitly indicates to use 1080 for 1088p. For ProRes the specs (RDD 44) only refer to to ST 377-1 without precision but no known commercial implementations are using rounded values. DV is not using 16x16 macroblocks, so 16 rounding makes no sense. The patch also fixes Sampled Width / Display Width to use unrounded values. Signed-off-by: Marton Balint <cus@passwd.hu>
Commit 18f24527eb accidentally made side data only packets be handled like a flush request. Fix this regression by effectively ignoring them as was the original intention. Signed-off-by: James Almer <jamrial@gmail.com>
Some encoders, like flac, can send side data only packets at the end. Eventually, said extradata update should ideally be used to update the header when writting to seekable output, but for now, ignore them. Should fix the undefined behavior of passing NULL to memcpy(). Signed-off-by: James Almer <jamrial@gmail.com>
PFM (aka Portable FloatMap) encodes its scanlines from bottom-to-top, not from top-to-bottom, unlike other NetPBM formats. Without this patch, FFmpeg ignores this exception and decodes/encodes PFM images mirrored vertically from their proper orientation. For reference, see the NetPBM tool pfmtopam, which encodes a .pam from a .pfm, using the correct orientation (and which FFmpeg reads correctly). Also compare ffplay to magick display, which shows the correct orientation as well. See: http://www.pauldebevec.com/Research/HDR/PFM/ and see: https://netpbm.sourceforge.net/doc/pfm.html for descriptions of this image format. Signed-off-by: Leo Izen <leo.izen@gmail.com> Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: James Almer <jamrial@gmail.com>