cc: @amazari @hyperfekt @bendlas

I have spare CPU power for a while, too. If having pre-built binaries will expedite the review/merge process, let me know and I can build these commits on top of nixos-unstable. (I'm currently stacking this on a mesa change locally)

does this include / supersede #56973?

@bendlas It entirely replaces #56973. Just in the interest of rationalizing yet another chromium vaapi PR --- That PR is out of date, and as far as I know, didn't receive testing of each build output due to the long build times. On the other hand, this is using today's Chromium channel builds, I have tested the four important outputs, is simpler, and includes the ozone functionality. I'm hoping it's an easy merge so we can get this in and start iterating.

I'd prefer to keep PRs separate, when possible.

Still, this PR is looking pretty good, IMO (thanks for the flag names)

I want to verify, that turning useVaapi=false doesn't result in derivation changes (for 19.03).

Barring any objections, I'll merge this in the evening.

@bendlas Does it make maintenance easier if I split these? I don't mind doing so. I'm putting final touches on nixos-unstable builds and instructions for testing, I can go ahead and pull out the Ozone commit.

At the very least, it would be a fun test of derivation changes, and might make the PR more appealing to you?

It does make maintenance both easier and harder (more branches), in a way, but it reduces the potential for having multiple discussions going on in a single issue thread and most importantly, it separates the PR's life cycles, so an issue with one feature won't hold up progress / merging of the other.

In any case, your version of vaapi seems to address all the open issues in #56973, whereas progress on that ticket seems to have stalled, so I'm willing to merge this, but will wait a bit for feedback ..

I have added testing instructions to the OP with pre-built binaries so everyone can test without needing to build Chromium multiple times.

I also have this same PR but without Ozone and without the version bump: https://github.com/colemickens/nixpkgs/commits/chromium-upstream1. This resulted in new wrappers for stable/beta, and new wrappers/builds for dev/ozone. These are also cached per the instructions in the OP. Let me know if you'd like me to push this branch here instead.

Thanks @bendlas!

The VAAPI parts looks like what I would've done.
We should be on the lookout for the issues that made Arch remove the patch very recently.
Currently trying to get the cachix builds to download.

I'm getting a crash to desktop whenever I click on any of the links on this site. The same does not happen with unstable.

Received signal 11 SEGV_MAPERR 000000000000
#0 0x563d78285593 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#1 0x7fd706e29860 
#2 0x7fd7054149fd __memmove_avx_unaligned_erms
#3 0x7fd7066226c5 png_combine_row
#4 0x7fd70661268b png_push_process_row
#5 0x7fd706612b3c png_process_IDAT_data
#6 0x7fd706612d45 png_push_read_IDAT
#7 0x7fd706612feb png_process_data
#8 0x7fd6d75193d2 
#9 0x7fd7058aab7b gdk_pixbuf_loader_load_module
#10 0x7fd7058ab505 gdk_pixbuf_loader_close
#11 0x7fd7058a6d3b load_from_stream
#12 0x7fd7058a855c gdk_pixbuf_new_from_stream
#13 0x7fd705bcda24 icon_info_ensure_scale_and_pixbuf
#14 0x7fd705bd0c28 gtk_icon_info_load_icon
#15 0x563d7aa73b71 libgtkui::GtkUi::GetIconForContentType()
#16 0x563d78086a0c IconLoader::ReadIcon()
#17 0x563d78285fb3 base::debug::TaskAnnotator::RunTask()
#18 0x563d782abe3e base::MessageLoopImpl::RunTask()
#19 0x563d782ac402 base::MessageLoopImpl::DoWork()
#20 0x563d782b937f base::(anonymous namespace)::WorkSourceDispatch()
#21 0x7fd706afb11f g_main_context_dispatch
#22 0x7fd706afb3d0 g_main_context_iterate.isra.26
#23 0x7fd706afb5ac g_main_context_iteration
#24 0x563d782ad122 base::MessagePumpGlib::Run()
#25 0x563d782d9309 base::RunLoop::Run()
#26 0x563d77ffb8d7 ChromeBrowserMainParts::MainMessageLoopRun()
#27 0x563d7687d724 content::BrowserMainLoop::RunMainMessageLoopParts()
#28 0x563d7687f9a2 content::BrowserMainRunnerImpl::Run()
#29 0x563d7687a2ce content::BrowserMain()
#30 0x563d77dfd50a content::ContentMainRunnerImpl::RunServiceManager()
#31 0x563d77dfd186 content::ContentMainRunnerImpl::Run()
#32 0x563d77e34828 service_manager::Main()
#33 0x563d77dfb4d1 content::ContentMain()
#34 0x563d759303e3 ChromeMain
#35 0x7fd7052e4b8e __libc_start_main
#36 0x563d7593027a _start
  r8: 0000000000000004  r9: 0000000000000010 r10: 0000000000000000 r11: 00002063c3a3911f
 r12: 0000000000000000 r13: 0000000000000001 r14: 00002063c2f7e150 r15: 00007fffc981a1e8
  di: 0000000000000000  si: 00002063c3a39120  bp: 0000000000000000  bx: 0000000000000000
  dx: 0000000000000040  ax: 0000000000000000  cx: 0000000000000040  sp: 00007fffc9809e78
  ip: 00007fd7054149fd efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000006
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

I'm getting a crash to desktop whenever I click on any of the links on this site. The same does not happen with unstable.

Doesn't crash for me, but vaapi doesn't seem to work at all

ERROR:vaapi_wrapper.cc(327)] vaInitialize failed: unknown libva error

