Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Please, support PV!
It allows to keep PV going, with more focus towards AI, but keeping be one of the few truly independent places.
Broadcast-safe video
  • What are broadcast safe limits for digital video dedicated for web distribution? As I have understood (correct me if I'm wrong) broadcast safe limits for minimum black level and maximum white level are mainly considered as analog displaying and broadcasting issues.

    Alexis van Hurkman states in his Color Correction Handbook that "For purposes of color correction you can ignore analog NTSC video requirements for a black signal level of 7.5 IRE, because that is an analog issue that video output interfaces typically take care of during output."

    In other chapter he says that "Maximum preferred white value for most broadcasters is 235, 235, 235, which sits about 93 percent when analyzed using a Waveform Monitor."

    Should I use broadcast safe limits and what are they? Googling gives me incoherent information. Thank you.

  • 11 Replies sorted by
  • 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.

  • The valid ranges for everything from black to white as defined by rec.601 and rec.709 (8-bit) are

    • Y=16-235

    • U and V=16-240

    Values outside these ranges may be allowed for broadcast in some circumstances, but they translate to colors brighter than white or darker than black, so there's no reason to use them. (they'll be clipped to black or white by the display) If you constrain the video to the rec.601/709 ranges before compression, it will be just barely outside of those ranges after compression.

    If you google 'delivery specification' plus some channel name, you'll find examples. The BBC, for example, says RGB signals must be in the range -5% to 105%, and the Y channel in the range -1% to 103% relative to rec.709. http://dpp-assets.s3.amazonaws.com/wp-content/uploads/specs/bbc/TechnicalDeliveryStandardsBBC.pdf

  • 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.

  • YouTube and Vimeo recommend uploading in rec.709-compliant YUV h.264 .mp4. @caveport, I don't know what RGB format you think you're uploading. Popular video formats are not RGB.

  • 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.

  • Yep, for any web publishing, you should be exporting in RGB color space. Anything else, it's rec601/709. There's no harm in working to safe color levels either for web delivery

  • 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.

  • @BurnetRhoades

    Looking at 4K rec 2020 standards they still implemented some restrictive values ranges and safe colors. Now argument being that you can use this values for time and other signals. I really do not understand that prevented to use for it just different data packets.

  • GD video engineers.

  • @mrbill, what RGB format do you think you should be uploading for the web? Vimeo and YouTube recommend YUV formats.

  • 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).