Closed
Bug 891238
Opened 12 years ago
Closed 12 years ago
[A/V] High power consumption during youtube streaming, compared with other device (v2)
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(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)
People
(Reporter: leo.bugzilla.gecko, Assigned: robert)
Details
(Keywords: perf, Whiteboard: [c= ] [leoVB+])
Attachments
(9 files)
90.01 KB,
image/jpeg
|
Details | |
111.76 KB,
image/jpeg
|
Details | |
7.49 KB,
patch
|
cajbir
:
review+
|
Details | Diff | Splinter Review |
36.64 KB,
image/png
|
Details | |
4.38 MB,
application/zip
|
Details | |
2.45 MB,
application/zip
|
Details | |
39.66 KB,
patch
|
Details | Diff | Splinter Review | |
37.12 KB,
image/png
|
Details | |
36.83 KB,
image/png
|
Details |
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•12 years ago
|
blocking-b2g: --- → leo+
Priority: -- → P1
Target Milestone: --- → 1.1 QE4 (15jul)
Comment 1•12 years ago
|
||
(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•12 years ago
|
||
Reporter | ||
Comment 3•12 years ago
|
||
Reporter | ||
Comment 4•12 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•12 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.
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.
Reporter | ||
Comment 10•12 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•12 years ago
|
||
Reporter | ||
Comment 12•12 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•12 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•12 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•12 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•12 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•12 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•12 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.
Reporter | ||
Comment 23•12 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•12 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•12 years ago
|
||
Reporter | ||
Comment 27•12 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•12 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•12 years ago
|
||
Reporter | ||
Comment 30•12 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?
Attachment #772557 -
Flags: review?(chris.double)
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•12 years ago
|
Attachment #772557 -
Flags: review?(cpearce)
Attachment #772557 -
Flags: review?(chris.double)
Attachment #772557 -
Flags: review+
mozilla-central try push: https://tbpl.mozilla.org/?tree=Try&rev=b7fadeb6b8f8
Reporter | ||
Comment 34•12 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!!
another mozilla-central try push: https://tbpl.mozilla.org/?tree=Try&rev=7290c41cc886
Try push good. Landed on central: https://hg.mozilla.org/integration/mozilla-inbound/rev/8e995398c00a
Comment 38•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
Flags: needinfo?(leo.bugzilla.gecko)
Reporter | ||
Comment 41•12 years ago
|
||
Reporter | ||
Comment 42•12 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);
Comment 43•12 years ago
|
||
Thanks for the confirmation.
Comment 44•12 years ago
|
||
Assignee: nobody → robert
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
status-b2g18:
--- → fixed
status-b2g18-v1.0.0:
--- → wontfix
status-b2g18-v1.0.1:
--- → wontfix
status-b2g-v1.1hd:
--- → affected
status-firefox23:
--- → wontfix
status-firefox24:
--- → wontfix
status-firefox25:
--- → fixed
Comment 45•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Whiteboard: [c= ] → [c= ] [leoVB+]
You need to log in
before you can comment on or make changes to this bug.
Description
•