Concat of H.264 video results in glitches at join point

[savingray]

Summary of the bug:

When using concat demuxer (concat.log) to join two segments (seg[12].mp4) of video the resulting file (concat.mp4) has playback issues (ffplay.log):

• a few first frames of second segment are lost (skipped?)
• frames at join point are reordered: last frame from first segment plays after first frame frame from second segment
• "mmco: unref short failure" errors in console

How to reproduce:

curl -o seg1.mp4 -o seg2.mp4 https://files.catbox.moe/ysoa9l.mp4 https://files.catbox.moe/zhuw5h.mp4
printf "file 'file:%s'\n" seg?.mp4 | ffmpeg -protocol_whitelist pipe,file -safe 0 -f concat -i - -c copy concat.mp4
ffplay concat.mp4

Additional notes:

The video segments were obtained from youtube video Sc_v1l8v9sw in the following way

yt-dlp -f 137 -o input.mp4 Sc_v1l8v9sw
ffmpeg -ss '130.09663' -i input.mp4 -t '3.97063' -c copy seg1.mp4
ffmpeg -ss '138.47167' -i input.mp4 -t '5.33867' -c copy seg2.mp4

[mkver]

The H.264 elementary stream has two important counters: frame_num and pic_order_cnt_lsb. The latter is how one can derive the frame (re)ordering from an elementary stream. The frame_num of the first frame of the second video is 11, its pic_order_cnt_lsb is 2; the values for the last frame of the first video are 10 and 10. According to the pic_order_cnt_lsb the last pic of the first video should be displayed after the first picture of the second video.

[savingray]

Replying to mkver:

Hi, thanks for having a look. But I'm not sure what are the implications of your comment.

The H.264 elementary stream has two important counters: frame_num and pic_order_cnt_lsb. The latter is how one can derive the frame (re)ordering from an elementary stream.

So how do these counters work e.g. what is their relation to frame/packet PTS/DTS timestamps? Is this information even extractable with fftools?

The frame_num of the first frame of the second video is 11, its pic_order_cnt_lsb is 2; the values for the last frame of the first video are 10 and 10. According to the pic_order_cnt_lsb the last pic of the first video should be displayed after the first picture of the second video.

Are you referring to merged video here or segments? Shouldn't these values be rewritten during mux anyway to ensure proper order? And why are some frames skipped entirely?

And most importantly is there a way to fix video? :)
As I stumble upon this problem quite often when dealing with H.264 videos from Youtube I wonder if this can be result of to the way these videos are encoded (I never experienced anything similar with VP9 encodes).

[savingray]

Is there a chance for this bug to become acknowledged as valid at least? Thanks