Closed Bug 1551547 Opened 5 years ago Closed 4 years ago

Twitch on Firetv/GV falls behind and stops playing video on busy channels (4k stick)


(Core :: Performance, defect)

Not set



Performance Impact ?
Tracking Status
firefox68 --- affected


(Reporter: jesup, Unassigned)



When viewing videos on a 4K firetv stick with geckoview, if the channel has a large number of watchers (likely really commenters), the video may stutter or more often eventually freeze as it streams all the comments by. When this happens, CPU use seems to be around 99% for long periods.

The guess is that all the comments are forcing lots of DOM manipulation and reflows/painting, and starving the media processing.

Whiteboard: [qf] → [qf:investigate]

I'll capture gecko and simpleperf profiles on this case (Moto G5)

Flags: needinfo?(acreskey)

Simpleperf capture of running on the Moto G5 (all 79 threads). GeckoView_example 05/24/2019:

It's running quite smooth even with the chat scroll.

Gecko Profiler capture on G5. Unfortunately missing many symbols even though this was from a taskcluster nightly build

But I don't think the G5 is a good device to test this on since the top Fortnite channel ran very smoothly for me.

Flags: needinfo?(acreskey)

Andrew: can you check that the resolution is set high via the cog menu on Twitch and see if perf is still acceptable? Twitch should automatically switch to a lower quality resolution if the player is struggling to keep up with a higher resolution.

Flags: needinfo?(acreskey)

Chris: with the resolution set to the highest (1080p60, previously was auto) the top 4 streams on are all silky smooth on my Moto G5, even with busy chat channels.

Flags: needinfo?(acreskey)

(In reply to Andrew Creskey from comment #2)

Simpleperf capture of running on the Moto G5 (all 79 threads). GeckoView_example 05/24/2019:

It's running quite smooth even with the chat scroll.

This is concerning: ~400ms locked up on the Socket Thread doing SSL decryption:

Now, this may have been a big buffer of video data, perhaps - hard to tell. Still 400ms is a long time. (Actually from the interspersed ssl_DefRecv() -> recvfrom() samples, like it's a stream of packets arriving in a burst). If this code is sufficiently optimized, then it will take what it will take.

(I presume this is an Arm32 Android ABI-16 build)

jcj - thoughts?

Flags: needinfo?(jjones)

Yes, this was an Arm32 android api 16 build.

See Also: → 1555407

We know NSS performance on 32-bit ARM is lackluster. In this case, it's AES-GCM, and that implementation is straight-C, without even NEON. In this case, we'd optimally want to prefer ChaCha20/Poly1305 -- which we're working on in Bug 1267894 (meta bug is bug 1555404).

That said, ChaCha20/Poly1305 isn't universally supported, and ultimately we want to have performant and safe algorithms everywhere.

Since this is fundamentally similar to our curve25519 on 32-bit ARM discussion in Bug 1550579, I've opened a meta bug about improving 32-bit ARM TLS performance, bug 1555407. We'll get started on research, but note that improving crypto takes time. (We don't even have 32-bit ARM build machines (

Flags: needinfo?(jjones)

NI'ing Randell to see if things have improved after the NSS performance improvements.

Flags: needinfo?(rjesup)
Closed: 4 years ago
Flags: needinfo?(rjesup)
Resolution: --- → INCOMPLETE
Performance Impact: --- → ?
Whiteboard: [qf:investigate]
You need to log in before you can comment on or make changes to this bug.