If you are creating for web distribution you can totally ignore broadcast safe colors. I work in a television station that broadcasts a digital signal and nearly every editor still edits for broadcast safe, which is mostly a holdover from analog days.

That said, really hot whites do not play very well when edited or broadcast, even digitally. If you look very closely, super hot whites will cause noticeable aliasing. At least in my experience. Another reason, especially with text and graphics, which is my main area, is that pure white just never really looks that good on tv. back off a little and it looks better.

I am not a professional colorist or television engineer, so I'm just telling you this based on personal experience.

For web, I'd pretty much ignore ntsc safe colors. Others may differ on this. I'd be interested to hear from a pro color correction person on this as well.

balazer is correct for broadcast delivery, but for web delivery the spec is generally RGB 0-255. For web delivery the rec.601 & rec.709 specs can be ignored. Just be sure you don't clip the whites if the original footage is shot on a pro video camera as they use the rec601/709 spec for levels in the camera i.e. 16-235. Most of these cameras will allow levels up to bit 255 to allow extra headroom in the whites. Programs like Avid have settings to export to RGB 0-255 levels or rec601/709 16-235 levels. Let me know if you need more detailed info on your particular workflow as I deal with these issues every day in my job.

Delivering rec.709 for a venue that's mostly viewed on sRGB displays is just sad. Scratch that, rec.709 broadcast spec is just sad. Hopefully one day we're finally rid of this lowest common denominator holdover business from the bad-old-days of analog video.

There's no such thing as un-safe colors in the digital realm. I would seriously like to hear the yarn someone might spin that made a case for "un-safe" colors and levels in the world of today and digital televisions that aren't radically different than standard computer monitors.

I can understand gamma issues related to the need for higher light levels and throw with an LCD television versus a monitor you sit a couple feet from, if that, but the rest is stupid analog tricks and compression of the signal should have been handled by the digital set top boxes or receivers that are necessary for an old analog set to receive any contemporary form of broadcast signal anyway.

That BBC document...it's completely obvious in several parts it was written by old men who don't understand content. The relevance of broadcast is shrinking so hopefully this will one day cleanse content creators from having to deal with these automatons in lab coats.

GD video engineers.

Perhaps he's mistaking working in and exporting sRGB colorspace for exporting in an RGB format.

It was a mistake for both Youtube and VIMEO to standardize on rec.709 given so few users actually look at their content on rec.709 displays. Perhaps this was wishful thinking. If they support full-swing then it's merely them boning their customers on gamma, and it's just another day in digital media, potentially, since the gamma of rec.709 isn't well defined and there might be as many or more professionals working at 2.2 as there are at 2.4 as it turns out.

What both providers should be doing is inspect the header of the file being uploaded and respect the choices of the original content creator. The information is there they've just chosen to or failed to respect their customer. Worse for streams at 240P which reportedly get encoded with 601 gamut (Youtube).