Analogue TV formats

As mentioned over here I’ve recently updated the OMAPVideo module to use the TV-out for the main display if a TV is detected. To decide whether to generate a PAL or NTSC signal it checks the configured territory against a list held in the driver and picks the most appropriate signal type. However, what’s probably needed is an addition to the territory manager to allow the territory modules to indicate what signal format should be used for each territory.

I don’t have much experience with the territory modules, but I’m guessing the most appropriate place to add this feature would be as a new reason code to Service_International. This would allow the territory manager to contain a copy of the lookup table that OMAPVideo currently uses, defining the TV signal types for all current territories, while still allowing additional territory modules to augment or override the data.

For the details of the call, I can see us needing an enumeration-style interface, to cope with the fact that some territories use more than one of the main three colour standards (PAL, NTSC, SECAM):

In: R1 = &67 (Service_International)
    R2 = 10 (Reason code)
    R3 = Territory number
    R4 = -1 to start enumeration, else value from previous call
    R5 = preserved from previous call (or undefined at start of enumeration)
Out: R1 = 0 (service call claimed)
     R4 = colour system (0=PAL, 1=NTSC, 2=SECAM, etc.) or -1 for end of list
     R5 = mask of available standards
     R6 = flags:
          bit 0-2 - preference/prevalence of standard. 0 = least popular/preferred, 7 = most popular/preferred.
          bits 3-31 - reserved

• The mask in R5 corresponds to the letters used in the ITU standards, with bit 0 of the mask corresponding to A, 1 to B, etc. So R4=0 and R5=(1<<2)+(1<<7) would correspond to a territory that uses PAL-B and PAL-G.
• Since this is an enumeration-style interface, territory modules will have to make sure that only one module is allowed to respond to the call for any particular territory.
• If a video driver supports several of the standards that a territory supports, it can use bits 0-2 of R6 to determine which is the most popular format amongst the formats that the driver supports. There’s no requirement for a territory to return this information, and multiple standards can be marked as equally popular if required.
• Requiring R5 to be preserved from the previous call allows multiple instances of the same colour standard to be reported. E.g. if a territory uses both PAL-I and PAL-M, PAL-I may be given a higher preference value than PAL-M due to PAL-M support being less widespread.

Any thoughts? For reference on different TV formats, I’ve found this and this useful.

What about countries that use more than one colour system?

That’s the whole reason behind using an enumeration interface! E.g. if you’re in Afghanistan then the first call would return PAL B, the second call would return SECAM B, and the third call would return -1 to signify the end.

I probably had more exposure to TV standards than was healthy when I was working on various RISC OS set-top boxes! I’m not sure that the APIs that were used there translate particularly well to “desktop” RISC OS, since they were somewhat tied into support for Macrovision anti-copying technology.

The suffixes (eg. the “I” in “PAL-I”) weren’t allocated particularly logically, and single letters don’t uniquely identify all the standards. Since it’s unlikely that any country would introduce a new analogue TV standard at this point, I’d say it would make more sense just to enumerate all existing standards. In fact, I would suggest is it’s maybe not worth introducing anything relating the RF (VHF/UHF) part of the standards at this stage – I expect it’s unlikely that any new RISC OS hardware will feature an RF modulator?

The enumeration of different baseband video signals is much simpler than RF ones – no need to distinguish different bandwidths/channel spacings, range of frequencies used, audio subcarrier / NICAM etc. The list reduces to only (!) 7 unique standards worldwide, plus another 2 (NTSC 4.43 and PAL 60) used in the non-broadcast space for displaying NTSC content on PAL TVs:

The exact positioning of the horizontal blanking (and therefore the nominal number of pixels across the screen) also varies from standard to standard, although since they were defined before the age of digital sampling, this was specified in time units and don’t exactly match to pixel boundaries. The gory details are in ITU-R BT.470-6.

Wait… The OMAP and/or Broadcom can even output SÉCAM?

The suffixes (eg. the “I” in “PAL-I”) weren’t allocated particularly logically

Somehow I knew it wouldn’t be as simple as it looked!

In fact, I would suggest is it’s maybe not worth introducing anything relating the RF (VHF/UHF) part of the standards at this stage – I expect it’s unlikely that any new RISC OS hardware will feature an RF modulator?

Sounds sensible to me.

The list reduces to only (!) 7 unique standards worldwide, plus another 2 (NTSC 4.43 and PAL 60) used in the non-broadcast space for displaying NTSC content on PAL TVs: […]

