GNOME Bugzilla – Bug 766438
rtpjitterbuffer: Accept streams with non-TIME segments.
Last modified: 2016-06-08 18:57:44 UTC
With non-time segments, it now assumes that the arrival time of packets is not relevant and that only the RTP timestamp matter and it produces an output segment start at running time 0. This is useful for streams of packets captured with multifilesink.
Created attachment 327878 [details] [review] rtpjitterbuffer: Work with non-TIME segments With non-time segments, it now assumes that the arrival time of packets is not relevant and that only the RTP timestamp matter and it produces an output segment start at running time 0.
Comment on attachment 327878 [details] [review] rtpjitterbuffer: Work with non-TIME segments While the patch seems OK, why can't we make upstream produce a TIME segment instead? Also a lot of other RTP code assumes TIME segments too, which would need changes then.
(In reply to Sebastian Dröge (slomo) from comment #2) > While the patch seems OK, why can't we make upstream produce a TIME segment > instead? Also a lot of other RTP code assumes TIME segments too, which would > need changes then. Because I want to read from filesrc or multifilesrc. My example pipelien is "multifilesrc ! rtpjitterbuffer ! depay ! dec ! sink".. I guess we shoudl also make sure that rtpbin can work without a time segment. Elements after the jitterbuffer (like depayloaders) can still safely require a TIME segment.
Ok, seems reasonable then :)
Merged commit 5328378132c7c100b8a17818862a3124affef1f8 Author: Olivier Crête <olivier.crete@collabora.com> Date: Sat May 14 14:46:17 2016 +0200 rtpjitterbuffer: Work with non-TIME segments With non-time segments, it now assumes that the arrival time of packets is not relevant and that only the RTP timestamp matter and it produces an output segment start at running time 0. https://bugzilla.gnome.org/show_bug.cgi?id=766438