[linux-dvb] Re: Suggestion for channel tuning

["Yu, Jacob" <jyu@opentv.com>]

Please see comments inserted.


Jacob
-----Original Message-----
From: Felix Domke [mailto:tmbinc@gmx.net]
Sent: Saturday, April 21, 2001 6:10 AM
To: linux-dvb@linuxtv.org
Subject: [linux-dvb] Re: Suggestion for channel tuning


>> Has anyone else had any experience of tuning like this?  It seems to me
that
>> ISO-13818 is implying that the only parameters needed to tune a channel
is
>> the service_id.  This makes sense to me - at least on Astra 28, the
channels
>> change PIDs quite frequently.
> Hm i thought one need the network_id (or even transponder_id?) as well,
but
> i'm not sure.

This depends.  If you have access to multiple transponders or multiplexes
you need
NIT or SDT to sort out the information.

> at the moment i'm storing a list of transponders (with
transport_stream_id,
> network_id and frontend-specific tuning parameters - one could get them
via
> the NIT, i think, but that's very slow then... the en300468 says that one
> could (or should) store the NIT for faster tuning, which implies for me
that
> it's the only thing one should cache.), together with a service list
> (service_id, service_name and service-type).

Again this depends too.  Ususaly, at startup, IRD or SetTop caches NIT of
actual transport
for fast access.  To uniquely identify a service, you need
"orignial_network_id",
"transport_stream_id" and "service_id".

> if the user selects one channel, i first tune to the transponder, get the
> PAT, PMT and then tune in the channel.
>
> i think it may make sense to store some "default" pids there, for faster
> zapping. if there are other PIDs given in the PMT, one could change after
> reading the PMT and store them as new default settings.

PID assignment can change on the fly for regular service or program so
storing default PIDs
is not typical.

> one HAVE to go trough the SDT to support, for example, NVOD the correct
way.
>
> but my code still sucks, because it waits too often and slows down the
whole
> thing (especially user input).
>
> i'm thinking of rewriting it so i use a event-driven mainloop (like the
> glib), where one can read the tables in the background (especially the
EIT),
> handling user input and, for example, have some kind of callback (or
> signal/slot) when the EIT data is there to display it. there could be
> another signal which informs the decoder of changed PIDs (maybe they
change
> WHILE we're looking that channel?)
>
> there is somehow no real open-source library that does this properly.
>
> maybe we could write such a library, based on the nokia-api and maybe QT
> (without that gui-stuff of course), since i don't like gtk/glib really
much
> (too much OO C-code ;), but maybe gtk is better, we'll see.
>
> bye,
> felix domke



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe
linux-dvb" as subject.



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.