Initial packet timecodes using IMediaStreamLivePacketNotify

Wowza Streaming Engine
1

I am attempting to determine the timecodes of incoming RTMP stream packets via IMediaStreamLivePacketNotify.onLivePacket() by checking AMFPacket.getAbsTimecode(). However, I am observing that regardless of the timecode strategy used by the encoder (for example using -output_ts_offset with ffmpeg) the first packet after publishing for each packet type (e.g. 8 and 9 for audio and video) always has a timecode of 0, then the subsequent packet has the expected start timecode.

For example, given an ffmpeg command like this:
ffmpeg -i bbb.mp4 -c copy -f flv -output_ts_offset 42000 rtmp://myhost/dev/test

Logging the packets directly shows something like this:

{AMFPacket: size: 4,  type: 8,  src: 1,  seq: 1,  absTimecode: 0,  timecode: 0}
{AMFPacket: size: 44,  type: 9,  src: 1,  seq: 2,  absTimecode: 0,  timecode: 0}
{AMFPacket: size: 25,  type: 8,  src: 1,  seq: 3,  absTimecode: 42000000,  timecode: 42000000}
{AMFPacket: size: 1444,  type: 9,  src: 1,  seq: 4,  absTimecode: 42000000,  timecode: 42000000}
{AMFPacket: size: 10,  type: 8,  src: 1,  seq: 5,  absTimecode: 42000021,  timecode: 21}
{AMFPacket: size: 17,  type: 9,  src: 1,  seq: 6,  absTimecode: 42000042,  timecode: 42}

If I also log in IHTTPStreamerCupertinoLivePacketizerDataHandler2.onFillChunkStart() the LiveStreamPacketizerCupertinoChunk.getStartTimecode() then I only see that 42000000 value which implies that the initial packets with timecode 0 are not actual audio or video data being included in an HLS chunk.

So this leads me to believe that these initial packets are some kind of metadata which has no bearing on the PTS of the actual stream contents, and so should be ignored for the purposes of timecode calculations.

For context, my ultimate goal is to calculate an offset to apply to each packet’s timecode so as to align it with wall-clock time. Some encoders can do this themselves, but for those that cannot I want to do it serverside. This then translates to chunk names via e.g. cupertinoCalculateChunkIDBasedOnTimecode.

Since packet timecodes are by definition relative to each other, I should only have to calculate this offset once at the beginning, then all subsequent packets should be treated as relative to that. Hence the problem with an initial 0 and then a jump to wherever the encoder is actually starting its timecodes.

My questions are:

  1. Are these initial packets (one per type) always guaranteed by RTMP (so I could just skip the first packet of each type blindly)?
  2. Is there some property of the AMFPacket that can be checked to determine if it is one of these presumed metadata packets?