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 783722 - Discoverer: some API additions for live URIs such as RTSP and channel positions
Discoverer: some API additions for live URIs such as RTSP and channel positions
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other All
: Normal enhancement
: 1.13.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-13 00:33 UTC by Mathieu Duponchelle
Modified: 2017-10-11 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
API: gst_discoverer_audio_info_get_channel_mask (5.79 KB, patch)
2017-06-13 00:33 UTC, Mathieu Duponchelle
committed Details | Review
discoverer: output channel positions (2.59 KB, patch)
2017-06-13 00:33 UTC, Mathieu Duponchelle
none Details | Review
API: gst_discoverer_info_get_live (4.67 KB, patch)
2017-06-13 00:33 UTC, Mathieu Duponchelle
committed Details | Review
discoverer: output whether the uri is live (1.02 KB, patch)
2017-06-13 00:33 UTC, Mathieu Duponchelle
committed Details | Review
discoverer: output channel positions (2.64 KB, patch)
2017-06-13 19:53 UTC, Mathieu Duponchelle
committed Details | Review

Description Mathieu Duponchelle 2017-06-13 00:33:26 UTC
This also updates the executable to expose the new information.
Comment 1 Mathieu Duponchelle 2017-06-13 00:33:30 UTC
Created attachment 353642 [details] [review]
API: gst_discoverer_audio_info_get_channel_mask
Comment 2 Mathieu Duponchelle 2017-06-13 00:33:35 UTC
Created attachment 353643 [details] [review]
discoverer: output channel positions
Comment 3 Mathieu Duponchelle 2017-06-13 00:33:40 UTC
Created attachment 353644 [details] [review]
API: gst_discoverer_info_get_live
Comment 4 Mathieu Duponchelle 2017-06-13 00:33:45 UTC
Created attachment 353645 [details] [review]
discoverer: output whether the uri is live
Comment 5 Thibault Saunier 2017-06-13 01:10:07 UTC
Review of attachment 353642 [details] [review]:

LGTM
Comment 6 Thibault Saunier 2017-06-13 01:11:39 UTC
Review of attachment 353643 [details] [review]:

lgtm
Comment 7 Thibault Saunier 2017-06-13 01:15:51 UTC
Review of attachment 353644 [details] [review]:

I guess it is good enough, but it would be nice to get the information about whether the stream is live in common language (ie, the stream current playback is "now", and you can't seek in the future).
Comment 8 Olivier Crête 2017-06-13 11:56:59 UTC
(In reply to Thibault Saunier from comment #7)
> I guess it is good enough, but it would be nice to get the information about
> whether the stream is live in common language (ie, the stream current
> playback is "now", and you can't seek in the future).

Would that be if it's "seekable", from the result of the seeking query?
Comment 9 Thibault Saunier 2017-06-13 13:05:28 UTC
(In reply to Olivier Crête from comment #8)
> (In reply to Thibault Saunier from comment #7)
> > I guess it is good enough, but it would be nice to get the information about
> > whether the stream is live in common language (ie, the stream current
> > playback is "now", and you can't seek in the future).
> 
> Would that be if it's "seekable", from the result of the seeking query?

Nop, a live stream can potentially be seekable (only in the past, sure).
Comment 10 Tim-Philipp Müller 2017-06-13 13:25:33 UTC
Just to be sure: there's

 - live + not seekable

 - live + duration + seekable past + future, anywhere between 0 and duration (e.g. RTSP VOD)

 - live + seekable anywhere between now and now-X (e.g. DASH live with potentially limited backbuffer)

unless "live" was supposed to mean something else in this context here (if so, I'm not sure if that's a good idea).
Comment 11 Tim-Philipp Müller 2017-06-13 13:26:48 UTC
oh, and of course also the case where we seeked into the backbuffer and can seek back to 'now' again (though we may not have a final/constant duration)
Comment 12 Thibault Saunier 2017-06-13 13:31:37 UTC
(In reply to Tim-Philipp Müller from comment #10)
> unless "live" was supposed to mean something else in this context here (if
> so, I'm not sure if that's a good idea).

Live means "live in the GStreamer sense" here (ie. the source does not produce data in PAUSED basically).
Comment 13 Mathieu Duponchelle 2017-06-13 19:53:56 UTC
Created attachment 353705 [details] [review]
discoverer: output channel positions
Comment 14 Mathieu Duponchelle 2017-06-13 20:02:18 UTC
> unless "live" was supposed to mean something else in this context here (if
> so, I'm not sure if that's a good idea).

Yeah no, it's strictly, as thibault said, in the gstreamer sense.

I think the information can be useful, for example to determine whether plugging in a source to a mixer will make it start timing out, things like that. The "live" terminology is a bit confusing but it's the one we have :)
Comment 15 Mathieu Duponchelle 2017-08-01 16:00:47 UTC
ping Tim :)
Comment 16 Tim-Philipp Müller 2017-08-01 16:30:29 UTC
No objections from me.

Please add 'Since: 1.14' markers to the gtk-doc chunks before you push.
Comment 17 Mathieu Duponchelle 2017-10-11 15:47:51 UTC
Attachment 353642 [details] pushed as 2a26baf - API: gst_discoverer_audio_info_get_channel_mask
Attachment 353644 [details] pushed as 545e0b0 - API: gst_discoverer_info_get_live
Attachment 353645 [details] pushed as 1d5a662 - discoverer: output whether the uri is live
Attachment 353705 [details] pushed as 889bb92 - discoverer: output channel positions