Next pts does not match previous pts plus duration when transcoding an AAC audio with ffmpeg

In my understanding, the following statement must hold:

next pts = previous pts + duration

But, I got this list of PTSes from ffprobe that looks odd to me:

<packet codec_type="audio" ... pts="63000" duration="2089" duration_time="0.023211" ...>
<packet codec_type="audio" ... pts="65070" duration="2089" duration_time="0.023211" ...>
<packet codec_type="audio" ... pts="67140" duration="2089" duration_time="0.023211" ...>
<packet codec_type="audio" ... pts="69300" duration="2089" duration_time="0.023211" ...>
<packet codec_type="audio" ... pts="71370" duration="2089" duration_time="0.023211" ...>
<packet codec_type="audio" ... pts="73440" duration="2089" duration_time="0.023211" ...>
<packet codec_type="audio" ... pts="75510" duration="2089" duration_time="0.023211" ...>
<packet codec_type="audio" ... pts="77670" duration="2089" duration_time="0.023211" ...>

The corresponding PTS gaps are as follows. You can see none of the below gaps matches 2089:

63000 <> 65070: 2070
65070 <> 67140: 2070
67140 <> 69300: 2160
69300 <> 71370: 2070
71370 <> 73440: 2070
73440 <> 75510: 2070
75510 <> 77670: 2160

I have no deep understanding of AAC or transcoding, so I talked with some random guy on #ffmpeg. As per what he said, the gap should be a fixed value:

20:01 -!- Icedream [~icedream@hzn-b.serverkomplex.de] has quit [Quit: A lol made me boom.]
20:02 < DeHackEd> I would expect them to increment at a constant rate, since AAC (which is probably what you're using) uses fixed size
                  audio chunks. But that's very inconsistent
20:03 < DeHackEd> (+/- 1 pts number would be acceptable)

To tell you the truth, this is a problematic video, but not in a way you would expect. I'm getting intermittent audio clipping sound, if two or more audio packets are crammed into a single PES packet. What's special about this configuration is that, the player must guess PTSes for the trailing audio packets except the first one. Since the PTS gaps are not consistent, the player must have used wrong PTSes for the trailing ones, and this looks to me like the cause.

But, what could be the trigger? Here are some contexts you can kindly refer to:

• the original video has no surprising PTS gap. This is the result from my custom-made script to extract all unique gaps:

$ ./foo.sh ./original.flv
diff 296448 occurs at 296448 // just a first packet (=has no previous packet)
diff 24 occurs at 296472
diff 23 occurs at 296495

• this is the command I used for transcoding:

$FFMPEG -hide_banner -loglevel info -nostats \
    -i $input \
    -map "[out1]" -c:v libx264 -r 30 -force_key_frames "expr:gte(t, n_forced*$keyFrameInterval)" -preset veryfast -vprofile high -minrate 4.5M -maxrate 6M -bufsize 6M \
    -map 0:a -c:a aac -b:a:1 128K -af "aformat=sample_rates=44100|48000:channel_layouts=stereo" \
    -map 0:a -c:a aac -b:a:2 32K -af "aformat=sample_rates=44100|48000:channel_layouts=stereo" \
    -f mpegts -tune zerolatency pipe:1 > \
        >($FFMPEG -hide_banner -loglevel info -nostats \
            -i - \
            -map 0:v -c:v copy -map 0:1 -c:a copy -bsf:a aac_adtstoasc -tune zerolatency -f flv -max_muxing_queue_size 1024 ${output}_1080 \
            -map 0:v -s $(width 1280 720 $orientation)x$(height 1280 720 $orientation) -c:v libx264 -r 30 -force_key_frames "expr:gte(t, n_forced*$keyFrameInterval)" -preset veryfast -vprofile high -minrate 3M -maxrate 4M -bufsize 4M -map 0:1 -c:a copy -bsf:a aac_adtstoasc -f flv -tune zerolatency -max_muxing_queue_size 1024 ${output}_720 \
            ...