Weirdness with H265 and GLSL shader

Steps causing the bug to occur

I’m really looking forward to finding the answer to this.

  1. Please find composition attached, and sample H265 movie here http://paulbourke.net/transient/4Vuo/
    Took a while to distill to the essence.
  2. If I run as supplied with the H265 movie, it stutters and eventually goes transparent.
  3. If I convert to a H264 movie then all is well. This might point to a movie issue(?)
  4. BUT, if I change the “missingcolour” value in the shader (which isn’t used to display the frames) to say (0.0,0.0,0.0,0.01), or (1.0,0.0,0.0,0.0) then it works fine.

Confused!

Have you found a workaround?

Yes.

Other notes

  • Vuo version: 2.4.2
  • macOS version: macOS 12
  • CPU: x86_64
  • Have you been able to reproduce the problem? Yes, the problem occurs consistently when I follow the steps above
  • How severely does this bug affect you? It’s annoying but I can work around it.

test.vuo (3.59 KB)

Well, we can confirm that what you described is indeed weird, but so far we haven’t been able to reproduce the problem. We tried running the composition for several minutes on two different computers.

If I convert to a H264 movie then all is well. This might point to a movie issue(?)

Vuo would be using its FFmpeg player for the H.265 movie. For the H.264 movie, depending on the specifics of the movie file, Vuo could be using either the FFmpeg player or the macOS AV Foundation player. If it’s using a different player for the two movies, that could partly explain the difference.

BUT, if I change the “missingcolour” value in the shader (which isn’t used to display the frames) to say (0.0,0.0,0.0,0.01), or (1.0,0.0,0.0,0.0) then it works fine.

The fact that the downstream Shadertoy node can somehow affect the movie image suggests either a macOS OpenGL driver bug or some sort of race condition in Vuo’s use of OpenGL.

Perhaps the problem only happens with certain GPUs?

Since you’ve found a workaround, and since we’ll be converting Vuo’s graphics from OpenGL to Metal in Vuo 2.5.0, we’re thinking it would be better not to take a detour to fix this bug, unless new information comes in indicating that the problem is not specific to OpenGL.

OK … since you can’t reproduce it + I’ve found a workaround + things are going to change with 2.5 … then sure, lets (try to) forget about it.
ps: I’m on Intel MacMini with Core I7 running Monterey.

Can I ask a question that your reply has given rise to, specifically your comments about ffmpeg and AV foundation.
Here’s the deal.

  1. I generate H264 movies outside of Vuo with ffmpeg, 1920x1080. I can play them backwards (playback rate=-1) and it’s smooth.
  2. If I generate similar movies at 2560x1440, H264, they play backwards very jerkily. Jumping to prior frames rather than showing intermediate frames.
  3. If I do the same thing with H265, the result is similar as long as I set the IBP frame structure similar to the H264 case, otherwise it’s generally worse.

I guess my question is, what different might be happening between the two resolutions in how reverse playback can occur?  

I noted the line “Moderator note: Adjusted formatting”
Why are the line feeds in my post being ignored?

I guess my question is, what different might be happening between the two resolutions in how reverse playback can occur?

Hard to say without seeing the movie files. Would you be able to provide examples? It might also help to see the ffmpeg commands used to generate the movies.

Why are the line feeds in my post being ignored?

We’ve moved to the new forum platform since your last comment, so the answer has changed somewhat. Both the old and the new platform allow Markdown formatting. In strict Markdown, if you have a paragraph followed by a numbered list or vice versa, you have to put a blank line in between. The new platform’s Markdown parser is a little more relaxed, but check the preview of your post to see if you need to add blank lines.