After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740790 - hlsdemux: Provide EXT-X-PROGRAM-DATE-TIME as a tag event.
hlsdemux: Provide EXT-X-PROGRAM-DATE-TIME as a tag event.
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-11-26 22:24 UTC by GstBlub
Modified: 2018-11-03 13:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (11.80 KB, patch)
2014-11-26 22:24 UTC, GstBlub
none Details | Review
Updated patch against master (7.33 KB, patch)
2016-07-28 15:29 UTC, GstBlub
none Details | Review

Description GstBlub 2014-11-26 22:24:39 UTC
Created attachment 291603 [details] [review]
Patch

This allows an application to receive a datetime tag for each fragment.
Comment 1 Tim-Philipp Müller 2014-11-26 22:58:04 UTC
Seems like an awful lot of code to get a date to the right place..
Comment 2 GstBlub 2014-11-27 03:55:27 UTC
(In reply to comment #1)
> Seems like an awful lot of code to get a date to the right place..

Do you mind elaborating?  Is there a better way to get this information to an application?
Comment 3 Sebastian Dröge (slomo) 2014-11-27 09:13:47 UTC
Review of attachment 291603 [details] [review]:

This probably breaks the unit test btw

::: ext/hls/gsthlsdemux.c
@@ +563,3 @@
+            gst_date_time_unref (prog_dt);
+            prog_dt = gst_date_time_new_from_g_date_time (pdt_new);
+            g_date_time_unref (pdt_new);

Do this conversion already in m3u8.c

@@ +2192,3 @@
   if (!gst_m3u8_client_get_next_fragment (demux->client, &discont,
+          &next_fragment_uri, &demux->prog_datetime, &duration, &timestamp,
+          &range_start, &range_end, &key, &iv, demux->segment.rate > 0)) {

Here just store a "pending_tags" taglist somewhere, and push it downstream on the next opportunity (i.e. if there is a srcpad)

::: ext/hls/m3u8.c
@@ +109,3 @@
 static GstM3U8MediaFile *
+gst_m3u8_media_file_new (gchar * uri, gchar * title,
+    GstDateTime * program_datetime, GstClockTime duration, guint sequence)

Maybe instead of passing title, datetime and more things in the future here... just pass a GstTagList with those things?

@@ +117,3 @@
   file->title = title;
+  file->program_datetime =
+      program_datetime ? gst_date_time_ref (program_datetime) : NULL;

And also only store a taglist here

@@ +955,3 @@
+    gboolean * discontinuity, gchar ** uri, GstDateTime ** program_datetime,
+    GstClockTime * duration, GstClockTime * timestamp, gint64 * range_start,
+    gint64 * range_end, gchar ** key, guint8 ** iv, gboolean forward)

And also only return a taglist here
Comment 4 Thiago Sousa Santos 2014-12-29 11:30:37 UTC
From the spec:

   The server MAY associate an absolute date and time with a Media
   Segment by applying an EXT-X-PROGRAM-DATE-TIME tag to it.  This
   defines an informative mapping of the (wall-clock) date and time
   specified by the tag to the first media timestamp in the segment,
   which may be used as a basis for seeking, for display, or for other
   purposes.  If a server provides this mapping, it SHOULD apply an EXT-
   X-PROGRAM-DATE-TIME tag to every segment that has an EXT-
   X-DISCONTINUITY tag applied to it


It seems a bit confusing as it says it can be used for display as well. I wonder if we should have this as a tag (datetime of creation) or if we should use this to map to our stream-time.

We have a symmetric issue here: https://bugzilla.gnome.org/show_bug.cgi?id=741159
Comment 5 Thiago Sousa Santos 2015-01-20 13:23:48 UTC
@reporter: do you plan on updating the patch with the review comments?
Comment 6 GstBlub 2015-01-23 16:26:16 UTC
(In reply to comment #5)
> @reporter: do you plan on updating the patch with the review comments?

I actually had an updated patch that I never posted here, but it no longer merges cleanly.  I'll have to update it against master and I'll post it here hopefully next week or so.
Comment 7 Thiago Sousa Santos 2015-02-20 04:35:57 UTC
Ping?
Comment 8 Arjen Veenhuizen 2015-08-18 07:15:40 UTC
It would be great if this feature can find its way upstream.
Comment 9 GstBlub 2016-07-28 15:29:04 UTC
Created attachment 332283 [details] [review]
Updated patch against master

Sorry for the long delay, I haven't had chance to work on this again.  I updated the patch against master.
Comment 10 GStreamer system administrator 2018-11-03 13:29:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/195.