933376 - [B2G] [YouTube] Audio and video lose sync when playing a long video (at least 10 minutes)

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Chris Kreinbring [:CKreinbring]]

Attachment: Log of YouTube video losing sync

Description:
On long YouTube videos, the audio and video fall out of sync with the audio playing ahead of the video.

Repro Steps:
1) Update Buri to Build ID: 20131030004003
2) Launch the Browser and navigate to the YouTube site.
3) Find a video that's at least 10 minutes long (one with subtitles work best).
4) Play the video, and pay attention to how the audio sounds in relation to the video being played.

Actual:
The audio eventually pulls ahead of the video, which is especially noticable on videos with subtitles.

Expected:
The audio and video remain synched throughout the video.

Environmental Variables
Device: Buri 1.2 mozilla RIL
Build ID: 20131030004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/4fbe1b01ed63
Gaia: a788ea1a3e04716938bd41a559c36a831cf1190b
Platform Version: 26.0a2

Does not repro on Leo 1.1 commercial RIL
Build ID: 20131028041204
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/41c15ddb7216
Gaia: 39b0203fa9809052c8c4d4332fef03bbaf0426fc
Platform Version: 18.1
RIL Version: 01.01.00.019.264

Notes:
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/cases/?filter-id=9396
See attached logcat logs

Comment 1

[Matthew Vaughan]

This bug first appears in the 9/13/13 1.2 build. Testing with the 6/21/13, 7/30/13, 8/01/13, and 9/12/13 builds, it appears that YouTube was in worse condition so I cannot say if this bug was present before 9/13/13. The YouTube issue prior to 9/13/13 was covered by bug 909564.

- Broken -
Environmental Variables:
Device: Buri v1.2 mozRIL
BuildID: 20130913040201
Gaia: 8ccb741b6adcfe9a78b842c17e5874242c0f8b86
Gecko: b9029b1de410
Version: 26.0a1

Comment 2

[Sotaro Ikeda [:sotaro]]

Before 9/13/13 1.2 build, video playback does not work correctly. They can not be used for comparison.

Comment 3

[Sotaro Ikeda [:sotaro]]

I did not see big out of av sync. ckreinbring, how much av sync difference did you see?

Comment 4

[Sotaro Ikeda [:sotaro]]

From v1.1 to v1.2, big difference is around gfx layer and audio output. gfx layer is changed to new one. Audio output is changed from libsydneyaudio to libcubeb.

Comment 5

[Sotaro Ikeda [:sotaro]]

Current v1.2 has a big difference around gfx layer. In v1.1, Compositor(b2g process) side hold one video frame. But since v1.2, Compositor side hold 2 video frames. There seems no necessity to hold 2 video frames on Compositor side.

Comment 6

[Sotaro Ikeda [:sotaro]]

I am going to create a bug for Comment 5.

Comment 7

[Sotaro Ikeda [:sotaro]]

ckreinbring, can you put a link to the youtube video you are using?

Comment 8

[Chris Kreinbring [:CKreinbring]]

Here's the link to the YouTube video that I used: http://www.youtube.com/watch?v=fOQqDMOLooc

About halfway through, the audio and video started going out of sync.  By the end, it was about three seconds out of sync.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Sotaro was saying that this requires a particular range of network speeds in order to be reproducible.  For example, Toronto office's WiFi is too slow to let us see this bug (we have trouble keeping up with YouTube in the first place), and Sotaro's home WiFi is fast enough that this isn't seen.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

I recall Roc figured out a way to limit network speeds when playing youtube videos on a b2g device. Roc: How did you do that?

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

edwin was able to dig up the IRC conversation where roc described his method:

    21:40 < roc> I seem to have solved my "test with a bad network" problem. I patched Gecko to dump loaded media resources to files on the phone, to get hold of an actual Youtube video. Then I set up
    Apache on my laptop to serve the video, and used "tc" (traffic control) to limit the bitrate on the laptop's wlan0 interface
    21:41 < roc> watch me forget to remove the limit and wonder why my laptop is slow at uploading things
    21:41 < francois> roc: what arguments do you give to tc?
    21:41 < roc> sudo tc qdisc add dev wlan0 root handle 1:0 tbf rate 500Kbit maxburst 1600 limit 4800
    21:42 < roc> I cargo-culted that
    21:44 < francois> that's similar to what I've been using for Perslona (the rate-limited Persona server that simulates 2G/3G connections) 

I think dumping the video to disk is against YouTube's Terms Of Service, so it may be nicer to setup a proxy on your box and use tc to limit its traffic speed.

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

I also wrote a simple rate limited webserver for testing this sort of thing, you may be able to use it to repro the bug, if the bug isn't dependent on the specific way youtube are doing things: https://github.com/cpearce/HttpMediaServer

Comment 13

[bhavana bajaj [:bajaj]]

