# Initial packet timecodes using IMediaStreamLivePacketNotify

**URL:** <https://community.wowza.com/t/initial-packet-timecodes-using-imediastreamlivepacketnotify/93086>\
**Category:** Wowza Streaming Engine\
**Created:** [March 31, 2021, 6:24pm UTC](https://community.wowza.com/t/initial-packet-timecodes-using-imediastreamlivepacketnotify/93086 "2021-03-31T18:24:49Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jsterling\_LLNW](https://sea2.discourse-cdn.com/flex002/user_avatar/community.wowza.com/jsterling_llnw/32/727_2.png) [@jsterling\_LLNW](https://community.wowza.com/u/jsterling_LLNW)\
**Post date:** [March 31, 2021, 6:24pm UTC](https://community.wowza.com/t/initial-packet-timecodes-using-imediastreamlivepacketnotify/93086/1 "2021-03-31T18:24:49Z")

</div>

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:

```auto
{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?