Subject: [Cellar] [PATCH FFV1] SliceContent description update

From: Jerome Martinez <[email-masked]>
Date: Mon, 6 Jun 2016 13:07:05 +0200

As "height" word is currently used for both height in raster elements 
and height in pixels, I do make it explicit when the pixel height is used.
I remove any reference to Plane() (which is not defined) in order to 
have colorspace_type and slice_pixel_height in the same block whatever 
is the color_space.
The slice height in pixels is defined; explicit floor() during its 
computing (I use the mathematical symbol instead of the C function name 
in order to be more generic)

From 62ead20d25c9b96931eeace0df8f5b7284a4f4a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Mon, 6 Jun 2016 13:04:05 +0200
Subject: [PATCH] SliceContent description update

Difference between height in slice raster elements and pixels
Defines slice_pixel_height
---
 ffv1.md | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index a503d6c..66ed0e2 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -125,6 +125,12 @@ __!a__          means boolean logical "not".
 __a ? b : c__   if a is true, then b, otherwise c.
 --------------- ----------------------------------------------------------------
 
+## Mathematical functions
+
+---------------             ----------------------------------------------------------------
+__&lfloor;a&rfloor;__       means the integral part of a  
+---------------             ----------------------------------------------------------------
+
 ## Order of operation precedence
 
 When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C.
@@ -462,9 +468,9 @@ The same context which is initialized to 128 is used for all fields in the heade
 
 The following MUST be provided by external means during initialization of the decoder:
 
-**frame\_width** is defined as frame width in pixels.
+**frame\_pixel\_width** is defined as frame width in pixels.
 
-**frame\_height** is defined as frame height in pixels.
+**frame\_pixel\_height** is defined as frame height in pixels.
 
 Default values at the decoder initialization phase:
 
@@ -623,9 +629,10 @@ Inferred to be 0 if not present.
 |SliceContent( ) {                                           | type  |
 |    if( colorspace\_type == 0) {                            |       |
 |        for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
-|            Plane( p )                                      |       |
+|            for( y = 0; y \< slice\_pixel\_height; y++ )    |       |
+|                Line( p, y )                                |       |
 |    } else if( colorspace\_type == 1 ) {                    |       |
-|        for( y = 0; y \< height; y++ )                      |       |
+|        for( y = 0; y \< slice\_pixel\_height; y++ )        |       |
 |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
 |                Line( p, y )                                |       |
 |    }                                                       |       |
@@ -633,6 +640,12 @@ Inferred to be 0 if not present.
 
 **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ).
 
+**slice\_pixel\_height** is the slice height in pixels.  
+Its value is &lfloor;( slice\_y + slice\_height ) * frame_pixel\_height / num\_v\_slices&rfloor; - slice\_pixel\_y
+
+**slice\_pixel\_y** is the slice vertical position in pixels.  
+Its value is &lfloor;slice_y * frame_pixel\_height / num\_v\_slices&rfloor;
+
 ## Slice Footer
 
 Note: slice footer is always byte aligned.
@@ -875,7 +888,7 @@ MAX\_CONTEXT\_INPUTS is 5.
 
 ### Restrictions
 
-To ensure that fast multithreaded decoding is possible, starting version 3 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.
+To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_pixel\_width * frame\_pixel\_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.
 
 For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping).
-- 
2.7.0.windows.1

---

From: Michael Niedermayer <[email-masked]>
Date: Wed, 8 Jun 2016 16:17:18 +0200

On Mon, Jun 06, 2016 at 01:07:05PM +0200, Jerome Martinez wrote:
> As "height" word is currently used for both height in raster
> elements and height in pixels, I do make it explicit when the pixel
> height is used.
> have colorspace_type and slice_pixel_height in the same block
> whatever is the color_space.
> computing (I use the mathematical symbol instead of the C function
> name in order to be more generic)
> 
> 

