I came across another issue with the CTS calculation for VVC bitstreams, where the IDR frames don't have POC 0.

Here you can find a sample bitstream: https://hege.cc/test_idr.vvc, which is created by VVenC v1.10.0 using more or less the default settings: 
`vvencapp -q 28 --preset faster -rs 1 -rt idr -c yuv420 -t 12 --sdr sdr_709 -i /data/YUV/foreman_352x288.yuv --size 352x288 --fps 25 -o test_idr.vvc`
The POCs for the bitstream look like this:
```
POC   23 LId:  0 TId: 0 ( IDR_W_RADL, I-SLICE, QP 19 ) [DT  0.019] [L0] [L1] [:,(unk)] 
POC   15 LId:  0 TId: 1 ( RADL, B-SLICE, QP 24 ) [DT  0.007] [L0 23] [L1 23c] [:,(unk)] 
POC    7 LId:  0 TId: 2 ( RADL, B-SLICE, QP 25 ) [DT  0.007] [L0 15] [L1 15c] [:,(unk)] 
POC    3 LId:  0 TId: 3 ( RADL, B-SLICE, QP 29 ) [DT  0.004] [L0 7] [L1 7c] [:,(unk)] 
POC    1 LId:  0 TId: 4 ( RADL, B-SLICE, QP 30 ) [DT  0.004] [L0 3] [L1 3c] [:,(unk)] 
POC    0 LId:  0 TId: 5 ( RADL, B-SLICE, QP 30 ) [DT  0.003] [L0 1] [L1 1c] [:,(unk)] 
POC    2 LId:  0 TId: 5 ( RADL, B-SLICE, QP 32 ) [DT  0.002] [L0 1c] [L1 3] [:,(unk)] 
POC    5 LId:  0 TId: 4 ( RADL, B-SLICE, QP 30 ) [DT  0.003] [L0 3c] [L1 7] [:,(unk)] 
...
```

Muxing that file using latest master MP4Box `MP4Box -new test.mp4 -add test_idr.vvc:fps=25` gives the following CompositionOffsets:
```
> MP4Box -diso test.mp4 && grep CompositionOffsetEntry test_info.xml
<CompositionOffsetEntry CompositionOffset="7" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="5" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="10" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="5" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="2" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="0" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="1" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="3" SampleCount="1"/>
...
```
The offsets should correctly be 28, 19, 10, 5, 2, 0, 1, 3.

There are more miscalculated CTSs later in the bit stream, when the POC wraps around.

I implemented a quick fix for this issue using a heuristic to probe for the minimum POC after an IDR. I will post it in a separate PR. With my fix MP4Box muxes the streams created by VVenC correctly, but a proper fix would probably involve parsing a significant portion of the SPS and then using the `dpb_max_num_reorder_pics` syntax element from the `dpb_parameters` structure to delay dispatching the packets instead of my heuristic.
Wrong CTS offset for non POC 0 IDR frames
This is a GitHub Issue
repo:gpac
owner:gpac
Title : Wrong CTS offset for non POC 0 IDR frames
Issue date:

--- start body ---
I came across another issue with the CTS calculation for VVC bitstreams, where the IDR frames don't have POC 0.

Here you can find a sample bitstream: https://hege.cc/test_idr.vvc, which is created by VVenC v1.10.0 using more or less the default settings: 
`vvencapp -q 28 --preset faster -rs 1 -rt idr -c yuv420 -t 12 --sdr sdr_709 -i /data/YUV/foreman_352x288.yuv --size 352x288 --fps 25 -o test_idr.vvc`
The POCs for the bitstream look like this:
```
POC   23 LId:  0 TId: 0 ( IDR_W_RADL, I-SLICE, QP 19 ) [DT  0.019] [L0] [L1] [:,(unk)] 
POC   15 LId:  0 TId: 1 ( RADL, B-SLICE, QP 24 ) [DT  0.007] [L0 23] [L1 23c] [:,(unk)] 
POC    7 LId:  0 TId: 2 ( RADL, B-SLICE, QP 25 ) [DT  0.007] [L0 15] [L1 15c] [:,(unk)] 
POC    3 LId:  0 TId: 3 ( RADL, B-SLICE, QP 29 ) [DT  0.004] [L0 7] [L1 7c] [:,(unk)] 
POC    1 LId:  0 TId: 4 ( RADL, B-SLICE, QP 30 ) [DT  0.004] [L0 3] [L1 3c] [:,(unk)] 
POC    0 LId:  0 TId: 5 ( RADL, B-SLICE, QP 30 ) [DT  0.003] [L0 1] [L1 1c] [:,(unk)] 
POC    2 LId:  0 TId: 5 ( RADL, B-SLICE, QP 32 ) [DT  0.002] [L0 1c] [L1 3] [:,(unk)] 
POC    5 LId:  0 TId: 4 ( RADL, B-SLICE, QP 30 ) [DT  0.003] [L0 3c] [L1 7] [:,(unk)] 
...
```

Muxing that file using latest master MP4Box `MP4Box -new test.mp4 -add test_idr.vvc:fps=25` gives the following CompositionOffsets:
```
> MP4Box -diso test.mp4 && grep CompositionOffsetEntry test_info.xml
<CompositionOffsetEntry CompositionOffset="7" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="5" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="10" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="5" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="2" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="0" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="1" SampleCount="1"/>
<CompositionOffsetEntry CompositionOffset="3" SampleCount="1"/>
...
```
The offsets should correctly be 28, 19, 10, 5, 2, 0, 1, 3.

There are more miscalculated CTSs later in the bit stream, when the POC wraps around.

I implemented a quick fix for this issue using a heuristic to probe for the minimum POC after an IDR. I will post it in a separate PR. With my fix MP4Box muxes the streams created by VVenC correctly, but a proper fix would probably involve parsing a significant portion of the SPS and then using the `dpb_max_num_reorder_pics` syntax element from the `dpb_parameters` structure to delay dispatching the packets instead of my heuristic.
--- end body ---

The issue describes a problem with the calculation of Composition Time Stamps (CTS) for IDR frames in VVC bitstreams, which can lead to incorrect offsets during muxing. This could potentially result in playback issues or synchronization problems in media players. The user has identified a workaround but suggests that a more robust solution would require deeper parsing of the SPS and adjustments based on the dpb_max_num_reorder_pics parameter.