I can't reproduce here, everything but MSE & WebM VP9 is checked with ffmpeg 1:2.7.2-2. Apart from an additional dep on libsoxr, nothing has changed anyway, h264 was untouched.

I can confirm it, on my current [testing] system, MSE & WebM VP9, MSE & H.264, and Media Source Extensions are all marked as unsupported. Didn't test with previous ffmpeg, though, and I don't use firefox on a regular basis.

This is from pacman.log from the update:
[2015-07-29 09:51] [ALPM] installed libsoxr (0.1.1-3)
[2015-07-29 09:51] [ALPM] upgraded libx264 (2:148.20150717-1 -> 2:148.20150725-1)
[2015-07-29 09:51] [ALPM] upgraded mesa (10.6.2-1 -> 10.6.3-1)
[2015-07-29 09:51] [ALPM] upgraded mesa-libgl (10.6.2-1 -> 10.6.3-1)
[2015-07-29 09:51] [ALPM] upgraded ffmpeg (1:2.7.2-1 -> 1:2.7.2-2)
[2015-07-29 09:51] [ALPM] upgraded git (2.4.6-1 -> 2.5.0-1)
[2015-07-29 09:51] [ALPM] upgraded libcacard (2.3.0-3 -> 2.3.0-5)
[2015-07-29 09:51] [ALPM] upgraded libvisio (0.1.1-2 -> 0.1.3-1)
[2015-07-29 09:51] [ALPM] upgraded linux (4.1.2-2 -> 4.1.3-1)

I tried to downgrade libx264 initially which seemed to have no effect.
Note, that I'm running stock kernel from core and on ati/amd r600 driver, but I can confirm this bug also applies when running same configuration in vmware, so I think we can exclude any mesa/driver weirdness.

I cannot confirm this. On my [testing] system with ffmpeg 1:2.7.2-2, everything on YouTube is marked as supported, including H.264 and VP9 with MSE. I use the radeon driver as well and don't see any problems with YouTube. I even disabled the Flash plugin recently.

edit:
I should note that some of these are marked "unsupported" if you don't manually enable several about:config options. I would assume Scimmia has not done this and his report is therefore not unusual.

I can reproduce it with instruction left by reporter, although downgrading ffmpeg to 1:2.7.2-1 doesn't bring 1080p support back. I'll try to take a look at it later this week.

Actually it looks like it didn't work in the first place – tried it on rootfs snapshot from previous week.

For what it's worth, here are my firefox config options that might relate to this stuff:

layers.acceleration.force-enabled true
layers.offmainthreadcomposition.enabled true
media.fragmented-mp4.exposed true
media.fragmented-mp4.ffmpeg.enabled true
media.fragmented-mp4.gmp.enabled true
media.gmp-gmpopenh264.lastUpdate 1431460428
media.gmp-gmpopenh264.version 1.4
media.gmp-manager.buildID 20150702232110
media.gmp-manager.lastCheck 1438506821
media.mediasource.enabled true
media.mediasource.webm.enabled true

I also have MOZ_USE_OMTC="1" set in my environment. Everything works beautifully.

edit: Okay, if I disable media.fragmented-mp4.gmp.enabled, It no longer shows MP4+MSE as supported.

So Alucryd might have media.fragmented-mp4.gmp.enabled set to true and MSE & H.264 works for him. I also had it set to true and it worked for me. Scimmia might have a default config and it wouldn't work for him anyway.

As far as I understand, firefox relies on libav and therefore on ffmpeg-libav compatibility? Assuming -2 is to blame, could the libsoxr change break ABI compatibility between ffmpeg and libav or something? <- Shot in the dark.

Nah, media.fragmented-mp4.gmp.enabled is set to false here. Toggling media.fragmented-mp4.ffmpeg.enabled also toggles MSE & H.264 as expected, so ffmpeg is definitely used as the decoder. I tried on a VirtualBox VM and got the same results. Wonder where all those different behaviors are coming from :/

As for the libsoxr inclusion, it only adds an alternative resampler, and doesn't change the default behavior (native swr is used by default), not that it should matter for h264 decoding anyway.

Hm, okay, I got it to work after enabling GMP. I don't really see ffmpeg failure here, as Maxime already said, -2 lets users to use alternative resampler and has nothing to do with ABI.