Packet Timestamps
Packet timestamps tell a playback pipeline when encoded media must be decoded and when the resulting content should be presented.
A decoder and a viewer can need pictures in different orders. If picture B predicts from C, the decoder must reconstruct C before B even when the viewer should see B first. Decoding timestamps (DTS) and presentation timestamps (PTS) describe these two schedules.
Follow this simplified three-picture group. Each displayed picture lasts 40 milliseconds, and C is a reference used to decode B.
| Packet read in decode order | DTS | PTS | Decoder action |
|---|---|---|---|
| A | 0 ms | 40 ms | Reconstruct A and retain it |
| C | 40 ms | 120 ms | Reconstruct C, retain it, and defer its display |
| B | 80 ms | 80 ms | Reconstruct B using its references |
The viewer's order is A at 40 ms, B at 80 ms, then C at 120 ms. The compressed packet order is A, C, B. The presentation offset in this invented example gives the decoder time to build the required reference state; it is not a universal delay used by a codec.
The queue is part of the mechanism
At decode time 40 ms, C is ready but does not yet belong on screen. It waits in a decoded-picture buffer. At 80 ms, B is reconstructed and can be presented before the retained C. The decoder must keep pictures for two potentially different reasons: later prediction and later presentation.
Sorting the compressed packets by PTS would send A, B, C to the decoder. B would then arrive before its reference C. The output schedule is a reason to reorder reconstructed pictures, not a reason to reorder dependent compressed input blindly.
For video with no such reordering, DTS and PTS may coincide. Audio also uses presentation timing, while its packet duration tells the scheduler how much decoded sound that packet contributes.
Comparing picture and sound
A video PTS and an audio PTS can be integers on different time bases. On a 90,000-tick scale, 90,000 means one second; on a 48,000-tick scale, 48,000 means the same moment. Synchronization compares the converted time, not the raw numbers.
If sound is consistently 200 ms late in an Emby session, an offset is one possibility. If the difference grows through the programme, durations, resampling, or an incorrectly interpreted clock can be involved. Those are different timing patterns, so the symptom guides which relationships to inspect.
Containers need not store two literal fields on every packet. They can describe decode durations and composition offsets from which a reader derives the schedules. Inspection tools report the resulting timestamps through their own packet model.
Reading a warning in context
PTS can move backwards in the file's decode order, as 120 → 80 ms does here. That is normal reordering. A DTS moving backwards where the receiving muxer expects an ordered decode timeline has another meaning. Timestamp resets in a continuing recording, missing durations, and discontinuities can also need explicit handling.
A useful packet inspection keeps DTS, PTS, duration, time base, stream identity, and the playback symptom together. Replacing all times with consecutive values would erase the information that makes this example display correctly.