mp4 video starts at different time on Quicktime/AV

问题:

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.

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

Thanks

回答1:

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:

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

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.

回答2:

The file has an Edit atom, which defines a portion of the file to play as a track.

Some demultiplexers take it into consideration (start from 54:24) and others ignore (start from 55:24).

A similar case is discussed here in FFmpeg ticket: adher to start media time in QuickTime edts/elst.

Quicktime and VLC subsequently play the file back according to the edit list, but ffmpeg uses the entire timeline.