Since there are only four attributes which identify each standard, would it be sensible to expose the values of those attributes, rather than the name of the standard? I.e.

R4 bits 0-1 = colour system
   bit 2 = lines/frame rate (0=525/29.97, 1=625/25)
   bits 3-5 = colour subcarrier (0=3.579545, 1=4.433619, etc.)
   bits 6 = 7.5 IRE pedestal
   bits 7-11 = preference/prevalence value
   bits 12-31 = reserved
R5 = pointer to textual name of standard (for configuration dialogs, etc.)

By listing the attributes of the standards it’s more clearcut exactly how the video encoder should be programmed in order to generate the required signal.

Wait… The OMAP and/or Broadcom can even output SÉCAM?

No. But that doesn’t mean we should pretend that it doesn’t exist.

By listing the attributes of the standards it’s more clearcut exactly how the video encoder should be programmed in order to generate the required signal.

I do wonder whether it’s reasonable to expect authors of Territory modules to know that level of detail. Perhaps the thing to do is to have a header file containing a named enumeration of bitpatterns for bits 0-7 as a single field, named after the TV standard, but sill assign them such that when they are evaluated as a set of smaller bitfields, they have the above meanings?

It might be worth listing the fields in order of importance to the production of a watchable picture. This would be:
1) lines / frame rate
2) colour subcarrier frequency
3) colour system
4) pedestal

Then, if when faced with hardware with limited capabilities, the driver had to choose between (say) the wrong frame rate and the right pedestal, or the right frame rate and the wrong pedestal, it would choose the latter.

Further, I’d suggest that the colour subcarrier field is only 2 bits wide and when SECAM is specified, the subcarrier field contains the pattern representing 4.433 MHz. Then if the hardware can’t do SECAM, the driver would fall back to PAL-B/D/G/H/I (which I believe most SECAM TVs will accept anyway) rather than, say, PAL combination-N.

Since there are only four attributes which identify each standard, would it be sensible to expose the values of those attributes, rather than the name of the standard?

You know, I can’t tell you – off the top of my head – what the freqs are for 50Hz (standard) PAL. It might be better to stick to names, which brings the list down to: PAL, PAL-M, NTSC, NTSC-443, SÉCAM.
There are others, as mentioned, for bodging NTSC onto a PAL TV, etc; but if we can support both PAL and NTSC natively in hardware, what reason would we have for supporting bastardised PAL-for-NTSC ?

Wait… The OMAP and/or Broadcom can even output SÉCAM?
No. But that doesn’t mean we should pretend that it doesn’t exist.

Being realistic, can any of these SoCs with video output support SÉCAM? I looked around a couple of nerdy-tech websites. All the digital boxes I could see support PAL/NTSC only. I have a handful of digital satellite receivers, a VCR, three DVD players, and an
ARM926 based PVR (a TI chip). Not one single device is capable of outputting SÉCAM (though the PVR can accept it via the tvp5150 chip).
TVs have been dual-standard in France since before the millennium, primarily because these newer digital thingies simply did not output SÉCAM.

http://en.wikipedia.org/wiki/SECAM#Problems_with_the_standard – second paragraph onwards.

That said, I think Ben’s approach is the most logical, to flag SÉCAM, but with a fallback to PAL.

TVs have been dual-standard in France since before the millennium, primarily because these newer digital thingies simply did not output SÉCAM.

Despite this, there still appears to be some support for the standard among relatively recent designs:

1. http://www.renesas.eu/products/soc/assp/av/enc_dec/3dyc_decode/d64012/index.jsp
2. http://www.arm.com/community/partners/display_product/rw/ProductId/3171/
3. http://www10.edacafe.com/nbc/articles/view_article.php?articleid=581312
4. http://www.design-reuse.com/news/25031/analog-video-multi-standard-decoder.html

All good ideas Ben. I think that’s the API sorted then, unless the horizontal blanking needs to be taken into account. I haven’t yet looked into how that fits into everything, but I’d hope that it’s something the OS/driver could just default to known-safe values on boot, and then leave the user free to fiddle with their MDFs until they get a display that’s correctly centred on their TV (much like *TV can be used to fine-tune the vertical position).

I was just about to comment on MDFs, because there are quite a few different modes needed to cope with all TVs (even before you tweak the precise position.)

