[Bug 731265] h265parse: small fix for buffer time stamping

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=731265
  GStreamer | gst-plugins-bad | unspecified

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #277945|none                        |needs-work
             status|                            |

--- Comment #1 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-06-06 10:20:24 UTC ---
Review of attachment 277945:
 --> (https://bugzilla.gnome.org/review?bug=731265&attachment=277945)

::: gst/videoparsers/gsth265parse.c
@@ +1432,3 @@
+   * For now, a naive method is used below.
+   */
+  GstClockTime dur;

Declare variables at the beginning of the block

@@ +1436,3 @@
+  GST_LOG_OBJECT (h265parse, "duration based ts");
+  /* naive method: no removal delay specified
+   * track upstream timestamp and provide best guess frame duration */

You could also keep the duration at GST_CLOCK_TIME_NONE for now. But does the
FIXME comment above mean that we currently don't calculate the DTS but only the
PTS, and still use the PTS magically as DTS? That seems wrong

@@ +2062,3 @@
+          (segment->start != 0 || segment->rate != 1.0
+              || segment->applied_rate != 1.0))
+        h265parse->do_ts = FALSE;

I think you should never timestamp when receiving a TIME segment, independent
of the start position, rate and applied rate

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.