1897302 - 60 fps YouTube video is jankier in Firefox than in Chrome

Status: NEW

(Core :: Audio/Video, defect)

Description

[Chris Peterson [:cpeterson]]

As reported on Reddit (https://www.reddit.com/r/firefox/comments/1crt534/why_does_any_video_do_this/), this video is jankier in Firefox on Android than in Chrome:

https://youtu.be/Cyxixzi2dgQ

On my Moto G5 running Android 8.1, the sweeping second hand rotates smoothly in Chrome, but intermittently skips 2-3 second marks in Firefox (even though YouTube's "Stats for Nerds" say the video is dropping fewer frames in Firefox than in Chrome).

Comment 1

[Cathy Lu [:calu]]

The link works smoothly on Desktop as well. John, any ideas what might be causing this on Android?

Comment 2

[John Lin [:jhlin][:jolin]]

Hi Paul, I found that the cubeb log showed odd AAudio latency and position values when this issue happened:

05-20 11:27:53.654 31436 31655 I Gecko : [Parent 31436: AudioIPC Server RPC]: E/cubeb cubeb_aaudio.cpp:1243:Cubeb stream (0x73f2c35080) INIT success
05-20 11:27:53.655 31436 31655 I Gecko : [Parent 31436: AudioIPC Server RPC]: E/cubeb cubeb_aaudio.cpp:1347:STARTING stream 0x73f2c35080: 1 (0 2)
...
05-20 11:27:53.677 31436 31482 I Gecko : [Parent 31436: cubeb_log]: E/cubeb aaudio output data cb on stream 0x73f2c35080: state 1 (3), num_frames: 4800
...
05-20 11:27:53.768 31436 31948 I Gecko : [Parent 31436: Unnamed thread 73cce34f00]: E/cubeb cubeb_aaudio.cpp:643:Latency in frames (output
): -27034073 (352233243ms)

The latency above was (but should not be?) negative, got stored in an uint32_t, and probably caused incorrect calculation of position below:

05-20 11:27:53.768 31436 31482 I Gecko : [Parent 31436: cubeb_log]: E/cubeb aaudio output data cb on stream 0x73f2c35080: state 4 (3), num
_frames: 4800
05-20 11:27:53.774 31436 31655 I Gecko : [Parent 31436: AudioIPC Server RPC]: E/cubeb cubeb_aaudio.cpp:1587:AAudioTimingInfo idx:4800 tsta
mp:1513068696692135 latency:4267933223
05-20 11:27:53.774 31436 31655 I Gecko : [Parent 31436: AudioIPC Server RPC]: E/cubeb cubeb_aaudio.cpp:1598:aaudio_stream_get_position: 18
446744069441623483 frames

This incorrect value will be recorded in stm->previous_clock and prevent future correct ones from taking effect.

What do you think we should do in this case? Thanks!

Comment 3

[Paul Adenot (:padenot)]

We need to not store those values indeed, that's the bug for sure. I wonder what the values above from the API call are, resulting in this weird value. Can we reproduce often enough to diagnose this?

Comment 4

[John Lin [:jhlin][:jolin]]

Attachment: Log with incorrect AAudio timestamp

I have reproduced it locally but it doesn't always happen. Restarting the phone does increase the chances on my Pixel 3.

It seems Chromium is aware of the issue?

Attaching log that shows key values in aaudio_get_latency() when things went wrong:

05-21 12:12:53.170  5847  7113 I Gecko   : [Parent 5847: Unnamed thread 7117746230]: E/cubeb cubeb_aaudio.cpp:646:app_frame_index=4800, signed_tstamp_ns=86849418753. hw_frame_index=1920, hw_tstamp=86664079672, frame_time_delta=60000000, app_frame_hw_time=86724079672

Comment 5

[Paul Adenot (:padenot)]

It seems Chromium is aware of the issue?

Ok then the docs are lying probably, so I guess we can do the same fix as them.

Comment 6

[Paul Adenot (:padenot)]

Patch at https://github.com/mozilla/cubeb/pull/786.