Search code examples
videoavfoundationmp4avplayerquicktime

mp4 video starts at different time on Quicktime/AVplayer vs Chrome/Firefox


I have a very strange issue. My OSX app is generating an mp4 video based on a screen cast. For some reason, if I open this video in Quicktime or any OSX-based AVPlayer, it will start about 14-15 frames in advance of frame 0. If I open the mp4 with Chrome or Firefox, it will actually start playing at frame 0.

What could cause this ignoring of beginning frames? Here's a screenshot of a timer countdown comparing Quicktime vs Firefox at time zero. Notice how the Firefox player starts at 9:55, while the Quicktime player skips ahead to 9:54. enter image description here

Here's my sample mp4 file if you'd like to see for yourself.

Thanks


Solution

  • This is an interesting question and your example is a great illustration of the effect.

    Using ffprobe to look at the file you linked to above gives:

    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'c44116b.mp4':
      Metadata:
        major_brand     : qt  
        minor_version   : 0
        compatible_brands: qt  
        creation_time   : 2015-04-25 15:54:30
      Duration: 00:00:03.70, start: 0.957000, bitrate: 1164 kb/s
        Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 480x360 [SAR 1:1 DAR 4:3], 899 kb/s, 22.99 fps, 22.99 tbr, 6k tbn, 12k tbc (default)
        Metadata:
          creation_time   : 2015-04-25 15:54:30
          handler_name    : Core Media Data Handler
          encoder         : H.264
    

    You can see here that ffprobe is reporting a 'start' of 0.957000, which would correspond to your 1 second offset.

    This does not explain why certain players abide by this and others ignore it (Windows Media player also appears to start form the beginning, rather than the offset). UPDATE: Roman points out below that this is a known behaviour and it has been discussed on the ffmpeg list (see Roman's answer). This may be due to the history of the mp4 container format, which grew from the Apple QuickTime spec.

    The purpose of the start parameter appears to be to allow a track be offset for synchronisation purposes. Why this would exist in your video with just one track is not clear.

    UPDATE: This is probably more info that anyone wants, but for those interested...

    Following up on Roman's answer I took a look at the mp4 file in more detail using MP4 Browser. From this we can see firstly the 'timescale' of the movie:

    enter image description here

    And then the edit atom (or edit box as atoms are also sometimes called in the mp4 world):

    enter image description here

    The time field in the edit atom tells the player to skip the first 5742 'samples' and start from there. Using this info with the timescale, which tells us how many samples there are per second, we can calculate the time it should delay:

    • 5742/6000 = 0.957

    This corresponds with the 'start time' that ffprobe reports and also with the delay that the OP reported.