Reducing overhead in ISOBMFF

[cconcolato]

The current specification requires HDR10+ Metadata OBU to be present at every frame. Given the size of the HDR10+ data, this leads to an overhead in the order of 16kbps @ 30fps. This may be a problem when the video is a low bitrate.
A possible approach would be to alter the storage in MP4. An ISOBMFF packager would remove duplicate HDR10+ metadata when constant and add them back upon un-packaging when passing OBUs to the decoder. Obviously, this would require a new brand to signal it to players.

[quantizationbit]

Such a change would not be compatible with fielded receivers with AV1 HDR10+ support.

[podborski]

This would make demultiplexers more complex which could lead to issues when editing streams like that. Also HDR is supposed to be a premium technology, therefore one could argue if for low bitrate its even just better to stick to SDR.

[cconcolato]

Such a change would not be compatible with fielded receivers with AV1 HDR10+ support.

With proper signaling, devices would know if they can play it or not. In many cases, the receivers can be updated. In the end, it's an agreement between the content provider and the players. The standard should offer the option.

This would make demultiplexers more complex

Yes, to some extent, but that's not an unusual operation to apply common data from the previous random access point.

HDR is supposed to be a premium technology, therefore one could argue if for low bitrate its even just better to stick to SDR.

Switching to lower bitrate due to network bandwidth shouldn't force you to switch back to SDR. The HDR/SDR transition could be annoying.

[cconcolato]

Discussion in the group:
What is the user experience if you switch from HDR10+ to HDR10, at a scene change?
There is no guideline for how to implement it so it may differ from receiver to receiver.