AV.io HD Video Artifacts/Tearing



I recently got the AV io HD to record Nintendo Switch games, but I’m noticing the video has these horizontal artifacts affecting it. It’ll show up for a few frames, then the screen will clear and the cycle repeats every 1-10 seconds. Here’s some stills with a close up for a visual:

We’ve tried it on Windows 7 and Linux, with CPU encoding (i7-3770k and i7-4790k) and GPU encoding (NVIDIA GTX970 and Radeon RX480), gone through countless settings in OBS, updated the card’s firmware to 4.0.0, but this issue will not go away.

It’s not too bad and the card is still usable, but has anyone else had these problems? If so, how did you solve them?


Very interesting! I assumed that the Nintendo Switch output would be HDCP encrypted, are you just capturing the HDMI output of the included Nintendo dock directly into the AV.io HD with a short HDMI cable? Or are you using a third party adapter or long cabling? Is there anything in between the switch HDMI output and the AV.io HD such as an extender, switch, or splitter?


I tried both. The first screenshot was done via the HDMI splitter, the second was plugged directly into the dock with nothing else in between. I just tested with the shortest HDMI cable we have plugged directly into the dock, no change.
I did look into it and as far as I can find, the Switch does not have HDCP encryption.


Hmm ok. Can you tell me a little more about the setup? Such as the capture computer you are running, operating system it uses, and software you are capturing in? Have you tested with other HDMI signals to make sure these capture ok, such as the HDMI output of a laptop?


The PC I’m running is Windows 7 64-bit, CPU: i7 4790k, GPU: Radeon RX 480, 16GB of EVGA DDR3 RAM, Motherboard: Z97 Extreme4, and the recording drive is a Seagate 500GB SATA SSHD.
I’m using OBS to capture. I could spend a long time listing the settings I normally run as well as the settings I’ve tried, so I’ll list the basics: record in “Custom Output (FFmpeg)” with varying bitrates from 5,000 to 12,000. Used both “x264” (CPU) encoding and “H264/AVC Encoder (AMD Advanced Media Framework)” (GPU) encoding. Renderer is Direct3D 11, colors are set to NV12 because RGB caused the recordings to fail. OBS is also set as a high process priority.

I did try two other HDMI signals, one directly from my graphics card and one from a laptop, both came out fine and crisp with no problems. I haven’t tested other game consoles yet, but so far the Switch appears to be the only one causing trouble.


We brought in a Nintendo Switch to test with and were able to confirm similar issues, though difficult to see most of the time. I have filed a bug report with the development and QA teams regarding this for them to investigate. Interestingly I did not see any issue when testing with the AV.io 4k, so if you are able to return the AV.io HD for credit towards the AV.io 4k this may be a workaround for you for the time being.


Thanks so much for all your help on this! I really appreciate it!


Hello, just wanted to let you know that we do have a fix for the Nintendo Switch HDMI output from its dock with the AV.io HD. This is currently in a Beta firmware and will be included in the next full release. If you would like to try out the Beta yourself (noting that it is possible being a Beta for other bugs to be introduced that haven’t been found by the QA team yet) please email info@epiphan.com



I’m seeing this same issue; is thw new firmware version almost ready for release?

Also, perhaps related (but perhaps not), when using the Switch with scaled output (i.e., the Switch outputting 1920x1080 but having the av.io hd scale it to something smaller) I see glitchy output every so often; like a frame or two of video aren’t being scaled. It’s fine outputting at 1920x1080 and having the computer scale so that problem can be worked around easily but I’d prefer to offload that work of course.

I haven’t yet tried if that issue exists with other sources; I’ll see about that later today.


I tried a different source (a MacBook Pro) and did not seem to experience the scaling glitch issue. So it may indeed be related.

I uploaded a short video of the phenomenon here: https://streamable.com/afv0j


Thanks for letting us know, that does look like it is likely related to the earlier bug! Unfortunately I am not sure when the next firmware release will be. I have a beta build with the proposed fixes for this that I can provide you if you’d like to try it out, just email our ticket system at info@epiphan.com and I can provide a link there.


I will do that, thanks.


I’d like to offer a subtle reminder that this firmware version, which is effectively a necessity for anyone wanting to capture Switch video using an av.io HD, and which I have been using without issue since my last post, is not yet publicly released. I’m sure a lot of (potential) Switch streamers would be interested in it.


That is true, this is just the development process. Basically we have to put a freeze on changes to the firmware so that we can then pass this off to the QA team for a full cycle of tests. Due to the fact that there are so few changes/improvements in the firmware over the released version this freeze hasn’t happened yet. But if anyone with a Switch sees this please email us at info@epiphan.com and we would be happy to provide the beta version!


I’m seeing similar tearing and glitching on video being captured out of an Geffin HDMI 4x4 Matrix at 1280x720 with HDCP disabled. Capture machine is running mimoLive 5.2 on a MacBook Pro mid 2015 with an i7 and integrated ATI graphics. Tearing occurs at what seems like random intervals. Given the fix was implemented in January (9 months ago) this seems like an extremely SLOW dev cycle. If there are only a few changes to QA then why not QA them and push them out as a dot release (4.0.1) so that those of us who have paid hundreds to use your devices can have access to these fixes as quickly as possible?


If you need the Beta firmware we can certainly provide this, just email info@epiphan.com

Sorry if the release of new drivers is taking longer than you expect here