[FFmpeg-trac] #502(undetermined:reopened): Jumping frames (wrong presentation order) when copying video (muxing) of an h264 file (to m4v/mp4) in Quicktime

FFmpeg trac at avcodec.org
Sun Oct 21 00:55:09 CEST 2012


#502: Jumping frames (wrong presentation order) when copying video (muxing) of an
h264 file (to m4v/mp4) in Quicktime
-------------------------------------+-------------------------------------
             Reporter:  Alex__       |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  mux h.264    |               Resolution:
  mp4 m4v quicktime                  |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by RyanS):

 My last comment was not clear. I think ffmpeg mux is getting the pts's
 wrong. Here is ffprobe -show_frames on the ffmpeg-muxed mp4 from the same
 x.264 file:

 [FRAME]
 key_frame=0
 pkt_pts=448399
 pkt_dts=581865
 pkt_duration=66733
 pkt_pos=106296
 pict_type=P
 coded_picture_number=7
 reference=3
 [FRAME]
 [FRAME]
 key_frame=0
 pkt_pts=581865
 pkt_dts=648599
 pkt_duration=66734
 pkt_pos=127438
 pict_type=B
 coded_picture_number=9
 reference=0
 [FRAME]
 [FRAME]
 key_frame=0
 pkt_pts=515132
 pkt_dts=715332
 pkt_duration=66733
 pkt_pos=116060
 pict_type=P
 coded_picture_number=8
 reference=3
 [FRAME]
 (I cut a bunch of lines that are irrelevant for space.)

 You can see here from pkt_pos that the frames are in the same order here
 as they were above in the mp4box mux. (Note that the pkt_pos values are
 offset by 1431 bytes probably because the different muxers put in a
 different header or something, but still the correspondence is clear.) So
 the frames here appear in the correct presentation order. So the pts
 values should simply be ascending, just like in the mp4box mux. But they
 aren't. So it looks like ffmpeg correctly re-orders the frames to
 presentation order but doesn't set the pts's correctly.

 If that is true, then the playback behavior would make sense if Quicktime
 pays attention to the pts's and ffplay/vlc doesn't. ffplay/vlc may just
 get the frames from libavformat/libavcodec and play them in the order
 received, because the decoder is supposed to (and does) put them in
 presentation order.

 Note that because I'm using ffprobe to inspect the mp4's, and ffprobe uses
 the same libs as ffmpeg, there's some question about what is being done by
 the mux step vs by the ffprobe decode step. But given the other evidence I
 think it's the mux step that has the problem.

 Here is the x.264 file I'm using:
 https://dl.dropbox.com/u/62496791/x.264

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/502#comment:14>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list