5 Commits

Author SHA1 Message Date
Anton Khirnov
303f10d4dd fftools/ffmpeg_dec: disregard demuxer timestamps for NOTIMESTAMPS formats
In this case any timestamps are guessed by compute_pkt_fields() in
libavformat. Since we are decoding the stream, we have more accurate
information from the decoder and do not need any guesses.

Eliminates spurious PTS gaps in a number of FATE tests.

Also avoids dropping the majority of frames in fate-dirac*
2023-10-03 16:57:02 +02:00
Anton Khirnov
c17e33c058 fftools/ffmpeg: propagate frame durations to packets when encoding
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.
2023-04-19 21:12:03 +02:00
Anton Khirnov
36237ac4ee tests: stop using -vsync drop
It depends on the muxer generating the timestamps, which is deprecated
and scheduled for removal on next bump.

A bunch of tests change timestamps, because of ffmpeg.c is not
generating them correctly. This should be fixed later.
2020-12-10 09:53:52 +01:00
Nekopanda
f4d5d7e8de avcodec/mpeg2dec: Fix motion vector rounding for chroma components
In 16x8 motion compensation, for lower 16x8 region, the input to mpeg_motion() for motion_y was "motion_y + 16", which causes wrong rounding. For 4:2:0, chroma scaling for y is dividing by two and rounding toward zero. When motion_y < 0 and motion_y + 16 > 0, the rounding direction of "motion_y" and "motion_y + 16" is different and rounding "motion_y + 16" would be incorrect.

We should input "motion_y" as is to round correctly. I add "is_16x8" flag to do that.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2018-02-11 12:04:47 +01:00
Zhong Li
7e294a1f09 fate: add a test for mpeg2 issue of ticket #6677
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2017-10-25 00:18:41 +02:00