Change:
import ./generic.nix { version = "6.1"; hash = "sha256-NzhD2D16bCVCyCXo0TRwZYp3Ta5eFSfoQPa+iRkeNZg="; <ins> extraPatches = [ { name = "avcodec-decode-validate-hw-frames-ctx.patch"; url = "https://git.ffmpeg.org/gitweb/ffmpeg.git/patch/e9c93009fc34ca9dfcf0c6f2ed90ef1df298abf7"; hash = "sha256-aE9WN7a2INbss7oRys+AC9d9+yBzlJdeBRcwSDpG0Qw="; } ]; </ins> }

Discussion:
VLC starts segfaulting at this commit (the previous does not segfault). Here's the error output: here's my system info: I have an Optimus laptop btw. successful output looks like this: Seems related to
Can you check coredumpctl for more details? Can you check if something like applies to your system?
doesn't have any effect. I have installed vlc via home-manager + a flake which sets nixpkgs to the previous commit which might be why. To emulate the intended result(?), I removed vlc from my home manager packages so that is not installed. Then I checkout that commit and from the nixpkgs repo root and rerun. It still crashes. Btw I don't really understand how there can be conflicting libraries. Shouldn't I expect an error somewhere during nix evaluation in this case? The backtrace I get from is: Sorry if this isn't very helpful.
Tacking on in here that I'm also having this issue, with a simpler configuration. Also, VLC does not segfault with all video formats. I've tested AVI (works), MP4 (segfault), MKV (segfault), and WEBM (works). Examples of each: Failure Success My system information is identical to the original report, including kernel version, so I won't repaste it. I am also using an Optimus laptop, but VLC is installed in via: Finally, the following are also set. The additions in were installed during my attempts to fix the problem, and did not change the behaviour in any way: Finally, I can confirm that another video player (MPV) does not have any issues playing the segfaulting formats, but did not play them without the installed extraPackages. Not sure if any of that was helpful, but hopefully?
Also ran into this issue with the following settings (dGPU is iGPU is ): MPV by default uses software decoding but you can use hardware decoding by passing . There : works : works (with ) : doesn't work : doesn't work With VLC I have the following results depending on the environment variables: Without it always wants to use the dGPU. Interestingly doesn't crash but enters some kind of race condition which leads to . Also there are a bunch of x11 errors, while I am using wayland (GNOME).

I've attached all logfiles below if somebody wants to look at them. () Lastly AVI videos in VLC do work with and but from the logs it seems that hardware decoding fails and it just falls back to software.
Can you reproduce this issue without vaapiVdpau? The project is pretty much dead since more than 10 years. Or without libvdpau-va-gl? That project is code wise dead for 8 years. I cannot reproduce this issue on intel iGPU, VDPAUDRIVER=vagl and with an mp4.
I can confirm that with and only and installed, it works. But when the environment variable is omitted, VLC crashes like described.
On my system ffmpeg attempts to use VAAPI, fails, falls back to VDPAU, succeeds to initialize the HW decoder using Nvidia's VDPAU driver and then ends up crashing here: because is . This code for this function has changed quite a bit on master, adding a NULL check among other things, as part of this commit here: So it seems like this has been fixed upstream already. I'll try cherry-picking that patch.
As I pointed out to deaf ears, yes there is a bug in (which can totally be fixed by cherry-picking the right patch) - but on top of that VLC tries to initialize it regardless of any setting or preference.
If I'm interpreting what I've seen during my single-stepping through ffmpeg code correctly, it does not actually seem to be using libva to initialize the Nvidia VDPAU driver. I don't even have installed here. This might be an unrelated issue, or perhaps a similar bug in ffmpeg code? Either way, I'm happy to report that cherry-picking fixes the crash and revives video playback: Edit: I'll create a PR to get the patch in here.
I can however confirm that the crash seems to be related to attempting and failing to initialize HW acceleration with VAAPI first, regardless of whether is installed or not. If I invoke the broken ffmeg from command line and ask it to use VDPAU directly, it does so happily. Anyway, PR to cherry-pick the patch is here:
did not solve the issue for me.
Did you build it yourself from the staging branch? Note that the patch hasn't reached master yet.

In my home flake I currently install it like this:
I build from via a flake. I fetched the remote and did To confirm that the fix is there. UPDATE: Actually I was wrong, the branch I use is and that one does not yet contain the fix. Sorry for a false alarm.
Today I built with that contains and it still does not work.
Are you assuming that the git command that you pasted would return exit code 0 if the commit is contained? That is not the case: it returns exit code 0 either way. It'd print the branch name if the commit was actually contained, which it does not. This command also assumes that the commit is merged with a merge commit and retained its original commit hash, but that isn't the case: it was . I suggest to just check the source file instead: Which clearly still doesn't contain the fix, yet. The fix is currently only present on and : You can use the expression that I pasted above as a stop-gap in the mean time.
thank you so much for properly digging into this and fixing this and so that we can keep moving forward. Very much appreciated.
Looks like this is still happening with the latest version: My system info: I'm able to fix it by reverting to via: This is the output using : VLC maintainers recommend removing ( and ) but I'm not sure how to do that since I'm using the Framework 'nixos-hardware' modules.
The package is via nixos-hardware for all intel based gpus: I've no experience in those areas and am unfamiliar with alternatives. But one can probably change the VLC setting by hand: ! Not sure what would be a proper solution. Maybe there is an alternative implementation available that should be used instead within nixos-hardware?
As a follow up, I decided to drop this driver from nixos-hardware:
As a quick test, I this to my config: Now the stock VLC package (without overriding ffmpeg) works, however, I'm not sure if it's using hardware acceleration; here's the output: Here's the output using the above config and override:
Fix in nixos-hardware has been merged.
did a mistake by adding it to intel gpus. It's only needed by the proprietary nvidia drivers.