[Regression] Audio silent for long MOV file

[cgbug]

Sample:
​https://drive.google.com/file/d/1-rNZyZCykN083EPlSRDS2_heAr7vERlO/view?usp=sharing

Regression since:
​http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=292c1df7c159c8a1a7afe52613d164ff417e81ce

No obvious anomalies in console output.

[MasterQuestionable]

͏    Interpreted link:
͏    ​https://drive.usercontent.google.com/download?export=download&id=1-rNZyZCykN083EPlSRDS2_heAr7vERlO
͏    ("Delta Force Urban Warfare PS1 Walkthrough [No Damage].mov": ~ 10.61 GiB)

͏    @ 2025-01-10T13:39:00Z
͏    ​https://github.com/FFmpeg/FFmpeg/commit/292c1df7c159c8a1a7afe52613d164ff417e81ce
͏    “avformat/mov: merge stts and ctts arrays into one
͏    Should reduce memory usage as well as remove code duplication.”

͏    Please report:
͏    ffprobe -hide_banner -threads 0 -show_entries "stream=time_base:format=size" -of "flat=h=0" "${In}"
͏    ; of such huge source.

͏    Also please verify if it's reproducible when remuxed to other containers.
͏    (assume there's no problem in the audio itself, after all)

͏    ----

͏    Note:
͏    Google currently reports:
[[
͏    Google Drive - Quota exceeded
͏    Sorry, you can't view or download this file at this time.

͏    Too many users have viewed or downloaded this file recently.
͏    Please try accessing the file again later.
͏    If the file you are trying to access is particularly large or is shared with many people, it may take up to 24 hours to be able to view or download the file.
͏    If you still can't access a file after 24 hours, contact your domain administrator.
]]
͏    (tested only anonymous access)
͏    .
͏    Not IP blocked, nor access method change.
͏    (other file may work; haven't specifically tested large ones)

[cgbug]

Remuxing is pointless as it is a regression in the MOV demuxer.

2025-01-08-git-251de1791e is ok
2025-01-13-git-851a84650e and later has bug

MediaInfo shows a conformance error.

General
Complete name               : C:\samples\Delta Force Urban Warfare PS1 Walkthrough [No Damage].mov
Format                      : MPEG-4
Format profile              : QuickTime
Codec ID                    : qt   0000.02 (qt  )
File size                   : 10.6 GiB
Duration                    : 2 h 18 min
Overall bit rate            : 10.9 Mb/s
Frame rate                  : 60.000 FPS
Encoded date                : 2023-10-06 14:00:33 UTC
Tagged date                 : 2023-10-06 14:00:33 UTC
Writing application         : Blackmagic Design DaVinci Resolve
Conformance errors          : 1
 mdat                       : Yes
  0x00000003                : Yes
   General compliance       : Element size 11386113113 is more than maximal permitted size 11383799837 (offset 0x2C)

Video
ID                          : 1
Format                      : HEVC
Format/Info                 : High Efficiency Video Coding
Format profile              : Main@L5.1@High
Codec ID                    : hvc1
Codec ID/Info               : High Efficiency Video Coding
Duration                    : 2 h 18 min
Bit rate                    : 9 396 kb/s
Width                       : 2 880 pixels
Height                      : 2 160 pixels
Display aspect ratio        : 4:3
Frame rate mode             : Constant
Frame rate                  : 60.000 FPS
Color space                 : YUV
Chroma subsampling          : 4:2:0
Bit depth                   : 8 bits
Scan type                   : Progressive
Bits/(Pixel*Frame)          : 0.025
Stream size                 : 9.11 GiB (86%)
Encoded date                : 2023-10-06 14:00:33 UTC
Tagged date                 : 2023-10-06 14:00:33 UTC
Color primaries             : BT.709
Transfer characteristics    : BT.709
Matrix coefficients         : BT.709
Codec configuration box     : hvcC

Audio
ID                          : 2
Format                      : PCM
Format settings             : Little / Signed
Codec ID                    : lpcm
Duration                    : 2 h 18 min
Bit rate mode               : Constant
Bit rate                    : 1 536 kb/s
Channel(s)                  : 2 channels
Channel layout              : L R
Sampling rate               : 48.0 kHz
Bit depth                   : 16 bits
Stream size                 : 1.49 GiB (14%)
Default                     : Yes
Alternate group             : 1
Encoded date                : 2023-10-06 14:00:33 UTC
Tagged date                 : 2023-10-06 14:00:33 UTC

Other
ID                          : 3
Type                        : Time code
Format                      : QuickTime TC
Duration                    : 2 h 18 min
Frame rate                  : 60.000 FPS
Time code of first frame    : 00:00:00:00
Time code of last frame     : 02:18:50:36
Time code, stripped         : Yes
Language                    : English
Encoded date                : 2023-10-06 14:00:33 UTC
Tagged date                 : 2023-10-06 14:00:33 UTC

[cgbug]

loglevel debug show this:

[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] ISO: File Type Major Brand: qt  
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] Unknown dref type 0x206c7275 size 12
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] Processing st: 0, edit list 0 - media time: 0, duration: 127958272
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] Unknown dref type 0x206c7275 size 12
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] chan: layout=6619138 bitmap=0 num_descr=0
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] Unknown dref type 0x206c7275 size 12
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] Processing st: 2, edit list 0 - media time: 0, duration: 127958272
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000000004e8cc0] Before avformat_find_stream_info() pos: 11386113157 bytes read:2378812 seeks:3 nb_streams:3

