Mp4 video starts at different times on Quicktime / AVplayer vs Chrome / Firefox

Question

I have a very strange problem. My OSX application generates screen-based mp4 video. For some reason, if I open this video in Quicktime or on any OSX-based AVP slot, it will start about 14-15 frames earlier than frame 0. If I open mp4 with Chrome or Firefox, it will start playing in frame 0 .

What can lead to ignoring the initial frames? Here is a screenshot of the timer countdown comparing Quicktime vs Firefox at zero time. Notice how Firefox starts at 9:55 and the Quicktime player skips until 9:54.

Here is my sample mp4 file if you want to see it.

thanks

Answer 1

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

Using ffprobe to view the file associated with the 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 

Here you can see that ffprobe reports a “start” of 0.957000, which corresponds to your 1 second offset.

This does not explain why some players abide by this, while others ignore it (Windows Media Player also begins to form a beginning, not an offset). UPDATE: The novel indicates below that this is a known behavior, and it has been discussed on the ffmpeg list (see Roman answer). This may be due to the history of the mp4 container format, which grew out of the Apple QuickTime specification.

The start parameter means the track will be offset for synchronization purposes. Why it would be in your single track video is unclear.

UPDATE: This is probably more information that anyone wants, but for those who are interested ...

Following the Roman answer, I took a closer look at the mp4 file using the MP4 browser. From this we see, firstly, the "timeline" of the film:

And then, in the mp4 world, the edited atom (or the edit field as atoms) is sometimes also called:

The time field in the editing atom tells the player to skip the first 5742 “selections” and start with them. Using this information with a time scale that indicates how many samples are available per second, we can calculate the time it should delay:

• 5742/6000 = 0.957

This corresponds to the "start time" reported by ffprobe, as well as with the delay reported by the OP.

Answer 2

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

Some demultiplexers take this into account (starting at 54:24), while others ignore it (starting at 55:24).

A similar case is discussed here on the FFmpeg ticket: stick to load times in QuickTime edts / elst .

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