Bug 181033 – <img> decode single frame h264 and hevc slower than jpg

• Status: NEW
• Component: Images

[Colin Bendell]

Comparing the decode time of a single frame h264 or hevc compared to jpg is much slower compared to jpg. 

https://github.com/colinbendell/webperf/img-decode/index.html

When testing locally (network transfer near 0) I get the following results while measuring the image.decode time on High Sierra with TP45:

JPG Decode: 7 ms
h264 Decode: 54 ms
hevc Decode: 47 ms

This is from a looping test of 10 iterations selecting the median result. The results are generally consistent that jpg decode is faster than h264/hevc single frame.

[Jer Noble]

There is probably more overhead in bringing up an instance of a VTDecompressionSession (and the hardware decoder) for only a single frame of decode than there would be for an equivalent decode of a JPEG. We could look into doing a software-based decode if there's only a single frame and see if that fixes the issue.

There's also the issue where a single-frame MP4-backed <img> will "loop". I wonder if that's causing an issue as well.

[Colin Bendell]

the repaint issue on single frame loops (Bug 180472) may be causing a measurement issue here. I'm performing the timing inside the decode() promise execution. If the promise is being delayed by a frame because of the constnat repaint, it might be skewing my timing results. 

(Would be nice to have a better way to measure image and video decode timings)