GNOME Bugzilla – Bug 783722
Discoverer: some API additions for live URIs such as RTSP and channel positions
Last modified: 2017-10-11 15:55:58 UTC
This also updates the executable to expose the new information.
Created attachment 353642 [details] [review] API: gst_discoverer_audio_info_get_channel_mask
Created attachment 353643 [details] [review] discoverer: output channel positions
Created attachment 353644 [details] [review] API: gst_discoverer_info_get_live
Created attachment 353645 [details] [review] discoverer: output whether the uri is live
Review of attachment 353642 [details] [review]: LGTM
Review of attachment 353643 [details] [review]: lgtm
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).
(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?
(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).
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).
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)
(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).
Created attachment 353705 [details] [review] discoverer: output channel positions
> 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 :)
ping Tim :)
No objections from me. Please add 'Since: 1.14' markers to the gtk-doc chunks before you push.
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