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

RESOLVED FIXED in Firefox 25

Status

defect
P1
major
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: leo.bugzilla.gecko, Assigned: robert)

Tracking

({perf})

unspecified
1.1 QE4 (15jul)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:leo+, firefox23 wontfix, firefox24 wontfix, firefox25 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 wontfix, b2g-v1.1hd fixed)

Details

(Whiteboard: [c= ] [leoVB+])

Attachments

(9 attachments)

Reporter

Description

6 years ago
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?
Reporter

Updated

6 years ago
blocking-b2g: --- → leo+
Priority: -- → P1
Target Milestone: --- → 1.1 QE4 (15jul)
(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
Reporter

Comment 2

6 years ago
Posted image graph for android
Reporter

Comment 3

6 years ago
Posted image graph for leo
Reporter

Comment 4

6 years ago
(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])
(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?
Reporter

Comment 6

6 years ago
(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?
(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.
Posted patch possible fixSplinter Review
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.
Please test roc's latest patch
Flags: needinfo?(leo.bugzilla.gecko)
Reporter

Comment 10

6 years ago
(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.
Flags: needinfo?(leo.bugzilla.gecko)
Reporter

Comment 11

6 years ago
Posted image Result after patch
Reporter

Comment 12

6 years ago
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.
Reporter

Comment 13

6 years ago
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.
Reporter

Comment 14

6 years ago
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.
(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.
Reporter

Comment 16

6 years ago
(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.
Reporter

Comment 17

6 years ago
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?
Yes. You do need a debug build though. (B2G_DEBUG=1 in .userconfig.)
Reporter

Comment 19

6 years ago
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.
Reporter

Comment 21

6 years ago
After enable B2G_DEBUG, my device cannot boot up.
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.

Updated

6 years ago
Keywords: perf
Whiteboard: [c= ]
Reporter

Comment 23

6 years ago
(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)
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.
Reporter

Comment 25

6 years ago
(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.
Reporter

Comment 26

6 years ago
Posted file mediacache log
Reporter

Comment 27

6 years ago
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.
Reporter

Comment 28

6 years ago
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.
Reporter

Comment 29

6 years ago
Posted file stuck in wifi case
Reporter

Comment 30

6 years ago
I sent logs by email, mediacache and logcat log for both case, wifi and 3G.
(It's too large to upload here)
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 on attachment 772557 [details] [diff] [review]
possible fix

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

Whoever gets to this first...
Attachment #772557 - Flags: review?(cpearce)

Updated

6 years ago
Attachment #772557 - Flags: review?(cpearce)
Attachment #772557 - Flags: review?(chris.double)
Attachment #772557 - Flags: review+
Reporter

Comment 34

6 years ago
(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!!
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.
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?
Flags: needinfo?(leo.bugzilla.gecko)
Reporter

Comment 40

6 years ago
Posted image New media cache
Flags: needinfo?(leo.bugzilla.gecko)
Reporter

Comment 41

6 years ago
Posted image NuCachedSource2
Reporter

Comment 42

6 years ago
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);
Thanks for the confirmation.
https://hg.mozilla.org/mozilla-central/rev/8e995398c00a
Assignee: nobody → robert
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Reporter

Updated

6 years ago
Whiteboard: [c= ] → [c= ] [leoVB+]
You need to log in before you can comment on or make changes to this bug.