GNOME Bugzilla – Bug 720176
videodec: Wrong output PTS for streams with only DTS set on input
Last modified: 2018-11-03 11:27:05 UTC
Sample: http://dev.lemote.com/files/upload/software/temp/sample.rmvb 1. For gstreamer playback under linux/mac, the video is ahead of audio 2. Using other media players on windows, the playback is fine
Confirmed, moving to rmdemux for now.
Still an issue in master When playing with vlc, the video doesn't start immediately. There might be a field we're not parsing correctly.
The problem is actually in the videodecoder base class rmdemux *does* push the video frames with the proper timestamps: Parsing a packet for stream=1, timestamp=0:00:02.466000000, size 1328, version=0, ts=2466 The video decoder gets properly timestamped buffers (note: DTS is set, not PTS): :gst_video_decoder_chain:<avdec_rv40-0> chain PTS 99:99:99.999999999, DTS 0:00:02.466000000 duration 99:99:99.999999999 size 81293 :gst_video_decoder_chain:<avdec_rv40-0> chain PTS 99:99:99.999999999, DTS 0:00:02.633000000 duration 99:99:99.999999999 size 24174 :gst_video_decoder_chain:<avdec_rv40-0> chain PTS 99:99:99.999999999, DTS 0:00:02.634000000 duration 99:99:99.999999999 size 1774 But the video decoder base class does a wrong guess: :gst_video_decoder_prepare_finish_frame:<avdec_rv40-0> finish frame 0x7f05901cb400 (#0) sync:1 PTS:99:99:99.999999999 DTS:0:00:02.466000000 :gst_video_decoder_prepare_finish_frame:<avdec_rv40-0> Guessing duration 0:00:00.041708405 for frame... :gst_video_decoder_prepare_finish_frame:<avdec_rv40-0> Guessing timestamp 0:00:00.000000000 for frame...
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/98.