Closed Bug 1889129 Opened 8 months ago Closed 6 months ago

AndroidDecoderModule::GetSupportedMimeTypes() takes over a 100ms during child process startup.

Categories

(Core :: Audio/Video, defect, P2)

Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
127 Branch
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

Summary: AndroidDecoderModule::GetSupportedMimeTypes() takes over a 100ms during startup. → AndroidDecoderModule::GetSupportedMimeTypes() takes over a 100ms during child process startup.
Whiteboard: [perf-android]

I can take a look at this when I have some spare cycles and see if I can improve performance.

Assignee: nobody → azebrowski
Severity: -- → S3
OS: Unspecified → Android
Priority: -- → P3
Priority: P3 → P2

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.

Does Chrome use the same API for codec dection? Why do we need to call it on the main thread during startup?

Flags: needinfo?(azebrowski)

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.

Flags: needinfo?(azebrowski)

Between this patch and the general fix alwu put together in Bug 1885671, I think we should be in better shape now.

Attachment #9395902 - Attachment is obsolete: true

Working on an alternative fix for this.

No longer blocks: fenix-startup
Pushed by azebrowski@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/10ac43f0b166 Remove Android codec support probe from content process initialization r=jolin
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → 127 Branch
Regressions: 1896841
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: