GNOME Bugzilla – Bug 667559
h264parse: wrong durationg calculation of outgoing buffers
Last modified: 2018-11-03 13:10:19 UTC
I only get a single, weird frame with this clip: http://samples.mplayerhq.hu/V-codecs/h264/last_samurai.ts Using a videosink with sync=false gives the correct output
Hmm.... the file doesn't contain PTS/DTS in all PES headers, but only once every few frames. As a result it sets the previously known valid pts on the outgoing frame. This should be handled more gracefully. Ideally by not setting a buffer timestamp when we don't have a pts
Even if we only set PTS/DTS on tsdemux output buffers when it's valid, it will still fail downstream. Either h264parse, or GstVideoDecoder, needs to fill in missing PTS/DTS at some point
the file plays back with current master. Only remaining issue is some stuttering at playback. This is related to h264parse setting "wrong" durations on the outgoing parsed buffers. Changing bug title accordingly
Actually ... there's another way to fix this file issue. The mpeg-ts file contains these two descriptors for the video stream: [descriptor 0x02 (video-stream)] [descriptor 0x07 (target-background-grid)] The first one gives information about framerate and so forth, and ... surprise surprise ... it states that it's 25/1 fps, meaning we could set that on the demuxer outgoing pad caps and the problem would be solved. Note that the other descriptor would also solve the cropping issue.
Making this block against #659489 since this issue should theoretically be fixed once PTS/DTS handling is fixed.
FYI, this plays equally badly with VLC and ffplay
-- 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-bad/issues/57.