Troubleshooting Skippy on Atomos Ninja V

I took receipt of my Atomos Ninja V (Adorama, Amazon) on October 6 that I might record 10-bit 4K DCI 30 4:2:2 out of my Fujifilm X100V (Adorama, Amazon), pairing it with a 1TB Team Group SSD, and encountered Skippy. On October 13, I pulled the trigger on a 2TB Crucial BX500 from Amazon for $159.99 BTAX, and continued encountering Skippy. The problem became most apparent while I was performing capture tests ahead of my first production.

I made a note to troubleshoot Skippy’s continued appearance, thinking it could be the cable, my SSDs, my camera, or my copy of the Ninja V itself…

To rule out the SSD, I reasoned I could test out an NVMe SSD housed within a SATA3 enclosure, but that would be a rather niche purchase. I educated myself, instead, on SSDs, learning they are not all made the same!

On December 18, I took receipt of my Sony A7S III (Adorama, Amazon), and, on December 21, I hooked it up with my Ninja V for the first time. With the 1TB Team Group SSD inserted, the Ninja V reported that I could record 45 minutes and 5 seconds of 4.2K30 12-bit ProRes RAW, at least in theory. In testing, however, I found Skippy kept rearing its head

On December 23, I opened up a new 2TB Samsung 860 EVO I purchased for $199.99 BTAX (, and set up my A7S III for yet another capture test. This time I was able to record for two hours before terminating the test so I could take the camera out with me

On December 25, I set up an endurance test. I returned home after visiting with my folks, and found Skippy, with my Ninja V reporting 00:12:49 recording time remaining. Recording had ceased altogether. I resumed recording on the Ninja V, and checked later to find it had successfully written to the point it could write no more. I initially assumed this meant it had written the drive out to capacity, but upon further investigation, discovered 101GB of free space remaining. Switching the Ninja V to a different recording format did not free up any recording time at this point.

On December 27, I conducted an endurance test at 4.2K60 RAW from my Sony A7S III, writing to my 2TB Samsung 860 EVO. The Ninja V and Sony A7S III passed, recording until the point the Ninja V would not write any more. I did observe the temperature warning icon on my Sony A7S III, which I ran with the monitor off and collapsed against the rear of the body throughout the recording run.

Hopefully, my experience troubleshooting Skippy appearing on my Ninja V helps you. I was prepared to go all out in my quest to get the Ninja V playing nicely with my cameras, and even considered shelling out for Atomos’s HDMI cables. Ultimately, the HDMI cable that came bundled with my Xbox One proved sufficient to handle the data rates of 4.2K30 RAW from my Sony A7S III. Granted, I’ll probably want to pick up a coiled HDMI cable ahead of any field work!


Atomos recommends these drives:

Further Exploration

If there’s something more you’re curious to learn, let me know in the comments, and I’ll get back to you!

Developing the Leader Within You by John C. Maxwell (First Pass)

I just wanted to share details of the work that went into cleaning this piece up from the original livestream version to the one you may have seen.

Disclaimer: I still haven’t watched it through to the end, so I don’t know how good of a job I did on this first pass, but I’ve been feeling the need to output content faster. #fuckitshipit

I ran FFmpeg with the following arguments
ffmpeg -i "Developing the Leader Within You.mp4" -c:v libx264 -preset ultrafast -crf 15 -threads 8 -c:a copy "Developing the Leader Within You CFR.mp4"

I’ve included both the head and tail of the output

Head of Output

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'D:\Blinks\Developing the Leader Within You\Developing the Leader Within You.mp4':
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf55.43.100
  Duration: 00:16:32.62, start: 0.000000, bitrate: 5170 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080, 5052 kb/s, 29.20 fps, 29.92 tbr, 90k tbn, 180k tbc (default)
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 108 kb/s (default)
      handler_name    : SoundHandler
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  Stream #0:1 -> #0:1 (copy)

Tail of Output

frame=29696 fps=131 q=-1.0 Lsize= 3150821kB time=00:16:32.61 bitrate=26003.7kbits/s dup=724 drop=7 speed=4.38x
video:3136735kB audio:13107kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.031094%
[libx264 @ 00000255e2328dc0] frame I:119   Avg QP:11.56  size:332738
[libx264 @ 00000255e2328dc0] frame P:29577 Avg QP:14.57  size:107260
[libx264 @ 00000255e2328dc0] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264 @ 00000255e2328dc0] mb P  I16..4: 17.0%  0.0%  0.0%  P16..4: 69.1%  0.0%  0.0%  0.0%  0.0%    skip:13.9%
[libx264 @ 00000255e2328dc0] coded y,uvDC,uvAC intra: 71.5% 83.9% 50.2% inter: 49.1% 54.2% 11.0%
[libx264 @ 00000255e2328dc0] i16 v,h,dc,p: 26% 21% 39% 14%
[libx264 @ 00000255e2328dc0] i8c dc,h,v,p: 31% 31% 19% 19%
[libx264 @ 00000255e2328dc0] kb/s:25887.07

Arguments were ones that I referenced from this post, which appeared on the GeForce forums: FFmpeg batch – a fix for variable frame rate for Adobe Premiere Pro

Next, I used MP4Muxer to demultiplex, separating the audio and video tracks.

I fed the audio track into Adobe Audition, where I:

  • Generated a Noise Print
  • Applied Noise Reduction
  • Applied De-Esser (if relevant)
  • Applied Normalization -16 LUFS

I exported the file as a CBR MP3 (320kbps) to ensure fidelity (I do recognize that the source audio is AAC – no notes on why I chose MP3)

I went back into MP4Muxer and multiplexed, setting Frame Rate to 30.

The output was pushed to YouTube, yielding what you see below:

I’d appreciate your feedback on this process. Constructive comments and criticism are always appreciated here 🙂