Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2334223009:
Don't use AVDA for <360p VPx content. (Closed)
|
Created:
4 years, 3 months ago by liberato (no reviews please) Modified:
4 years, 3 months ago Reviewers:
DaleCurtis CC:
chromium-reviews, feature-media-reviews_chromium.org, piman+watch_chromium.org, posciak+watch_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionDon'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.
Committed: https://crrev.com/cbf3eb056e5d75a33379bff11c117a9453db6715
Cr-Commit-Position: refs/heads/master@{#418964}
Patch Set 1 #Patch Set 2 : supported profiles #Patch Set 3 : comments! #Messages
Total messages: 19 (7 generated)
Description was changed from ========== 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 TEST=manually checked 240p and 360p. ========== to ========== 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 TEST=manually checked 240p and 360p. ==========
liberato@chromium.org changed reviewers: + dalecurtis@chromium.org
viva libvpx. -fl
You can specify this is the SupportedProfiles section to avoid GPU hop.
Patchset #2 (id:20001) has been deleted
oops, didn't think about it. thanks! -fl
lgtm, but add a comment explaining why. Did we want to do this for vp9 as well?
On 2016/09/15 17:08:37, DaleCurtis wrote: > lgtm, but add a comment explaining why. Did we want to do this for vp9 as well? comment: done. vp9: i thought based on our conversation yesterday that we did. let me do a test of libvpx vp9 decoding, to see if it's approximately as expensive as vp8 decoding. as long as it's not more expensive, then i believe that we should even if we don't know what hw vp9 decoding looks like. -fl
On 2016/09/15 17:32:15, liberato wrote: > On 2016/09/15 17:08:37, DaleCurtis wrote: > > lgtm, but add a comment explaining why. Did we want to do this for vp9 as > well? > > comment: done. > > vp9: i thought based on our conversation yesterday that we did. let me do a > test of libvpx vp9 decoding, to see if it's approximately as expensive as vp8 > decoding. as long as it's not more expensive, then i believe that we should > even if we don't know what hw vp9 decoding looks like. > > -fl vp9 sw numbers are in line with vp8 sw. unless you have an objection, i suggest landing it as-is with vp9 excluded from hw < 360p -fl
lgtm, I'd tag this against the mediaserver drain fix as well since all users seem to have vp8 codecs in their history. So it's probably a good idea to merge back.
(16x16 vp8 specifically)
Description was changed from ========== 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 TEST=manually checked 240p and 360p. ========== to ========== 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. ==========
The CQ bit was checked by liberato@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== 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. ========== to ========== 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. ==========
Message was sent while issue was closed.
Committed patchset #3 (id:60001)
Message was sent while issue was closed.
Hmm, just realized this may break EME content if any such exists below <360p on Android :/
Message was sent while issue was closed.
Description was changed from ========== 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. ========== to ========== 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. Committed: https://crrev.com/cbf3eb056e5d75a33379bff11c117a9453db6715 Cr-Commit-Position: refs/heads/master@{#418964} ==========
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/cbf3eb056e5d75a33379bff11c117a9453db6715 Cr-Commit-Position: refs/heads/master@{#418964} |