> 27e2cc62b6d01343143ef004d80b487b21e326f0  0001-SliceContent-description-update.patch

what is the integer part of -1.5 ?
and is that intended ?

i suggest "the largest integer less than or equal to a"

> +|            for( y = 0; y \< slice\_pixel\_height; y++ )    |       |

this doesnt work as not all planes have the same size in case of
chroma subsampling

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle

---

From: Luca Barbato <[email-masked]>
Date: Wed, 8 Jun 2016 16:41:32 +0200

> this doesnt work as not all planes have the same size in case of

If there is a plan to support non-planar formats as well probably it 
could be spun as a separate description depending on the colorspace.

lu

---

From: Dave Rice <[email-masked]>
Date: Wed, 8 Jun 2016 10:46:23 -0400

> On Jun 8, 2016, at 10:41 AM, Luca Barbato <[email-masked]> wrote:
> 
> If there is a plan to support non-planar formats as well probably it could be spun as a separate description depending on the colorspace.

I would like to see bayer formats in the plan at some point to accommodate raw camera and film scanner data.
Dave Rice

---

From: Jerome Martinez <[email-masked]>
Date: Wed, 8 Jun 2016 16:56:46 +0200

> i suggest "the largest integer less than or equal to a"

it is intended for positive values (pixels), and from 
https://en.wikipedia.org/wiki/Floor_and_ceiling_functions :
"The floor function is also called the *greatest integer* or *entier* 
(French for "integer") function, and its value at /x/ is called the 
*integral part* or *integer part* of /x/; for negative values of /x/ the 
latter terms are sometimes instead taken to be the value of the 
/ceiling/ function, i.e., the value of /x/ rounded to an integer towards 0."

So I reused the "integral part" wording from this definition, and the 
integer part of -1.5 is 1 which is sometimes used for floor of negative 
number (not in C/C++, but maybe elsewhere?)

anyway, I have no strong opinion on it, I just preferred to use the 
Wikipedia definition rather than the C/C++ spec definition and I am 
using it only for positive values, and if nobody else has an opinion on 
it I am OK to switch to the C/C++ definition.

> this doesnt work as not all planes have the same size in case of

ho, right, slice_pixel_height should be slice_pixel_height[p] and its 
definition defined accordingly.
but I reused the code for colorspace_type == 1, which does not make any 
difference between planes, and I don't see constraints on 
h_chroma_subsample and v_chroma_subsample when colorspace_type == 1.

I need a clarification: are the following settings valid?
- colorspace_type == 1 and chroma_planes == 0.
- colorspace_type == 1 and chroma_planes == 1 and (h_chroma_subsample 
not 1 or v_chroma_subsample not 1). I see nothing about such forbidden 
settings and the part "for( y = 0; y < height; y++ )" already in the 
spec would be wrong in that case, for the same reason, or did I 
misunderstand something?

---

From: Michael Niedermayer <[email-masked]>
Date: Wed, 8 Jun 2016 17:35:08 +0200

[...]
> ho, right, slice_pixel_height should be slice_pixel_height[p] and
> its definition defined accordingly.
> but I reused the code for colorspace_type == 1, which does not make
> any difference between planes, and I don't see constraints on

> - colorspace_type == 1 and chroma_planes == 1 and
> (h_chroma_subsample not 1 or v_chroma_subsample not 1). I see
> nothing about such forbidden settings and the part "for( y = 0; y <
> height; y++ )" already in the spec would be wrong in that case, for
> the same reason, or did I misunderstand something?

The implementation does not support these cases, so you can do
either define them to something usefull or disallow, it should not
affect anything existing

[...]

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus

---

From: Reto Kromer <[email-masked]>
Date: Wed, 8 Jun 2016 23:18:35 +0200

Dave Rice wrote:

[...]

>I would like to see bayer formats in the plan at some point
>to accommodate raw camera and film scanner data.

