GNOME Bugzilla – Bug 686988
tsparse: Fix per-program handling
Last modified: 2018-11-03 13:13:32 UTC
Running dvbbasebin via gst-launch-1.0 will result every time into gstbasesrc.c(2791): gst_base_src_loop (): /GstPipeline:pipeline0/DvbBaseBin:dvbbasebin0/GstDvbSrc:dvbsrc0: streaming task paused, reason not-linked (-1) Using the same pipeline with gst-launch-0.10 works just fine. This is a serious regression which results in dvbbasebin not being usable at all!
Created attachment 227403 [details] Log file with gstreamer-0.10
Created attachment 227404 [details] Log file with gstreamer-1.0 from git master
Created attachment 227795 [details] Log file for gst 1.0 when reading from file It seems that tsparse is to blame, because when read from a file I get the same error. Please find attached the log when running the following pipeline: gst-launch-1.0 location=sample.mpeg ! tsparse .program_16398 ! fakesink The sample file is available at http://k-d-w.org/clipboard/sample.mpeg
The flow aggregation seems to be a bit messed up. For what it's worth, you can work around it by connecting the "src" pad to queue ! fakesink or so.
The workaround is really not helpful when what I ultimately want is to watch the file using Totem. This is a major regression which deserves more attention, IMHO.
Perhaps you could have a look at it then?
To be honest I would have no idea where to start looking for the cause or a fix thereof. I'm not familiar with the tsparse internals.
confirmed this is still an issue with current git.
Hmm... actually wait. I was only commenting on the pipeline from comment 3. dvbbasebin works perfectly fine. Note that the behaviour between tsparse (and therefore dvbbasebin) 0.10 and 1.0 changed in 0.10 you had dynamic source pads for each programs In 1.0 you have one static source pad for all input and you only request a specific program source pad if you want a specific program filtered out. the reason for that change is that: * In normal use-cases (within dvbbasebin), you select a program and only the program/pat/pmt/es pids are selected on dvbsource, so you've essentially already filtered out one program * The filtering per-program caused massive overhead (creating plenty of small buffers). Sebastian, does that help ?
Yes, let's consider this fixed then.
He might have meant the other Sebastian ;)
I did mean Sebastian Polsterl. Reopening
I can confirm that the pipeline works when not using ".program_16398". But I'm still confused why it doesn't work if specified. Usually, you have multiple programs on the same multiplex, how do you choose the program you want to watch with Gst 1.0?
Several ways: * if you're using dvbbasebin, the output only contains one program. Nothing to do. * if you're using a single file/stream containing multi-program, use the tsdemux program property (there's another bug open about that with patches which I should push) * Finally ... if you have a multi-program file or stream, and you want to extract individual streams (for storage, forwarding or whatever) then you need to use tsparse (but not dvbbasebin) and the request pads. Keeping the bug open to fix the tsparse request_pad issue.
After further investigations, tsparse needs to be refactored a bit to: * Not push out per-program packets individually, but instead aggregate them all until the incoming buffer has been fully parsed * On input-done, create *one* buffer per program pad and set the incoming buffer timestamp on it * Be smarter about which packets should go on which program pad: 1) If it's from a pid that the program handles take it (we know we need it) 2) Else if it's from a pid of another program refuse it (we know we don't need it) 3) Else take it (It's a global/generic MPTS pid) Furthermore, we need to make sure that if a program/bin is listening synchronously to the bus messages, and especially the PAT, it can request/release a program pad *before* the data for that program goes out.
-- 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/81.