Subject: [Cellar] [PATCH] Rewrite of the restrictions paragraph

From: Jerome Martinez <[email-masked]>
Date: Fri, 13 May 2016 11:40:06 +0200

Following the discussion "FFV1 slices count", I propose the attached 
patch in order to be more explicit about the restrictions.

- Definition of frame width and height,
- Removal of pixel size in the formula (we can have a formula based on 
the bitstream fields)

Jérôme

From 2c197e480486d80640665e58ff2fb49a8bf3dcfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Fri, 13 May 2016 11:37:45 +0200
Subject: [PATCH] Rewrite of the restrictions paragraph

- Definition of frame width and height,
- Removal of pixel size in the formula (we can have a formula based
on the bitstream fields)
---
 ffv1.md | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ffv1.md b/ffv1.md
index e48a7ee..0480c63 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -458,6 +458,12 @@ Note, this is different from JPEG-LS, which doesn’t use prediction in run mode
 
 The same context which is initialized to 128 is used for all fields in the header.
 
+The stream transport layer MUST provide the following data during initialization of the decoder:
+
+**frame\_width** is defined as frame width in pixels.
+
+**frame\_height** is defined as frame height in pixels.
+
 Default values at the decoder initialization phase:
 
 **ConfigurationRecordIsPresent** is set to 0.
@@ -843,7 +849,8 @@ MAX\_CONTEXT\_INPUTS is 5.
 
 ### Restrictions
 
-In version 2 and later the maximum slice size in pixels is $\frac{width\centerdot height}{4}$, unless the frame is smaller or equal 352x288 this is to ensure that fast multithreaded decoding is possible.
+To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height SHOULD be less or equal to num\_h\_slices * num\_v\_slices / 4.
+Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
 
 # Changelog
 
-- 
2.7.0.windows.1

---

From: Michael Niedermayer <[email-masked]>
Date: Fri, 13 May 2016 20:14:32 +0200

> ade5ca179746784b68b5123b83d4a25f9b29d2f0  0001-Rewrite-of-the-restrictions-paragraph.patch

not sure about the exact wording "stream transport layer" vs
something like "the follwing must be provided by external means"
but its ok either way with me
ITU H.263 talks about "external means" in similar cases (the ones i
looked at at least)

> +Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.

is it possible to use stronger wording than just SHOULD ?
explicitly stating that not doing so would quarduple the time needed
to decode the frames and that thus potentially significantly fewer
decoders would be able to decode the stream in realtime
but i still feel that some harder restriction should be left in the
spec

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.

---

From: Jerome Martinez <[email-masked]>
Date: Fri, 13 May 2016 21:21:00 +0200

> ITU H.263 talks about "external means" in similar cases (the ones i

Changed.

> but i still feel that some harder restriction should be left in the

I think that the definition of SHOULD fits your point, but as we can not 
agree on this word right now I propose to postpone the SHOULD/MUST 
debate and go with the rest.
Modified with MUST.

Jérôme
>From d92c4687a23f293f4958614fc00fd608cfa15e37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Fri, 13 May 2016 21:09:38 +0200
Subject: [PATCH] Rewrite of the restrictions paragraph

diff --git a/ffv1.md b/ffv1.md
index e48a7ee..4de8ac9 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -458,6 +458,12 @@ Note, this is different from JPEG-LS, which doesn’t use prediction in run mode

+The following MUST be provided by external means during initialization of the decoder:
+
+**frame\_width** is defined as frame width in pixels.
+
+**frame\_height** is defined as frame height in pixels.
+
 Default values at the decoder initialization phase:

 ### Restrictions
 
-In version 2 and later the maximum slice size in pixels is $\frac{width\centerdot height}{4}$, unless the frame is smaller or equal 352x288 this is to ensure that fast multithreaded decoding is possible.
+To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
+Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
 
 # Changelog
 
-- 
2.7.0.windows.1

---

From: Michael Niedermayer <[email-masked]>
Date: Sat, 14 May 2016 00:05:54 +0200

On Fri, May 13, 2016 at 09:21:00PM +0200, Jerome Martinez wrote:
> I think that the definition of SHOULD fits your point, but as we can
> not agree on this word right now I propose to postpone the
> SHOULD/MUST debate and go with the rest.
> Modified with MUST.
> 
> Jérôme

> b5af0f23762c6259596632f895f8798d17da3caa  0001-Rewrite-of-the-restrictions-paragraph.patch

applied

thx

[...]

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.