891238 - [A/V] High power consumption during youtube streaming, compared with other device (v2)

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P1)

Description

[leo.bugzilla.gecko]

If the patch for Bug 884188 release, then it can reduce power level about 20mA.
But it still has difference, if the streaming play is over 3 minutes.

In the case of android, if there's enough cached data, it doesn't receive data any more until size of cached data is under a criteria.
(Buffer size is 20MB on the RAM. It disconnect HTTP connection when it fulls and it restart connection and resume buffering when cached data is under 4MB)

Because it can save more power than now, is it possible to apply this logic into Leo device?

Comment 1

[Kan-Ru Chen [:kanru] (UTC+9)]

(In reply to leo.bugzilla.gecko from comment #0)
> If the patch for Bug 884188 release, then it can reduce power level about
> 20mA. But it still has difference, if the streaming play is over 3 minutes.

Could you share the expected power saving?

The current media.cache_size preference for b2g is 4MB
http://dxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#l265

Comment 2

[leo.bugzilla.gecko]

Attachment: graph for android

Comment 3

[leo.bugzilla.gecko]

Attachment: graph for leo

Comment 4

[leo.bugzilla.gecko]

(In reply to Kan-Ru Chen [:kanru] from comment #1)
> (In reply to leo.bugzilla.gecko from comment #0)
> > If the patch for Bug 884188 release, then it can reduce power level about
> > 20mA. But it still has difference, if the streaming play is over 3 minutes.
> 
> Could you share the expected power saving?
> 
> The current media.cache_size preference for b2g is 4MB
> http://dxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#l265

I'm not sure about exact value.
But if you see an Attachment #772517 [details], there's an area between max level and min level.
FFOS doesn't have pattern like that. (Please refer Attachment #772518 [details])

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to leo.bugzilla.gecko from comment #0)
> In the case of android, if there's enough cached data, it doesn't receive
> data any more until size of cached data is under a criteria.
> (Buffer size is 20MB on the RAM. It disconnect HTTP connection when it fulls
> and it restart connection and resume buffering when cached data is under 4MB)
> 
> Because it can save more power than now, is it possible to apply this logic
> into Leo device?

We could do something like that. How do you know it will help?

Have you measured power usage when playing a local resource vs playing the same local resource on Android?

Comment 6

[leo.bugzilla.gecko]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5)
> (In reply to leo.bugzilla.gecko from comment #0)
> > In the case of android, if there's enough cached data, it doesn't receive
> > data any more until size of cached data is under a criteria.
> > (Buffer size is 20MB on the RAM. It disconnect HTTP connection when it fulls
> > and it restart connection and resume buffering when cached data is under 4MB)
> > 
> > Because it can save more power than now, is it possible to apply this logic
> > into Leo device?
> 
> We could do something like that. How do you know it will help?
> 
> Have you measured power usage when playing a local resource vs playing the
> same local resource on Android?

In the case of local file, FFOS has better result than android.
FFOS: 136.5mA
Android: 155mA

Actually, I'm not sure how much it affects to power consumption.
But I think it's worth to try if it doesn't need huge efforts and changes.

Robert,
Could you please share your opinion?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to leo.bugzilla.gecko from comment #6)
> In the case of local file, FFOS has better result than android.
> FFOS: 136.5mA
> Android: 155mA

OK, that's some evidence we may benefit from doing what you suggest.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: possible fix

This patch might help.

If it doesn't help, try increasing media.cache_size to 20000 and try again.

If that doesn't help, let me know and I'll try to figure out why.

Comment 9

[Alex Keybl [:akeybl]]

Please test roc's latest patch

Comment 10

[leo.bugzilla.gecko]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8)
> Created attachment 772557 [details] [diff] [review]
> possible fix
> 
> This patch might help.
> 
> If it doesn't help, try increasing media.cache_size to 20000 and try again.
> 
> If that doesn't help, let me know and I'll try to figure out why.

I have checked 4MB cache case.
Sometimes, it's stuck with showing spinner.
It seems like that there'not enough cache but it doesn't resume receiving anymore.

Comment 11

[leo.bugzilla.gecko]

Attachment: Result after patch

Comment 12

[leo.bugzilla.gecko]

Please refer Attachment #775508 [details].

It show pattern for 5 minutes, but it doesn't resume again.
(The video duration is more than 10 minutes and sometimes this problem occurs)

The screen is stopped with spinner.

Comment 13

[leo.bugzilla.gecko]

I think the problem in comment #12 possibly caused by other reason.
it happened 4 times at that time, but after that it have never occurred yet.

Comment 14

[leo.bugzilla.gecko]

Cancel my comment #13.

It happen again and it's not network problem.
When it happen, all of function (seek, pause, resume) doesn't work.
(It remains paused video frame with spinner)
But it can be played well, when I pushed back and retried.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to leo.bugzilla.gecko from comment #11)
> Created attachment 775508 [details]
> Result after patch

This looks like a significant improvement in power usage, so the patch is basically working --- right?

I'll try to fix my patch so you don't get into that stuck state. If I can reproduce it.

Running a debug build of B2G with NSPR_LOG_MODULES=nsMediaCache:5 would produce information that would help locate that bug.

Comment 16

[leo.bugzilla.gecko]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #15)
> (In reply to leo.bugzilla.gecko from comment #11)
> > Created attachment 775508 [details]
> > Result after patch
> 
> This looks like a significant improvement in power usage, so the patch is
> basically working --- right?
> 
> I'll try to fix my patch so you don't get into that stuck state. If I can
> reproduce it.
> 
> Running a debug build of B2G with NSPR_LOG_MODULES=nsMediaCache:5 would
> produce information that would help locate that bug.

Yes, it's perfectly working.

I will try to get the logs.

Comment 17

[leo.bugzilla.gecko]

1. export NSPR_LOG_MODULES=nsMediaCache:5
2. export NSPR_LOG_FILE=/data/local/tmp/myLogFile
3. stop b2g
4. /system/bin/b2g.sh

is this right process to get log of MediaCache?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes. You do need a debug build though. (B2G_DEBUG=1 in .userconfig.)

Comment 19

[leo.bugzilla.gecko]

Hello, Robert.

HTTP logging is working like below.
NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,nsHostResolver:5

But when I follow procedure in comment #17.
I cannot get any log in the file.

is it possibly because of B2G_DEBUG=1?
How can I turn on the Macro?
I cannot find the file.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Customization_with_the_.userconfig_file#Create_a_debug_build

Comment 21

[leo.bugzilla.gecko]

After enable B2G_DEBUG, my device cannot boot up.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Hmm. That's strange. The debug output on the console (or in logcat) might give you a clue why.

I'll try to reproduce this. Meanwhile it would be helpful if you tell me your exact steps that lead to the bug.

Comment 23

[leo.bugzilla.gecko]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #22)
> Hmm. That's strange. The debug output on the console (or in logcat) might
> give you a clue why.
> 
> I'll try to reproduce this. Meanwhile it would be helpful if you tell me
> your exact steps that lead to the bug.

I'll check what I can do for log.
I just played this video, repeatedly.

http://www.youtube.com/watch?v=V1IBH1bz5-c

I think network connection was not so good.
(It happened under both 3G connection and wifi)

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I haven't been able to reproduce this so far. I'll wait for your logs.

You could try using a regular (non DEBUG) build, and adding #define FORCE_PR_LOG to the top of nsMediaCache.cpp, *before* any #includes.

Comment 25

[leo.bugzilla.gecko]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #24)
> I haven't been able to reproduce this so far. I'll wait for your logs.
> 
> You could try using a regular (non DEBUG) build, and adding #define
> FORCE_PR_LOG to the top of nsMediaCache.cpp, *before* any #includes.

I have been trying to reproduce the problem after enabling MediaCache log.
I'll give it ASAP.

Sorry for waiting.

Comment 26

[leo.bugzilla.gecko]

Attachment: mediacache log

Comment 27

[leo.bugzilla.gecko]

Please check Attachment #777510 [details] for stuck case.

If you think the problem is not from your patch, please land it, then I'll create another one.

Comment 28

[leo.bugzilla.gecko]

It seems like network problem.

When I used wifi, video frame was stuck without any network icon for the time more than normal.
However, if I waited, it recovered anyway. (It takes sometimes more than 2~3 minutes)
I think device cannot receive data normally for some reason.

But in 3G case, device cannot receive data at certain time. It cannot recover.

It think this is not the issue of this patch.
If you think that there's no problem, please land it.

Comment 29

[leo.bugzilla.gecko]

Attachment: stuck in wifi case

Comment 30

[leo.bugzilla.gecko]

I sent logs by email, mediacache and logcat log for both case, wifi and 3G.
(It's too large to upload here)

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

In the logs you sent me, for both Wifi and 3G, after the last "avoiding wakeup since more data is not needed" there's a Resume followed by many DataReceived notifications. This indicates that we successfully resumed the network connection and received more data (a lot more --- 7816424 bytes for 3G). Whatever caused your connection to get stuck, I don't think it was my patch.

Can you (or did you) reproduce similar problems without my patch?

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 772557 [details] [diff] [review]
possible fix

Review of attachment 772557 [details] [diff] [review]:
-----------------------------------------------------------------

Whoever gets to this first...

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

mozilla-central try push: https://tbpl.mozilla.org/?tree=Try&rev=b7fadeb6b8f8

Comment 34

[leo.bugzilla.gecko]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #31)
> Can you (or did you) reproduce similar problems without my patch?

I'll test it and create another one if it's reproduced.

Thanks!!

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

another mozilla-central try push: https://tbpl.mozilla.org/?tree=Try&rev=7290c41cc886

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Try push good. Landed on central: https://hg.mozilla.org/integration/mozilla-inbound/rev/8e995398c00a

Comment 37

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/1dffc79bfac5

Comment 38

[Sotaro Ikeda [:sotaro]]

Attachment: temporary patch - use android's NuCachedSource2 and http

The patch is temporary patch to compare the efficiency of http communication and data chache. For http, it uses android's NuCachedSource2 and gingerbread's http code in stagefright.

Comment 39

[Sotaro Ikeda [:sotaro]]

Leo, I thinks attachment 779027 [details] [diff] [review] can be used to compare the efficiency of media cache and http between android and Firefox OS one. How do you think about it?

Comment 40

[leo.bugzilla.gecko]

Attachment: New media cache

Comment 41

[leo.bugzilla.gecko]

Attachment: NuCachedSource2

Comment 42

[leo.bugzilla.gecko]

Please check Attachment #779057 [details] and Attachment #779058 [details].

Currently, I think, MediaCache acts as efficient as NuCahcedSource.
Only the different this is buffer size. But it's not important here.

I changed one line from your patch to activate high-watermark feature.

in omxDecoder.cpp
from dataSource = new NuCachedSource2(httpSource);
to dataSource = new NuCachedSource2(httpSource, NULL, true);

Comment 43

[Sotaro Ikeda [:sotaro]]

Thanks for the confirmation.

Comment 44

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8e995398c00a

Comment 45

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/1dffc79bfac5