GNOME Bugzilla – Bug 740959
tsdemux broken for network TS streams (NKF RTP/TS/MPEG2 stream)
Last modified: 2018-11-03 13:29:10 UTC
I am currenty looking into a number of regressions from 0.10 with old network camera sources. This one is about support on NKF MPEG2 cameras that send their payload in RTP/TS/MPEG2. There seems to be a regression wrt 0.10. I am listening to the stream: gst-launch-1.0 rtpsrc uri=rtp://239.2.68.148:50010 ! rtpmp2tdepay ! tsparse ! tsdemux ! dumpinfo buffersize=1 ! fakesink dump=1 -v the data is stuck at the tsdemux and even worse, it is leaking memory. <snip> 2014-12-01T11:41:50.349328 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183) 2014-12-01T11:41:50.388793 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2 2014-12-01T11:41:50.389256 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer 2014-12-01T11:41:50.389285 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999 2014-12-01T11:41:50.389293 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183) 2014-12-01T11:41:50.429265 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2 2014-12-01T11:41:50.429753 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer 2014-12-01T11:41:50.429782 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999 2014-12-01T11:41:50.429791 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183) 2014-12-01T11:41:50.468842 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2 2014-12-01T11:41:50.469279 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer 2014-12-01T11:41:50.469307 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999 2014-12-01T11:41:50.469316 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183) 2014-12-01T11:41:50.508809 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2 2014-12-01T11:41:50.509303 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer 2014-12-01T11:41:50.509342 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999 2014-12-01T11:41:50.509379 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183) 2014-12-01T11:41:50.548795 3450 DEBUG tsdemux stream:0x7f53f0026c60, pid:0x0100 stream_type:2 state:2 2014-12-01T11:41:50.549261 3450 DEBUG tsdemux Not enough information to push buffers yet, storing buffer 2014-12-01T11:41:50.549287 3450 DEBUG tsdemux stream PTS 99:99:99.999999999 DTS 99:99:99.999999999 2014-12-01T11:41:50.549295 3450 DEBUG tsdemux Moving data forward by 14 bytes (packet_size:0, have:183) <snip>
When not using rtpsrc, this is the equivalent line: GST_DEBUG=*tsdemux*:5 gst-launch-1.0 udpsrc uri=udp://239.2.68.148:50010 caps="application/x-rtp, clock-rate=90000, media=video, payload=33" ! rtpmp2tdepay ! tsparse ! dumpinfo buffersize=1 ! tsdemux ! dumpinfo buffersize=1 ! fakesink dump=1 -v
Capture files: http://crichton.supercomputerrobot.com/~marc/downloads/nkf-20141201.ts.gdp.xz http://crichton.supercomputerrobot.com/~marc/downloads/nkf-20141201.ts.xz
The reason it doesn't play is because it doesn't contain any PCR. The PMT states that PCR will be on stream 0x0100 (the video stream)... but then there's no PCR values on it.
Created attachment 292844 [details] [review] if PCR is incorrect, get a guess at the TS from the adapter buffers I don't know if this is the way to get out of this, but it's a first attempt. As always for broken streams, it is configurable.
Created attachment 292846 [details] [review] if PCR is incorrect, get a guess at the TS from the adapter buffers update, default value in previous patch changed previous behaviour.
*** Bug 779854 has been marked as a duplicate of this bug. ***
Created attachment 347639 [details] [review] do not wait for PCR, set TS from adapter
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/196.