[Cellar] Re: [PATCH v2] ffv1: Support CRC with initial and final values not 0

[Michael Niedermayer <[e-mail]>]

On Sun, Sep 29, 2024 at 09:30:02AM +0200, Steve Lhomme wrote:
> Hi Michael,
> 
> > On 28 Sep 2024, at 22:41, Michael Niedermayer <[e-mail]> wrote:
> > 
> > Hi Steve
> > 
> > On Sat, Sep 28, 2024 at 08:45:59AM +0200, Steve Lhomme wrote:
> >> Hi Michael,
> >> 
> >> Given RFC 9043 is published and this seems like an addition to the format, it would probably needs its own document to introduce this new bit handling. Hopefully it’s backward compatible so it’s a no brainer. I don’t think it can be an errata, but you may try that.
> > 
> > RFC 9043 is about version 0, 1, and 3.
> > we are of course discussing about version 4.
> 
> OK, no problem then.
> 
> > The hunk in the patch was missing the tag for V4, it should have been:
> > 
> > @@ -1267,7 +1267,8 @@ Figure: Description of the coding of `initial_state_delta[ i ][ j ][ k ]`. {#fig
> > |value | error detection/correction type           |
> > |------|:------------------------------------------|
> > |0     | 32-bit CRC in `ConfigurationRecord`       |
> > -|1     | 32-bit CRC in `Slice` and `ConfigurationRecord`|
> > +|1     | 32-bit CRC in `Slice` and `ConfigurationRecord` using crcref=0  as initial and final values|
> > +|2     | 32-bit CRC in `Slice` and `ConfigurationRecord` using crcref=0x7a8c4079 as initial and final values|{V4}
> > |Other | reserved for future use                   |
> > Table: The definitions for `ec` values. {#tableEc}
> > 
> > About compatible. As its written ATM in teh patch there is nothing an encoder
> > needs to do differently, the old variant would still be valid.
> > 
> > On  the decoder side a old decoder would not know what to do with the
> > error detection type=2. So if it ignores it it might decode things ok but
> > more likely it will fail without trying
> > 
> > I think we can expect that most new features that will be in v4 will need a
> > decoder thats aware of v4. another example will be floating point pixel formats
> 
> Indeed. The text change you propose doesn’t make it clear that this value should only be used (MUST or SHALL in IETF terms) if the bitstream is marked as FFV1 v4 or above. I assume that should be the same for other new features as well.

yes, will apply the change with that magic v4 tag so it only ends in teh v4 version

thx for reviewing!

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier