[Bug 725828] hlsdemux: reporting playlist and fragment download time stat

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=725828
  GStreamer | gst-plugins-bad | 1.x

--- Comment #5 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-06-23 11:09:14 UTC ---
(In reply to comment #4)
> Gratuitous comments: I don't entirely see the value of the
> gst_hls_demux_post_stat_msg() helper function, might just as well do it in the
> code, doesn't save any lines really, does it (if you embed the
> gst_structure_new() without assigning it to a variable)?
> 
> Regarding the names:
> 
>  - "hlsdemux-statistics" -> maybe "hls-statistics" ?
>     Or maybe we want to make it generic for all these
>     adaptive thingies from the start? Or does it not map?

Good point, we can generalize that for all the adaptive things. They all have
some kind of playlist (usually called manifest) and fragments. And sometimes
other things.

>  - "time-of-first-playlist" -> this time is absolute?
>     why only for the first then?

Because the first playlist is downloaded externally, even before hlsdemux
exists. So we can only report an absolute time here. The download is started as
a result of something the app is doing.

For the other playlist messages, here the download is started manually without
the app knowing and hlsdemux knows when it was started and finished. So we can
report either a duration here, or two absolute times.

Maybe generalize it and always report two absolute times... and for the first
playlist report -1 for the start time? And then for consistency we should
report the two times instead of durations for the fragment downloads too.

>  - "time-to-playlist" -> "playlist-download-time" ?
> 
>  - "time-to-download-fragment" -> "fragment-download-time" ?

I prefer those too, yes

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