On Thursday 31 October 2013 01:25 PM, Edward Hervey-4 [via GStreamer-devel] wrote: > Hi, > > On Wed, 2013-10-30 at 23:46 -0700, sudipj wrote: > > There is also a tuner which tunnels the data within kernel to hw demuxer > > before it is pulled in the userspace by gstreamer element dvbsrc and pushed > > to dvbsrc. > > > > This could also be helpful for multitrack files where in a user could play a > > particular track by just passing the stream pid. For e.g just an english > > audio track without actually playing all the tracks of a particular program. > > playing != demuxing/decoding > > If you want to be able to quickly switch tracks (without waiting for > the demuxer to start reconstructing PES, pushing out data, the decoder > to start decoding data (or wait for a keyframe?) and finally the data > reaching the a/v sinks) ... you'll need to have data available further > down the pipeline (ex: the decoders could keep around the last X buffers > or GOP without decoding them if they know they are not used, but the > moment they are (re)activated they have data available to quickly decode > and catch up). [SJ] At first, I am just interested in a particular a/v stream(s), might not be required switching to another track. For eg. I want to test a/v sync for an audio/video pair. > If you were fine with that delay, you could also do the same thing in > user-land (temporarily ignore and avoid reconstructing the specified > PID). Hell, that would be a few lines of code in tsdemux (but we won't > enable it by default for reasons mentioned above). [SJ]Fair enough, not expected to be enabled by default. Only when a user provides "requested_stream_pid(s). May be you should be allowed to switch when you are interested in particular track(s) only. > > > > Its seem bit out of range, but today we use for many practical reasons. > > Internally we do have a clone of tsdemux(stts_demux), which actually works > > by just accepting the PES data. But the limitation is that I cannot > > interface with other gstreamer elements. > > You might want to explain what "practical reasons" you have. There are > maybe other ways to achieve the same results. [SJ] 1. when you introduce a custom recorder element that can record a particular stream. 2. Decode only video (no audio) for PIP. > > Also, I'm going to assume that by "just accepting the PES data", you > mean you're using individual fd for each reconstructed PID ES streams > and not just one stream on which all PES are interleaved. [SJ] Right, our kernel demuxer pushes a SPTS(single program TS) rather MPTS (multiple program TS). This stream is an interleaved ES depending on the PIDS provided to the demuxer.There is an invidual fd for an interleaved stream, different from the one received at the input of the kernel demuxer. (atleast the PSI sections are stripped) > > > > Can I try to provide a solution for this in tsdemux, if you see a point > > here. ? > > So, what *could* be doable would be to re-use most of the code in > tsdemux and have an alternate "pid filtering and packet reconstruction > done in kernel" demuxer. So the PID filtering part (i.e. what is in > mpegtspacketizer.[ch] and the stream reconstruction part of tsdemux is > done in kernel). > *But* you would still need to get the PSI/SI back from the kernel for > the demuxer to work (so it can figure out the nature of the streams). > [SJ] PID filtering is done in kernel demuxer , except that it does not forward the PSI sections to the user, probably it maintains PAT/PMT table within itself. Right, stream type is required, but that is also taken as a user argument :). My point here is, if user has all the bare minimum stream info then tsdemux should not restrict the user. For the two practical purposes I sited above(recorder and PIP). > Note also that you *would* have another issue, which is that this > element wouldn't be accepting any data (if I understood correctly) and > would need to be a source element .. but it can't be since it would be > exposing multiple pads. > Ways to circumvent this: > * Have it cloned (i.e. source elements which only expose one stream > from the program) => very very very ugly [SJ] No, I don't want this solution. > * Have it accept data (for example only the PAT/PMT streams) from > dvbsrc. [SJ] This would require change in kernel demuxer, not an easy task as they won't adapt specifically to gstreamer tsdemux. > * Have it signal upstream (with an event) to the dvbsrc which PIDs it > is interested in (this will introduce latency though). [SJ] It is as good as providing user space arguments something like gst-launch ! filesrc location = xxx.ts ! tsdemux vid-pid/type= 100/2, audio-pid/type = 101/3 ! ...) which is actually I am trying to propose. > .. or just use tsdemux as-is :) > > Edward > > P.S. I haven't mentioned the dvb clock estimation, accurate > synchronization/timestamping and latency, that's another minefield which > is hard to deal with if you only have a limited visibility of what's > going on. [SJ] I knew that, timing is one thing that also needs to be validated. But this is next. > > P.S. Please please please please stop calling this a hardware demuxer. > It's not because you do the pid filtering in the kernel that it's a > "hardware". You might as well say that you have "TCP/IP" hardware stack, > or a "hardware CFQ i/o scheduler" (hint: no). [SJ] Ok, I am not sure if there is a dedicated hardware for demuxer. But only thing I know, it is tightly coupled to the the tuner which is actually a hardware block. > > P.S: A smarter move would be to help provide a mmap-ringbuffer interface > to the kernel API (like V4L2) so you can avoid memcpy (right now they > are only read() API) when getting data from the DVB interfaces. That way > the software demuxer would be as fast (and more flexible) as the > hardware^Wkernel one, if not faster. Would be great if people stopped > with this crazy belief that code in the kernel runs faster than code in > user-land... Last time I spoke to linuxtv folks they weren't against the > idea, it's just that nobody got round to implementing it. Removing > 30Mb/s copies ? Absolute win, regardless of whether it's a multiplex or > reconstructed ES streams. [SJ] Fair > P.S: Have you profiled all this ? There aren't a million different ways > of doing filtering and packet reconstruction. The biggest performance > hit of a ts demuxer is going to be packet reconstruction (due to the > copying which needs to be done) and it is going to cost you the same > whether you do it in kernel or userland. [SJ] Yes, I have done profiling mainly to know the IOs per sec. Untill the cpu load is below 10 %, it fine. Our frontend (tuner + demuxer) guys are pretty happy to provide a generic solution to the customers leaving them to adapt the way it is rather vice-versa. > > > > Sudip > > > > > > > > > > > > -- > > View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/play-stream-without-parsing-PAT-PMT-tp4662984p4663019.html" target="_top" rel="nofollow" link="external">http://gstreamer-devel.966125.n4.nabble.com/play-stream-without-parsing-PAT-PMT-tp4662984p4663019.html</a> > > Sent from the GStreamer-devel mailing list archive at Nabble.com. > > _______________________________________________ > > gstreamer-devel mailing list > > [hidden email] > > <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_top" rel="nofollow" link="external">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_top" rel="nofollow" link="external">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> > > If you reply to this email, your message will be added to the discussion below: > <a href="http://gstreamer-devel.966125.n4.nabble.com/play-stream-without-parsing-PAT-PMT-tp4662984p4663022.html" target="_top" rel="nofollow" link="external">http://gstreamer-devel.966125.n4.nabble.com/play-stream-without-parsing-PAT-PMT-tp4662984p4663022.html</a> > To start a new topic under GStreamer-devel, email <a href="/user/SendEmail.jtp?type=node&node=4663067&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a> > To unsubscribe from play stream without parsing PAT/PMT, click here. > NAML <hr align="left" width="300" /> View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/play-stream-without-parsing-PAT-PMT-tp4662984p4663067.html">Re: play stream without parsing PAT/PMT</a> Sent from the <a href="http://gstreamer-devel.966125.n4.nabble.com/">GStreamer-devel mailing list archive</a> at Nabble.com.