Honestly on two different phones and multiple app versions it only caused problems for me, which is counter-intuitive but I’m guessing I wasn’t the only one. It only stayed on for a few minutes a couple of times “out of curiosity”.
I sort of suspect as your developer options show that Android always uses the hardware decoder and somehow the app was a “double negative” disabling it? Or maybe the app was supposed to say “disable” instead of “enable”?
Even my Samsung J7 Prime (2017, was junk when it was new) shows the same performance with and without it and with it enabled, it would constantly have blank or frozen video.
Huh, on a Moto G7 Power (2018) Android 11 it improves live cam loading and responsiveness some 15-20% (detectable) and hasn’t caused instability. It hasn’t improved this, though:
For me the app doesn’t crash it just bogs and I have to force-close. I have 3 gig RAM.
Yeah I can’t say I’ve tried it on many phones, just the two, 8 year old Samsung with the 2.5 app and a now 4 year old Pixel when it had the 2.5 app. I can’t recall if the 3.x app ever had it, but if it did I most likely tried it again after that got updated on the Pixel.
I don’t like replacing phones often obviously. But both had the same issues, and no improvement in performance that I could notice.
Me too. I was never able to get a benefit from it on multiple phone. It always made things worse for me. But I do know there have been people reporting that it helped them. I think it’s probably because I usually gravitate to more high-end phones.
What are you implying about @peepeep’s Moto?
I love the names they give these phones. Moto Power with 3 gigs of ram. My J7 Prime which was the one and only J7 that did not have an OLED screen… thanks work for the wonderful phone.
Hardware decoder is used for phones where the older or weaker CPU struggles to keep up with software decoding. So when you turn on Hardware decoder, it switches from trying to use the CPU to using the GPU which has a faster video processing option. BUT it also causes more compression artifacts and drains the battery faster.
So, technically, if Hardware decoding improves your experience, it basically indicates your phone’s CPU is having trouble for some reasons. Maybe it’s weaker, maybe it wore out over the years, any number of things. But if the CPU was good, then software decoder would work better. I am not trying to imply something subtly, it just simply means it’s not working well with the CPU, and your phone is having better luck using the GPU instead.
Though I don’t like that people call it “Hardware encoder” because in my opinion, both the CPU and the GPU are “Hardware”…I wish they’d just call it CPU and “GPU” to be clear about what’s being used for which.
Sort of the opposite of pretty much everything else then, where typically using the CPU vs dedicated chip is a bad thing. I don’t really keep up to date on phone tech, so that’s news to me. Counterintuitive.
1 Like
In this case, POWER refers to its big battery 
. It’s heavy and it lasts a long time.
I like the title you gave that. 
1 Like
Yeah, it’s actually common to refer to it this way in the industry (Hardware/GPU+ vs Software/CPU encoding). Heavy encoding needs do tend to lean more toward Hardware encoding lately. Even on mobile, a lot of SoC architecture are integrating Media Engines and DSP’s to encode tasks without draining the CPU or battery.
It’s my understanding that the software encoding works better with compression settings, quality and formats, but is way more resource intensive and slower. So if you don’t have a great processor, it may not be better. Hardware encoding should be faster and efficient, preserve the battery and have smoother streaming, but potentially more compatibility issues, and issues with the compression algorithms. And we know that Wyze is VERY HEAVY on their compression.
So, software encoding probably works better for me because my processor is usually in the high end category, while hardware encoding works better for some people because even though it struggles more with the compression algorithms, it’s less than the struggle from their processor.
But yeah, computing industry in general (both Mobile and Desktop) are heavily pushing toward GPUs and SoCs, though a lot of it depends on different priorities.
But I think this is why some people find the Wyze app drains their battery faster than other some other apps.
It is a big thing in the networking industry too, even on cheap home routers and onboard PC NICs. Basically if a feature isn’t “supported in hardware” it is pretty much useless when it comes to the speeds we’re dealing with these days.
In virtually every case on computers, the GPU (even the iGPU) will be far faster and better quality than anything the CPU can do, but I suppose it probably does use more energy, we just don’t really notice in that case. I do recall a case where Adobe Acrobat in particular you had to disable the hardware encoder to eliminate some oddities, that was years ago. So I guess in this case it is more common than not for the hardware to interfere.
I suppose with so many different SoCs across phone brands it would be difficult for Wyze to design for them all, but you’d think the phone’s drivers for said chipset would handle most of that, I mean we’re really just talking about MP4 compression here. But the battery thing I can see, though I don’t watch my cams nearly enough for it to be an issue either way. I mostly just tried enabling it because I’m accustomed to that being “better”.
Apparently from this thread it does work better for some, for me it wasn’t any better and was buggy so never really even paid attention to the feature, didn’t even notice it was gone. 
Agreed, very similar to my thoughts. I also didn’t notice it was gone. I am curious if it was intentional or inadvertent. I know they aggregate stats on how often something is used or not, so I wonder if they found it’s rarely used anymore. Personally I think this is partially because nobody even knows what it is or what it does or why they might consider trying it.
