[opendtv] Re: Google: Upload High Dynamic Range (HDR) videos (also streaming with Chromecast)

  • From: Jeroen Stessen <jeroen.stessen@xxxxxxxxxxx>
  • To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
  • Date: Mon, 21 Nov 2016 10:01:43 +0000

Hello friends,

On 2016-11-21 05:21, Manfredi, Albert E wrote:
We covered this, Craig. The transmission standard can be made compatible with 
SDR monitors, with metadata added for HDR displays. Read Jeroen's paper.

While I was at IBC I suffered a stroke, and since then I've been in rehab and 
not doing much other work. I hope to return part-time to my job soon, minus a 
functioning right hand. I shall have to write shorter stories with my left. But 
enough about that.

The Philips HDR project has been joined with the Technicolor HDR project, and 
the result could be seen in multiple places on the IBC floor. It is still a 
compatible system: we transmit one grade, preferably SDR, plus the metadata to 
generate other grades from it. That conversion is done on the fly by the (HDR) 
receiver, on simple hardware. The SDR receiver does not need to do any 
processing, i.e. we are legacy-compatible. The metadata can be generated 
manually, HDR-to-SDR by a colorist, or automatically and in real-time by an 
algorithm. I did much of the work on that. The same metadata can be applied to 
forward and inverse DR conversion, that's just simple math.

Compared to HLG, which also wants to be backwards compatible, our SDR grade is 
more accurate and we have better creative control over it. But we need to get 
our metadata across intact, at least to the HDR receivers. It's only a handful 
of bytes per frame, but it's needed. The specifics have been submitted in an 
ETSI standard.

You might think that receiver-side conversion of a single video signal matters 
only for broadcast, but also for a multicast/streaming content provider it is 
important to not have to store too many versions or grades. We all know how the 
amount of content on Google/Youtube grows exponentially. Those servers are 
expensive and eat power.

Best,
Jeroen

Other related posts: