[Bug 660260] isomp4: Add support for GstForceKeyUnit events

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Nov 6 18:33:31 PST 2013


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

Thiago Sousa Santos <thiago.sousa.santos> changed:

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

--- Comment #24 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2013-11-07 02:33:25 UTC ---
Review of attachment 259061:
 --> (https://bugzilla.gnome.org/review?bug=660260&attachment=259061)

Patch looks good overall, just a few simple remarks below.

::: gst/isomp4/gstqtmux.c
@@ +385,3 @@
       g_param_spec_uint ("fragment-duration", "Fragment duration",
+          "Fragment durations in ms (used when the fragment-method='time')",
+          0, G_MAXUINT32, 2000,

Use the DEFAULT_FRAGMENT_DURATION here?

@@ +398,3 @@
+          GST_QT_MUX_FORMAT_ISML ? FRAGMENT_METHOD_TIME :
+          DEFAULT_FRAGMENT_METHOD,
+          G_PARAM_READWRITE | G_PARAM_CONSTRUCT | G_PARAM_STATIC_STRINGS));

Can't we install properties conditionally so we only get those fragmented
options on formats that accept fragmented output?

@@ +2142,3 @@
     }

+    gst_qt_mux_dequeue_force_key_unit_event (qtmux, pad);

Why is it always removed? Can't it happen that some scenario other than the
event caused the new fragment? Any scenario with a force=True?

Additionally it causes a GST_WARNING when no events are queued, maybe only call
if we know there is an event or if the event caused the fragment?

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


More information about the gstreamer-bugs mailing list