[FFmpeg-trac] #6905(undetermined:new): When copying video from .avi to .mp4, frames have incorrect pts values

[FFmpeg]

#6905: When copying video from .avi to .mp4, frames have incorrect pts values
-------------------------------------+-------------------------------------
             Reporter:  Misaki       |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by Misaki):

 Converting from avi gives the error message, [mp4 @ 0x5572f6242e80] pts
 has no value (Last message repeated 29 times).

 (I don't know if '-vsync drop' is working correctly. When I try to use it,
 it gives the error 'av_interleaved_write_frame(): Invalid argument' and
 'Conversion failed!', whether codec is copy or x264, though x264 only
 stops after reading a little more than rc_lookahead frames. Not making a
 new bug report unless sure it's a bug.)

 But anyway, it seems that the mp4 muxer is probably giving pts values to
 the packets that don't have any, based on the packet order instead of the
 frame order.

 In all cases, it seems like the packet's 'pts' is the same as the frame's
 'pkt_pts', even though for normal files this is also the same as the
 frame's 'pkt_dts', while in the bugged files it's the same as the packet's
 'dts', which is different from the frame's 'pkt_dts'.

 If the mp4 muxer is writing these pts values for the frame, it should be
 possible for it to assume pts values based on the frame order (or using
 the frame dts), not the packet order.

 This gives a consistent explanation for the stuttering in Chrome: for an
 avi file, Chrome is making up pts values based on the packet order. These
 just happen to be the same as the dts values for those packets (which is
 different from the dts values for the frames contained in the packets, as
 reported by ffprobe). The mp4 muxer component of ffmpeg makes up pts
 values if frames don't have them, and it also does this based on the
 packet order instead of the frame order.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/6905#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker