[FFmpeg-trac] #8452(undetermined:reopened): slow png decode starting with ffmpeg-3.3.1

FFmpeg trac at avcodec.org
Sat Jan 18 03:58:56 EET 2020

#8452: slow png decode starting with ffmpeg-3.3.1
             Reporter:  DonMoir      |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:  regression   |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
Changes (by DonMoir):

 * status:  closed => reopened
 * resolution:  worksforme =>


 Carl's response has got to be in the top five worse responses.

 Carl says worksforme. We have to guess what it means. Assume he means he
 used ffplay and he could not see any difference between versions. I
 mentioned above: ''"Just looking at the playback is probably not enough to
 verify."'' Using ffplay I see about the same CPU usage in either version
 which is about 20 percent. If you look at the table above that would be
 expected. Using a single thread the CPU usage is about the same. But it
 takes 1.5 seconds to decode the 30 frames. Older versions decode the 30
 frames in .745 seconds.

 I mentioned that the best way to check is to time the decode and cross
 check my numbers. I assume this would have been done by someone who knows
 what he is doing. This is a simple thing to do if you know what you are
 doing. Show your stats and OS. Is it a windows thing? It could be some
 flag or something I am not doing right for the new versions but I tried
 several variations. I tried avcodec_decode_video2 and avcodec_send_packet
 and other things. All the time was in avcodec_send_packet.

 worksforme basically says there is no problem and no need to look at it

 Before I saw the increase in CPU for PNG, it appeared to me there was a
 slight increase in other formats as well. Maybe 2 percent. Did not concern
 me too much at the time. gdgsdg123 mentions he is seeing slower decoding
 with x264rgb. I am thinking the problem is widespread but not very
 noticeable for most formats. Probably the reason it has gone unnoticed for
 years. PNG has a slow decode in the first place. It also appears to do
 more locking which again may point to the atomic functions. The increase I
 see of about 10 percent could be an increase of 20 to 40 percent on slower
 machines. In the new versions the CPU usage increases proportionately to
 the complexity of the PNG. Sure the usages increases likewise in the old
 versions but in the new versions it climbs at higher rate. It does not
 appear to be related directly to the PNG decoding code. Since PNG shows
 the problem the best it should be used for testing no matter the scope of
 the problem.

 When using any new version of ffmpeg I test it extensively before I use it
 publicly. Since I was using an old API and I assumed there would be
 problems using the new ffmpeg I made my code ffmpeg API independent so I
 can easily switch back. I ran into this problem early on in testing and
 ran into road blocks when reported. What else in new? You benefit form my
 testing but I might as well stop now if this is the kind of BS I have to
 deal with. I wonder how many thousands of times issues have been closed
 incorrectly. During my first go around I wasted far more time reporting a
 problem than it would take to fix the problem. I don't have that kind of
 time now. If the issue is closed again without any resolution I am out of
 here and will fix the problems myself without reporting them.

Ticket URL: <https://trac.ffmpeg.org/ticket/8452#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list