[Bug 660260] isomp4: Add support for GstForceKeyUnit events

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #13 from Andoni Morales <ylatuya at gmail.com> 2013-09-27 09:08:18 UTC ---
Review of attachment 252750:
 --> (https://bugzilla.gnome.org/review?bug=660260&attachment=252750)

::: gst/isomp4/gstqtmux.c
@@ +391,1 @@


The patch needs to be rebased. This property is now deprecated for regular mp4
muxers.

@@ +2082,3 @@

+    if (GST_BUFFER_FLAG_IS_SET (buf, GST_BUFFER_FLAG_DELTA_UNIT)) {
+      GST_WARNING ("Next fragment will not start with a keyframe");

I would leave it there just to make sure that everything is ok, I found it very
useful for debugging (maybe make it GST_DEBUG instead of GST_WARNING?)

@@ -3086,0 +3169,42 @@
+static gint
+_sort_fku_events (GstEvent * e1, GstEvent * e2)
+{
... 39 more ...

This code tries to handle the scenario in which the muxer is muxing several
tracks (it does not happen in DASH were you have a single track but it's a
valid FMP4 use case).
If the event is an upstream FKU (hence commming from the src pad), it enqueues
the event in each sink pad, the first pad to reach the fragment limit creates
the new fragment and the event is dequeued from the all the pads.
If it's a downstream event its only queued in the corresponding sink pad.
It could probably be documented in a better way :)

--- Comment #14 from Andoni Morales <ylatuya at gmail.com> 2013-09-27 09:08:20 UTC ---
Review of attachment 252750:
 --> (https://bugzilla.gnome.org/review?bug=660260&attachment=252750)

::: gst/isomp4/gstqtmux.c
@@ +391,1 @@


The patch needs to be rebased. This property is now deprecated for regular mp4
muxers.

@@ +2082,3 @@

+    if (GST_BUFFER_FLAG_IS_SET (buf, GST_BUFFER_FLAG_DELTA_UNIT)) {
+      GST_WARNING ("Next fragment will not start with a keyframe");

I would leave it there just to make sure that everything is ok, I found it very
useful for debugging (maybe make it GST_DEBUG instead of GST_WARNING?)

@@ -3086,0 +3169,42 @@
+static gint
+_sort_fku_events (GstEvent * e1, GstEvent * e2)
+{
... 39 more ...

This code tries to handle the scenario in which the muxer is muxing several
tracks (it does not happen in DASH were you have a single track but it's a
valid FMP4 use case).
If the event is an upstream FKU (hence commming from the src pad), it enqueues
the event in each sink pad, the first pad to reach the fragment limit creates
the new fragment and the event is dequeued from the all the pads.
If it's a downstream event its only queued in the corresponding sink pad.
It could probably be documented in a better way :)

--- Comment #15 from Andoni Morales <ylatuya at gmail.com> 2013-09-27 09:08:20 UTC ---
Review of attachment 252750:
 --> (https://bugzilla.gnome.org/review?bug=660260&attachment=252750)

::: gst/isomp4/gstqtmux.c
@@ +391,1 @@


The patch needs to be rebased. This property is now deprecated for regular mp4
muxers.

@@ +2082,3 @@

+    if (GST_BUFFER_FLAG_IS_SET (buf, GST_BUFFER_FLAG_DELTA_UNIT)) {
+      GST_WARNING ("Next fragment will not start with a keyframe");

I would leave it there just to make sure that everything is ok, I found it very
useful for debugging (maybe make it GST_DEBUG instead of GST_WARNING?)

@@ -3086,0 +3169,42 @@
+static gint
+_sort_fku_events (GstEvent * e1, GstEvent * e2)
+{
... 39 more ...

This code tries to handle the scenario in which the muxer is muxing several
tracks (it does not happen in DASH were you have a single track but it's a
valid FMP4 use case).
If the event is an upstream FKU (hence commming from the src pad), it enqueues
the event in each sink pad, the first pad to reach the fragment limit creates
the new fragment and the event is dequeued from the all the pads.
If it's a downstream event its only queued in the corresponding sink pad.
It could probably be documented in a better way :)

--- Comment #16 from Andoni Morales <ylatuya at gmail.com> 2013-09-27 09:08:21 UTC ---
Review of attachment 252750:
 --> (https://bugzilla.gnome.org/review?bug=660260&attachment=252750)

::: gst/isomp4/gstqtmux.c
@@ +391,1 @@


The patch needs to be rebased. This property is now deprecated for regular mp4
muxers.

@@ +2082,3 @@

+    if (GST_BUFFER_FLAG_IS_SET (buf, GST_BUFFER_FLAG_DELTA_UNIT)) {
+      GST_WARNING ("Next fragment will not start with a keyframe");

I would leave it there just to make sure that everything is ok, I found it very
useful for debugging (maybe make it GST_DEBUG instead of GST_WARNING?)

@@ -3086,0 +3169,42 @@
+static gint
+_sort_fku_events (GstEvent * e1, GstEvent * e2)
+{
... 39 more ...

This code tries to handle the scenario in which the muxer is muxing several
tracks (it does not happen in DASH were you have a single track but it's a
valid FMP4 use case).
If the event is an upstream FKU (hence commming from the src pad), it enqueues
the event in each sink pad, the first pad to reach the fragment limit creates
the new fragment and the event is dequeued from the all the pads.
If it's a downstream event its only queued in the corresponding sink pad.
It could probably be documented in a better way :)

--- Comment #17 from Andoni Morales <ylatuya at gmail.com> 2013-09-27 09:08:21 UTC ---
Review of attachment 252750:
 --> (https://bugzilla.gnome.org/review?bug=660260&attachment=252750)

::: gst/isomp4/gstqtmux.c
@@ +391,1 @@


The patch needs to be rebased. This property is now deprecated for regular mp4
muxers.

@@ +2082,3 @@

+    if (GST_BUFFER_FLAG_IS_SET (buf, GST_BUFFER_FLAG_DELTA_UNIT)) {
+      GST_WARNING ("Next fragment will not start with a keyframe");

I would leave it there just to make sure that everything is ok, I found it very
useful for debugging (maybe make it GST_DEBUG instead of GST_WARNING?)

@@ -3086,0 +3169,42 @@
+static gint
+_sort_fku_events (GstEvent * e1, GstEvent * e2)
+{
... 39 more ...

This code tries to handle the scenario in which the muxer is muxing several
tracks (it does not happen in DASH were you have a single track but it's a
valid FMP4 use case).
If the event is an upstream FKU (hence commming from the src pad), it enqueues
the event in each sink pad, the first pad to reach the fragment limit creates
the new fragment and the event is dequeued from the all the pads.
If it's a downstream event its only queued in the corresponding sink pad.
It could probably be documented in a better way :)

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