In this guide
Read an original illustrative scheduleDo not reorder payload from one timestamp columnKeep genuine faults in viewA packet inspection listing can show presentation timestamps out of numerical order even when the intended picture sequence is coherent. Encoded decode order may differ from display order because a predicted picture needs a later-displayed reference first.
This does not make every timestamp anomaly valid. Preserve the original file and both timing roles, then evaluate the actual dependencies and timeline context.
Read an original illustrative schedule
Consider display order A, B, C, with B depending on A and C. A simplified decode order is A, C, B. In a hypothetical millisecond time base, the packet rows have decoding timestamps 0, 40 and 80, while their presentation timestamps are 40, 120 and 80 respectively.
The presentation values appear to go backward between the second and third packet because C is decoded before B. Sorting the pictures for display gives A at 40 ms, B at 80 ms and C at 120 ms. This schedule is an explanatory example, not a complete conforming media file.
Do not reorder payload from one timestamp column
Sorting encoded packets by presentation timestamp could feed B before its required C reference. That changes the dependency order rather than repairing it. A player/container implementation needs the relevant decoding and composition relationships, initialization and valid timestamps.
When inspecting with a trusted local tool, retain the stream identifier and time base. Do not compare raw integers from different streams as though they share units. Network arrival time is another observation and should not be inferred from the stored presentation timestamp sequence.
Keep genuine faults in view
Check whether decoding timestamps, timestamp availability, discontinuity context and actual sample structure satisfy the applicable format. A source can still have a real gap, invalid offset or malformed packet. Reordering explains one valid pattern; it does not certify the whole resource.
A useful report includes the original packet order, timestamp roles/units, codec configuration and observed decoder or presentation symptom. State whether the finding is a metadata inspection or actual playback observation. This lets a developer assess ordering without an unsupported packet-loss claim or a destructive “sort the timestamps” workaround.
| Decode packet order | Picture | DTS in ms | PTS in ms |
|---|---|---|---|
| 1 | A | 0 | 40 |
| 2 | C | 40 | 120 |
| 3 | B | 80 | 80 |