http://forums.androidcentral.com/samsung-galaxy-s7-edge/717166-mediaserver-issues.html and https://www.reddit.com/r/GalaxyS7/comments/4ytwob/i_think_i_found_the_problem_causing_the/ are interesting reads.

I have this issue with my S7 edge Exynos, I have had to revert to the older version of chrome that came pre-installed on my phone to stop it.

dalecurtis@, could that be Spitzer related?

ice.returns@, if you go to chrome://flags and enable "Disables the unified media pipilene on Android", does this solve your issue?

I will re-update to the latest chrome and let you know

Posted on the reddit forum, https://www.reddit.com/r/GalaxyS7/comments/4ytwob/i_think_i_found_the_problem_causing_the/d75zz8z


ice.returns: Can you check chrome://media-internals when in this drain state and see if there are any players listed? I'm most interested to see if any of them are not in the suspended state.

I will re-enable the media pipeline (which seems to be working, but 5 mins isn't a good enough test) and check the media internals when I feel my phone burning a hole in my pocket.

I'll be back with results.

It's still behaving itself, but I will keep you posted

My phone is burning up and I got this from media internals

render_id: 4
player_id: 0
pipeline_state: kSuspended
event: WEBMEDIAPLAYER_CREATED
url: data:video/webm;base64,GkXfowEAAAAAAAAfQoaBAUL3gQFC8oEEQvOBCEKChHdlYm1Ch4ECQoWBAhhTgGcBAAAAAAACNxFNm3RALE27i1OrhBVJqWZTrIHfTbuMU6uEFlSua1OsggEwTbuMU6uEHFO7a1OsggIa7AEAAAAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVSalmAQAAAAAAAEUq17GDD0JATYCNTGF2ZjU1LjQ4LjEwMFdBjUxhdmY1NS40OC4xMDBzpJAvovgexxqSyucVQwYw4Wu/RImIQI9AAAAAAAAWVK5rAQAAAAAAADuuAQAAAAAAADLXgQFzxYEBnIEAIrWcg3VuZIaFVl9WUDiDgQEj44OEC+vCAOABAAAAAAAABrCBELqBEB9DtnUBAAAAAAAAl+eBAKO2gQAAgHACAJ0BKhAAEAAARwiFhYiFhIgCAgAMDN2sx+Ng/VP//u0p//8rQ5Hz//3WA//+aDAAo5WBAMgAsQEAARAQABgAGFgv9AAIAACjlYEBkACxAQABEBAAGAAYWC/0AAgAAKOVgQJYALEBAAEQEAAYABhYL/QACAAAo5WBAyAAsQEAARAQABgAGFgv9AAIAAAcU7trAQAAAAAAABG7j7OBALeK94EB8YIBd/CBAw==
total_bytes: 1244
streaming: false
single_origin: true
passed_cors_access_check: false
range_header_supported: true
info: FFmpegDemuxer: created video stream, config codec: vp8 format: 2 profile: vp8 coded size: [16,16] visible rect: [0,0,16,16] natural size: [16,16] has extra data? false encrypted? false
duration: 1
bitrate: 9952
coded_height: 0
coded_width: 0
found_audio_stream: false
found_video_stream: true
height: 16
max_duration: 1
start_time: 0
time_base: 1/1000
video_codec_name: vp8
video_format: PIXEL_FORMAT_YV12
video_is_encrypted: false
width: 16
video_dds: false
video_decoder: GpuVideoDecoder

It's funny how it roll almost all day to start going rogue again.I'm going to try disabling the unified pipeline and see if that works.

Yep, disabling the unified media pipeline works, and I no longer have any players under media internals

w/ ump disabled it will never show players there. Your list in c#10 is interesting as that means that MediaCodec usage should be closed by Chrome. Did you have any other players listed or was that the only one?

Do you know what site that was from?

Other users are reporting that killing Chrome didn't help them:
https://www.reddit.com/r/GalaxyS7/comments/51g7wt/why_is_media_server_taking_up_alot_of_my_battery/
https://www.reddit.com/r/GalaxyS7/comments/4wvog5/media_server_killing_my_battery/

Possibly Chrome is more likely to spin up MediaServer (since we now load some videos by default) and hit some Samsung side issue. Looking into getting a device locally to see if we can reproduce the issue.

i've been trying to get it to happen on my exynos-based s6.  no luck so far.

what i find interesting in the various reports is that chrome isn't always in the foreground, even in those cases where stopping chrome helps.  clearly, some connection between mediaserver and chrome exists, such that closing chrome fixes whatever's going wrong in mediaserver.  the most obvious choice is a mediacodec instance.

however, with an instrumented version of chrome, AVDA always tried to drop its MediaCodec instance when chrome was backgrounded in every test that i've tried.

i wonder if we're posting a actual MC release to the construction thread, but the thread is hung up, and the release never happens.

i do not suspect that keeping an idle mediacodec instance around would cause this by itself.  however, it seems likely that a mediacodec instance must be around as a precondition to having mediaserver behave this way.

or, there's some process-wide connection to mediaserver that's enabling the bad behavior.

@liberato: Were you trying with vp8 content? It's also possible this is specific to the S7. I wasn't able to trigger any issues on my S4.

vp8: no.  i've tried 264 and vp9.

s7: good point.  even so, i'm fairly convinced that there must be some way to keep a MediaCodec instance around while backgrounded.  that shouldn't depend on the device.

if so, then fixing that might reduce the impact of whatever bug is really the root cause.

unless, of course, it's the construction thread.  :)

I have friends with Exynos s6, they don't seem to have this, only s7. After force clouding chrome the media server seems to take a few seconds to wind down, by that I mean if you go and check it's stats e.g run time, mAh used, then press back then tap on media server again, the timer has moved on a couple of seconds, but if you do this 2 or 3 more times, you realise the timer has stoped and the phone goes cold.

I think some peeps might have confused this delay with a still running media server after closing chrome

Sorry, but at the time I had several tabs open in chrome, no idea which one caused it.

And no that was the only thing listed under media internals, I even checked the audio tab and that was empty.

Thanks for the details. I'll try to get an s7 here soon and see if we can find anything interesting. 

I'll let the experts take it from here, thanks!

I have the same battery drain issue with my samsung s7 edge. And the reason is 100% chrome. I have this issue several times a day. It´s very annoying. After some minutes of surfing the mediaserver process goes and stays to a cpu utilzation of 35-40% until i close chrome completely. Mostly I notice the probelm when my S7 gets hot. Closing all tabs and put chrome to background is not enough. 
I have to touch the recent apps button and close chrome completely. Then the mediaserver process goes immediately to 0% CPU utilization.

Maybe it helps you with your analysis. I´m not sure which site to use to force the problem. But i´m using very often the pages ntv.de and bild.de.

schorle@ can you provide the contents of chrome://media-internals before you kill chrome when you experience this? We need to see the list of active players to take action. We're also working on getting an s7 edge.

The last 2 hours i had the problem two times. When i noticed the problem the list in media-internals was completely empty in both cases. After checking media-internals i closed chrome and the problem was gone.

Until now i have found no way to force the problem reliable. Sometimes i use the same pages during a longer period and no problem happens. The next time the problem appears after a few minutes.

If that list is empty it means the new media pipeline is not being used; they are HLS clips (which if I look at the sites you link is what I see too) which means we just pass the clip to the Android system for playback. If you go to chrome://flags and disable the unified media pipeline, do you still get this issue?

Do you watch videos in any other apps?

Out of interest, what is the purpose of the internal media thing, I only ask add I have had mine disabled for a week and have been using chrome with no problems. All media on all websites works fine, so what am I missing.

The UMP replaces our usage of Android's MediaPlayer with Chrome for network loading, demuxing, audio decoding, and some software video decoding (vp8, vp9 on phones w/o hardware decoders). It vastly improves security by moving risky operations like demuxing (see stagefright) and decoding out of the browser process (where your cookies and other important data are) into a separate process. Web Platform integration features like WebAudio, WebRTC and things like playback rate now also work.

Video loading and playback are also much quicker with the new path; sometimes on the order of seconds faster. It also allows us to provide Data Saver to Chrome users in emerging markets for video playback. Here's the blog post on it, and the tracking bug if you want more details:

https://chrome.googleblog.com/2016/08/fast-and-smooth-video-on-android.html
https://bugs.chromium.org/p/chromium/issues/detail?id=507834

Also over to liberato@ who was able to hang the vp8 decoder on his Galaxy S6.

summary: discovered a battery drain on my personal s6, though not as extreme.  phone wasn't hot, but noticed that the battery was draining by about 10% / hour when the phone was idle.  wasn't doing anything in particular trying to repro it today.

chrome had two connections to mediaserver, both hw vp8 decoders (dumpsys media.resource_manager).  two open tabs, no video on either.

chrome crashed while i was trying to diagnose, and mediaserver began behaving again.

i'll switch over to an instrumented version of chromium, and see if i can figure out what's up.

I have an S6 edge+ and have seen this issue for about 3 weeks.  I moved back to the factory version of chrome, and mediaserver never started up (to any noticeable percentage) meaning the problem went away.  I then tried Beta, and it was fine, meaning mediaserver did not ramp up.  I just installed the most recent update, though, and now Beta is behaving the same way (mediaserver ramps up after being triggered on a site).

I tried the latest update to Chrome, and the problem remains.

I noticed that the latest version number of both Chrome "regular" and Beta is the same: 53.0.2785.97.  I hadn't seen this before.

Hopefully this helps: something just changed between the next most recent version of Beta and the latest. I'm sorry, but I don't have the version number I had been using, but it was the latest according to Play Store.

@dalecur: First summary with disabled unified media pipeline after two days. 

Till now the problem has been gone. No problems with the mediaserver process any more. I also have the feeling that my smartphone in general is cooler during surfing than with enabled media pipeline. I try out a few more days to make sure tha the problem is gone. 

I experienced the same issue yesterday on my S7 going from full battery to 20% in a few hours without being used by me. The mediaserver was also reported to be the culprit. 
The only thing I changed recently was installing the Video app by Samsung through Samsung store. I believe it's called Samsung Video Library in play store.

I tried uninstalling and reinstalling a few times and when it was installed, the battery consumption was higher. The steep periods in attached screenshot was when Video app was installed. 

I also attached a screenshot of media internals.

Hope this info can be to any use.
Thanks.

Deleted: Screenshot_20160912-065942.png 166 KB

	Screenshot_20160912-065942.png 166 KB View Download

Deleted: Screenshot_20160912-070501.jpg 313 KB

	Screenshot_20160912-070501.jpg 313 KB View Download

@bjerg...: the mediainternals screen shot is cut off on the right side.  do you remember what the row labeled "event" said in the "value" column?  All i see is "WEBMEDIAPLAYER", but the whole word should be either "WEBMEDIAPLAYER_CREATED" or ...DESTROYED.

my mediaplayer instances were both in the destroyed state.  if yours were too, then methinks that we've got something to work with.

i have no idea why i edited that detail out of c#29 (oops).

update on my testing: ran an instrumented version of chromium over the weekend on my s6, but failed to repro the bug.  tried to use video more than normal.

the instrumentation keeps track of chrome's use of Android's MediaCodec and some internal state.  since i saw that chrome had two MediaCodec instances when it was in a bad state, the instrumentation is supposed to let me know what chrome is doing with them.

If this is the kind of info you need I will also try and obtain it for you. :( that means turning my phone back into a pocket heater

ice..@ thanks, but it's probably not needed.  one additional confirmation that it's in the destroyed state is all i really need; more than one won't tell me anything.  i want to verify that my device is in a similar state to what other reporters on this thread are seeing.

it just helps me to know that i'm tryinig to fix the same problem.  :)

as an aside, the reason that it's interesting (assuming that it's the same), is that it means that chrome tried to free up all MediaCodec instances.  that means that i can concentrate on figuring out why (if) they didn't really get freed, even though chrome tried to do so.  it looks quite a bit like some are left around somehow.

@liber... both mine were also in DESTROYED state.

Hi, I have the same problem on my Samsung S7 and so the battery gets hot. I've looked in the overview and see that "media server" was on the first place with over 60%. I have read a lot and get the tip to deinstall chrome. After I have deactivied chrome the "media server" didn't burn my battery. Please solve this issue, because normally I use chrome.... now I switched to Samsung Webbrowser.

Happened to me today on my Galaxy s7Edge. Noticed it getting much warmer than usual but didn't think anything of it. Checked it few hours later and the battery had gone from 90% to 27%. Media player reported as the culprit. Only change in my phone usage is I've used Chrome(updated) instead of samsung browser

@dalecur: I have disabled the unified media pipeline for four days now. 

The problem is gone. No more mediaserver draining the battery of my Samsung S7. And as is mentioned in my last post my smartphone generally needs less battery during surfing with deactivated media pipeline. The mediaserver process even don´t appear in the battery usage list of my smartphone any more. 

What even is the unified media pipeline ? And for what is it needed ? Everything works without it with no noticeable problems or disadvantages.

I asked exactly the same thing, check out comment 28 for the response

I'm experiencing this issue on my S7, the problem is appearing random during the day. I disabled the media pipeline, will report about the results in the coming days.
Thanks for the support, it's vital for me to have Chrome's straight sync between mobile and desktop, would hate to be forced to use Samsung's browser.

The problem may be related to chrome leaking VP8 codecs.  At least, when my g6 was in a bad state, it had also leaked one.  And, I can make chrome leak VP8 codecs in the most recent chromium, more or less on demand.  the 'suspended' state in c#10 could potentially trigger this bug too.

haven't been able to repro in stable yet, but it's a race condition.  my local build doesn't have all optimizations turned on, so maybe i'm just winning the race more often.

i'm going to verify that this isn't a new bug introduced between stable and ToT (likely is not).  assuming not, then it's a small fix.

i've not seen my s6 draining power again, though, so it's not clear that it's a fix for this particular problem.  just seems like a reasonable bet.

Here is a copy of media-internals when the issue appeared on my s6 edge+:

render_id: 9
player_id: 1
pipeline_state: kStopped
event: WEBMEDIAPLAYER_DESTROYED
url: data:video/webm;base64,GkXfowEAAAAAAAAfQoaBAUL3gQFC8oEEQvOBCEKChHdlYm1Ch4ECQoWBAhhTgGcBAAAAAAACNxFNm3RALE27i1OrhBVJqWZTrIHfTbuMU6uEFlSua1OsggEwTbuMU6uEHFO7a1OsggIa7AEAAAAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVSalmAQAAAAAAAEUq17GDD0JATYCNTGF2ZjU1LjQ4LjEwMFdBjUxhdmY1NS40OC4xMDBzpJAvovgexxqSyucVQwYw4Wu/RImIQI9AAAAAAAAWVK5rAQAAAAAAADuuAQAAAAAAADLXgQFzxYEBnIEAIrWcg3VuZIaFVl9WUDiDgQEj44OEC+vCAOABAAAAAAAABrCBELqBEB9DtnUBAAAAAAAAl+eBAKO2gQAAgHACAJ0BKhAAEAAARwiFhYiFhIgCAgAMDN2sx+Ng/VP//u0p//8rQ5Hz//3WA//+aDAAo5WBAMgAsQEAARAQABgAGFgv9AAIAACjlYEBkACxAQABEBAAGAAYWC/0AAgAAKOVgQJYALEBAAEQEAAYABhYL/QACAAAo5WBAyAAsQEAARAQABgAGFgv9AAIAAAcU7trAQAAAAAAABG7j7OBALeK94EB8YIBd/CBAw==
total_bytes: 1244
streaming: false
single_origin: true
passed_cors_access_check: false
range_header_supported: true
info: FFmpegDemuxer: created video stream, config codec: vp8 format: 2 profile: vp8 coded size: [16,16] visible rect: [0,0,16,16] natural size: [16,16] has extra data? false encrypted? false
duration: 1
bitrate: 9952
coded_height: 0
coded_width: 0
found_audio_stream: false
found_video_stream: true
height: 16
max_duration: 1
start_time: 0
time_base: 1/1000
video_codec_name: vp8
video_format: PIXEL_FORMAT_YV12
video_is_encrypted: false
width: 16
video_dds: false
video_decoder: GpuVideoDecoder

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78ab3ba497f659cbec188ed50f6cb70dc5c10b1c

commit 78ab3ba497f659cbec188ed50f6cb70dc5c10b1c
Author: liberato <liberato@chromium.org>
Date: Wed Sep 14 20:11:32 2016

Don't require free PicturBuffers when draining AVDA for destroy.

When draining AVDA for destroy or reset, DequeueOutput will discard
any decoded frames from the codec.  Previously, it would still
refuse to check for available output unless a free picture buffer
was available to hold it.

This could prevent a flush for destroy or reset from completing.

In the case of destruction, this would also prevent the codec from
being released.  This affected only VP8 codecs, which require a
drain on some platforms.

BUG= 642948 

Review-Url: https://codereview.chromium.org/2332253004
Cr-Commit-Position: refs/heads/master@{#418651}

[modify] https://crrev.com/78ab3ba497f659cbec188ed50f6cb70dc5c10b1c/media/gpu/android_video_decode_accelerator.cc

If anybody's interested in trying this, here's a link to an apk with the patch in c#44 applied:

https://drive.google.com/file/d/0B7ROFckpOJrgdXNNTWF1Zm14ZlU/view?usp=sharing

Assuming that one downloads it as ChromePublic.apk, then one would:

adb install -r ChromePublic.apk

and start the blue 'chromium' icon, rather than the normal chrome icon.  Note that you must have installed 'adb' at some point prior.

Be sure to force quit chrome else it could be holding vp8 codec instances.  Chromium is an entirely independent app than chrome, so while testing, you probably don't want to start chrome at all.  on the plus side, it won't affect your chrome installation.

Last, the obligatory warning: since this is a build from the current tip of tree, it may make Canary look stable by comparison.

Hopefully Chrome Dev will update soon and folk can just use that instead, but hey, if you're feeling adventurous...

I hope the patch fixes the issue. I just experienced the issue once more on my S7. I've added media-internals including logs below.

data:video/webm;base64,GkXfowEAAAAAAAAfQoaBAUL3gQFC8oEEQvOBCEKChHdlYm1Ch4ECQoWBAhhTgGcBAAAAAAACNxFNm3RALE27i1OrhBVJqWZTrIHfTbuMU6uEFlSua1OsggEwTbuMU6uEHFO7a1OsggIa7AEAAAAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVSalmAQAAAAAAAEUq17GDD0JATYCNTGF2ZjU1LjQ4LjEwMFdBjUxhdmY1NS40OC4xMDBzpJAvovgexxqSyucVQwYw4Wu/RImIQI9AAAAAAAAWVK5rAQAAAAAAADuuAQAAAAAAADLXgQFzxYEBnIEAIrWcg3VuZIaFVl9WUDiDgQEj44OEC+vCAOABAAAAAAAABrCBELqBEB9DtnUBAAAAAAAAl+eBAKO2gQAAgHACAJ0BKhAAEAAARwiFhYiFhIgCAgAMDN2sx+Ng/VP//u0p//8rQ5Hz//3WA//+aDAAo5WBAMgAsQEAARAQABgAGFgv9AAIAACjlYEBkACxAQABEBAAGAAYWC/0AAgAAKOVgQJYALEBAAEQEAAYABhYL/QACAAAo5WBAyAAsQEAARAQABgAGFgv9AAIAAAcU7trAQAAAAAAABG7j7OBALeK94EB8YIBd/CBAw==
http://static.ws-cdn.com/assets/adCodeGenerator/47619/lowResVideo_1472132870518.mp4
Player 49:3
Player Properties  Copy to clipboard

Property	Value
bitrate	9952
coded_height	0
coded_width	0
duration	1
event	WEBMEDIAPLAYER_DESTROYED
found_audio_stream	false
found_video_stream	true
height	16
info	FFmpegDemuxer: created video stream, config codec: vp8 format: 2 profile: vp8 coded size: [16,16] visible rect: [0,0,16,16] natural size: [16,16] has extra data? false encrypted? false
max_duration	1
passed_cors_access_check	false
pipeline_state	kStopped
player_id	0
range_header_supported	true
render_id	47
single_origin	true
start_time	0
streaming	false
time_base	1/1000
total_bytes	1244
url	data:video/webm;base64,GkXfowEAAAAAAAAfQoaBAUL3gQFC8oEEQvOBCEKChHdlYm1Ch4ECQoWBAhhTgGcBAAAAAAACNxFNm3RALE27i1OrhBVJqWZTrIHfTbuMU6uEFlSua1OsggEwTbuMU6uEHFO7a1OsggIa7AEAAAAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVSalmAQAAAAAAAEUq17GDD0JATYCNTGF2ZjU1LjQ4LjEwMFdBjUxhdmY1NS40OC4xMDBzpJAvovgexxqSyucVQwYw4Wu/RImIQI9AAAAAAAAWVK5rAQAAAAAAADuuAQAAAAAAADLXgQFzxYEBnIEAIrWcg3VuZIaFVl9WUDiDgQEj44OEC+vCAOABAAAAAAAABrCBELqBEB9DtnUBAAAAAAAAl+eBAKO2gQAAgHACAJ0BKhAAEAAARwiFhYiFhIgCAgAMDN2sx+Ng/VP//u0p//8rQ5Hz//3WA//+aDAAo5WBAMgAsQEAARAQABgAGFgv9AAIAACjlYEBkACxAQABEBAAGAAYWC/0AAgAAKOVgQJYALEBAAEQEAAYABhYL/QACAAAo5WBAyAAsQEAARAQABgAGFgv9AAIAAAcU7trAQAAAAAAABG7j7OBALeK94EB8YIBd/CBAw==
video_codec_name	vp8
video_dds	false
video_decoder	GpuVideoDecoder
video_format	PIXEL_FORMAT_YV12
video_is_encrypted	false
width	16
Log 
property filter

Timestamp	Property	Value
00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 00	url	data:video/webm;base64,GkXfowEAAAAAAAAfQoaBAUL3gQFC8oEEQvOBCEKChHdlYm1Ch4ECQoWBAhhTgGcBAAAAAAACNxFNm3RALE27i1OrhBVJqWZTrIHfTbuMU6uEFlSua1OsggEwTbuMU6uEHFO7a1OsggIa7AEAAAAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVSalmAQAAAAAAAEUq17GDD0JATYCNTGF2ZjU1LjQ4LjEwMFdBjUxhdmY1NS40OC4xMDBzpJAvovgexxqSyucVQwYw4Wu/RImIQI9AAAAAAAAWVK5rAQAAAAAAADuuAQAAAAAAADLXgQFzxYEBnIEAIrWcg3VuZIaFVl9WUDiDgQEj44OEC+vCAOABAAAAAAAABrCBELqBEB9DtnUBAAAAAAAAl+eBAKO2gQAAgHACAJ0BKhAAEAAARwiFhYiFhIgCAgAMDN2sx+Ng/VP//u0p//8rQ5Hz//3WA//+aDAAo5WBAMgAsQEAARAQABgAGFgv9AAIAACjlYEBkACxAQABEBAAGAAYWC/0AAgAAKOVgQJYALEBAAEQEAAYABhYL/QACAAAo5WBAyAAsQEAARAQABgAGFgv9AAIAAAcU7trAQAAAAAAABG7j7OBALeK94EB8YIBd/CBAw==
00:00:00 103	total_bytes	1244
00:00:00 103	streaming	false
00:00:00 103	single_origin	true
00:00:00 103	passed_cors_access_check	false
00:00:00 103	range_header_supported	true
00:00:00 122	pipeline_state	kInitDemuxer
00:00:00 157	info	FFmpegDemuxer: created video stream, config codec: vp8 format: 2 profile: vp8 coded size: [16,16] visible rect: [0,0,16,16] natural size: [16,16] has extra data? false encrypted? false
00:00:00 157	duration	1
00:00:00 157	bitrate	9952
00:00:00 157	coded_height	0
00:00:00 157	coded_width	0
00:00:00 157	found_audio_stream	false
00:00:00 157	found_video_stream	true
00:00:00 157	height	16
00:00:00 157	max_duration	1
00:00:00 157	start_time	0
00:00:00 157	time_base	1/1000
00:00:00 157	video_codec_name	vp8
00:00:00 157	video_format	PIXEL_FORMAT_YV12
00:00:00 157	video_is_encrypted	false
00:00:00 157	width	16
00:00:00 157	pipeline_state	kInitRenderer
00:00:00 432	video_dds	false
00:00:00 432	video_decoder	GpuVideoDecoder
00:00:00 432	pipeline_state	kPlaying
00:00:10 273	pipeline_state	kStopping
00:00:10 274	pipeline_state	kStopped
00:00:10 274	event	WEBMEDIAPLAYER_DESTROYED


Players

data:video/webm;base64,GkXfowEAAAAAAAAfQoaBAUL3gQFC8oEEQvOBCEKChHdlYm1Ch4ECQoWBAhhTgGcBAAAAAAACNxFNm3RALE27i1OrhBVJqWZTrIHfTbuMU6uEFlSua1OsggEwTbuMU6uEHFO7a1OsggIa7AEAAAAAAACkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVSalmAQAAAAAAAEUq17GDD0JATYCNTGF2ZjU1LjQ4LjEwMFdBjUxhdmY1NS40OC4xMDBzpJAvovgexxqSyucVQwYw4Wu/RImIQI9AAAAAAAAWVK5rAQAAAAAAADuuAQAAAAAAADLXgQFzxYEBnIEAIrWcg3VuZIaFVl9WUDiDgQEj44OEC+vCAOABAAAAAAAABrCBELqBEB9DtnUBAAAAAAAAl+eBAKO2gQAAgHACAJ0BKhAAEAAARwiFhYiFhIgCAgAMDN2sx+Ng/VP//u0p//8rQ5Hz//3WA//+aDAAo5WBAMgAsQEAARAQABgAGFgv9AAIAACjlYEBkACxAQABEBAAGAAYWC/0AAgAAKOVgQJYALEBAAEQEAAYABhYL/QACAAAo5WBAyAAsQEAARAQABgAGFgv9AAIAAAcU7trAQAAAAAAABG7j7OBALeK94EB8YIBd/CBAw==
http://static.ws-cdn.com/assets/adCodeGenerator/47619/lowResVideo_1472132870518.mp4
Player 49:3
Player Properties  Copy to clipboard

Property	Value
bitrate	127583
coded_height	0
coded_width	0
duration	10.067
event	WEBMEDIAPLAYER_DESTROYED
found_audio_stream	false
found_video_stream	true
height	234
info	FFmpegDemuxer: created video stream, config codec: h264 format: 2 profile: h264 baseline coded size: [414,234] visible rect: [0,0,414,234] natural size: [416,234] has extra data? true encrypted? false
max_duration	10.067
passed_cors_access_check	false
pipeline_state	kStopped
player_id	1
range_header_supported	true
render_id	47
single_origin	true
start_time	0
streaming	false
time_base	1/90000
total_bytes	160548
url	http://static.ws-cdn.com/assets/adCodeGenerator/47619/lowResVideo_1472132870518.mp4
video_codec_name	h264
video_dds	false
video_decoder	GpuVideoDecoder
video_format	PIXEL_FORMAT_YV12
video_is_encrypted	false
width	414
Log 
property filter

Timestamp	Property	Value
00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 00	url	http://static.ws-cdn.com/assets/adCodeGenerator/47619/lowResVideo_1472132870518.mp4
00:00:01 642	total_bytes	160548
00:00:01 642	streaming	false
00:00:01 642	single_origin	true
00:00:01 642	passed_cors_access_check	false
00:00:01 642	range_header_supported	true
00:00:01 684	pipeline_state	kInitDemuxer
00:00:01 801	info	FFmpegDemuxer: created video stream, config codec: h264 format: 2 profile: h264 baseline coded size: [414,234] visible rect: [0,0,414,234] natural size: [416,234] has extra data? true encrypted? false
00:00:01 801	duration	10.067
00:00:01 801	bitrate	127583
00:00:01 801	coded_height	0
00:00:01 801	coded_width	0
00:00:01 801	found_audio_stream	false
00:00:01 801	found_video_stream	true
00:00:01 801	height	234
00:00:01 801	max_duration	10.067
00:00:01 801	start_time	0
00:00:01 801	time_base	1/90000
00:00:01 801	video_codec_name	h264
00:00:01 801	video_format	PIXEL_FORMAT_YV12
00:00:01 801	video_is_encrypted	false
00:00:01 801	width	414
00:00:01 801	pipeline_state	kInitRenderer
00:00:01 889	video_dds	false
00:00:01 889	video_decoder	GpuVideoDecoder
00:00:01 889	pipeline_state	kPlaying
00:00:16 979	pipeline_state	kSuspending
00:00:17 18	pipeline_state	kSuspended
00:02:59 422	pipeline_state	kStopping
00:02:59 423	pipeline_state	kStopped
00:02:59 424	event	WEBMEDIAPLAYER_DESTROYED

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cbf3eb056e5d75a33379bff11c117a9453db6715

commit cbf3eb056e5d75a33379bff11c117a9453db6715
Author: liberato <liberato@chromium.org>
Date: Thu Sep 15 20:50:12 2016

Don't use AVDA for <360p VPx content.

Power measurements on a nexus 5 show that there's very little
difference below 360p between hardware and libvpx decoding.  This CL
switches to libvpx decoding for <360p, even if it could be hardware
accelerated by AVDA.

This saves a hardware codec instance, and avoids potential stability
issues with lots of MediaCodecs in use at once.

BUG= 647259 ,  642948 
TEST=manually checked 240p and 360p.

Review-Url: https://codereview.chromium.org/2334223009
Cr-Commit-Position: refs/heads/master@{#418964}

[modify] https://crrev.com/cbf3eb056e5d75a33379bff11c117a9453db6715/media/gpu/android_video_decode_accelerator.cc

Your change meets the bar and is auto-approved for M54 (branch: 2840)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d532efaca37fc8a3c7de35e09bf2e0ecc922f199

commit d532efaca37fc8a3c7de35e09bf2e0ecc922f199
Author: liberato <liberato@chromium.org>
Date: Fri Sep 16 05:56:11 2016

Always allow MediaCodec for encrypted VPx content.

https://codereview.chromium.org/2334223009 caused AVDA to avoid VPx
content < 360p.  Unfortunately, it did not have an exception for
encrypted content.

This CL adds an addition "encrypted only" profile that covers all
supported sizes.

BUG= 647259 ,  642948 

Review-Url: https://codereview.chromium.org/2348653002
Cr-Commit-Position: refs/heads/master@{#419108}

[modify] https://crrev.com/d532efaca37fc8a3c7de35e09bf2e0ecc922f199/media/gpu/android_video_decode_accelerator.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/90534dfcf1c0016eeaa5493c608da9c2371270ca

commit 90534dfcf1c0016eeaa5493c608da9c2371270ca
Author: liberato <liberato@chromium.org>
Date: Fri Sep 16 14:59:01 2016

[M54] Roll-up of fixes for VP8/VP9 stability on Android.

This is a roll-up of:
https://codereview.chromium.org/2332253004
https://codereview.chromium.org/2334223009
https://codereview.chromium.org/2348653002

====

Don't require free PicturBuffers when draining AVDA for destroy.

When draining AVDA for destroy or reset, DequeueOutput will discard
any decoded frames from the codec.  Previously, it would still
refuse to check for available output unless a free picture buffer
was available to hold it.

This could prevent a flush for destroy or reset from completing.

In the case of destruction, this would also prevent the codec from
being released.  This affected only VP8 codecs, which require a
drain on some platforms.

https://codereview.chromium.org/2332253004

====

Don't use AVDA for <360p VPx content.

Power measurements on a nexus 5 show that there's very little
difference below 360p between hardware and libvpx decoding.  This CL
switches to libvpx decoding for <360p, even if it could be hardware
accelerated by AVDA.

This saves a hardware codec instance, and avoids potential stability
issues with lots of MediaCodecs in use at once.

https://codereview.chromium.org/2334223009

====

Always allow MediaCodec for encrypted VPx content.

https://codereview.chromium.org/2334223009 caused AVDA to avoid VPx
content < 360p.  Unfortunately, it did not have an exception for
encrypted content.

This CL adds an addition "encrypted only" profile that covers all
supported sizes.

https://codereview.chromium.org/2348653002

BUG= 647259 ,  642948 
TEST=manually checked 240p and 360p.
NOPRESUBMIT=true
NOTRY=true
TBR=dalecurtis@chromium.org

Review-Url: https://codereview.chromium.org/2347193002
Cr-Commit-Position: refs/branch-heads/2840@{#389}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/90534dfcf1c0016eeaa5493c608da9c2371270ca/media/gpu/android_video_decode_accelerator.cc

If we're doing anymore M53 Android stable updates this would be good to pick up there too.

[Automated comment] Request affecting a post-stable build (M53), manual review required.

We're done with M53.  Marking this as fixed since this was merged to M54, which will begin rolling out next week if all goes according to plan.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/90534dfcf1c0016eeaa5493c608da9c2371270ca

commit 90534dfcf1c0016eeaa5493c608da9c2371270ca
Author: liberato <liberato@chromium.org>
Date: Fri Sep 16 14:59:01 2016

[M54] Roll-up of fixes for VP8/VP9 stability on Android.

This is a roll-up of:
https://codereview.chromium.org/2332253004
https://codereview.chromium.org/2334223009
https://codereview.chromium.org/2348653002

====

Don't require free PicturBuffers when draining AVDA for destroy.

When draining AVDA for destroy or reset, DequeueOutput will discard
any decoded frames from the codec.  Previously, it would still
refuse to check for available output unless a free picture buffer
was available to hold it.

This could prevent a flush for destroy or reset from completing.

In the case of destruction, this would also prevent the codec from
being released.  This affected only VP8 codecs, which require a
drain on some platforms.

https://codereview.chromium.org/2332253004

====

Don't use AVDA for <360p VPx content.

Power measurements on a nexus 5 show that there's very little
difference below 360p between hardware and libvpx decoding.  This CL
switches to libvpx decoding for <360p, even if it could be hardware
accelerated by AVDA.

This saves a hardware codec instance, and avoids potential stability
issues with lots of MediaCodecs in use at once.

https://codereview.chromium.org/2334223009

====

Always allow MediaCodec for encrypted VPx content.

https://codereview.chromium.org/2334223009 caused AVDA to avoid VPx
content < 360p.  Unfortunately, it did not have an exception for
encrypted content.

This CL adds an addition "encrypted only" profile that covers all
supported sizes.

https://codereview.chromium.org/2348653002

BUG= 647259 ,  642948 
TEST=manually checked 240p and 360p.
NOPRESUBMIT=true
NOTRY=true
TBR=dalecurtis@chromium.org

Review-Url: https://codereview.chromium.org/2347193002
Cr-Commit-Position: refs/branch-heads/2840@{#389}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/90534dfcf1c0016eeaa5493c608da9c2371270ca/media/gpu/android_video_decode_accelerator.cc

I still see this issue with Chrome version 57 causing high battery drain on a Google Pixel running Android 7.1.2. I've tested it by disabling the Chrome app and installing Firefox instead and that fixes the battery drain from Mediaserver. Any information you need to troubleshoot this?

Yes, please report the contents of chrome://media-internals on a new bug.