GNOME Bugzilla – Bug 706872
mpegtsmux does not flag key frames properly for tcpserversink
Last modified: 2015-03-15 16:09:41 UTC
It appear that the current 1.0.9 version of mpegtsmux does not flag the key frame properly. This affects other modules such as tcpserversink that are then unable to determine correct from where in a stream it should start sending out a TS stream. Please see intital mail http://lists.freedesktop.org/archives/gstreamer-devel/2013-August/042628.html http://lists.freedesktop.org/archives/gstreamer-devel/2013-August/042635.html And please see Tim-Phillipps mail suggesting filing a bug report for mpegtsmux http://lists.freedesktop.org/archives/gstreamer-devel/2013-August/042668.html
TS-muxing in combination with tcpclientsrc still broken in 1.2 See also thread http://lists.freedesktop.org/archives/gstreamer-devel/2013-September/043142.html
(In reply to comment #1) > TS-muxing in combination with tcpclientsrc still broken in 1.2 > See also thread > http://lists.freedesktop.org/archives/gstreamer-devel/2013-September/043142.html I should have stated 'with tcpserversink' and not 'with tcpclientsrc' although a tcpserversink in some cases implies a tcpclientsrc in the other end. Anyway, I believe the issue is with mpegtsmux, which affects other plugins/elements using a flagged keyframe such as tcpserversink.
This seems to work fine for me now with git master. I've added a unit test too. commit ec6e93d45fc04953489b00857656f779289d610b Author: Tim-Philipp Müller <tim@centricular.com> Date: Sun Mar 15 15:54:01 2015 +0000 tests: mpegtsmux: add test for keyframe/delta flag propagation The first output MPEG-TS packet that corresponds to a video input buffer which had the delta flag cleared (i.e. was a keyframe) should have the delta flag cleared as well. This is needed e.g. by tcpserversink in order to keep track of the last keyframe and be able to burst data to newly- connected clients. https://bugzilla.gnome.org/show_bug.cgi?id=706872