Addendum:

It also happens with current stable version (as of today) of Chrome on macOS and Windows.

b-frames don't work in webm AFAIK, which only has the concept of presentation timestamps. What happens if you remux those to mp4?

Ah, sorry didn't finish reading, I see you tried it in mp4. Will take a look.

Thank you for looking into it. Having this combo work is particularly important for Chromecast, as AAC 5.1 support has been removed in its latest firmware and Opus is supposed to used as the natural replacement for multichannel.

Here's a B-Frame mp4 sample that does not play properly, exactly like the webm version:
http://bubblesoftapps.com/tmp/h264_opus_b_frames.mp4

Also, if you find the cause and can fix it for mp4, it would also be extremely useful to have it working for mkv/webm.  There reason is that mkv/webm can be used for on the fly transcoding while mp4 cannot (moov atom requires seekability of the output stream).

Definitely seems like some sort of ffmpeg demuxer bug. I've verified extracting the video track will cause it to play normally, it's only the combined opus+h264. To workaround this currently you can just use MSE with separate source buffers.

Using MSE is not a practical solution for me. I hope it will be fixed in Chrome with (supposedly) a ffmpeg update.

For what it's worth:

- Firefox and Edge: no link above  play at all. Codec error or similar
- Safari, VLC and stock Windows 10 movie player all plays without stutter the mp4 with or without b-frames, but without audio 
- VLC stock Windows 10 movie player plays without stutter the webm b-frame version, with audio

Ah this is a bug in our demuxer; it's applying a workaround intended for chained ogg files to the opus stream. I'll put together a fix and some tests and have a change out shortly to resolve this.

https://chromium-review.googlesource.com/c/chromium/src/+/830831 -- fix should land in Sunday's canary build and roll out with M65.

Thanks for the report!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b3c04f947ebe878bd1c0787a1347c968460841a3

commit b3c04f947ebe878bd1c0787a1347c968460841a3
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Sat Dec 16 02:24:28 2017

Stop conflating negative ts and chained ogg workarounds.

Now that opus is supported in containers outside of ogg, we shouldn't
allow negative timestamp fixups to imply the need for chained ogg
support. I.e. we shouldn't apply chained ogg workarounds to mp4
files or any other container that opus is allowed in now.

This has been broken for a while, but h264+bframes and opus is not
common, so the issue hasn't arisen before. The fix is simply to
separate these workaround flags and restrict the chained ogg one
to only content which we expect to support.

BUG= 795392 
TEST=new unittest.

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I3a7465110fd1f1defe4b41f1f471e5050d8c469a
Reviewed-on: https://chromium-review.googlesource.com/830831
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524566}
[modify] https://crrev.com/b3c04f947ebe878bd1c0787a1347c968460841a3/media/filters/ffmpeg_demuxer.cc
[modify] https://crrev.com/b3c04f947ebe878bd1c0787a1347c968460841a3/media/filters/ffmpeg_demuxer.h
[modify] https://crrev.com/b3c04f947ebe878bd1c0787a1347c968460841a3/media/filters/ffmpeg_demuxer_unittest.cc
[add] https://crrev.com/b3c04f947ebe878bd1c0787a1347c968460841a3/media/test/data/tos-h264-opus.mp4
[modify] https://crrev.com/b3c04f947ebe878bd1c0787a1347c968460841a3/media/test/pipeline_integration_test.cc

Many thanks for fixing that issue so fast.
I will test the canary version when it is availbale.

Confirmed working in Canary as of today, with both webm and mp4. Thanks !