Subject: [Cellar] FFV1 slices count

From: Jerome Martinez <[email-masked]>
Date: Tue, 26 Apr 2016 22:01:26 +0200

Checking FFmpeg code for how FFV1 slices are constrained, I understand that:
- FFmpeg encoder tries to find a value compatible with some constraints 
(minimum 2 rows and 2 columns, rows count must not be > 2x columns 
count, columns count must not be > 2x rows count, and slices count can 
not be more than 64). so 25 is acceptable (5x5, OK), 26 is not (13x2 or 
2x13 are the only combinations, NOK)
- FFmpeg decoder accepts any slices count below 256

I don't see any of these constraints in the current FFV1 specifications.
I also don't see any reason to have these constraints: cases like 1 row 
and 64 columns could be used somewhere, not really worse than 8 rows and 
8 columns (and maybe someday an encoder could compare compression 
performance an select 1x64 for compression performance with some 
frames). In 10 years, maybe we'll have 8K frames and CPUs with 1024 
low-powered cores everywhere, having 32x32 slices (slices of 256x144 
pixels) could make sense.

On another side, the current specifications don't limit the count of 
slices, so having more slices than pixels on a row (so we have slices 
with 0 pixels) is theoretically possible.

I would like to have comments on:
- do we agree that we don't have any constraint on the slices count in 
the specification. FFmpeg implementation is a developer decision only 
and does not have any impact on the specification?
- should we add a constraint about num_h_slices must be less or equal to 
the frame width, and num_v_slices must be less or equal to frame height?
- In the future, we could have "profiles" as constraints for performance 
reasons, like "profile 1 = 720x576 pixels maximum, 64 slices maximum; 
profile 2 = 1920x1080 pixels maximum, 256 slices maximum", in addition 
to the core specifications without such arbitrary choices.

---

From: Michael Niedermayer <[email-masked]>
Date: Wed, 27 Apr 2016 02:37:39 +0200

On Tue, Apr 26, 2016 at 10:01:26PM +0200, Jerome Martinez wrote:
> - FFmpeg encoder tries to find a value compatible with some
> constraints (minimum 2 rows and 2 columns, rows count must not be >
> 2x columns count, columns count must not be > 2x rows count, and
> slices count can not be more than 64). so 25 is acceptable (5x5,
> OK), 26 is not (13x2 or 2x13 are the only combinations, NOK)
> I also don't see any reason to have these constraints: cases like 1
> row and 64 columns could be used somewhere, not really worse than 8
> rows and 8 columns (and maybe someday an encoder could compare
> compression performance an select 1x64 for compression performance
> with some frames). In 10 years, maybe we'll have 8K frames and CPUs
> with 1024 low-powered cores everywhere, having 32x32 slices (slices
> of 256x144 pixels) could make sense.
> 
> slices, so having more slices than pixels on a row (so we have
> slices with 0 pixels) is theoretically possible.
> 
> 
> - do we agree that we don't have any constraint on the slices count
> in the specification. FFmpeg implementation is a developer decision
> only and does not have any impact on the specification?

There is:
    5.6.1   Restrictions
    In version 2 and later the maximum slice size in pixels is width*height
                                                               ------------
                                                                    4
    , unless the frame is smaller or equal
    352x288 this is to ensure that fast multithreaded decoding is possible.

> - should we add a constraint about num_h_slices must be less or
> equal to the frame width, and num_v_slices must be less or equal to
> frame height?

I think a restriction stating that "each slice must contain at least
one sample from each plane" should be added
Otherwise that may lead to odd special cases where a slice has
luma but no chroma samples

> - In the future, we could have "profiles" as constraints for
> performance reasons, like "profile 1 = 720x576 pixels maximum, 64
> slices maximum; profile 2 = 1920x1080 pixels maximum, 256 slices
> maximum", in addition to the core specifications without such
> arbitrary choices.
> 
> 
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates