Compatibility of Prores codecs

[hino]

Hi.

 

When using Prores codecs in Watchout6.1.6,

Top and bottom of video level is over the range.

 

I tested using 16steps grayscale.

 

In other app:QuickTimePlayer,Premiere,finalcut etc...,

It's no problem.

 

When using other codec:animation,h264,mpeg2,hap...,

It's no problem in Watchout.

 

Dose watchout have compatibility of Prores codecs perfectly?

 

I upload  tested file on link below:

 

https://srv06.bitsend.jp/download/9a80634f7a5c4cbf60d7019b42c764c3.html

 

thank you.

[Erik Rönnqvist]

The prores decoder in watchout assumes that the video is encoded in limited range, meaning that the luma range (translated to 8 bits) is assumed to be 16-235, and the chroma range is assumed to be 16-240. In the process of decoding, these ranges are stretched to 0-255, which also means that the values 0-16 will all be mapped to 0, and the values 235(240)-255 will all be mapped to 255 for luma(chroma). This is the effect you are seeing in the sample movie you provided. The two leftmost bars have luma 0 and 16, which will both be mapped to 0 for display. Same goes for the two rightmost bars which have luma 239 and 255, which will both be mapped to 255, making them look identical. 

To further complicate things, in the header of a prores file, there is a field indicating if the pixels are in  ITU-R BT.709-2 or ITU-R BT.601-4, which could be used to adjust the stretching automatically. Unfortunately this field is quite often empty, contains an incorrect value or simply says unknown, which makes it impossible to use. 

Which way is the correct way of doing it (stretching or no stretching) is up for discussion. 

 

/Erik

[Erik Rönnqvist]

I have now tried encoding with some prores encoders, and all of them encode to full range by default. This means that the stretching does not really make sense anymore. This will be fixed in the next release of Watchout. 

As a side note, some years ago, when the prores decoder was implemented in Watchout, this was not the case. Many encoders used the limited range then. 

 

 

/Erik 

[hino]

Thanks Erik.

 

I'm looking forward to the next release..

 

By the way,

about quicktime movies,

How are you getting the difference between limited range and full range?

 

Is there useful application??

 

[Erik Rönnqvist]

Do you mean how you can tell if the movie is limited or full range? The easiest way is to encode a video just like you did and play it in a player you trust not to do any conversions (I would tend to believe VLC is a good choice here). Set the desktop background to black and compare it to the darkest bar in the video. If the darkest bar in the video is lighter than the black desktop background, the video is most likely in limited range. 

 

/Erik 

[matkeane]

To further complicate things, in the header of a prores file, there is a field indicating if the pixels are in  ITU-R BT.709-2 or ITU-R BT.601-4, which could be used to adjust the stretching automatically. Unfortunately this field is quite often empty, contains an incorrect value or simply says unknown, which makes it impossible to use. 

Which way is the correct way of doing it (stretching or no stretching) is up for discussion. 

 

/Erik

 

 

Hi Erik,

 

I am a little surprised by the assumption that r601 should be used by default by the ProRes decoder. I haven't encoded anything in the r601 colour space since the days of PAL production. Since HD production took over, and content is generally being produced for on-screen or video projection instead of broadcast TV, r709 is - for me at least - the default. Maybe other Watchout users have use-cases that require r601, but I would think that modifying the colour space of user-generated content should be the exception, not the rule, especially if other video formats are being handled in a different way.