Reference decoder (FFmpeg's ffv1dec.c) doesn't match spec behavior for quant_table_set_count about ffv1 HOT 11 CLOSED

In my opinion the spec should not limit quant_table_set_count, as there is no technical constraints here (IIUC code in FFmpeg is an arbitrary choice for a fixed structure instead of dynamic allocation).

But there is an compatibility issue with the reference decoder (and even if we udpate the code, older versions would not decode such stream), I suggest to add a line e.g. "For maximum compatibility with some decoders, quant_table_set_count SHOULD not be more than 8". in IETF terms, SHOULD says this is not forbidden but you would need a good reason to do so.

from ffv1.

This sounds like a reasonable compromise.

In my own decoder, I used dynamic allocation anyway.

from ffv1.

@JeromeMartinez, could you give an example of a good reason?

from ffv1.

In my own decoder, I used dynamic allocation anyway.

+1

from ffv1.

@JeromeMartinez, could you give an example of a good reason?

I see the other boundary: why should we limit? Why this field and not e.g. Width and Height fields (some formats are limited to 12-bit, so 4095, it was considered as no good reason do go upper and can not be used for nowadays frames)? should we limit bit depth field too?

I suggest to have the format very open, and for v4 maybe add profiles for limiting a couple of fields.

from ffv1.

I suggest to have the format very open, and for v4 maybe add profiles for limiting a couple of fields.

+1

from ffv1.

Unlimited is a big number, which requires alot of memory. How much compression is gained by values larger than what ffv1dec.c can handle ?
The problem "unlimited" has IMHO is that someone will create a file that has this much larger than what helps compression. And then theres a file in the wild everyone needs to support because it is a valid file even when the file is bigger than it would have been with fewer tables.
This is different from unlimited resolution where its the content that dictates what value is used.
For tables, it might be just a user parameter that the user could set to any random thing when the encoder supports more tables.
Maybe this number should be limited so it doesnt limit compression but it does limit stupidity.

from ffv1.

@michaelni Do we have data for possible gains on anything larger than 8 (or even 2)? I'd expect them to drop off a edge at somepoint, too.

from ffv1.

i dont remember testing multiple tables. I would also expect a dropoff, also theres the obvious limit of slices * frames as thats the maximum distinct tables which could be used.
More tables have 2 costs to them compression wise, 1. the size of the table itself, and 2. the inability to reuse the statistics of the previous frame (because of different tables). 2. can be reduced by using initial states but they then need to be stored too increasing the cost of more tables.
So it seems expected that there is a point where more tables would hurt compression. But i dont know where that point is.

from ffv1.

But i dont know where that point is.

As we don't know, and actually things may change in the future even if we know now, isn't SHOULD NOT (be upper than 8) a good balance? From IETF definition:
"This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label."

In my opinion it suits well the issue: if one decides to implement more than 8 tables, this is known to be risky about interoperability as it is not recommended, and e try to limit stupidity without preventing genius idea if one can prove in the future that it is useful.

from ffv1.

allowing arbitrary numbers of tables means that it is not possible to implement a decoder (sw+hw) that could be said supports FFV1 videos of resolution up to X x Y.
As an example even the highest end machiene then couldnt be guranteed to be able to decode a 320 x 200 video.
What do we gain from this ? nothing has been shown to be gained so far.
I think making this unlimited as long as no gain has been shown is unreasonable.

from ffv1.