GNOME Bugzilla – Bug 663756
[mpegtsdemux] problem when using es-pids property
Last modified: 2013-07-09 12:46:43 UTC
Created attachment 201126 [details] mpegts over udp file that allows to reproduce the problem described in this bug Hi, On attempting to play the attached espn_small.pcap stream, the pipeline is blocked in PREROLL step when indicating the audio PID. The pcap file contains a mepgts stream with VIDEO: pid 0x801 (2049) codec mpeg2 and AUDIO: pid 0x802 (2050) codec AC3. * Steps to reproduce: gst-launch-0.10 filesrc location=espn_small.pcap ! pcapparse ! mpegtsparse ! mpegtsdemux es-pids="0x802" name=d ! queue ! mpegvideoparse ! mpeg2dec ! xvimagesink d. ! queue ! ac3parse ! a52dec ! audioconvert ! alsasink * Actual result: Piepline blocked in PREROLL step * Aother infos: If I set es-pids="0x801" then the video AND the audio are played. Why is audio played so ?
Created attachment 201386 [details] first draft to only play elementary streams pids when using es-pids property Hi, I looked a bit into the gstmpegtsdemux.c code from gst-plugins-bad/gst/mpegdemux and the attached diff seems to resolve the problem I described in this bug. Note that I read into gstmpegtsdemux.c for the first time and at this time I have not understood or read the whole file(s). The diff also could help to make a final patch.
Note that I think a recent commit may need some more work because the pipeline just block when prerolling since commit http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst/mpegdemux?id=9715fc318980763a3665afb977c8fc52aaf794a8
(In reply to comment #2) > Note that I think a recent commit may need some more work because the pipeline > just block when prerolling since commit > http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst/mpegdemux?id=9715fc318980763a3665afb977c8fc52aaf794a8 This pipeline sends very large timestamp buffers to mpegtsdemux. The in-gap patch was to sync to live streams, and it's getting fooled into thinking the source started a very long time ago. It should be only enabled when reading from a live stream, where timestamps are 0 based and the offset to first buffer makes sense. This plugin's very easy to break things in, so I'm not pushing till you confirm it fixes things for you, if you have various other samples.
Created attachment 203065 [details] [review] mpegtsdemux: only offset timestamps when live This code is to sync to a live source when there is a delay between start and when we receive the first buffer, so it does not make sense in a non live case. This fixes playback of streams where the input timestamps are based off some arbitrary offset.
(In reply to comment #4) > Created an attachment (id=203065) [details] [review] > mpegtsdemux: only offset timestamps when live > > This code is to sync to a live source when there is a delay > between start and when we receive the first buffer, so it does > not make sense in a non live case. > > This fixes playback of streams where the input timestamps are > based off some arbitrary offset. Hi, thanks for the fix, it resolves the problem exposed in comment #2. Nice ! Now do you have an idea about the problem exposed in the description and my patch ?
I don't know enough on MPEG TS to really know if that makes sense. The patch does not test whether the given PID is part of the list given by es-pids, which seems odd, but I can't say whether the convoluted logic might end up checking this later somewhere else.
Live in-gap patch pushed, the original report is still pending review from someone more familiar with MPEG TS. commit 09f0860a1037b73bf314dd6d80ebbfa096ff93bf Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Thu Dec 8 12:42:57 2011 +0000 mpegtsdemux: only offset timestamps when live This code is to sync to a live source when there is a delay between start and when we receive the first buffer, so it does not make sense in a non live case. This fixes playback of streams where the input timestamps are based off some arbitrary offset. https://bugzilla.gnome.org/show_bug.cgi?id=663756
(In reply to comment #7) >the original report is still pending review from > someone more familiar with MPEG TS. > Yes, the "es-pids" property of mpegtsdemux is not working.
This seems to work here, with the caveat that, with a simple video only pipeline: gst-launch-0.10 filesrc location=test.ts ! mpegtsdemux es-pids=0x1389,0x1388 ! ffdec_mpeg2video ! colorspace ! xvimagesink the pipeline only works if the PID of the video is specified first (the other one above is the audio). Supplying the PIDs in the other order causes the pipeline to block on preroll. It might be due to some preexisting issue with mpegtsdemux, however.
Created attachment 205115 [details] this mpegts file stream contains 1 video stream and 2 audio stream (stereo and 5.1) This attached cnbc_small.ts file shows that mpegtsdemux does not select the supplied audio pid. The file contains: video: pid 1361 (0x551) (mpeg2video) audio: pid 1362 (0x552) (ac3, 6 audio channels) audio: pid 1363 (0x553) (ac3, 2 audio channels) The following pipelines shows that the selected audio streams has 6 channels whereas it should be 2 because we asked pid 0x553 GST_DEBUG=ac3parse:5 gst-launch-0.10 filesrc location=cnbc_small.ts ! mpegtsdemux es-pids=0x551:0x553 name=d ! queue ! mpegvideoparse ! fakesink silent=1 d. ! queue ! ac3parse ! fakesink silent=1 Symmetric error when asking 0x552. (it selects the other audio stream)
The commit 09f0860a1037b73bf314dd6d80ebbfa096ff93bf, now part of release 0.10.23, breaks multicast streaming via udp. While souphttpsrv and filesrc are still working, a pipeline with udpsrc does not. WORKS: gst-launch-0.10 playbin video-sink=glessink uri=file:///tmp/capture.ts gst-launch-0.10 playbin video-sink=glessink uri=http://web01/capture.ts FAIL: gst-launch-0.10 playbin video-sink=glessink uri=udp://239.0.21.1:4444 Using a manual generated pipeline like above shows the same results. gst-launch-0.10 filesrc location=/tmp/capture.ts ! mpegtsdemux name=demux demux. ! audio/mpeg,mpegversion=1 ! { queue2 ! mpegaudioparse ! audio mpeg,mpegaudioversion=1,layer=2,channels=2,rate=48000 ! ffdec_mp2float } !{ queue2 ! audioconvert ! alsasink } demux. ! queue2 ! { ffdec_mpeg2video max-threads=0 ! queue2 } ! glessink
Regression, marking as blocker.
Also it would be great to add the "es-pids" property to tsdemux
The commit mentioned by Soeren in comment 11 breaks streaming via rtsp as well (see bug 675227).
This is against 0.10. Do we keep it open/blocker ?
Should be closed if the issue does not exist in 1.x any more.
Closing because: * mpegtsdemux is not ported * the es-pids property doesn't exist on tsparse/tsdemux And it's a bit dubious to set es-pids that way without any pat/pmt. Closing.