first public drop of VL.FFmpeg — a video player for gamma, powered by FFmpeg.
play the files you actually have, not only the formats the built-in player likes. same source goes to Skia and Stride. audio goes through VL.Audio.
install VL.FFmpeg, then use VideoPlayer. VideoPlayer (Advanced) if you need Open / Play / Pause / Stop / Close / Seek from different parts of the patch.
help: HowTo FFmpeg Video Playback
now
play / pause / seek / loop
Skia + Stride
audio via VL.Audio
GPU decode when the renderer can take a texture, otherwise software
Windows x64, FFmpeg 8.1 LGPL
not yet
Windows only, local files only
no streams, no speed, no subtitles, no HDR tone mapping
A/V sync is still basic
inspired by kbln/vvvv-FFmpeg by Ivan Kabalin.
MIT, native FFmpeg is LGPL 3.
try it on the ugly files. if something breaks, post codec and Skia or Stride.
Well, just tried a spread of 16 full HD resolume DXV and getting a steady 60fps, so thats pretty good, but it is saying software playback, I think ffmpeg supports DXV as a GPU codec. The detailed node gives – dxv, 1920x1080, Hardware fallback; D3D11VA was not selected (AV_PIX_FMT_RGBA); Software RGB full (metadata assumed) → linear RGBA16F; transfer BT.709.
If we can get GPU support for all codecs, this makes vvvv into the media server its always wanted to be. I just checked a h264 and it is GPU already.
Great work anyway! (and it loads jpgs and pngs…!)
There is a bit of garbage collection going on, 0 1 and 2
hap, 512x512, Hardware fallback; D3D11VA was not selected (AV_PIX_FMT_RGB0); Software BT.601 limited (metadata assumed) → linear RGBA16F; transfer BT.709.
@catweasel@nissidis Yes, I’ve been testing ProRes and HAP; the alpha channel was particularly interesting. That was practically what motivated me.
The problem is that for more complex codecs, it’s really difficult to get hardware acceleration via FFmpeg. I’m still exploring possible solutions, but don’t expect anything in the near future. For now, it’s important for me to keep things simple.
Also wanted to share our experience quickly:
works good for standard resolutions for h264, fails on everything else
tried on two pcs (identical hardware) with mixed results, probably due to avaliable ffmpeg version
h264, 8192x4096, Hardware fallback; D3D11VA was not selected (AV_PIX_FMT_YUV420P); Software BT.709 limited → linear RGBA16F; transfer BT.709.
dxv3, Hap, prores fails for us, or play with Seconds/Frame.
@bildwerk Am I right in understanding that, at high resolutions, none of the formats listed (which lack hardware acceleration) can be rendered in real time on your computers?
That makes perfect sense, because FFmpeg does not provide hardware acceleration for these formats. And rendering at such a resolution using just the CPU is an extremely resource-intensive task.
I’ll look into what workarounds might be available. But as I wrote earlier, you shouldn’t expect much success in the near future.
@bildwerk I’ve implemented GPU acceleration where possible (or removed CPU processing where possible—it depends on your point of view).
I have an HAP file at 8190x1080, 50fps, ~190mb/s; performance is clearly limited by the HDD on which this file is stored. On a warmed-up HDD, it delivers 50 fps; tests show it can even go higher. But generally, the fps clearly drops off the rest of the time. Still, it’s no longer a slideshow, which looks promising.
Can you give it a go yourself?
I’ve also noticed that the clock logic works in such a way that the video slows down rather than skipping frames. I’ll look into this later.
quickly gave it a go with a 8192x8192@30 Hap test file. At clip start it needs a bit of “run up time”, where the framerate is slowly increasing and then plays perfectly smooth. SSD speed should not be the issue on the test system.
DXV3, and Prores with lower resolutions also looked good.
Could you please provide some more detailed feedback? What exactly is the issue with the alpha? And perhaps you could share a short video – 1–3 seconds long – as an example?
Actually, this seems to be a well-known compatibility issue between FFmpeg and NotchLC.
A massive improvement in performance. I still couldn’t play my HAP video without stuttering; no miracle happened — it’s stored on a hard drive that can’t provide the necessary data transfer rate, but I played this video in another FFmpeg-based player and experienced exactly the same stuttering. Perhaps the VVVV Gamma player subjectively stutters just a little more, but it’s hard to spot the difference with the naked eye.
The LIVE player has been implemented to play back http/https streams and, most interestingly, RTSP streams. People on the forum have repeatedly asked what they can use to get a feed from an online camera — now you know what to choose. In theory, the standard player can also play back streams, but stability isn’t guaranteed.
Sorry, but NotchLC won’t display alpha channels in videos properly until a patch is applied to FFmpeg itself.
