GNOME Bugzilla – Bug 706292
mpegtsmux: Can't re-use safely after coming back from GST_STATE_NULL again
Last modified: 2015-08-16 13:41:15 UTC
When MpegTSmux with requested pads is being reset the associated pid on the pads is set to 0. Later, when the mpegtsmux is set to playing the following errors is generated since PID 0 is reserved for PAT : 0:00:08.918212309 4108 0x1984150 DEBUG mpegtsmux mpegtsmux.c:565:mpegtsmux_create_stream:<muxer:sink_66> Creating stream with PID 0x0000 for caps video/x-h264, stream-format=(string)byte-stream, width=(int)720, height=(int)576, parsed=(boolean)true, alignment=(string)au 0:00:08.920068219 4108 0x1984150 WARN mpegtsmux mpegtsmux.c:767:mpegtsmux_create_streams:<muxer> error: Could not create handler for stream Edward Hervey summarised it as follows: "essentially the code assumes that pad won't be resetted and re-used"
The pid associated with a pad is set when the pad is requested (either provided as part of the requested pad name, or provided by tsmux). When the muxer is set to NULL and back to PAUSED/PLAYING .. it gets resetted, ends up having an associated PID of 0 (amongst other NULL values) and mayhem ensues.
Making this bug more generic.
I believe this is fixed by this commit: commit 55373e21a8870d92ffe49a2d88deb68cf40cfdb4 Author: Jan Schmidt <jan@centricular.com> Date: Wed Jul 29 22:57:44 2015 +1000 mpegtsmux: Don't clear the PID on reset. The PID on a pad shouldn't change on a state change, only if the pad is freed and a new one created. Clearing the PID prevented mpegtsmux from being reused, because all packets would end up muxed in PID 0 https://bugzilla.gnome.org/show_bug.cgi?id=752999 Please re-open if not.