Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teletext for Raspberry Pi

github.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Teletext for Raspberry Pi

#11

Post by jamesbrownuhh »

lovelearning wrote: post #7

From the code, BCM2835 peripherals pdf and [1], I gather that this is writing to the pixelvalve1 region of the Videocore to change PAL resolution. But there's nothing about this in the Videocore docs. Anybody here knows where this is documented and what pixelvalve0 in [1] is? [1]: https://github.com/msperl/rpi-registers/blob/master/md/READM...

As I understand it, it's moving the active display area of the analogue output to a position 16 lines earlier than it would normally be. In effect that moves the top of the display area into the Vertical Blanking Interval.

From there the code is painting the required 0 and 1 pulses as a bitmap onto the top region of the Pi's display (which is now in the VBI area that teletext sets will be looking at.) Voila - right signal, right place, right time. Very elegant solution.

Re: Teletext for Raspberry Pi

#12

Post by vertex-four »

hayksaakian wrote: post #6

given that most TVs support this type of thing, I wonder if there's anything useful that could be built with the software.

TV information services for hotels? Though the ones I go to already have something technically better, I assume via custom firmware.

Re: Teletext for Raspberry Pi

#13

Post by omribahumi »

jamesbrownuhh wrote: post #8
bestham wrote: post #5

Earlier quoted context omitted.

"UPDATE: This demo will also crash modern LCD TV's teletext decoder. It's because the demo sends the same packet over and over and new TVs can't handle it..." It has nothing to do with digital or analog, it't that most modern TTV decoders don't like the format that this app sends data in.

It's a bit more complicated than that - as with all matters pertaining to agreed broadcast standards, the demo is sending data in the correct format but in a way which you would be unlikely to see in 'normal' use, hence the code drives a truck load of edge cases through the various TV manufacturers' implementation of the spec, and some of them fall over and crash hard. To explain it in a bit more detail: Teletext wor…

I wonder if this can be exploited somehow to do something cool with those TVs

Re: Teletext for Raspberry Pi

#14

Post by ali1234 »

lovelearning wrote: post #7

From the code, BCM2835 peripherals pdf and [1], I gather that this is writing to the pixelvalve1 region of the Videocore to change PAL resolution. But there's nothing about this in the Videocore docs. Anybody here knows where this is documented and what pixelvalve0 in [1] is? [1]: https://github.com/msperl/rpi-registers/blob/master/md/READM...

It isn't documented. I figured it out by looking at the github you linked and then looking at register values and trying to guess what they mean.

About the pixel valves.

The chip has three pixel valves. One is for DSI0, one is for DSI1, and the final one (pixel valve 2) is shared between HDMI and composite.

Re: Teletext for Raspberry Pi

#15

Post by rnhmjoj »

jamesbrownuhh wrote: post #8
bestham wrote: post #5

Earlier quoted context omitted.

"UPDATE: This demo will also crash modern LCD TV's teletext decoder. It's because the demo sends the same packet over and over and new TVs can't handle it..." It has nothing to do with digital or analog, it't that most modern TTV decoders don't like the format that this app sends data in.

It's a bit more complicated than that - as with all matters pertaining to agreed broadcast standards, the demo is sending data in the correct format but in a way which you would be unlikely to see in 'normal' use, hence the code drives a truck load of edge cases through the various TV manufacturers' implementation of the spec, and some of them fall over and crash hard. To explain it in a bit more detail: Teletext wor…

Great explanation. Thank you.

Re: Teletext for Raspberry Pi

#16

Post by Cort3z »

jamesbrownuhh wrote: post #8
bestham wrote: post #5

Earlier quoted context omitted.

"UPDATE: This demo will also crash modern LCD TV's teletext decoder. It's because the demo sends the same packet over and over and new TVs can't handle it..." It has nothing to do with digital or analog, it't that most modern TTV decoders don't like the format that this app sends data in.

It's a bit more complicated than that - as with all matters pertaining to agreed broadcast standards, the demo is sending data in the correct format but in a way which you would be unlikely to see in 'normal' use, hence the code drives a truck load of edge cases through the various TV manufacturers' implementation of the spec, and some of them fall over and crash hard. To explain it in a bit more detail: Teletext wor…

Wonder if this can be used maliciously. Sounds like a major security issue to me.

Re: Teletext for Raspberry Pi

#18

Post by TazeTSchnitzel »

Cort3z wrote: post #16
jamesbrownuhh wrote: post #8

Earlier quoted context omitted.

It's a bit more complicated than that - as with all matters pertaining to agreed broadcast standards, the demo is sending data in the correct format but in a way which you would be unlikely to see in 'normal' use, hence the code drives a truck load of edge cases through the various TV manufacturers' implementation of the spec, and some of them fall over and crash hard. To explain it in a bit more detail: Teletext wor…

Wonder if this can be used maliciously. Sounds like a major security issue to me.

If it's a simple stack overflow or buffer overrun, then given that they're plain binary data packets, it should be pretty easy to exploit.

Re: Teletext for Raspberry Pi

#19

Post by lovelearning »

ali1234 wrote: post #14
lovelearning wrote: post #7

From the code, BCM2835 peripherals pdf and [1], I gather that this is writing to the pixelvalve1 region of the Videocore to change PAL resolution. But there's nothing about this in the Videocore docs. Anybody here knows where this is documented and what pixelvalve0 in [1] is? [1]: https://github.com/msperl/rpi-registers/blob/master/md/READM...

It isn't documented. I figured it out by looking at the github you linked and then looking at register values and trying to guess what they mean. About the pixel valves. The chip has three pixel valves. One is for DSI0, one is for DSI1, and the final one (pixel valve 2) is shared between HDMI and composite.

Thank you for the info, Alistair! Nice work.

Re: Teletext for Raspberry Pi

#20

Post by mschuster91 »

TazeTSchnitzel wrote: post #18
Cort3z wrote: post #16

Earlier quoted context omitted.

Wonder if this can be used maliciously. Sounds like a major security issue to me.

If it's a simple stack overflow or buffer overrun, then given that they're plain binary data packets, it should be pretty easy to exploit.

800 packets/sec x 40 byte/packet = 32 kByte/sec data throughput. Plenty of space for a nice exploit.

Heh, I wonder what happens if one could modify a DOCSIS modem to transmit on a DVB channel - in theory you could compromise an entire house, or worse, an entire block (depending on where the DOCSIS concentrator filters out uplink frequencies) by transmitting a fake DVB-C channel... it might even be better to look for problems in the DVB EPG code, because TV PC software can be better debugged.

Post reply on HN