How does Mediabunny calculate MP4 (container) duration?

[zhmou]

I have a sample video muxed by mediabunny, and the ffprobe output is as follows:

1.mp4

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '1.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isommp41
    creation_time   : 2026-03-24T11:54:22.000000Z
  Duration: 00:00:43.44, start: 0.000000, bitrate: 61 kb/s
  Stream #0:0[0x1](und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv), 1280x1936, 126 kb/s, 12.03 fps, 50 tbr, 57600 tbn (default)
    Metadata:
      creation_time   : 2026-03-24T11:54:22.000000Z
      handler_name    : MediabunnyVideoHandler
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 8000 Hz, mono, fltp, 15 kb/s, start 13.080000 (default)
    Metadata:
      creation_time   : 2026-03-24T11:54:22.000000Z
      handler_name    : MediabunnySoundHandler

As you can see, the container duration is about 43 seconds.

However, when inspecting the actual video and audio tracks:

Video track packets:

ffprobe -v error -select_streams v:0 -show_entries packet=pts_time,duration_time -of csv=p=0 1.mp4

0.000000,0.119583
0.119583,0.040347
...
17.119861,0.040347
17.160208,0.040000

Audio track packets:

ffprobe -v error -select_streams a:0 -show_entries packet=pts_time,duration_time -of csv=p=0 1.mp4

13.080000,13.208000
13.208000,0.128000
...
30.104000,0.128000
30.232000,0.128000

From this, it seems:

• The video track ends around ~17 seconds
• The audio track ends around ~30 seconds

So neither track appears to reach the reported ~43 seconds duration.

Interestingly:
When playing the file in an HTML <video> element, the control bar uses the container duration (~43s)
But in VLC, it seems to use the longest track duration instead.

A portion of my code looks like this:

    const target = new Mediabunny.BufferTarget()
    const output = new Mediabunny.Output({
      format: new Mediabunny.Mp4OutputFormat(),
      target: target,
    })
    const videoSource = new Mediabunny.EncodedVideoPacketSource('hevc')
    output.addVideoTrack(videoSource)

    const audioSource = new Mediabunny.AudioSampleSource({
      codec: 'aac',
      bitrate: 128000,
    })
    output.addAudioTrack(audioSource)
    await output.start()
    
    // loop to add frame
    const sample = new Mediabunny.AudioSample({
        data: pcmData,
        format: 's16',
        numberOfChannels: channels,
        sampleRate: sampleRate,
        timestamp: timeRelative,
    })
    await audioSource.add(sample)
    sample.close()
    
    const packet = new Mediabunny.EncodedPacket(
      frame.realData,
      frame.isKeyFrame ? 'key' : 'delta',
      frame.timeRelative,
      duration
    )

    await videoSource.add(packet, chunkMetaData)
    
    // generate mp4
    await task.mediabunnyOutput.finalize()

Is Mediabunny calculating the MP4 duration incorrectly? Any insights into how Mediabunny computes duration (and whether this behavior is expected) would be greatly appreciated.

[Vanilagy]

Hey! Actually I cannot see what Mediabunny is doing wrong here. Mediabunny itself parses the file's duration as 30.36 seconds, which lines up with the end timestamp of the last packet. Even in the container metadata that value is stored. So the question is, why do FFmpeg and Chromium think the video is 43 seconds long? Could be that Chromium uses FFmpeg to determine the duration and that's why they agree.

The thing that sticks out to me is

13.080000,13.208000

which is odd, since the duration is supposed to be 0.128000. FFmpeg is probably summing up all packet durations and adding the start offset to reach the final duration of 43 seconds.

That first packet duration is probably a side-effect of how the start offset is being modeled by Mediabunny, since MP4 doesn't play too well with tracks starting at non-zero timestamps. But to be honest, this almost seems like incorrect behavior from FFmpeg (an FFmpeg bug).

If you need a quick fix, since you're working with media that uses non-zero timestamp offsets, try using fragmented MP4 as muxing output instead - it handles that quite a bit better.

[Vanilagy]

Update: I fixed this behavior in 782d3e1. FFmpeg now reports the correct duration for non-zero start timestamp MP4s.