Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thoughts on VDR evolution - my 2 cent
Carsten Koch writes:
> It depends.
> If the firmware does the re-insertion automatically,
> you are right: we would gain nothing over analog teletext.
> But then it would also be impossible to use this path
> for the OSD, so I could not possibly have meant this. ;-)
>
> The path that I envisioned was: vdr reads the teletext
> data from /dev/vbi and collects it on hard disk or in RAM.
> However, instead of the OSD it uses re-insertion to feed
How does it get the data back to the ARM for re-insertion
(and see below) ?
Via the old "reliable" OSD polling data interface?
Or via the new one nobody has written yet?
> ANY data (which could happen to be collected teletext,
> but could also be vdr's own menus) to the TV - on a fixed
> page number (say, 100).
No, this is not possible.
The RTSL (Real Time Support Library) which controls the low level
functions of the firmware only offers one function for re-insertion
and there you have to give it a PID and a logical channel which
corresponds to one of the 32 filters. You cannot feed it other data.
The RTSL is only available as a binary and no datasheet mentions
specifics about the re-insertion process.
I guess it is somehow written into the video encoder microcode which
is also explained nowhere.
> > What I would really like to have is a faster OSD.
>
> No argument at all from me here.
> That would be the solution, my idea would be merely a workaround.
>
> I, too, would welcome Ralph's comments on speed and
> reliability of the OSD.
Well, itīs slow and buggy :-)
Ralph
Home |
Main Index |
Thread Index