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

[FFmpeg]

#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 command line and ffmpeg version output was in my prior post. My
 complete console output does not appear to be substantively different from
 the original bug report, but I can include it if you think it is worth the
 extra post size.

 Note that I do not see the symptom in VLC (Windows version 2.0.1) just
 Quicktime.

 Using ffprobe, it looks like my speculation was backwards. The ffmpeg-
 muxed mp4 has pts's that are not in order, they match the
 coded_picture_number order. However, an mp4box-muxed mp4 (that quicktime
 plays correctly) has pts's that are simply ascending. Here is ffprobe
 -show_frames output for the mp4box mp4 that plays correctly (notice coded
 picture numbers 7,9,8):

 [FRAME]
 media_type=video
 key_frame=0
 pkt_pts=32032
 pkt_pts_time=0.444889
 pkt_dts=36036
 pkt_dts_time=0.500500
 pkt_duration=4004
 pkt_duration_time=0.055611
 pkt_pos=107727
 width=720
 height=480
 pix_fmt=yuv420p
 sample_aspect_ratio=N/A
 pict_type=P
 coded_picture_number=7
 display_picture_number=0
 interlaced_frame=0
 top_field_first=0
 repeat_pict=0
 reference=3
 [FRAME]
 [FRAME]
 media_type=video
 key_frame=0
 pkt_pts=36036
 pkt_pts_time=0.500500
 pkt_dts=40040
 pkt_dts_time=0.556111
 pkt_duration=4004
 pkt_duration_time=0.055611
 pkt_pos=128869
 width=720
 height=480
 pix_fmt=yuv420p
 sample_aspect_ratio=N/A
 pict_type=B
 coded_picture_number=9
 display_picture_number=0
 interlaced_frame=0
 top_field_first=0
 repeat_pict=0
 reference=0
 [FRAME]
 [FRAME]
 media_type=video
 key_frame=0
 pkt_pts=40040
 pkt_pts_time=0.556111
 pkt_dts=44044
 pkt_dts_time=0.611722
 pkt_duration=4004
 pkt_duration_time=0.055611
 pkt_pos=117491
 width=720
 height=480
 pix_fmt=yuv420p
 sample_aspect_ratio=N/A
 pict_type=P
 coded_picture_number=8
 display_picture_number=0
 interlaced_frame=0
 top_field_first=0
 repeat_pict=0
 reference=3
 [FRAME]

 I notice that the pts is always < dts, and that pts is always equal to
 prior frame's dts (in stream order).

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