FFmpeg

110330 Commits

37 Branches

400 Tags

476 MiB

Tag: Branch: Tree: af286f17a1

Commit Graph

Author	SHA1	Message	Date
Anton Khirnov	cea71b2139	fftools/ffmpeg: stop using fake dts for generating timestamps When no packet dts values are available from the container, video decoding code will currently use its own guessed values, which will then be propagated to pkt_dts on decoded frames and used as pts in certain cases. This is inaccurate, fragile, and unnecessarily convoluted. Simply removing this allows the extrapolation code introduced in the previous commit to do a better job. Changes the results of numerous h264 and hevc FATE tests, where no spurious timestamp gaps are generated anymore. Several tests no longer need -vsync passthrough.	2 years ago
Anton Khirnov	5d407cb2d7	fftools/ffmpeg: change video decoding timestamp generation When no timestamps are available from the container, the video decoding code will currently use fake dts values - generated in process_input_packet() based on a combination of information from the decoder and the parser (obtained via the demuxer) - to generate timestamps during decoder flushing. This is fragile, hard to follow, and unnecessarily convoluted, since more reliable information can be obtained directly from post-decoding values. The new code keeps track of the last decoded frame pts and estimates its duration based on a number of heuristics. Timestamps generated when both pts and pkt_dts are missing are then simple pts+duration of the last frame. The heuristics are somewhat complicated by the fact that lavf insists on making up packet timestamps based on its highly incomplete information. That should be removed in the future, allowing to further simplify this code. The results of the following tests change: * h264-3386 now requires -fps_mode passthrough to avoid dropping frames at the end; this is a pathology of the interaction of the new and old code, and the fact that the sample switches from field to frame coding in the last packet, and will be fixed in following commits * hevc-conformance-DELTAQP_A_BRCM_4 stops inventing an arbitrary timestamp gap at the end * hevc-small422chroma - the single frame output by this test now has a timestamp of 0, rather than an arbitrary 7	2 years ago
Michael Niedermayer	07f5e75a47	tests/fate: Add test for ticket 3386 ([H264] [Regression] illegal short term buffer state detected) Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>	9 years ago

Author

SHA1

Message

Date

Anton Khirnov

cea71b2139

fftools/ffmpeg: stop using fake dts for generating timestamps

When no packet dts values are available from the container, video
decoding code will currently use its own guessed values, which will then
be propagated to pkt_dts on decoded frames and used as pts in certain
cases. This is inaccurate, fragile, and unnecessarily convoluted.
Simply removing this allows the extrapolation code introduced in the
previous commit to do a better job.

Changes the results of numerous h264 and hevc FATE tests, where no
spurious timestamp gaps are generated anymore. Several tests no longer
need -vsync passthrough.

2 years ago

Anton Khirnov

5d407cb2d7

fftools/ffmpeg: change video decoding timestamp generation

When no timestamps are available from the container, the video decoding
code will currently use fake dts values - generated in
process_input_packet() based on a combination of information from the
decoder and the parser (obtained via the demuxer) - to generate
timestamps during decoder flushing. This is fragile, hard to follow, and
unnecessarily convoluted, since more reliable information can be
obtained directly from post-decoding values.

The new code keeps track of the last decoded frame pts and estimates its
duration based on a number of heuristics. Timestamps generated when both
pts and pkt_dts are missing are then simple pts+duration of the last frame.
The heuristics are somewhat complicated by the fact that lavf insists on
making up packet timestamps based on its highly incomplete information.
That should be removed in the future, allowing to further simplify this
code.

The results of the following tests change:
* h264-3386 now requires -fps_mode passthrough to avoid dropping frames
  at the end; this is a pathology of the interaction of the new and old
  code, and the fact that the sample switches from field to frame coding
  in the last packet, and will be fixed in following commits
* hevc-conformance-DELTAQP_A_BRCM_4 stops inventing an arbitrary
  timestamp gap at the end
* hevc-small422chroma - the single frame output by this test now has a
  timestamp of 0, rather than an arbitrary 7

2 years ago

Michael Niedermayer

07f5e75a47

tests/fate: Add test for ticket 3386 ([H264] [Regression] illegal short term buffer state detected)

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

9 years ago

3 Commits (af286f17a1c79b6d543c586cf020d08d4e84f0eb)