Metadata blocks are not ordered properly when parsing

[quietvoid]

No description provided.

[quietvoid]

So it seems the blocks are not necessarily ordered in the RPU, but dovi_tool reorders while parsing with mode 0:

  |  Extension block 3, Level 8, Length 10
     | target_display_index 255
     | trim_slope           2458
     | trim_offset          2048
     | trim_power           2208
     | trim_chroma_weight   2048
     | trim_saturation_gain 2048
     | ms_weight            2048
  |  Extension block 4, Level 8, Length 10
     | target_display_index 20
     | trim_slope           2048
     | trim_offset          2048
     | trim_power           1900
     | trim_chroma_weight   2048
     | trim_saturation_gain 2048
     | ms_weight            2048

Therefore, reordering affects the final CRC32.

[manuelrn]

So this only happens with mode 0, correct?

And it also happens when using the editor? (as it simply parses the RPU without conversion)

[quietvoid]

So this only happens with mode 0, correct?
And it also happens when using the editor? (as it simply parses the RPU without conversion)

Yes, however editing sets a modified flag to true, which skips comparing the original CRC32 hash.
This will be in 1.4.1 soon.

[manuelrn]

So this only happens with mode 0, correct?
And it also happens when using the editor? (as it simply parses the RPU without conversion)

Yes, however editing sets a modified flag to true, which skips comparing the original CRC32 hash. This will be in 1.4.1 soon.

So with the editor there has never been any problem since a new CRC32 was always generated? Or was the editor affected too?

[quietvoid]

This was only a bug in 1.4.0, so there's nothing to worry about with previous versions.
There's also no negative impact for the editor, because the RPU is almost always assumed edited (unless you run an edit with mode=0 for some reason).

There's no negative effect, but maybe Dolby expects both L8 and L10 blocks to be ordered the same.
Either way, when reordered, that is still the case.

I just made the issue because this would halt parsing when using mode 0, whether it's demuxing/extracting, etc.

[manuelrn]

Ok, thanks for the explanation.

As a result of this, I have thought that perhaps it would be interesting to add a new command (verify or validation or something like that) that simply parses an RPU to check if it is valid or not. That is to say, that it checks the CRC32 in all the frames and other validations that you consider appropriate.

[quietvoid]

That is to say, that it checks the CRC32 in all the frames and other validations that you consider appropriate.

This is already the case when writing RPUs, as long as they were parsed.
The info command also performs validation by default, and it parses all the frames.

At this point I wonder if defaulting to mode 0 would make sense, instead of simply copying bytes.

[manuelrn]

That is to say, that it checks the CRC32 in all the frames and other validations that you consider appropriate.

This is already the case when writing RPUs, as long as they were parsed. The info command also performs validation by default, and it parses all the frames.

At this point I wonder if defaulting to mode 0 would make sense, instead of simply copying bytes.

Ah ok, I didn't know that the info command already verified it.

And the info command checks the full RPU? Or just the specified frame?

[quietvoid]

It parses every frame while validating, then prints the info for the specified frame.

[manuelrn]

It parses every frame while validating, then prints the info for the specified frame.

OK, thanks for answering.

I just saw that you edited the above message to specify that it parses all the frames. Sorry, I hadn't read it.