[Bug 668094] dashsink: New sink for DASH
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sun Mar 15 05:13:47 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=668094
Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nicolas.dufresne at collabora.
| |co.uk
--- Comment #4 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
@@ -2144,6 +2181,17 @@ flush:
GstBuffer *buffer;
guint i, total_size;
+ if (GST_BUFFER_FLAG_IS_SET (buf, GST_BUFFER_FLAG_DELTA_UNIT)) {
+ GST_WARNING ("Next fragment will not start with a keyframe");
+ }
Maybe we would post a warning in this case (I mean GST_ELEMENT_WARNING), since
it means multiple issues could arrived around this area of the file.
+++ b/gst/isomp4/gstqtmux.c
@@ -104,6 +104,7 @@
#include <gst/audio/audio.h>
#include <gst/video/video.h>
#include <gst/tag/tag.h>
+#include <gst/video/video.h>
you are including video.h twice.
+ {FRAGMENT_METHOD_EVENT, "GstForceKeyUnit events", "event"},
Arguably, the GstForceKeyUnit was really designed to ask a decoder to produce a
keyframe. Overriding it for this task have an interesting side effect. Let's
say you have a decoder set to produce keyframe only on request. Then there
would be no way to have more then 1 keyframe per fragment. By adding a specific
event to force a Fragment, we could send GstForceKeyUnit to insert keyframes in
the current fragment and later cut the fragment. This may or may not be very
useful, but I think it's good to understand the limitation.
One thing I notice is that with time method, we use a simplistic approach which
makes the fragment always slightly bigger then then target duration. I don't
know if that is a problem or not.
p.s. I'll be posting multiple comment while going through
--
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