[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