[Bug 728356] jpegparse: Does not passthrough timestamps depending on downstream elements

[GStreamer (bugzilla.gnome.org)]

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

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #275017|none                        |reviewed
             status|                            |

--- Comment #10 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2014-05-30 16:55:23 UTC ---
(From update of attachment 275017)
> /* Special optimized scan for mask 0xffffff00 and pattern 0x00000100 */
> static inline gint
>-_scan_for_start_code (const guint8 * data, guint offset, guint size)
>+_scan_for_start_code (const guint8 * data, guint offset, guint size,
>+    guint32 * value)

Did you measure if the addition of this has a negative performance impact on
the non-peek function? (i.e. if the compiler actually inlines it and optimises
it away or not)


>+    if (value)
>+      *value = *((guint32 *) (data + i + offset));

This looks problematic for two reasons: are we guaranteed aligned access here?
what about endianness? Is it always native? That seems unlikely, but I haven't
looked at the code.

> /**
>- * gst_byte_reader_masked_scan_uint32:
>+ * gst_byte_reader_masked_scan_uint32_peek:
>  * @reader: a #GstByteReader
>  * @mask: mask to apply to data before matching against @pattern
>  * @pattern: pattern to match (after mask is applied)
>  * @offset: offset from which to start scanning, relative to the current
>  *     position
>  * @size: number of bytes to scan from offset
>+ * @value: pointer to uint32 to return matching data
>  *
>  * Scan for pattern @pattern with applied mask @mask in the byte reader data,
>  * starting from offset @offset relative to the current position.
>@@ -818,29 +823,11 @@ _scan_for_start_code (const guint8 * data, guint offset, guint size)
>  *
>  * Returns: offset of the first match, or -1 if no match was found.
>  *
>- * Example:
>- * <programlisting>
>- * // Assume the reader contains 0x00 0x01 0x02 ... 0xfe 0xff
>- *
>- * gst_byte_reader_masked_scan_uint32 (reader, 0xffffffff, 0x00010203, 0, 256);
>- * // -> returns 0
>- * gst_byte_reader_masked_scan_uint32 (reader, 0xffffffff, 0x00010203, 1, 255);
>- * // -> returns -1
>- * gst_byte_reader_masked_scan_uint32 (reader, 0xffffffff, 0x01020304, 1, 255);
>- * // -> returns 1
>- * gst_byte_reader_masked_scan_uint32 (reader, 0xffff, 0x0001, 0, 256);
>- * // -> returns -1
>- * gst_byte_reader_masked_scan_uint32 (reader, 0xffff, 0x0203, 0, 256);
>- * // -> returns 0
>- * gst_byte_reader_masked_scan_uint32 (reader, 0xffff0000, 0x02030000, 0, 256);
>- * // -> returns 2
>- * gst_byte_reader_masked_scan_uint32 (reader, 0xffff0000, 0x02030000, 0, 4);
>- * // -> returns -1
>- * </programlisting>
>+ * Since: 1.4
>  */
> guint
>-gst_byte_reader_masked_scan_uint32 (const GstByteReader * reader, guint32 mask,
>-    guint32 pattern, guint offset, guint size)
>+gst_byte_reader_masked_scan_uint32_peek (const GstByteReader * reader,
>+    guint32 mask, guint32 pattern, guint offset, guint size, guint32 * value)

Maybe you could move the new _peek() function behind the other one, so we don't
have all this diff churn? :)

-- 
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.