This happens on my PC with nvidia card, as well as on my laptop with intel GPU

Thanks for the update, to reduce the scope to just vaapi! I've built your latest version and the unknown libva error is gone now. However, the build doesn't seem to play any h264 videos now.

If you want to test for yourself, you can install my build:

curl -L https://bendlas.net/public/chromium-vaapi.nar.xz | xz -d | sudo nix-store --import

and run it by

/nix/store/g6804n7m3028ccp175x06m2w6h41iq8i-chromium-73.0.3683.75/bin/chromium --user-data-dir=/tmp/va-chr

Maybe it still needs chromium-libs-media-freeworld or libva-intel-driver as detailed here https://www.linuxuprising.com/2019/01/fedora-updates-chromium-with-vaapi.html

Sorry, that was my bad. I rebuilt with proprietaryCodecs = true, now the videos play again, but chrome://media-internals still shows a software renderer ... unsure how to proceed here.

Updated build is at https://bendlas.net/public/chromium-vaapi-prc.nar.xz

@bendlas Before I dig into this, can you confirm if libva is working on your system? vainfo output?

I set it up according to your instructions here https://nixos.wiki/wiki/Accelerated_Video_Playback and vainfo shows the intel drm driver

Okay @bendlas. Thank you for testing and patience, I will try to take a look at this tonight and provide an update.

@bendlas Okay, I've pushed it again, here's a screenshot of it working again. I had dropped an important line when rebasing/splitting the PR.

Rebuilt against nixos-unstable again. This should get you the same build and leverage my cache:

set -x
set -u
set -e

# first arg is my nixpkgs branch
b=${1}
shift

export GDK_BACKEND=x11
export url="https://github.com/colemickens/nixpkgs/archive/${b}.tar.gz"
o=()
o+=("--option" "narinfo-cache-negative-ttl" "0")
o+=("--option" "binary-caches" "https://cache.nixos.org https://nixpkgs-wayland.cachix.org https://colemickens.cachix.org")
o+=("--option" "substituters" "https://cache.nixos.org https://nixpkgs-wayland.cachix.org https://colemickens.cachix.org")
o+=("--option" "trusted-public-keys" "cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= nixpkgs-wayland.cachix.org-1:3lwxaILxMRkVhehr5StQprHdEo4IrE8sRho9R9HOLYA= colemickens.cachix.org-1:oIGbn9aolUT2qKqC78scPcDL6nz7Npgotu644V4aGl4=")

# second arg is the package name
p=$1
shift

