last frame in file with -show_frames 86400
code writes "15" @ 86400
then "16" @ 90000

Seems to be a similar thing if twice as much is written to the output (only the last frame is missing).

The output of ffprobe -v quiet -print_format json -show_format -show_streams -show_frames -select_streams v:0 build/test/ffmpeg_encoder_missing_frame_at_end.mov seems quite interesting.

When the trak tags are written, with track duration, they are wrong because the durations are obtained from trk->end_pts, which (in the video case, at least) is calculated by adding the AVPacket.duration onto the last PTS seen. Nobody is setting the AVPacket duration; hacking it into DoM seems to fix it. Not sure why packets coming back from avcodec_receive_packet() have no duration.

Need to finish off the test and then maybe just get DoM to set these durations.

Seems like when reading the video stream we have 26 chunks read from the STCO atom. We then read 25 video frames from that. Maybe there should be 27 chunks.

It's written in DoM as 26, during the mov_write_trailer. The "good" file also seems to have 26 chunks. But bad ends up with nb_index_entries=25, good with 26.

Good and bad end up[ with START_WITH 26 but then bad has

[1]nb_index_entries -> 25

good

[1]nb_index_entries -> 26

i.e. the loop marked index=%d, current=%p being run one less time.
but the termination condition looks the same

edit_list_duration is 90000 when I think it should be higher?

bad 90000/3600 = 25
good 26 / 1 = 26

edit_list_duration seems to be read by get_edit_list_entry(); ELST atom

** WRITING 1000
<WB>: 4
<WB>: 12
<WB>: 4
<WB>: 11
<WB>: 31
WRITE THE * STCO 26
get chunkCount as 26
** WRITING 1040
<WB>: 4
<WB>: 12
<WB>: 4
<WB>: 11

is it writing it twice here, first time wrong?

Writing trak tags for 2 streams, first length 1000, second length 1040.
one has duration 90000, scaled by 1000/90000
one has duration 49920, scaled by 1000/48000

trk->end_pts is used, set to 90000.

pkt->duration is 0?

Running tests.

Holy moley. This is more complicated than I expected!

Yeah it's a classic FFmpeg rabbit hole... I think I must be missing something but it's hard to work out what.

d33678b8e64de795becd3fa336dbbb099c691f58

Confirmed fixed in 2.16.65.

Thanks for checking!