I second this strongly. Best regards, Reto

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 9 Jun 2016 19:00:47 +0200

> either define them to something usefull or disallow, it should not

I prefer to explicitly forbid what we did not test, I'll provide another 
patch for it.
New patch attached, expecting that v_chroma_subsample is 1 when 
colorspace_type == 1.
I need to change the definition of "/" for being able to use "ceil" so 
there is some formatting changes in other parts of the spec, let me know 
if you prefer that I split the patch.

>From ba2c3471a60b2480259e118be8f2ea3085003d51 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Thu, 9 Jun 2016 18:52:47 +0200
Subject: [PATCH] SliceContent description update

Difference between height in slice raster elements and pixels
Defines slice_pixel_height
---
 ffv1.md | 71 ++++++++++++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 46 insertions(+), 25 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index a503d6c..9eea06a 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -74,7 +74,7 @@ __-a__          means negation of a.
 
 __a \* b__      means a multiplied by b.
 
-__a / b__       means a divided by b with truncation of the result toward zero.
+__a / b__       means a divided by b.
 
 __a % b__       means remainder of a divided by b.
 
@@ -125,6 +125,16 @@ __!a__          means boolean logical "not".
 __a ? b : c__   if a is true, then b, otherwise c.
 --------------- ----------------------------------------------------------------
 
+## Mathematical functions
+
+---------------             ----------------------------------------------------------------
+__&lfloor;a&rfloor;__       the largest integer less than or equal to a  
+---------------             ----------------------------------------------------------------
+
+---------------             ----------------------------------------------------------------
+__&lceil;a&rceil;__         the smallest integer greater than or equal to a  
+---------------             ----------------------------------------------------------------
+
 ## Order of operation precedence
 
 When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C.
@@ -462,9 +472,9 @@ The same context which is initialized to 128 is used for all fields in the heade

 

@@ -618,21 +628,32 @@ Inferred to be 0 if not present.
 
 ## Slice Content
 
