Re: [FFmpeg-trac] #6905(undetermined:closed): 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:  closed
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |  needs_more_info
Analyzed by developer:  0|   Blocked By:
 |  Reproduced by developer:  0
-+-

Comment (by Misaki):

 Mpeg4 streams work the same way. The reasons for using h.264 were that I
 was sure it would lead to B-pyramids and unpredictable frame order, and
 also that it would work in browsers like Chrome on Linux so verifying an
 error would be easier.

 As I said, MP4Box does it correctly. I don't know how accurate ffprobe is,
 but if it is accurate, then ffmpeg just needs to generate pts's for a
 frame that are the same as the dts's that already exist for that frame,
 when converting an avi to mp4.

 There's also the issue of timestamps being bumped up when converting to
 and from avi; in a 30-fps file this isn't noticeable, but at 1 fps it was
 more so. Although the packet dts as reported by ffprobe started from 0,
 the frames' pkt_dts_time starts at 2 for the ordered-frames.avi file
 (pkt_dts=4). Even if .avi can't have negative timestamps, could still
 start at 0 instead of higher than that. The original mp4 does start at 0
 dts and pts for frames.

--
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:closed): 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:  closed
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |  needs_more_info
Analyzed by developer:  0|   Blocked By:
 |  Reproduced by developer:  0
-+-
Changes (by cehoyos):

 * status:  new => closed
 * resolution:   => needs_more_info


Comment:

 I suggest we shorten this discussion: H.264 timestamps are not always
 correct with FFmpeg, this is a known limitation, it is apparently very
 difficult to fix, several tickets exist.
 H.264 in avi may have issues, this may be unrelated though.

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

 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] #6859(undetermined:reopened): 2pass moov not written and block ffmpeg if input live stream stops before

[FFmpeg]

#6859: 2pass moov not written and block ffmpeg if input live stream stops before
-+-
 Reporter:  zermok   |Owner:
 Type:  defect   |   Status:  reopened
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by cehoyos):

 Use this version instead of 3.4: 80154b1b

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

Re: [FFmpeg-trac] #6859(undetermined:reopened): 2pass moov not written and block ffmpeg if input live stream stops before

[FFmpeg]

#6859: 2pass moov not written and block ffmpeg if input live stream stops before
-+-
 Reporter:  zermok   |Owner:
 Type:  defect   |   Status:  reopened
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by zermok):

 ok, but it's what I did until now,
 compiled myself the last git, and then?
 use git bisect ... how?

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

Re: [FFmpeg-trac] #6906(documentation:open): Re-order options for testsrc family of filters in manual

[FFmpeg]

#6906: Re-order options for testsrc family of filters in manual
-+-
 Reporter:  Misaki   |Owner:
 Type:  defect   |   Status:  open
 Priority:  minor|Component:
  Version:  git-master   |  documentation
 Keywords:  testsrc  |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by llogan):

 * version:  unspecified => git-master


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

Re: [FFmpeg-trac] #6906(documentation:open): Re-order options for testsrc family of filters in manual (was: Option order wrong for filter 'color')

[FFmpeg]

#6906: Re-order options for testsrc family of filters in manual
-+-
 Reporter:  Misaki   |Owner:
 Type:  defect   |   Status:  open
 Priority:  minor|Component:
  Version:  unspecified  |  documentation
 Keywords:  testsrc  |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by llogan):

 * keywords:   => testsrc
 * status:  new => open
 * component:  undetermined => documentation


Comment:

 Don't rely on shorthand: it can be ambiguous or confusing and lead to
 mistakes, and there may be no guarantee that the order will always remain
 the same. Include the option names with your values:
 `color=c=white:s=160x160:r=1:d=10:sar=1`.

 The manual entry is an unorganized combination for the color and other
 related testsrc based source filters, so trying to count the position of
 each supported option (and excluding the options specific to the other
 filters) is not recommended. If you must use shortcuts then refer to
 `ffmpeg -h filter=color` instead. As you can see from this output `sar` is
 currently option five.

 To address this the order in the manual can be changed to: level, c, s, r,
 d, sar, alpha, n. I did not check the order of other non-testsrc filters.
 To check them all is arguably a "wontfix" ticket out of pure laziness
 because reviewing each filter is going to be a boring, mindless job as
 there are at least 350 filters I estimate, and filter authors may not sync
 the option order in future filters. Patch welcome!

 Your output is one frame because you told it to make a frame rate of 1 and
 a duration of 1 second.

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

Re: [FFmpeg-trac] #6775(avcodec:closed): gst-libav can no longer decode video (3.4 regression)

[FFmpeg]

#6775: gst-libav can no longer decode video (3.4 regression)
+---
 Reporter:  heftig  |Owner:
 Type:  defect  |   Status:  closed
 Priority:  critical|Component:  avcodec
  Version:  git-master  |   Resolution:  fixed
 Keywords:  regression  |   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+---
Changes (by cehoyos):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The work-around by James Cowgill was applied as
 02ba4b91b5616ecbebee5c9565e1be7af2a6b980 and backported for 3.4.1.

 I would like to add that I find it disturbing that - assuming this is a
 very shallow bug - both GStreamer and Kodi did not test FFmpeg for at
 least six months.

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

Re: [FFmpeg-trac] #6859(undetermined:reopened): 2pass moov not written and block ffmpeg if input live stream stops before

[FFmpeg]

#6859: 2pass moov not written and block ffmpeg if input live stream stops before
-+-
 Reporter:  zermok   |Owner:
 Type:  defect   |   Status:  reopened
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by cehoyos):

 To find out which commit introduced the regression you are reporting, you
 need to compile yourself and use `git bisect`.

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

Re: [FFmpeg-trac] #6906(undetermined:new): Option order wrong for filter 'color'

[FFmpeg]

#6906: Option order wrong for filter 'color'
-+-
 Reporter:  Misaki   |Owner:
 Type:  defect   |   Status:  new
 Priority:  minor|Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by cehoyos):

 Replying to [ticket:6906 Misaki]:
 > According to the manual, option four for filter 'color' should be sample
 aspect ratio: https://ffmpeg.org/ffmpeg-filters.html
 Where is this specified?

--
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] #6906(undetermined:new): Option order wrong for filter 'color'

[FFmpeg]

#6906: Option order wrong for filter 'color'
-+-
 Reporter:  Misaki   |Owner:
 Type:  defect   |   Status:  new
 Priority:  minor|Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by Misaki):

 * component:  avfilter => undetermined


--
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] #6906(avfilter:new): Option order wrong for filter 'color'

[FFmpeg]

#6906: Option order wrong for filter 'color'
--+---
 Reporter:  Misaki| Type:  defect
   Status:  new   | Priority:  minor
Component:  avfilter  |  Version:  unspecified
 Keywords:|   Blocked By:
 Blocking:|  Reproduced by developer:  0
Analyzed by developer:  0 |
--+---
 According to the manual, option four for filter 'color' should be sample
 aspect ratio: https://ffmpeg.org/ffmpeg-filters.html

 However, the command {{{ffmpeg -filter_complex
 "color=white:160x160:1:1:10" output.mp4}}} produces output of 1 frame.

--
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