16:9 or 4:3
Over-scan or not
Interlace or not. (CRTs not being good with interlaced)

I think these would be the resolutions needed (approximately)
1024 × 575, 1024 × 278, 760 × 575, 760 × 278
854 × 480, 640 × 480, 854 × 240, 640 × 240

And that is just for 625 TV

There are others, as mentioned, for bodging NTSC onto a PAL TV, etc; but if we can support both PAL and NTSC natively in hardware, what reason would we have for supporting bastardised PAL-for-NTSC ?

I doubt there are any NTSC 4.43 or PAL 60 encoders that can’t also generate true PAL and NTSC. It’s more of a question of what the TV that it’s attached to will lock onto. When I was at Pace, we had dozens of different TVs for testing purposes, and some would display one correctly and not the other. Admittedly the wholesale replacement of CRT TVs with LCD ones in recent years (at least in the Western world) has probably changed the situation somewhat, but it might still be useful to someone to have them available.

Also note that no countries broadcast in NTSC 4.43 or PAL 60, so you’d never see them reported by the Territory module. I’m assuming there will be some API to override the TV standard specified by the Territory – in the same way as you can override the keyboard, timezone etc – so they could reasonably be options in that API instead.

Also note that no countries broadcast in NTSC 4.43 or PAL 60,

I’m glad of that. ;-)

But we’re really talking of baseband (CVBS/s-video) video signals here, aren’t we? If it is broadcast standards, for completeness we’d need to mention that France’s SÉCAM is different to everybody else’s (positive modulation). But it all looks the same when demodulated. And it definitely all looks the same when analogue is phased out (France already has; hasn’t the UK also?).

I’m assuming there will be some API to override the TV standard specified by the Territory – in the same way as you can override the keyboard, timezone etc – so they could reasonably be options in that API instead.

I think I’m going to have to patch together my own territory. I live in France, want my system in English, metric, YYYY/MM/DD style dates, euro currency. Currently use an AZERTY keyboard {*} (but it’s bloody awful trying to find where symbols are hidden – I have loads of respect for Frenchies that can actually get code written with that layout – so hopefully a friend will be bringing a UK QWERTY keyboard).
For sure it isn’t a regular setup, but it is something that ought to be possible without too many headaches. I think when Acorn defined the Territory system, they made a lot of assumptions so it isn’t as flexible as it ought to be. I could say more, but I want to dig up my PRMs first so I don’t end up speaking crap (…like normal).

* – !ConfiX talks to me in French. It appears to use the keyboard setting to determine the system language!

With the price of the Pi, it is likely to be used with some very old kit.

It may make sense to include the broadcast modulation (or at least the capability to add it) in case someone wants to use one of the boards as the basis of system for display on old TVs. It would also make sense to have the ability to add other frame rates (e.g. 405) for a similar purpose.

I think the configure should be expanded to have a second section for screen for the TV output.
it would have a frame section and a colour section.

The frame section would have the choice of auto (from territory module), 525, 525-J and 625 (this is where other systems might be added), it would also have interlace on/off.

The colour section (or color section depending on territory :) ) would have the choices of auto, monochrome, and all the encoders offered by the hardware in use.

Auto would use the territory for the preferred system, however when that isn’t available, then a second choice should be used. A question is whether that should come from the territory module or just a default set of choices.

PAL M, N and SECAM are less likely to be supported by the encoders.

Not being able to automatically set a second choice that will work for most TVs in that region wouldn’t be a disaster, because you would get a monochrome picture.

It is likely that virtually all SECAM TVs would work with PAL B/G/D/K/I if they support any other systems. (Likely on modern kit.)

I would expect modern PAL M TVs (Brazil) to support NTSC.

It is possible that in PAL-N regions, NTSC might be the best fallback, in which case the auto modes for frame and colour would need to be linked for those territories.

I’m assuming there will be some API to override the TV standard specified by the Territory – in the same way as you can override the keyboard, timezone etc – so they could reasonably be options in that API instead.

That’s the plan, yes. That functionality should come along when I get round to dealing with the multiple graphics drivers/multiple heads part of the GraphicsV improvements (since the user could – in theory – have multiple TV outputs, and want each one configured for a different signal type!)

It may make sense to include the broadcast modulation (or at least the capability to add it) in case someone wants to use one of the boards as the basis of system for display on old TVs.

By specifying the different attributes of the signal format, there’s plenty of scope for extending the API to specify more attributes in future.

Also if Wikipedia is to be believed, it looks like we’ll need to support 525/30 for PAL M/PAL 60, so we’ll need two bits for lines/frame rate instead of one.

With the price of the Pi, it is likely to be used with some very old kit.

That’s fair enough. It’s just a shame it is composite, not s-video. Hey – welcome back twinklies in MODE 0 on a telly. ;-)

I think the configure should be expanded to have a second section for screen for the TV output. it would have a frame section and a colour section.

Good idea.
Additionally, FWIW, I believe Configure needs to be reformatted slightly as some screens go off the bottom of my Beagle’s PAL display; I’d imagine RPi behaviour would be similar.

The colour section (or color section depending on territory :) )

Does Windows 7 British version still say “Favorites” in Explorer’s menus? Or things talking about being, or to be “canceled”?
Sorry – just irks me that back in the day XP that wasn’t bundled cost a fair packet and yet the “British” edition still talks to me in American.

It is likely that virtually all SECAM TVs would work with PAL B/G/D/K/I if they support any other systems. (Likely on modern kit.)

Yes – because the underlying base video (at line level) is the same for PAL and SÉCAM, it’s the colour encoding that differs.

Hi Rick,

I guess ConfiX uses ResFind to switch between languages. ResFind is pre-territory and is still popular (e.g. used in SparkFS, CDBurn/CDVDBurn). It decides the language based on your current “country” setting, mainly because most countries never got their own Territory module.

I know that there was a ResFind which used the Territory to choose the language…

Additionally, FWIW, I believe Configure needs to be reformatted slightly as some screens go off the bottom of my Beagle’s PAL display; I’d imagine RPi behaviour would be similar.

Yes. One of the many things on my “once my Pandora arrives” list is to go through and make sure all the configure plugins display properly (probably just a case of adding scroll bars to them all). Although I guess that task isn’t intrinsically linked to having a Pandora, since 640×480 is smaller than 800×480.

Also if Wikipedia is to be believed, it looks like we’ll need to support 525/30 for PAL M/PAL 60, so we’ll need two bits for lines/frame rate instead of one.

Good point, yes PAL-M is technically 30 Hz rather than (30000÷1001) Hz, I’d forgotten that. ITU-R BT.470-6 is more definitive than Wikipedia, and it agrees.

As a historical point, back in the days of black-and-white TV, the US used a frame rate of 30 Hz (and a field rate of 60 Hz), based upon the AC mains frequency. When NTSC standardised colour, they tweaked it slightly to avoid cross-talk from the 4.5 MHz sound subcarrier. I guess Brazil either never got that message, live with the cross-talk, or changed the sound carrier instead (I’ve never seen any technical details on Brazilian TV audio).

Since PAL 60 and NTSC 4.43 were primarily designed as a fudge for displaying US content on European TVs, they’re not formally standardised, but I’d guess that they run at 29.97 Hz because they’re just mangled versions of NTSC-M.

[…] is to go through and make sure all the configure plugins display properly

I vaguely recall looking at this a while ago, since the filer plugin has got very tall and didn’t quite fit onto a Risc PC with no MDF loaded. Looking in the toolbox resources there does appear to be a graceful fallback version of the window (with scroll bars) but for some reason it wasn’t being selected. I’m wondering if it’s something simple like reading the screen size and getting X & Y mixed up or forgetting to take into account the eigen factor?

I’m wondering if it’s something simple like reading the screen size and getting X & Y mixed up or forgetting to take into account the eigen factor?

It’s because the screen height is tested against MinWindowHeight which is a constant set to 1100 OS units. If you choose a mode smaller than this (640×480) then the scroll bar appears, on larger modes (800×600 and beyond) the scroll bar is not used.

Looking in the toolbox resources there does appear to be a graceful fallback version of the window (with scroll bars) but for some reason it wasn’t being selected.

Hmm, I don’t really like the idea of there being two versions of the same window – that’s just bound to cause problems when someone updates one but not the other. A better approach would be to just show/hide the scroll bars as necessary. I think I fixed one plugin recently to just have scrollbars all the time, so I’ll have to remember to go through them all and make sure they behave in consistent manners.

Scrollbars don’t take up that much space. I vote for just adding scrollbars to everything.

Scrollbars when needed across the board would be nice. It would separate RISC OS from the Linux distros I’ve seen and from Windows, because they regularly have windows that don’t work on small screens.