Subject: [Cellar] [PATCH FFV1] Median Predictor formula update

From: Jerome Martinez <[email-masked]>
Date: Tue, 6 Sep 2016 18:56:17 +0200

Some streams in the wild were found not conforming to current 
specification. This patch describes what a FFV1 decoder should do in 
such case, and also what an encoder should do in order to permit correct 
decoding by decoders in the wild (the current goal is to describe what 
exists, so we will change the expected behavior only in the next version 
of the bitstream).
Impacted streams are FFV1 configured with 16-bit YCbCr color space and 
Range Coder coder (this includes 16-bit gray because it is YCbCr color 
space with chroma deactivated).

From 5cbb6ad48d080b4169a438685384ef9bc0a43fdf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Tue, 6 Sep 2016 18:43:21 +0200
Subject: [PATCH] Median Predictor formula update

In order to be compatible with files in the wild
---
 ffv1.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/ffv1.md b/ffv1.md
index f996595..24d5e1c 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -167,6 +167,18 @@ left, top, diag are the left, top and left-top samples
 
 Note, this is also used in [JPEG-LS and HuffYuv](#references).
 
+Exception for the media predictor:
+if colorspace_type == 0 && bits_per_raw_sample == 16 && ( coder_type == 1 || coder_type == 2 ), the following media predictor MUST be used:
+
+median(left16s, top16s, left16s + top16s - diag16s)
+
+with:  
+- left16s = left >= 32768 ? ( left - 65536 ) : left  
+- top16s = top >= 32768 ? ( top - 65536 ) : top  
+- diag16s = diag >= 32768 ? ( diag - 65536 ) : diag  
+
+Background: a two's complement signed 16-bit signed integer was used for storing pixel values in all known implementations of FFV1 bitstream. So in some circumstances, the most significant bit was wrongly interpreted (used as a sign bit instead of the 16th bit of an unsigned integer). Note that when the issue is discovered, the only configuration of all known implementations being impacted is 16-bit YCbCr color space with Range Coder coder, as other potentially impacted configurations (e.g. 15/16-bit JPEG 2000 RCT color space with Range Coder coder, or 16-bit any color space with Golomb Rice coder) were implemented nowhere. In the meanwhile, 16-bit JPEG 2000 RCT color space with Range Coder coder was implemented without this issue in one implementation and validated by one conformance checker. It is expected (to be confirmed) to remove this exception for the media predictor in the next version of the bitstream.
+
 ## Context
 
 |   |   |   |   |
-- 
2.7.0.windows.1

---

From: Luca Barbato <[email-masked]>
Date: Tue, 6 Sep 2016 21:50:03 +0200

> space with chroma deactivated).

Maybe we can make that generic in case somebody is creative enough to
try to use even higher bitdepth ?

lu

---

From: Jerome Martinez <[email-masked]>
Date: Tue, 6 Sep 2016 22:09:10 +0200

> try to use even higher bitdepth ?

I don't follow: the specification supports any bit depth, so people 
wanting to use e.g. bits_per_raw_sample = 1000 can do it (if they have 
code for handling maths with 1000-bit or 1001-bit integers for YUV or 
RGB, and the corresponding CPU :) ).
the exception is only for files already in the wild, and this "bug" is 
limited to streams with 16-bit YCbCr color space because the "bug" was 
discover before 16-bit RGB is implemented in an encoder (and the bug has 
no impact on streams with bitdepth <16). The goal is actually to permit  
such creative people to use 32-bit integers (for example: newly 16-bit 
RGB support needs 17 bits for intermediate storage, so a 32-bit integer 
is used).

Long stories short, the patch is for making that generic in case 
somebody is creative enough to try to use even higher bitdepth, with 
support of files already in the wild
(for example, the support of FFV1 in MediaConch is being upgraded to 
maximum 31-bit per component thanks to 32-bit integers, we could expand 
it to 63-bit per component if need with an upgrade to 64-bit integers, 
and we added an exception for 16-bit YCbCr color space only because the 
files in the wild are not compatible with the generic method)

Note that we propose to remove the exception in the next version of FFV1 
so it will be 100% generic in the future.

---

From: Luca Barbato <[email-masked]>
Date: Tue, 6 Sep 2016 22:16:54 +0200

> so it will be 100% generic in the future.

Ah, good as proposed then =)

lu