GNOME Bugzilla – Bug 774128
rtmp: add is-live to rtmpsrc
Last modified: 2018-10-01 09:45:41 UTC
Created attachment 339362 [details] [review] Patch against git master Add the is-live property to rtmpsrc
What problem does that solve for you, how can this problem be reproduced? rtmpsrc is not really a live source in GStreamer terms
I think I've seen a discussion somewhere, please provide a appropriate context to open the discussion. Also, commit messages should explain why you think adding this today make sense for you. (I know is has something to do with the Aggregators, but isn't it better to force the aggregator to be live instead of this lie ?)
I compositing multiple RTMP sources, but having a hard time getting my pipeline to 'degrade gracefully' under heavy load. If my CPU can keep up with 30 FPS (FPS of RTMP cameras it works great) but if it can only do 28 FPS it quickly falls gets very bad. I noticed that the compositor was blocking every time a video would hang, and was investigating why. Then I noticed the behavior in the attached .c, if one pad of a `non-live source` is not getting buffers it will block all other `non-live sources` as well. Maybe I am barking up the wrong tree, but just trying to alleviate an overloaded compositor OR overloaded encoder
Created attachment 339426 [details] Example pipeline showing compositor behavior when one input has a DROP=true valve
@stormer Is it possible to force the aggregator to be live right now? For me this behavior exists on a per pad basis. So two live sources, and two non-live sources against the same VideoAggregator have different behaviors. I am still learning GStreamer, but the use of `is-live` is confusing for me. I stumbled upon this behavior of is-live+VideoAggregator and just assumed this patch could be helpful for others.
Just add a "identity sync=true" between the source and the compositor somewhere, it will make the non-live stream into a "fake" live stream.
This patch solves the problem with gst-rtsp-server with retransmitting streams from rtmp to rtsp. gst-rtsp-server code from current master performs seek to the time from rtsp play command if upstream is seekable, most opensource rtsp clients implementation always uses 'Range: npt=0.000-' in PLAY request (tested on ffplay, vlc). As rtmpsrc reports that it's seekable and current rtmp time could be not 0 gst-rtsp-server fails on seek to time 0 on start.