play stream without parsing PAT/PMT
Edward Hervey
bilboed at bilboed.com
Mon Nov 25 00:50:38 PST 2013
Hi,
On Sun, 2013-11-03 at 01:20 -0800, sudipj wrote:
> 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.
Yes, but we (GStreamer) need to keep it working for all scenarios.
>
> > 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.
We *could* create a custom event sent upstream for tsdemux to notify
the source which PIDs it is interested in. That would enable lowering
the I/O some more.
At the cost of event more latency.
> > >
> > > 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.
Those two "reasons" are very different.
For 1: I still don't see the point (I'm assuming a particular stream
is a particular SPTS, you'd better record the PAT/PMT along with it,
else you'll never be able to play it back).
For 2: I just explained two solutions above (note: track switching
*also* included "I don't want to play any (a/v/s/..) track").
> >
> > 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)
So is it a SPTS (i.e. mpeg-ts packets, you have 0x47 every 188 bytes)
or PES interleaved (PES packets, you have 0x000001 every so often) ?
It's still not clear.
>
> > >
> > > 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).
And that "bare minimum stream info" ... includes at least the PMT. If
you don't do that, it's as if you wanted to playback an AVI/MOV/MKV/...
file without the headers.
>
> > 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.
Which is totally unacceptable. And you're also going under the
assumption that just specifying the "codec" type will be enough, which
is not the case (you potentially need a lot more info contained in the
descriptors of the PMT).
What you're essentially saying is:
"The kernel could provide the information (one way or another,
including not stripping the PAT/PMT) straight to the demuxer and just
use standard GStreamer stream selection... but we think that's too easy
of a solution, so instead we prefer to have the user/application
intercept some information via another medium, sprinkle some fuzzy
magic, and manually set a whole bunch of properties on an element"
Do you realize how cumbersome and convoluted that is ??
>
> > .. 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.
Yes, that's not what i'd call "demuxing" it's "PID filtering" and yes,
every single tuner/demod out there will be able to do PID filtering in
hardware. But stop calling it "hardware demuxer".
Demuxing is *more* than just filtering PID, it's analyzing the SI/PSI
to understand the structure of the underlying streams, exposing those
streams, reconstructing the PES streams, properly parsing PES headers
(and set PTS/DTS/.. accordingly) and a whole bunch of other time-related
handling.
> >
> > 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.
The generic solution is : don't strip out the PAT/PMT.
Edward
>
> > >
> > > Sudip
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/play-stream-without-parsing-PAT-PMT-tp4662984p4663019.html
> > > Sent from the GStreamer-devel mailing list archive at
> Nabble.com.
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > [hidden email]
> > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> > If you reply to this email, your message will be added to the
> discussion below:
> >
> http://gstreamer-devel.966125.n4.nabble.com/play-stream-without-parsing-PAT-PMT-tp4662984p4663022.html
> > To start a new topic under GStreamer-devel, email
> [hidden email]
> > To unsubscribe from play stream without parsing PAT/PMT, click
> here.
> > NAML
>
>
>
> ______________________________________________________________________
> View this message in context: Re: play stream without parsing PAT/PMT
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
--
Edward Hervey
bilboed at bilboed.com
More information about the gstreamer-devel
mailing list