Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

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*	1 year ago
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.	2 years ago
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.	4 years ago
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>	7 years ago
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>	7 years ago