-|                                                                    |
-|------------------------------------------------------------|:------|
-|SliceContent( ) {                                           | type  |
-|    if( colorspace\_type == 0) {                            |       |
-|        for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
-|            Plane( p )                                      |       |
-|    } else if( colorspace\_type == 1 ) {                    |       |
-|        for( y = 0; y \< height; y++ )                      |       |
-|            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
-|                Line( p, y )                                |       |
-|    }                                                       |       |
-|}                                                           |       |
+|                                                                      |
+|--------------------------------------------------------------|:------|
+|SliceContent( ) {                                             | type  |
+|    if( colorspace\_type == 0) {                              |       |
+|        for( p = 0; p \< primary\_color\_count; p++ ) {       |       |
+|            for( y = 0; y \< plane\_pixel\_height[ p ]; y++ ) |       |
+|                Line( p, y )                                  |       |
+|    } else if( colorspace\_type == 1 ) {                      |       |
+|        for( y = 0; y \< slice\_pixel\_height; y++ )          |       |
+|            for( p = 0; p \< primary\_color\_count; p++ ) {   |       |
+|                Line( p, y )                                  |       |
+|    }                                                         |       |
+|}                                                             |       |

+**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice.  
+plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height  
+if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is &lceil;slice\_pixel\_height / ( 1 << v_chroma_subsample )&rceil;
+
+**slice\_pixel\_height** is the height in pixels of the slice.  
+Its value is &lfloor;( plane\_y + plane\_height ) * frame_pixel\_height / num\_v\_slices&rfloor; - slice\_pixel\_y  
+
+**slice\_pixel\_y** is the slice vertical position in pixels.  
+Its value is &lfloor;slice_y * frame_pixel\_height / num\_v\_slices&rfloor;
+
 ## Slice Footer
 
 Note: slice footer is always byte aligned.
@@ -837,15 +858,15 @@ Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0
 
 Stored values: 1, 3, 1
 
-```c
-QuantizationTable( i ) {                          // type
-    scale = 1
-    for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) {
-        QuantizationTablePerContext( i, j, scale )
-        scale *= 2 * len_count[ i ][ j ] - 1
-    }
-    context_count[ i ] = ( scale + 1 ) / 2
-```
+|                                                                           |
+|---------------------------------------------------------------------------|
+| QuantizationTable( i ) {                                                  |
+|   scale = 1                                                               |
+|   for( j = 0; j < MAX_CONTEXT_INPUTS; j++ ) {                             |
+|       QuantizationTablePerContext( i, j, scale )                          |
+|       scale \*= 2 \* len_count[ i ][ j ] - 1                              |
+|   }                                                                       |
+|   context_count[ i ] = &lfloor;( scale + 1 ) / 2&rfloor;                  |

 MAX\_CONTEXT\_INPUTS is 5.
@@ -875,7 +896,7 @@ MAX\_CONTEXT\_INPUTS is 5.
 
 ### Restrictions

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 9 Jun 2016 23:29:25 +0200

Sorry, there was a typo (around v_chroma_subsample usage in the 
definition of plane_pixel_height) in the previous patch proposal, here 
is a new one.

Le 09/06/2016 à 19:00, Jerome Martinez a écrit :
> I prefer to explicitly forbid what we did not test, I'll provide 
> another patch for it.
> there is some formatting changes in other parts of the spec, let me 
> know if you prefer that I split the patch.
>
>
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

>From 4f99215fd2075a7e8212f4bfce45c2e7d45164af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Thu, 9 Jun 2016 23:27:19 +0200
Subject: [PATCH] SliceContent description update

Difference between height in slice raster elements and pixels
Defines slice_pixel_height and plane_pixel_height[ p ]
---
 ffv1.md | 71 ++++++++++++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 46 insertions(+), 25 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index a503d6c..2d23de5 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -74,7 +74,7 @@ __-a__          means negation of a.

 

 

 

 
 ## Slice Content
 
-|                                                                    |

+if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is &lceil;slice\_pixel\_height / v\_chroma\_subsample&rceil;

 Stored values: 1, 3, 1
 
-```c

 ### Restrictions

---

From: Michael Niedermayer <[email-masked]>
Date: Sat, 11 Jun 2016 22:19:55 +0200

On Thu, Jun 09, 2016 at 11:29:25PM +0200, Jerome Martinez wrote:
> definition of plane_pixel_height) in the previous patch proposal,
> here is a new one.
> 
> >I need to change the definition of "/" for being able to use
> >"ceil" so there is some formatting changes in other parts of the
> >spec, let me know if you prefer that I split the patch.
> >
> >
> >

>  ffv1.md |   71 +++++++++++++++++++++++++++++++++++++++++-----------------------
> 80e49d33f9e13946b1160098da0d3c7e2ef0a93f  0001-SliceContent-description-update.patch

if a / b is the precisse and not rounded value then a % b as
the corresponding remainder does not make sense

[...]

> +if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is &lceil;slice\_pixel\_height / v\_chroma\_subsample&rceil;

the plane\_pixel\_*[0] should be changed to be rounded toward chroma
raster size in the next bitstream version
this would simplify slice geometry i think

[...]
> -    context_count[ i ] = ( scale + 1 ) / 2

please move the reformating into a separate patch
its difficult to see what changed

[...]

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato

---

From: Jerome Martinez <[email-masked]>
Date: Mon, 13 Jun 2016 21:14:07 +0200

> the corresponding remainder does not make sense

a % b removed

> its difficult to see what changed

Patch 1/2 is about formatting only.
>From 42509e64d6560e5724c0ccfbc27f3ca306d35451 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Mon, 13 Jun 2016 21:05:17 +0200
Subject: [PATCH 1/2] Reformatting before SliceContent changes

Explicit floor and ceil instead of truncation of a / b
Add "pixel_" prefix in order to avoid conflict with width/height
in count of elements in the slice raster
Larger SliceContent formatted array size
QuantizationTable() moved to a formatted array
---
 ffv1.md | 64 ++++++++++++++++++++++++++++++++++++----------------------------
 1 file changed, 36 insertions(+), 28 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index a503d6c..49019c2 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -74,9 +74,7 @@ __-a__          means negation of a.

-__a / b__       means a divided by b with truncation of the result toward zero.
-
-__a % b__       means remainder of a divided by b.
+__a / b__       means a divided by b.
 
 __a & b__       means bit-wise "and" of a and b.
 
@@ -125,6 +123,16 @@ __!a__          means boolean logical "not".
 __a ? b : c__   if a is true, then b, otherwise c.
 --------------- ----------------------------------------------------------------

 When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order (from top to bottom, operations of same precedence being evaluated from left to right). This order of operations is based on the order of operations used in Standard C.
@@ -153,7 +161,7 @@ __a...b__ means any value starting from a to b, inclusive.
 
 **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser.
 
-**byte\_aligned( )** means remaining\_bits\_in\_bitstream( ) % 8 is 0.
+**byte\_aligned( )** means remaining\_bits\_in\_bitstream( ) is a multiple of 8.
 
 \pagebreak
 
@@ -462,9 +470,9 @@ The same context which is initialized to 128 is used for all fields in the heade

 

@@ -618,18 +626,18 @@ Inferred to be 0 if not present.
 
 ## Slice Content
 
-|                                                                    |
+|            Plane( p )                                        |       |
+|        for( y = 0; y \< height; y++ )                        |       |

@@ -837,15 +845,15 @@ Table: 0 0 1 1 1 1 2 2-2-2-2-1-1-1-1 0
 
 Stored values: 1, 3, 1
 
-```c

 MAX\_CONTEXT\_INPUTS is 5.
@@ -875,7 +883,7 @@ MAX\_CONTEXT\_INPUTS is 5.
 
 ### Restrictions

---

From: Jerome Martinez <[email-masked]>
Date: Mon, 13 Jun 2016 21:18:38 +0200

> this would simplify slice geometry i think

I add this item to my list of items to debate after the standardization 
of FFV1 0/1/3.

Attached is the patch corresponding to changes only.
>From 1791299ecd9df5b623416b58398c4c3fe63d06d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Mon, 13 Jun 2016 21:11:39 +0200
Subject: [PATCH 2/2] SliceContent description update

Describe how to call Line() when color_space is 0
Define slice_pixel_height and slice_pixel_y
Define plane_pixel_height[ p ]
---
 ffv1.md | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index 49019c2..dfdb7e7 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -631,9 +631,10 @@ Inferred to be 0 if not present.
 |SliceContent( ) {                                             | type  |
 |    if( colorspace\_type == 0) {                              |       |
 |        for( p = 0; p \< primary\_color\_count; p++ ) {       |       |
-|            Plane( p )                                        |       |
+|            for( y = 0; y \< plane\_pixel\_height[ p ]; y++ ) |       |
+|                Line( p, y )                                  |       |
 |    } else if( colorspace\_type == 1 ) {                      |       |
-|        for( y = 0; y \< height; y++ )                        |       |
+|        for( y = 0; y \< slice\_pixel\_height; y++ )          |       |
 |            for( p = 0; p \< primary\_color\_count; p++ ) {   |       |
 |                Line( p, y )                                  |       |
 |    }                                                         |       |
@@ -641,6 +642,16 @@ Inferred to be 0 if not present.

---

From: Michael Niedermayer <[email-masked]>
Date: Fri, 17 Jun 2016 11:37:02 +0200

[...]

> +|   context_count[ i ] = &lfloor;( scale + 1 ) / 2&rfloor;                  |
                            ^^^^^^^
i ommitted this one from the commit as scale is always odd thus scale+1
always a multiple of 2

[...]

It is what and why we do it that matters, not just one of them.

---

From: Michael Niedermayer <[email-masked]>
Date: Fri, 17 Jun 2016 11:28:59 +0200

> 863cabb56a2e87858b26101b59445d6317f3b0bd  0001-Reformatting-before-SliceContent-changes.patch

applied

thanks

[...]

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope

---

From: Michael Niedermayer <[email-masked]>
Date: Sat, 18 Jun 2016 09:14:20 +0200

On Mon, Jun 13, 2016 at 09:18:38PM +0200, Jerome Martinez wrote:
> I add this item to my list of items to debate after the
> standardization of FFV1 0/1/3.
> 

> c2176452cd73caa1b268391913deab1b38d34aa1  0002-SliceContent-description-update.patch

> +Its value is &lfloor;( plane\_y + plane\_height ) * frame_pixel\_height / num\_v\_slices&rfloor; - slice\_pixel\_y  

what is plane_y or plane_height ?

[...]

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA

---

From: Michael Niedermayer <[email-masked]>
Date: Sat, 18 Jun 2016 09:25:32 +0200

> +Its value is &lfloor;slice_y * frame_pixel\_height / num\_v\_slices&rfloor;

also these are just the y coordinates, the x ones are missing

[...]

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad

---

From: Jerome Martinez <[email-masked]>
Date: Sat, 18 Jun 2016 12:59:53 +0200

> what is plane_y or plane_height ?

sorry, typos during some changes I have made between my initial thoughts 
and the final patch.
They are slice_y and slice_height, which are defined (in the slice header).
Updated patch attached.

> also these are just the y coordinates, the x ones are missing 

x coordinates will be defined the same way after the y coordinates are 
accepted (in order to not do the same mistakes as with x coordinates) 
and when we need them (y coordinates are not used in SliceContent() so 
not defined in this location, they are used in Line() which will be 
defined in the next patch).
>From 8520d64d8982e256285e04dc1dccb6ce6c5bd182 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= <[email-masked]>
Date: Sat, 18 Jun 2016 12:11:13 +0200
Subject: [PATCH 2/2] SliceContent description update

index a02744b..395fecc 100644

+**plane\_pixel\_height[ p ]** is the height in pixels of plane p of the slice.  
+plane\_pixel\_height[ 0 ] and plane\_pixel\_height[ 1 + ( chroma\_planes ? 2 : 0 ) ] value is slice\_pixel\_height  
+if chroma\_planes is set to 1, plane\_pixel\_height[ 1 ] and plane\_pixel\_height[ 2 ] value is &lceil;slice\_pixel\_height / v\_chroma\_subsample&rceil;
+
+**slice\_pixel\_height** is the height in pixels of the slice.  
+Its value is &lfloor;( slice\_y + slice\_height ) * slice\_pixel\_height / num\_v\_slices&rfloor; - slice\_pixel\_y  
+
+**slice\_pixel\_y** is the slice vertical position in pixels.  
+Its value is &lfloor;slice_y * frame\_pixel\_height / num\_v\_slices&rfloor;
+
 ## Slice Footer

---

From: Michael Niedermayer <[email-masked]>
Date: Sat, 18 Jun 2016 13:12:47 +0200

On Sat, Jun 18, 2016 at 12:59:53PM +0200, Jerome Martinez wrote:
> sorry, typos during some changes I have made between my initial
> thoughts and the final patch.
> x coordinates will be defined the same way after the y coordinates
> are accepted (in order to not do the same mistakes as with x
> coordinates) and when we need them (y coordinates are not used in
> SliceContent() so not defined in this location, they are used in
> Line() which will be defined in the next patch).

> c4214698f7c22886680a46ad8ae1a621feffcd5c  0002-SliceContent-description-update.patch

applied

btw, maybe the trailing whitespace of the file should be removed
and not be re-added

thanks

[...]

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable