[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 =>
Comment:
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
further.
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