UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

Example URL:
https://vimeo.com/channels/staffpicks

Steps to reproduce the problem:
On an ARM-based device where V4L2-based HW video acceleration is supposed to work, do: 

1. Go to https://vimeo.com/channels/staffpicks and start playing the main video
2. After 2-3 seconds playing the video click on any of the other video thumbnails right before the main video's description
3. Start playing the new video quickly after it gets loaded in the main video's place
4. Repeat steps 2-3 for a few times more (e.g. 5-10 times should be enough)
5. Leave the last video playing for a couple of minutes

What is the expected behavior?
Every video loaded should play smoothly, using the HW accelerated V4L2 video decoder, including the last one.

What went wrong?
The first video plays smoothly, but the following ones do not, as they no longer use the HW video decoder and fall back to SW video decoding instead.

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes 

Chrome version: 48.0.2564.82 (Developer Build) (ARM 32-bit)  Channel: dev
OS Version: 3.10.33.20150928 armv7l
Flash Version: No flash

The problem seems to be that, in this particular website (which does not reload, simply replaces the content of a video widget with a different video), the VideoDecoder element is not being destroyed when switching to a new video, keeping the instance of GenericV4L2Device created for the first video to stay alive when trying to play the second one.

And this is a problem, because playing the second video means it will try to create a second VideoDecoder for it, but it won't be able to do it since the associated file descriptor (/dev/video-dec) would be still open at that time, causing the GpuVideoDecodeAccelerator::CreateV4L2VDA() call to return an invalid video decoder accelerator, thus falling back into software mode.

We detected this problem a while ago in Endless and got a patch applied that worked it around, although it caused another issues due to the early returns it introduced (e.g. no sound on Duolingo), so we had to revert it after all. See it here for reference:
https://github.com/endlessm/chromium-browser/commit/4c7734ddc9b39df0eade0feed1cb75f3677e2b13

Our second attempt to workaround that issue involved distinguishing between video and audio but, while it seemed to also work fine for Vimeo without breaking audio in Duolingo, we recently found out that it literally broke every single place relying on the Video.JS framework because of the call to stop() we added in this second patch:
https://github.com/endlessm/chromium-browser/pull/38/commits/1f662ea4f417415e54b073032429784395b37007

At the moment I'm playing with a second patch on top of this last one that simply makes sure that the network state is set to EMPTY when removedFrom() is called if there is no data processed yet (another option that seems to work is to simply call userCancelledLoad(), but I tried to kept the patch down to a minimum), but I need to test it a bit more before feeling more confident about it:
https://github.com/endlessm/chromium-browser/commit/c479503f51922889427ca9803f31ec2aaff1bc83

In any case, regardless of whether we adopt or not this workaround downstream, I feel like this is an issue worth reporting, since the V4L2 related code does not seem to have changed much upstream compared to the version I'm using (48.0.2564.82 for armhf), and so it might be an issue in other environments too, such as ChromeOS maybe?

Note: In my particular setup (Amlogic S805 with Mali 450) I check whether the HW video decoder is actually being used by setting it in debug mode via /sys/module/meson_vdec/parameters/debug, and then checking the output of journalctl | grep meson, but YMMV.