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