Audio of damaged MP4 suddenly stops playing

[PumaD]

Follow-up to #11005

Got a slightly damaged 1.9 GiB MP4 file. When playing with ffplay (or any ffmpeg based player like mpv) the audio suddenly stops playing at 00:43:05.

Remuxing the file with mkvtoolnix resolves this problem.
(​https://gitlab.com/mbunkus/mkvtoolnix; mkvmerge --output out.mkv slightly-damaged-audio-stops-at-00-43-05.mp4)

Remuxing with ffmpeg instead does not.
(ffmpeg -i slightly-damaged-audio-stops-at-00-43-05.mp4 -c copy out.mkv)

Sorry for the large "sample". I didn't manage to extract data from the middle without breaking the file completely or baking the problem into the sample.
​https://streams.videolan.org/ffmpeg/incoming/11028/slightly-damaged-audio-stops-at-00-43-05.mp4 (~ 1 GiB)

Note: NSFW

How to reproduce:

$ ffplay -ss 00:43:00 slightly-damaged-audio-stops-at-00-43-05.mp4 
ffplay version N-115363-g3146b77a7d Copyright (c) 2003-2024 the FFmpeg developers
  built with gcc 14.1.1 (GCC) 20240507
  configuration: 
  libavutil      59. 19.100 / 59. 19.100
  libavcodec     61.  5.104 / 61.  5.104
  libavformat    61.  3.103 / 61.  3.103
  libavdevice    61.  2.100 / 61.  2.100
  libavfilter    10.  2.102 / 10.  2.102
  libswscale      8.  2.100 /  8.  2.100
  libswresample   5.  2.100 /  5.  2.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x726024000c80] Sample size 3043950162 is too large
[h264 @ 0x726024001c00] concealing 1691 DC, 1691 AC, 1691 MV errors in I frame
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'slightly-damaged-audio-stops-at-00-43-05.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.62.100
  Duration: 01:28:36.03, start: 0.000000, bitrate: 1577 kb/s
  Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(progressive), 960x720 [SAR 1:1 DAR 4:3], 3028 kb/s, 29.93 fps, 30 tbr, 90k tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 93 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]
[h264 @ 0x72602455e800] concealing 1127 DC, 1127 AC, 1127 MV errors in P frame
2589.48 A-V: -0.008 fd=   0 aq=    0KB vq=15360KB sq=    0B

[PumaD]

Added the sample to reproduce.

[Balling]

Does not it warn that

[mov,mp4,m4a,3gp,3g2,mj2 @ 000001fabf400100] Sample size 3043950162 is too large

?

Also, did you see this applied patch:
​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211116141533.1708-1-ffmpeg@gyani.pro/

"The muxer should be adjusted to be able to write larger durations in the
stts but that's a larger undertaking which I'll do later."

Also by setting -v debug we see

Processing st: 0, edit list 0 - media time: -1, duration: 2790

Negative priming, indeed (media time of 0xFFFFFFFF means -1 per genius spec of MP4):

00000110 Track duration: 31 (0x0000001F) - 31 (0x1F)
00000114 Media time: 4294967295 (0xFFFFFFFF)
00000118 Media rate: 65536 (0x00010000) - 1.000

[Balling]

00:43:05? Here in mpv it plays 00:44:29

[PumaD]

Replying to Balling:

Does not it warn that

[mov,mp4,m4a,3gp,3g2,mj2 @ 000001fabf400100] Sample size 3043950162 is too large

?

There's this in the output posted above:
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x726024000c80] Sample size 3043950162 is too large
Is that what you were looking for?

Replying to Balling:

Also, did you see this applied patch:
​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211116141533.1708-1-ffmpeg@gyani.pro/

"The muxer should be adjusted to be able to write larger durations in the
stts but that's a larger undertaking which I'll do later."

I did not see it, but what does that tell me? I'm but a humble user, I'm happy when I manage to pass the correct parameters to a CLI.

Replying to Balling:

Negative priming, indeed (media time of 0xFFFFFFFF means -1 per genius spec of MP4):

Given that the file is damaged, how much relevance does the spec hold? All other files in the set play without problems, so my assumption would be that any problems are the result of corruption. I just reported it because mkvtoolnix manages to fix it up anyway.

Replying to Balling:

00:43:05? Here in mpv it plays 00:44:29

Yes, sound goes out at 00:43:05. 00:44:29 is the total duration of the sample. It's the largest I could cut it and not be rejected by the upload page.

[MasterQuestionable]

͏    The essence of the problem is that FFmpeg should probably use more permissive parsing, rather than outright failing.
͏    Alike: ​https://trac.ffmpeg.org/ticket/10008#comment:7

͏    This should aid handling similar broken files.

[PumaD]

As requested at ​https://trac.ffmpeg.org/ticket/11005#comment:14

[PumaD]

As requested at ​​https://trac.ffmpeg.org/ticket/11005#comment:14 (now actually of the original file)

[PumaD]

Updated exiftools to 12.85, ffmpeg to latest master, and the timestamp output around the failure site, which was missed before, is now included:

​https://pastebin.com/3hBRUHvq

Yes, the audio timestamps just kind of stop at 2585.147256 while the video timestamps continue.

[Balling]

Another related issue: #10326

[MasterQuestionable]

͏    Filtered:
͏    ​https://pastebin.com/raw/3hBRUHvq

͏    Probably not of much use... included for completeness.