Bug 181033
| Summary: | <img> decode single frame h264 and hevc slower than jpg | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Colin Bendell <colin> |
| Component: | Images | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, jer.noble |
| Priority: | P2 | ||
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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)