Re: [xine-devel] Re: Re: Satellite input plugin

[Andre' D. <an...@gm...>]

Hi,

According to Mauro Borghi:
> shaheed wrote:
> >On Monday 08 April 2002 12:25 pm, Mauro Borghi wrote:
> >
> >>For tuning, we used "szap" code as a starting point, which uses a config
> >>file (txt) in order to give a nickname to each channel, and map them to
> >>freq,pol,srate,vpid,apid,...
> >>In this way we simply invoke e.g. 'xine dvbs://onyx'
> >
> >Of course the right solution is to use the NIT.
> 
> AFAIK, the NIT carries information about one provider at a time: this means 
> that you need to gather information from _many_ NITs in order to have the 
> complete table of available channels from a given satellite.

To clear it up - the NIT carries the information about the frequency,
polarization, fec and the other infos needed to tune to a digital
transponder for all tranponders in a whole network (cable, sat, etc.).

After you have that information you need to scan the SDT on the transponder
you are tuned to to find out the service ids of all the services available.
After that you start to scan pat and pmt.

> How would you do then? Would you reconstruct such information every time 
> you tune a transponder? And how would you tell xine "I want MTV now"?

have a transponder list mapping original network id and transport stream id
to a frequency/pol/sr/fec/... combination and a service list mapping
originalnetwork id, transport stream id, service id and network id to a
frontend.

> >>> Currently, all the communication with the dvb card in localized in the
> >>> input plugin and all the si parsing is in the ts demuxer.
> >>>
> >>> The problem is how to control the filtering of pids.
> >>>
> >>> - Another alternative is adding lots of dvb-specific variables and
> >>> call-backs to the common input_plugin structure so the demuxer can call
> >>> the input plugin and control which pids to filter. This doesn't seem
> >>> very tidy either.
> >>
> >>Agreed.

actually, i think that to not be such a bad thing. this way, you can filter
out unneccessary data already in hardware if possible, but still have the
option to do it in software, too.

> >>> - Yet another is to not filter in the driver at all, but to send the
> >>> whole transport stream to the demuxer and have the filtering done there.
> >>> Although this seems pretty clean, I doubt that the performance would be
> >>> acceptable.
> >>
> >>I agree: why deal with a 40 Mbps stream when you are only using up to 10
> >>Mbps of it?
> >
> >It is possible to make demultiplexing go VERY fast. On a 466 Mhz Alpha, 
> >for example, at over 1 Gbps. So, I would suggest to do it right, in the 
> >demuxer. Others will thank you for this later.

That's not the point, imho. Demultiplexing the TS stream has to be done
nonetheless and after thinking about it, it's not really a performance
issue, you are right. Implementing the other proposal would just be an
improvement to reduce overall load (and to enable all DVB card users to use
it, as stated in my other mail).

> >>> - Finally, although more work, would be to use something like dvbtune
> >>> (at linuxstb.org) to create an xml transponder map and then build a ui
> >>> to navigate it and create an mrl. In this case, the mrl would contain
> >>> all pids to select from the transport stream.
> >
> >If you choose not to follow the suggestion above, but to do the filtering 
> >in the input plugin, please, please make the control point a program 
> >number, NOT a list of PIDs. That would preserve the ability for the 
> >demuxer to support multiple-language audio etc.

not only a program number, only the combination of service-id/original
network id/transport stream id is an accurate description of a dvb service.

> There is a "demux" stage in the Linux DVB API from Convergence, which is 
> _supposed_ to do packet filtering (PID based).

its not only supposed to do so, it does so.

> Using the Hauppauge WinTV Nova, you can setup up to 8 filters, i.e. extract 
> a TS with up to 8 PIDs in it. I don't know if this filtering is done in 
> hardware or in the kernel driver, but since this is a useful operation, I 
> want to use it!

for the Nova, it's done in the driver. For full featured cards it's done in
hardware.

> I do not even know if it is possible at all to get the whole stream coming 
> from a transponder (45Mbps or so) -- if anybody knows, please tell me!

That's possible with Nova cards only, use 0x2000 as pid.

> I agree (in a longer term perspective) on the fact that we might need more 
> than just 2 PIDs at a time, to eventually support multiple-language, 
> teletext and subtitles...

yes.

> and I think, if and when this need will arise, it 
> will be quite easy to find the right way to satisfy it.
> Presently, if I want the opportunity to watch, say, EuroNews both in 
> english and in italian, I find easy to have 2 config lines which differ 
> only in a) the channel nickname (e.g. EuroNews-en, EuroNews-it) and b) the 
> audio PID.

eventually, switching languages of a DVB service should be no different than
switching languages on a DVD from the user's point of view.

But selecting services and tuning from a clickable or so window in xine
requires quite some changes in xine, I think James wrote something about him
wanting to implement this stuff some time ago. Anybody knows if he made some
progress? James?


Greets,
André