Re: [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):

 What do you mean by working file? Many programs play it back just fine.
 ffplay does it normally the first time; if you seek back to the start,
 frame 0 does display for an extra 2~3 seconds. totem plays it completely
 normally. vlc has a short delay, plays it normally, then starts dropping
 frames because of "more than 5 seconds of late video".

 ffmpeg doesn't give any warnings or errors for that command.

 Using MP4Box, part of the 'gpac' package, I was able to get a non-bugged
 mp4 that doesn't stutter in Chrome OS. That program doesn't seem to accept
 the h.264 (avc1) codec, but it's still an interim solution for someone
 wishing to convert old avis (using mpeg4 codec) to mp4s that won't stutter
 in Chrome.
 https://bugs.chromium.org/p/chromium/issues/attachment?aid=315836=1

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [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 cehoyos):

 Replying to [ticket:6905 Misaki]:

 > {{{ffmpeg -i ordered-frames.mp4 -c copy ordered-frames.avi}}}

 Why is this supposed to produce a working file?

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [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: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

[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   | Type:  defect
   Status:  new  | Priority:  normal
Component:   |  Version:  git-
  undetermined   |  master
 Keywords:   |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
 Step 1, generate a video with numbered frames:

 {{{ffmpeg -filter_complex
 
"color=white:160x160:1,drawtext='fontcolor=black:fontsize=96:x=(W-tw)/2+4:y=(H-th)/2+4:text=%{n}:alpha=0.5',boxblur,drawtext='fontcolor=black:fontsize=96:x=(W-tw)/2:y=(H-th)/2:text=%{n}'"
 -preset veryslow -refs 8 -aq-strength 0.5 -threads 1 -crf 20 -frames:v 30
 -movflags faststart ordered-frames.mp4}}}

 Step 2, convert it to avi:

 {{{ffmpeg -i ordered-frames.mp4 -c copy ordered-frames.avi}}}

 Step 3, convert back to mp4:

 {{{ffmpeg -i ordered-frames.avi -c copy -movflags faststart ordered-
 frames-avicopy.mp4}}}

 Examine the frames using ffprobe:

 {{{ffprobe -hide_banner -show_entries
 frame=pkt_pts_time,pkt_dts_time,pkt_size,coded_picture_number ordered-
 frames.mp4 -select_streams v | less}}}

 In another terminal tab, compare the new mp4:

 {{{ffprobe -hide_banner -show_entries
 frame=pkt_pts_time,pkt_dts_time,pkt_size,coded_picture_number ordered-
 frames-avicopy.mp4 -select_streams v | less}}}

 The pkt_dts_time values are just two more than the original file, but the
 pts values are now completely different. They are the packet dts values,
 which are different from the frame's pkt_dts values. This can be seen by
 looking at the packets and looking for similar sizes:

 {{{ffprobe -hide_banner -show_entries packet=pts_time,dts_time,size
 ordered-frames-avicopy.mp4 -select_streams v | less}}}

 Could also make arrays and by doing so sort everything by size so you
 wouldn't have to search to compare packets to frames, but it's easy to
 look for two or three packets.

 Most programs seem to effectively ignore the pts for a frame shown by
 ffprobe, because they pay attention to the dts for a frame, which is
 different from the packet dts but usually the same as the frame pts and
 the packet pts.

 So the 'bugged' mp4 files, copied from avi, appear to have a delay of a
 couple frames at most at the start, but then play normally with maybe a
 slight audio-video sync mismatch.

 But it appears that the Chrome browser and Chrome OS's video player do
 care about the pts values, because they read the frames earlier than the
 dts values. This results in stuttering output:
 https://bugs.chromium.org/p/chromium/issues/detail?id=793635

 They stutter the same way with the original avi file. This is probably
 unrelated to any ffmpeg libraries, but it does seem possible to make the
 copied mp4 files have better timestamps and so play correctly in Chrome.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac