AndroidDecoderModule::GetSupportedMimeTypes() takes over a 100ms during child process startup.
Categories
(Core :: Audio/Video, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox127 | --- | fixed |
People
(Reporter: jrmuizel, Assigned: az)
References
(Blocks 1 open bug)
Details
(Whiteboard: [perf-android])
Attachments
(1 file, 1 obsolete file)
See this profile from a pixel 6: https://share.firefox.dev/4cE3MbY
Reporter | ||
Updated•8 months ago
|
Reporter | ||
Updated•8 months ago
|
I can take a look at this when I have some spare cycles and see if I can improve performance.
The call which is causing the delay is can be boiled down to:
new MediaCodecList(MediaCodecList.REGULAR_CODECS).getCodecInfos();
... which is an Android API call. I don't know if there's much that can be done to make this call faster. I chatted with jhlin, and apparently the call reads + parses XML files to get codec information. This information is cached at OS level on a per-process basis, which doesn't help us. It'd probably make the most sense to cache this information in a similar manner to 1551890 - 68ms used to GetHWEncoderCapabilities() during Fenix startup, though I might have to roll a different mechanism for doing so.
Reporter | ||
Comment 3•8 months ago
|
||
Does Chrome use the same API for codec dection? Why do we need to call it on the main thread during startup?
It looks like Chrome uses the same API call. We've been using getCodecInfos() before the about:support changes landed, though I profiled a copy of 109 on my phone and it didn't seem to have the same startup delay. Spinning this off to its own thread might make the most sense. I'm going to investigate a bit more and I'll update again here after.
Between this patch and the general fix alwu put together in Bug 1885671, I think we should be in better shape now.
Updated•7 months ago
|
Reporter | ||
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Comment 10•6 months ago
|
||
bugherder |
Description
•