[MasterQuestionable]

͏    Try remuxing with the OK version.
͏    Also extracting only audio to WAV and verify.

͏    Seems like MP4 editlist issue.
͏    Would "-ignore_editlist" workaround?
͏    .
͏    Caveat: ​https://trac.ffmpeg.org/ticket/11201#comment:3


͏    Side note:
͏    Removing the memory addresses in your log may help reading.
͏    ​https://trac.ffmpeg.org/ticket/10998

[cgbug]

The problem seems to be that the file has an invalid value in stsz atom for the PCM audio track.

sample_size = 4
sample_count = 399869600

When multiplied this roughly equals the size of the audio track (1.5GB) as indicated by MediaInfo. So likely a bug in the writing app, which is Davince Resolve. Video has duration of 2H:18M.

This high value for sample_count triggers the sanity check in mov_merge_tts_data, while it did not in older code due to size difference in structs (stts_data vs tts_data).

I can make the file playable by adjusting sample_count to a lower value in mov_read_stsz.

[cgbug]

Proper fix would be to calculate the max number of entries based on the atom size, and use that to validate and correct the entries value.
That would also prevent doing unnecessary large allocations and reads.

[James]

Can you upload a portion of the file that contains the moov header including the faulty stsz?

[cgbug]

Here is first 30mb of the file:
​https://www.sendspace.com/file/7cbl4x

And here last 5mb from end of file that contain rest of atoms:
​https://www.sendspace.com/file/50zdec

[cgbug]

This fixes the problem:

In mov_merge_tts_data() change

    if (!sc->sample_count || sc->sample_count >= UINT_MAX / sizeof(*sc->tts_data))
        return -1;

to

    if (!sc->sample_count || sc->sample_count >= UINT_MAX / sizeof(*sc->tts_data) && (ctts || stts))
        return -1;

With pcm audio data, the stsz atom contains a fixed nonzero sample_size and empty sample size table. With very long duration the sample_count can be so high it triggers the original check when it is not relevant due to ctts and stts being 0.

[cgbug]

Ping

[MasterQuestionable]

͏    ​https://github.com/FFmpeg/FFmpeg/blob/1731eba20d87a7f62f91c4507fca783c20b5ece4/libavformat/mov.c#L4564
͏    ​https://github.com/FFmpeg/FFmpeg/commits/master/libavformat/mov.c

͏    You may also add a commit alike:
͏    ​https://trac.ffmpeg.org/ticket/10869#comment:7
͏    (better for review)

͏    Better looking:
[[

    if (
    ! sc->sample_count || (
    sc->sample_count >= UINT_MAX / sizeof( *sc->tts_data )
    && ( ctts || stts ) )
    )
    return -1;

]]
͏    With PCM audio data, the "stsz" atom contains a fixed non-0 "sample_size" and empty sample size table.
͏    With very long duration, the "sample_count" can be so high it triggers the original check:
͏    When it is not relevant due to "ctts" and "stts" being 0.

[Derek Buitenhuis <derek.buitenhuis@gmail.com>]

In ae03b629/ffmpeg:

avformat/mov: Merge tts after building index for old-style uncompressed PCM

This was a regression introduced in 292c1df7c159c8a1a7afe52613d164ff417e81ce.

Since we don't know the length of the stts data until after building the
index, since we're generating it, we need to merge any ctts data after,
since otherwise tts_count is set to 0, and no packets will be output.

We can't remove the merge entirely, because uncompressed PCM with
a ctts atom is technically valid (e.g. a constant CTS offset).

This fixes old-style uncompressed PCM demuxing.

Fixes #11490.

Signed-off-by: Derek Buitenhuis <​derek.buitenhuis@gmail.com>