#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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
