Seems like an awful lot of code to get a date to the right place..

(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?

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

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

@reporter: do you plan on updating the patch with the review comments?

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

Ping?

It would be great if this feature can find its way upstream.

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.

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