Video glitches

Support
1

Hi Chris,

I was wondering if I could get your feedback on the following. I noticed choppy video presentations in both rig 1 and rig 2. It is similar to the “glitches” from the movie Matrix. I attached a MOV file that shows such an example clip starting at 4 seconds.

I haven’t found any warning messages in the MWorks log in either rig. I typically use ‘deterred = explicit’ but also tried without this option and ran into the same observation.

Happy to provide further details or the whole experiment if you’d like. I’m wondering if it’s time to upgrade the Mac Pro (to a Mac Studio).

Thanks,
Yoon

4

Hi Yoon,

I noticed choppy video presentations in both rig 1 and rig 2. It is similar to the “glitches” from the movie Matrix. I attached a MOV file that shows such an example clip starting at 4 seconds.

That is strange looking. It’s almost like the video is jumping ahead a frame or two and then jumping back. The fact that it’s happening on two different Mac’s makes me suspect a software issue rather than a hardware failure. That said, the graphics cards in the 2013 Mac Pro have had a tendency to fail, so I wouldn’t rule it out.

Can you send me your experiment file and the video that starts playing at the 4 second mark? I can’t think of anything your experiment could be doing to cause the glitches, but it’s probably worth a look. Also, what versions of MWorks and macOS are you running?

I’m wondering if it’s time to upgrade the Mac Pro (to a Mac Studio).

It’s probably time for that in any case. The current base configuration of the Mac Studio (M2 Max, $1999 retail) looks like an excellent replacement for the old Mac Pro’s.

The only issue to be aware of is that a few MWorks components are still Intel-only, because they depend on third-party software that doesn’t support Apple Silicon. Specifically, as of MWorks 0.12.1,the DATAPixx and EyeLink interfaces, MWClient’s MATLAB window, and the MATLAB data tools are Intel-only. You can still use them on an Apple Silicon system, but you have to run MWServer and/or MWClient in Intel mode via Rosetta. This shouldn’t cause any problems, as app performance under Rosetta is very good, but I wanted you to be aware.

Cheers,
Chris

5

Thank you for looking into this, Chris!

Here are the requested items:

6

Hi Yoon,

It looks like the attachments were stripped from your message. (I think Discourse limits uploads to 10MB, which may be the issue.)

Could you share them on Dropbox or just email them to me directly?

Thanks,
Chris

7

Hi Chris,

Sure, here is the dropbox link: https://www.dropbox.com/scl/fo/8eossgwsws7yf9v440roe/h?dl=0&rlkey=5jqz3kyj4la0cwxoi1ksa08zo

Thanks,

Yoon

8

Hi Yoon,

Thanks for sharing the files.

I don’t see anything amiss in your MWEL file. This isn’t surprising, since, as I said, I don’t think your experiment code could be causing the issue.

I wasn’t able to find the specific video file that glitched in the set you shared. (I see that the experiment expects 1076 videos, while the “videos” folder contains only 445 videos.) Do you think you could share that one, specific video (or a full set that includes it)? I want to confirm that there’s nothing odd/broken about it in particular. Again, I don’t really expect to find anything, but we should still check.

Assuming everything looks OK, the next step would be for me to trying running your experiment on a couple different machines, including my 2013 Mac Pro. If there’s a software issue (in MWorks or macOS), then it should show up. If it doesn’t, then a hardware issue seems more likely.

Also, what versions of MWorks and macOS are you running?

Thanks,
Chris

9

Hi Chris,

Sorry about the slow response. Here are my answers to your questions.

  • I replaced the “videos” folder with all 1076 videos
  • Sorry, I could not find the exact video. However, I could see glitches again fairly easily across every 3-4 videos. I also pause the experiment after an hour to give the animal a break, but not sure if this plays a role (I suppose not).
  • MWorks version: 0.11
  • Mac OS: Monterey (12.6)

Additionally, here is an alternative experiment showing the same “glitch” with a smaller number of videos (~700 videos): https://www.dropbox.com/scl/fo/cx4taw5huxpv7bt20ow74/h?rlkey=osv8ywocefsrkj1stvav7q2sy&dl=0

Thanks again,

Yoon

10

Hi Yoon,

Thanks for sharing the additional files.

I think the video I wanted is 428.mp4. Unsurprisingly, I don’t see any issues with it, and it plays smoothly for me in both QuickTime Player and MWorks.

I’ve been running the smaller, alternative experiment on my M1 iMac. At present, it’s been going for over 20 minutes, and I haven’t seen any glitches in the video playback. Have you seen the issue on any system other than a 2013 Mac Pro?

One more question: What is the refresh rate of the display(s) on which you’ve seen the issue?

Thanks,
Chris

11

I haven’t tested the experiment extensively elsewhere. I’ve tried it on my M1 macbook pro for 30 min but did not see the glitches. On the other hand, both rigs 1&2 show glitches.

The refresh rate, on both rigs, is 120 Hz at 1080p resolution. I’m using a gaming monitor and checked the 120 Hz refresh rate with a photodiode, using the approach you provided.

Do you have a suggestion on next steps? Happy to try out your suggestion.

Thanks,

Yoon

12

Hi Yoon,

Can you change the refresh rate to 60Hz and see if that affects the glitches? I’m wondering if the graphics card in the old Mac Pro isn’t quite up to the task of presenting smooth, 120Hz output.

That said, even if 120Hz is too much for the GPU, I would expect the failure mode to be skipped frames. The fact that the video seems to be jumping back and forth along the timeline is very strange, and I’m having a hard time imagining any reason why that would be happening.

I’d still like to run your experiment on my 2013 Mac Pro. I will try to do that this Thursday.

Cheers,
Chris

13

Hi Yoon,

Running your experiment on my 2013 Mac Pro, I’m seeing some glitchy video. I didn’t notice anything until around trial 200, and the glitches stopped after a while, but they definitely looked like the problem you’re having. Also, my stimulus display is running at 60Hz, so I think we can discard my theory about your 120Hz displays.

It’s a weird problem. As you said, there are no warnings from MWorks about frames being skipped. Qualitatively, the issue doesn’t really look like frame skips – more like the back and forth time jumps that your example video showed. I thought MWorks might be leaking some system resource (memory, threads, kernel ports), but I don’t see anything.

I’m currently running your experiment on my 2020 iMac. Like the Mac Pro, it has an Intel CPU and AMD GPU, but both are much newer.

Cheers,
Chris

14

Hi Yoon,

I never saw any video glitches on my 2020 iMac. It’s possible I just missed them or that they would have started eventually, but otherwise this supports the theory that the issue is specific to the 2013 Mac Pro.

Also, I noticed that the glitches are visible in the mirror window as well as the main stimulus display. This suggests that the video frames are getting messed up before MWorks receives them from the OS.

When possible, macOS employs hardware acceleration for video decoding. There may be an issue in the graphics drivers for the 2013 Mac Pro that results in the video frames sometimes being delivered to the OS (and thus to MWorks) out of order. We could probably test this by using a less-common video format whose decoding is not hardware accelerated, although I don’t know of an appropriate format at the moment.

That said, the better solution is probably still just to replace the old Mac Pro. FYI, the EyeLink Developers Kit very recently gained native support for Apple Silicon, so you’ll no longer be forced to run MWServer in Intel mode to interface with an EyeLink.

Cheers,
Chris