[Bug 796962] h264parse: wrong DTS calculation when not provided by the stream
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Mon Sep 24 14:05:32 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=796962
Gaylord CHARLES <gaylord.charles at veo-labs.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gaylord.charles at veo-labs.co
| |m
--- Comment #3 from Gaylord CHARLES <gaylord.charles at veo-labs.com> ---
Created attachment 373745
--> https://bugzilla.gnome.org/attachment.cgi?id=373745&action=edit
Allow DTS from PTS infering even if PTS interpolation is disabled
Further analysis shows a possible problem with DTS/PTS inference in
gstbaseparse.c.
The first video frame is pushed with PTS = 0:00:02.518099556 and infered DTS =
0:00:00.000000000
0:00:00.530085680 LOG baseparse
gstbaseparse.c:2391:gst_base_parse_push_frame:<h264parse0> processing buffer of
size 82147 with dts 0:00:00.000000000, pts 0:00:02.518099556, duration
0:00:00.016666666
If my understanding is correct, DTS inferring from PTS is not done (and I think
it should because infer_ts is true) and only relies on next_dts value, which is
initialized to 0.
Consequently, a wrong DTS value is set in the buffer, resulting in a gap
between PTS and inferred DTS.
I was tempted to allow DTS infering even if PTS interpolation is disabled
(please refer to the attached patch) but it partially reverts the following
patch:
commit f27a3e12f6d35695ebbf2edc5aa4937c2e7c3843
Author: Sebastian Dröge <sebastian.droege at collabora.co.uk>
Date: Tue Apr 23 11:47:54 2013 +0200
baseparse: Only infer TS if PTS interpolation is enabled
Otherwise this is breaking timestamps of formats that
need reordering.
https://bugzilla.gnome.org/show_bug.cgi?id=597662
So, it may be a bad idea.
Do you have other suggestions ?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list