1) There's a more specific flag that matters here. In Chrome://gpu, you should see VPx Video Decode:
Does it say hardware or software?
2) Relatedly, something to try: Go to YouTube in Chrome, play any video. Right-click on the video while it's playing and choose Stats for Nerds from the context menu.
That will tell you if YouTube is giving you VP8, VP9, or H.264. This can be a helpful clue, especially if you're getting H.264. (It would be more helpful on a laptop, because if Chrome is like MS Edge, it will stop advertising VPx support when the laptop is on battery power, forcing YouTube to give it H.264, because VPx consumes a lot more battery than H.264 even when it's hardware decoded. H.264 is a much less taxing codec, and its hardware decoding is more efficient than VPx hardware decoding. Kaby Lake might finally close the gap.)
3) There are a few other issues. The Chrome software rendering list has some interesting entries that suggest that Chrome might be ignoring even fairly new Intel GPUs, including your Braswell chip. Check it out here. Notice that one entry says: "VPx decoding is too slow on Intel Broadwell, Skylake, and CherryView".
If you follow the breadcrumb trail, you see that means every gpu with some specific PCIID mask (N3150 should be 0x22b1 for example). That's Windows only though, and moreover it may as well be a remnant of an old bug already fixed.
Keep also note of other possible entries, some of which mention specific Intel driver versions, as well as specific Linux kernel versions.
4) Make sure that your Chrome://flags page actually indicates that the software rendering list is overriden (it's the very first flag). You mentioned the command-line syntax, with the old "blacklist" term, but this flag has had some bugs in recent years, basically not working for some people and other issues. I would just double-check that however you set this flag, it actually shows up with the right setting in the flags page. If not, obviously set it properly in that page. Note that there's a bug, which may or may not be tied to your issues – overriding the software rendering list flips the VPx Video Decode flag in chrome://gpu to Hardware Accelerated even on PCs that have no VPx hardware acceleration, like the Ivy Bridge laptop I'm on now with an Intel HD 4000. I don't know if this is just a presentational bug, and Chrome is not actually attempting to use hardware acceleration, or if Chrome is actually doing so (which would seem to have to crash or something, but it doesn't).
The Chrome flags are a mess of confusion and colliding word choices. The flag says Override software rendering list. This flag needs to be enabled, not disabled. But if it's enabled, you won't see the word Enabled or any kind of status indicator. You'll see the word Disable, as an invitation to change the setting. Just so you know... maybe this is all old hat to you.
5) Last ditch, but very powerful resource to see what's going on with VP8 on your system is the Intel Media SDK. If it's not free by default, it's free as part of the student version of Intel's IDEs/C++ compilers, and the free trial editions of the paid IDE editions. There's a lot you can do there to see what's up. I was struck by this passage in page 24 of their Developer's Guide:
Hardware acceleration can be added to FFmpeg with a simple compile
step. For applications written to use FFmpeg command line or libav*
APIs they can then be hardware enabled by changing the codec name –
for example from libx264 to h264_qsv.
I would play around with that method for the VP8 codecs in ffmpeg to see if you can trigger hardware acceleration on your system at all, outside of Chrome.
6) Also note that the term "hardware acceleration" when it comes to video codecs is used inconsistently across the industry, and I'm not sure what exactly Chrome means by it (in the flags). Decode can be accelerated by a GPU, or it can be performed fully in hardware by a fixed-function unit which also happens to be on the GPU (but does not use GPU shaders). Both of these are called hardware acceleration, but they're not the same thing. Sometimes "fully in hardware" or "fixed function" will be used to differentiate that scenario from general GPU acceleration (which is sometimes called partial acceleration or hybrid acceleration).
The official docs are quite confusing, but Braswell (just like its predecessor and Broadwell) should have full fixed function decoding for VP8. While encoding and VP9 (just like in Skylake, which may have the same QSV module) are provided via an hybrid solution. I think they are using some kind of GPU acceleration (with the shaders, maybe using OpenGL or OpenCL or something but I don't know the details). This distinction can matter especially when you are with a device on battery (let alone HEVC would be leaps and bounds more efficient as per quality). And I guess like this may justify the Chrome dev team's decisions on how to use your Braswell model. Unfortunately, all of this is poorly documented...