# chromium
export NIX_PATH=nixpkgs=${url}
nix-shell "${o[@]}" -p "${p}"

and then invoke it: ./script 4a27575 chromium and then chromium.

(This would just be a wrapper rebuild, but nixos-unstable has updated and I rebased this as well, just fyi)

@hyperfekt When I click on those h265 videos, they download. When I use file:/// to navigate to them and play, I simply don't get any playback. However, since this is the same behavior I get from normal chromium builds from nixos-unstable, I don't see a problem with the change. When I tested the h264 videos, they also downloaded, but then played through the Mojo Decoder as well.

In fact, looking at the logs, it seems that it falls through the Mojo decoder, attempts the ffmpeg decoder and then reports an error (with or without my change):

[1:15:0321/205908.993506:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: no supported streams"}
[1:1:0321/205908.993761:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_NO_SUPPORTED_STREAMS

Screenshot of chromium from nixos-unstable trying to play the x265 video:

This makes me more suspicious that the ffmpeg used by chromium is built without x265 support or something like that?

FINAL EDIT: I don't think we should expect Chromium to play HEVC content. We are (1) not using the system ffmpeg, and (2) we are not enable manual HEVC support. See here for more: shaka-project/shaka-packager#501 (comment)

Yeah, I didn't necessarily expect them to play (as you noticed chromium without the change just downloads), but I also didn't expect them to crash chromium. Strange that you can't reproduce.

I didn't see any chromium crashes and my laptop is now able to play videos through the Mojo Decoder. Merged to master. Thanks!

This broke video decoding on my 2011 laptop with a Radeon HD 6470M.

I used services.xserver.videoDrivers = [ "ati" ] and test page https://i.imgur.com/vE2uW0K.gifv

Workaround is to disable chrome://flags/#disable-accelerated-video-decode

Yeah, that's what I was afraid of .. probably the reason that other distros deactivated it again .. I think we might have to disable it by default as well ...

I wonder if it's viable for us to maintain our own whitelist for devices we confirm it works with.

@ivan Thanks for the video, that was interesting to see. I'm sorry to hear that it is broken, maybe we should flip useVaapi to false asap to minimize the amount of disruption to users? @bendlas ?

@hyperfekt This is an interesting idea. I wonder if we should try to get in touch or start a "common thread" for distro Chromium-package maintainers to discuss best approaches. The patch currently excludes Nvidia, maybe it should exclude all non-Intel -- https://github.com/NixOS/nixpkgs/pull/57837/files#diff-58a5fed9a4a5453d7f82957c8a706606R111 ?

Alternatively, we leave useVaapi on, and we edit the patch to make the flag opt-in, rather than opt-out. This leaves the functionality in the build, but disabled, and we can expect this to work since @ivan is saying that the build is usable with the current flag flipped.

I think I prefer the last option, personally, but would need some time to try to make the necessary changes and it would mean we're diverging from the patch that other distros are carrying.

I think the last option is a great idea, since both actually testing all platforms we would like this to be available for and having users compile their own version don't seem like really good solutions.
Given the problems that not only we but also other distros will face which may lead to them removing the patch anyway I'm not sure if divergence is that big an issue - although it would of course be preferable if many distros could share the best solution (and maybe a list of confirmed working devices).

edit the patch to make the flag opt-in, rather than opt-out

I think it would be good not to hard - code any device whitelist into chromium, so this option seems best to me (or rather: create a patch, applying on top of the common - distro one)

Multiple chromium builds are out of the question, unless we can find a cheap way to derive them from a single nix build.

Also: do we need a patch, or can this be done in the wrapper? https://www.chromium.org/developers/how-tos/run-chromium-with-flags

@bendlas I was wondering something similar - can we do something to "enable" the disable flag by default? Otherwise the extra patch is going to be a bit larger than I was thinking, if we have to actually reverse the flag and change all the places the flag is used.

I saw that you went ahead and disabled it for now, thanks. I'll probably leave this for a few days at least, and try to get some input from the Arch packager in the meantime, etc.