Sotaro/Milan what are the next steps here ? Can you please help with an assignee on this.

Comment 14

[Sotaro Ikeda [:sotaro]]

Only thing, I recognize is waiting fix Bug 935118.

Comment 15

[Sotaro Ikeda [:sotaro]]

From Comment 14, I assign to this bug.

Comment 16

[Preeti Raghunath(:Preeti)]

I've requested 935118 to be checkin-needed.

Please check on the bug once landed.

Comment 17

[Jason Smith [:jsmith]]

QA Wanted - Can we retest to see if bug 935118 fixed this bug?

Comment 18

[Matthew Vaughan]

This issue DOES reproduce on the 11/20/13 1.2 build. I tested with a video that is 4:54 in length, and the audio started going out of sync around the 3 minutes mark. By the end of the video, the audio was about 1 second out of sync.

Additionally, I ran a bandwidth speed test for our wireless network and the outcome was 2,798Kb/s down and 3,023Kb/s up.

Environmental Variables:
Device: Buri V1.2 COM RIL
BuildID: 20131120004000
Gaia: 5ec2963fff60492c840707df8d8090f9908a5251
Gecko: 2d454e0de2ed
Version: 26.0
Firmware Version: 20131115
RIL Version: 01.02.00.019.102

Comment 19

[Sotaro Ikeda [:sotaro]]

(In reply to Matthew Vaughan from comment #18)

> Gecko: 2d454e0de2ed

The above include the fix of Bug 935118.

Comment 20

[Sotaro Ikeda [:sotaro]]

I recognized some changes of youtube. There is alreay Bug 940445. Another change is youtube send mpeg4 video instead of H.264. But it seems not related to this problem.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Sotaro Ikeda [:sotaro] from comment #20)
> I recognized some changes of youtube. There is alreay Bug 940445. Another
> change is youtube send mpeg4 video instead of H.264. But it seems not
> related to this problem.

Should I close this bug & open a new bug for the problem in comment 18 then?

Comment 22

[Sotaro Ikeda [:sotaro]]

> Should I close this bug & open a new bug for the problem in comment 18 then?

This bug does not handle a patch in this bug. So it seems better to continue the problem in this bug. I also confirmed that the problem is not fixed by Bug 935118.

Comment 23

[Sotaro Ikeda [:sotaro]]

I downloaded a mp4 movie file of youtube video in Comment 12. Then play backed the video locally. Even in this case, a/v sync problem happened. After seeking, a/v sync became correct in sync state. From this, I suspect accumulated calculation error seems to cause the problem. Problem seems to happen around audio out put side. Audio output is also changed from v1.1 as in Comment 4.

Comment 24

[Sotaro Ikeda [:sotaro]]

During debugging, I reminded that return value of AudioTrack::getPosition() is not often. Actually, the update was not often.

Comment 25

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #24)
> During debugging, I reminded that return value of AudioTrack::getPosition()
> is not often. Actually, the update was not often.

Created Bug 944167 for it.

Comment 26

[Sotaro Ikeda [:sotaro]]

Confirmed attachment 8340031 [details] [diff] [review] in Bug 944132 fixed the a/v sync problem of the youtube video on master hamachi. attachment 8340031 [details] [diff] [review] has a bit overflow problem. To confirm the a/v sync, locally fixed the bit overflow problem.

Comment 27

[Alex Keybl [:akeybl]]

(In reply to Sotaro Ikeda [:sotaro] from comment #26)
> Confirmed attachment 8340031 [details] [diff] [review] in Bug 944132 fixed
> the a/v sync problem of the youtube video on master hamachi. attachment
> 8340031 [details] [diff] [review] has a bit overflow problem. To confirm the
> a/v sync, locally fixed the bit overflow problem.

Is this resolved in that case? Or is further work needed?

Comment 28

[Sotaro Ikeda [:sotaro]]

By Bug 944132 fix, this bug should be fixed. Right now, no work needed.

Comment 29

[Matthew Vaughan]

This issue does NOT reproduce for me anymore on the Buri with the 12/03 1.2 and 1.3 builds. I played a video for about 20 minutes on each build and I did not see the audio lose sync with the video.

- Buri 1.2 Build -
Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131203004002
Gaia: c8f14ad3950d59ba13d7639eff02d080060bb3ce
Gecko: 244e98241b2c
Version: 26.0
Firmware Version: v1.2_20131115
RIL Version: 01.02.00.019.102

- Buri 1.3 Build -
Environmental Variables:
Device: Buri v1.3 COM RIL
BuildID: 20131203040236
Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b
Gecko: 8648aa476eef
Version: 28.0a1
Firmware Version: 20131115
RIL Version: 01.02.00.019.102

Comment 30

[Jason Smith [:jsmith]]

Closing as fixed per bug 944132 with comment 29's proof of testing.