FFmpeg

110346 Commits

37 Branches

400 Tags

484 MiB

Tag: Branch: Tree: 95a78c08c1

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
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
Anton Khirnov	ba4b73c977	lavf/rawdec: set avg_frame_rate Timestamps in two FATE H.264 conformance tests now start at 1 instead of 0, which also happens in some other H.264 tests before this commit and so is not a big issue. Conversely, timestamps in some HEVC conformance tests start from a smaller value now. Ideally this should be addressed later in a more general way. h264-conformance-frext-frext2_panasonic_b no longer requires -vsync passthrough.	2 years ago
Michael Niedermayer	6939174bfc	tests/fate/hevc: Add test for `3fbf873792` Tested-on: x86-32/64/ARM/MIPS Linux, Mingw/WINE 32/64 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>	4 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

Anton Khirnov

ba4b73c977

lavf/rawdec: set avg_frame_rate

Timestamps in two FATE H.264 conformance tests now start at 1 instead
of 0, which also happens in some other H.264 tests before this commit
and so is not a big issue.
Conversely, timestamps in some HEVC conformance tests start from a
smaller value now.
Ideally this should be addressed later in a more general way.

h264-conformance-frext-frext2_panasonic_b no longer requires -vsync
passthrough.

2 years ago

Michael Niedermayer

6939174bfc

tests/fate/hevc: Add test for 3fbf873792

Tested-on: x86-32/64/ARM/MIPS Linux, Mingw/WINE 32/64
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

4 years ago

3 Commits (95a78c08c17b73a50ad64c1b82e47970a3f2bc41)