play stream without parsing PAT/PMT

[Edward Hervey]

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).

  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).

> 
> 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.

  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.

> 
> 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).

  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
  * Have it accept data (for example only the PAT/PMT streams) from
dvbsrc.
  * Have it signal upstream (with an event) to the dvbsrc which PIDs it
is interested in (this will introduce latency though).

 .. 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.

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).

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.

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.
> 
> 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
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel