Changes between Initial Version and Version 1 of Ticket #4536, comment 4


Ignore:
Timestamp:
May 2, 2018, 6:41:21 PM (16 months ago)
Author:
mkver
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #4536, comment 4

    initial v1  
    1616}}}
    1717If one encodes with the libfdk_aac encoder (which has 2048 samples encoder delay which is longer than one frame at 24/1.001 fps), all video frames except the very first one are offset.
    18 2. This happens generally with encoder delay, it is not opus-specific. Although Opus should be treated specially in this regard (the CodecDelay header field already indicates the delay, using this header field and baking the delay into the timestamps is wrong, but that is another issue).
     182. This happens generally with encoder delay, it is not opus-specific. Although Opus should be treated specially in this regard (the CodecDelay header field already indicates the delay, using this header field and baking the delay into the timestamps is wrong, but that is another issue). [Edit]: The "another issue" is now issue #7182. The CodecDelay field actually shows that one can't rely on a single offset for all tracks.
    19193. Judging from this, I think that the decisions regarding delay should be made before any packet is written so that packets from all tracks (or all tracks for which packets are available at the beginning) can be considered.
    20204. For a container like Matroska for which the offset decision is based upon pts (by default) there is also another issue that could happen and could be fixed by not making the decision about the offset in write_packet: Just because the first packet of a track has a lower dts than the first packet of another track does not mean that the first track needs a bigger offset. That's because the difference of dts and pts can be different for the tracks. An example: Imagine a video track with (say) 24/1.001 fps and two reorder frames whose first packet has a pts of -1 ms (easily createable with -itsoffset). Then the first packet has a pts of -1 ms and a dts of about -84 ms. If one has e.g. an audio track whose first packet has a pts=dts in between -1 ms and -84 ms (given the encoder delay, this can easily happen), then the audio packet will still have a negative pts after shifting. For Matroska this means that the file is against the [https://matroska.org/technical/specs/notes.html specifications].