Introduction
Following the events of "AVerMedia Live Gamer ULTRA 2.1 on macOS", I've been making some content while utilising the card with a new PS3 that I bought. Here's a tweet about that:
5 generations of PlayStation in 2 consoles! I decided to pick up a backwards-compatible PS3 for the game room. It is a launch model CECHA01 with PS2 support. Pretty good condition too. It now sits alongside my PS5. pic.twitter.com/3BUaI1P2tF
— Claıre 🌺 (@iDestyKK) June 25, 2025
5 generations of PlayStation in 2 consoles! I decided to pick up a backwards-compatible PS3 for the game room. It is a launch model CECHA01 with PS2 support. Pretty good condition too. It now sits alongside my PS5. pic.twitter.com/3BUaI1P2tF
— Claıre 🌺 (@iDestyKK) June 25, 2025
So, let's tell a story. I want to document the entire production process. That way, the problem can be replicated or avoided. This blog post is, admittedly, kind of a mess. I may edit it later to clean it up.
Recording and Archival
Recording footage
This is very simple. In the aforementioned blog post up above, I give an
FFmpeg command to record video. I turned it into a script which will allow
for storing more metadata, as well as choosing devices correctly and fixing
the 4.0 audio stream issue. Here that script is. Note, it's for macOS only
due to gdate and avfoundation.
# Get the video and audio devices to specify for AVFoundation
DEV_VID="$(\
ffmpeg -f avfoundation -list_devices true -i "" 2>&1 \
| grep "Live Gamer Ultra 2.1-Video" \
| head -n 1 \
| sed 's/\[.*\] \[//;s/\].*//'
)"
DEV_AID="$(\
ffmpeg -f avfoundation -list_devices true -i "" 2>&1 \
| grep "Live Gamer Ultra 2.1-Audio" \
| head -n 1 \
| sed 's/\[.*\] \[//;s/\].*//'
)"
# Timestamp of recording
DATE_REC="$(gdate +%s.%N)"
# Record
ffmpeg \
-hide_banner \
-rtbufsize 2G \
-f avfoundation -framerate 60 -video_size 1280x720 -i "${DEV_VID}:${DEV_AID}" \
-filter_complex '[0:a]pan=stereo|c0=c0|c1=c1[fa]' \
-map 0:v -map '[fa]' \
-c:v utvideo \
-c:a pcm_s16le \
-metadata DATE_RECORDED="$(gdate -d "@${DATE_REC}" -In | sed 's/,/./')" \
"${DATE_REC}.mkv"It will spit MKV files out with filenames being the UNIX timestamp of the exact moment when recording started. I opted for 720p because unless I'm playing one of the handful of PS2 games that support 1080i, there is no point in wasting space.
The Archival Procedure of DERPG
DERPG is my main YouTube channel, which features over 10,000 unlisted videos of archived game content. When I record video content, my goal is to preserve the moment in its entirety. That means more than just the video content itself. I record commentary audio tracks of all participants separately. I have developed ways to automatically sync all audio tracks and preserve them in an MKV container. This is standard procedure.
Here's an example audio session from the other day where we were capturing gameplay of Taz: Wanted and Need for Speed: Hot Pursuit 2 on PS2:
The information stored here is game audio, as well as audio input from two stereo microphones. The top segment are reference tracks. After those, channels 1 and 2 are the gameplay. Channels 3 and 4 are my microphone. Channels 5 and 6 are my brother. macOS allows aggregate devices so I can easily record these in sync with drift correction being accounted for.
When all exported, I utilise FFmpeg to join all of the video and audio tracks together into a single MKV file. As such, the MKV file will have multiple audio tracks. Here's an example of that:
You starting to see the amount of effort I put into preserving the moment? In "Grind Series: Quantity without compromising Quality", you can see an even more extreme example of this. In DERPG's case, the reason for storing all of these separately is so we can go back later on and edit them in post. Or just archive them. Archival is important. Videos uploaded to YouTube generally do not have voice tracks included in them.
Processing the Recordings
Those "master recordings" were meant to be spliced further into separate parts to upload to YouTube. For instance, one huge MKV file contains an entire gameplay session where we play several levels. But I want each level uploaded to YouTube as a separate video. This requires further editing.
Further Editing
This is best taught by example. In the Audacity screenshot up above, you will notice two UNIX timestamps: 1756692334.314295000 and 1756696990.334200000. These are session recordings which were meant to be chopped up into smaller videos. In the former's case, 2 smaller videos and 1 big video were supposed to come out of it. So it's time to whip out FFmpeg and write some commands to do just that:
#!/bin/bash
# 1:28.846 -> 29:26.782
ffmpeg \
-ss 88.846 -to 1766.782 \
-i "1756692334.314295000.mkv" \
-map 0 \
-c:a copy \
-c:v libx265 -crf 17 -pix_fmt yuv420p10le -preset slow \
-metadata DATE_ENCODED="$(date -In | sed 's/,/./')" \
"09_granny_canyon.mkv"
# 29:33.285 -> 1:12:29.850
ffmpeg \
-ss 1773.285 -to 4349.85 \
-i "1756692334.314295000.mkv" \
-map 0 \
-c:a copy \
-c:v libx265 -crf 17 -pix_fmt yuv420p10le -preset slow \
-metadata DATE_ENCODED="$(date -In | sed 's/,/./')" \
"10_taz_haunted.mkv"
# Uncut
ffmpeg \
-i "1756692334.314295000.mkv" \
-map 0 \
-c:a copy \
-c:v libx265 -crf 17 -pix_fmt yuv420p10le -preset slow \
-metadata DATE_ENCODED="$(date -In | sed 's/,/./')" \
"session_03.mkv"Like other blog posts, this one is not an FFmpeg tutorial. But all it's doing is giving me 3 MKV files:
- 09_granny_canyon.mkv - Between 1m28s - 29m26s
- 10_taz_haunted.mkv - Between 29m33s - 1h12m29s
- session_03.mkv - Unedited (for archival purposes)
These commands will preserve the audio tracks in their entirety, while compressing the video with x265.
But there was just one problem...
When the script was finished, I was left with 3 YouTube deliverables. So it was time to upload them to YouTube. Here are 2 of those 3 videos:
Notice anything odd about them? I guess it's hard to when you probably haven't played the game I'm mentioning. Anyway, the video is skipping all over the place. 1:31 in the left video is a good example of it. 1:49 is another instance of it. But these weird "jumps" or "cuts" are all over the place. The video does seem to correct itself later on and resync with the audio.
In fact, even the very beginning of the video cuts. I played around with some FFmpeg parameters in an effort to find the culprit:
|
Test 1 (Broken) -
Download
|
Test 2 (Working) -
Download
|
Test 3 (Broken) -
Download
|
I even provided downloads so anyone could analyse the videos and see if they could find the culprit to the problem. Here's the commands used to generate the three videos:
# Test 1 (Broken)
ffmpeg \
-ss 88.846 -to 108.876 \
-i "1756692334.314295000.mkv" \
-map 0:v -map 0:a:0 \
-c:a flac -compression_level 12 \
-c:v libx265 -crf 17 -pix_fmt yuv420p10le -preset slow -vf fps=60 \
-metadata DATE_ENCODED="$(date -In | sed 's/,/./')" \
"test1.mkv"
# Test 2 (Working)
ffmpeg \
-ss 88.846 -to 108.876 \
-i "1756692334.314295000.mkv" \
-map 0:v -map 0:a:0 \
-c:a flac -compression_level 12 \
-c:v libx265 -crf 17 -pix_fmt yuv420p10le -preset slow \
-metadata DATE_ENCODED="$(date -In | sed 's/,/./')" \
"test2.mkv"
# Test 3 (Broken)
ffmpeg \
-ss 88.846 -to 108.876 \
-i "1756692334.314295000.mkv" \
-map 0:v -map 0:a:0 \
-c:a copy -compression_level 12 \
-c:v libx265 -crf 17 -pix_fmt yuv420p10le -preset slow \
-metadata DATE_ENCODED="$(date -In | sed 's/,/./')" \
"test3.mkv"Interestingly, tests 2 and 3 feature the exact same processing on the video track. And yet one is broken and the other isn't. The first video was an attempt to correct VRR (Variable Refresh Rate) because that is one of the capture card's features. And the frame jumping appears to happen at very specific times. The only difference between tests 2 and 3 is that I copy the audio track rather than process it. The problem is, while the second command works, if I have it render a longer period of the video, the video will result in the same glitches and we are back to square one. So no matter what I do, there will be bugs throughout the video.
In fact, if you use FFmpeg to compare the streams (via simple hash check), the video and audio tracks of all three MKVs are identical:
UNIX> ffmpeg -loglevel error -i "test1.mkv" -map 0:v -f md5 - -i "test2.mkv" -map 0:v -f md5 - -i "test3.mkv" -map 0:v -f md5 -
MD5=a2e80c48a34e94d442dc4c9896a95f81
MD5=a2e80c48a34e94d442dc4c9896a95f81
MD5=a2e80c48a34e94d442dc4c9896a95f81
UNIX> ffmpeg -loglevel error -i "test1.mkv" -map 0:a -f md5 - -i "test2.mkv" -map 0:a -f md5 - -i "test3.mkv" -map 0:a -f md5 -
MD5=9e86fd39aa301722e3a8428028f81f9a
MD5=9e86fd39aa301722e3a8428028f81f9a
MD5=9e86fd39aa301722e3a8428028f81f9aIt should be noted that all of these video files play normally on a local video player like VLC or MPC-HC. They do not have these glitches. The only one that has issues is YouTube.
Resolving the problem
There's a few other tricks I have.
Screen recording
Since the video appears correctly on VLC, there's nothing stopping me from taking a screen recording of the video and then uploading that. And I can record losslessly. The problem with this is that then I'd have two massive files on my hard drive unnecessarily, and it takes a huge amount of time to record. The single session recording above goes over 2 hours long. And there's more than just that session recording, which spans even longer.
While this is guaranteed to work, I don't feel like sitting there for several hours just to fix the gameplay. So let's try looking for another solution.
Remuxing
It is possible to take the video stream out directly and put it into another container without loss of quality. Perhaps there's a quirk of MKV that YouTube doesn't support? I don't know. But let's try some sample commands:
# Extract video only
ffmpeg -i "broken.mkv" -map 0:v -c copy "video.265"
# Remux video with old video's audio
ffmpeg -i "video.265" -i "broken.mkv" -map 0:v -map 1:a -c copy "fixed.mp4"
I wanted it in two commands to have that .265 file and see how
FFmpeg reacts to it. Interestingly, when doing this, there were some
warning messages that popped up:
[mp4 @ 000001f950526b40] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[mp4 @ 000001f950526b40] pts has no value
Last message repeated 572 times
[mp4 @ 000001f950526b40] pts has no value
Last message repeated 585 times
[mp4 @ 000001f950526b40] pts has no valueWhat happens when we upload the video this time?
Well how about that? Our problem is fixed. So it was bad PTS information. For context, a raw H.265 stream doesn't have timestamps. So when we extracted it from the MKV, it threw away the bad timestamp information. Then, we threw it into an MP4 container and I am assuming FFmpeg automatically generated correct timestamps for the video.
A lot of sources via Google also tell me that -fflags +genpts
will fix such problem. However, it doesn't in my case. If you are curious,
I could not remux the 265 file back into an MKV file either. This happens:
[matroska @ 000001d099b8cb40] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
[matroska @ 000001d099b8cb40] Can't write packet with unknown timestamp
[aost#0:3/copy @ 000001d0995ed2c0] Error submitting a packet to the muxer: Invalid argument
Last message repeated 1 times
[out#0/matroska @ 000001d099bc71c0] Error muxing a packet
[out#0/matroska @ 000001d099bc71c0] Task finished with error code: -22 (Invalid argument)
[out#0/matroska @ 000001d099bc71c0] Terminating thread with return code -22 (Invalid argument)
[matroska @ 000001d099b8cb40] Can't write packet with unknown timestamp
[out#0/matroska @ 000001d099bc71c0] Error writing trailer: Invalid argument
[out#0/matroska @ 000001d099bc71c0] video:70KiB audio:13KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown
frame= 9 fps=0.0 q=-1.0 Lsize= 1KiB time=N/A bitrate=N/A speed=N/A
Conversion failed!Oh, and just while I was typing up this blog post, I found a video where the remuxing method doesn't work. This is what happens to that video:
[hevc @ 000001efc5e72d40] Format hevc detected only with low score of 1, misdetection possible!
Failed to reallocate parser buffer to -2147483584
[hevc @ 000001efc5e74440] Invalid NAL unit 0, skipping.
Last message repeated 9 times
[hevc @ 000001efc5e74440] Invalid NAL unit 54, skipping.
[hevc @ 000001efc5e74440] Invalid NAL unit 0, skipping.
Last message repeated 3 times
[hevc @ 000001efc5e74440] Invalid NAL unit 13, skipping.
...
...
...
[hevc @ 000001efc5e74440] vps_reserved_three_2bits is not three
[hevc @ 000001efc5e74440] Skipping invalid undecodable NALU: 32
[hevc @ 000001efc5e74440] Skipping NAL unit 23
[hevc @ 000001efc5e72d40] Stream #0: not enough frames to estimate rate; consider increasing probesize
[hevc @ 000001efc5e72d40] Could not find codec parameters for stream 0 (Video: hevc, none): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
[mp4 @ 000001efc5e87b40] dimensions not set
[out#0/mp4 @ 000001efc605de80] Could not write header (incorrect codec parameters ?): Invalid argument
Conversion failed!How interesting. This all wasn't a problem when we were recording Need for Speed: Carbon back in June. I wonder why it only bit me now. Anyway, we got our problem fixed in some cases. I'm done for now. This is a disaster.
Conclusion
I'm kind of pissed off. I don't know. I still don't understand why footage from this capture card becomes a mess on YouTube. Though it probably explains why the OBS footage in my previous blog post was also messed up. It, too, had glitchy frames that jumped all over the place. At least now I know how to possibly prevent this from being a problem in the future. I hope it helps someone out there too when they try to record with this card. Maybe I'll play around with some recording parameters and see if anything fixes it.
This solution is automatable, but I'd like something simpler. The card should just work. I don't understand why I keep running into problems with capture cards. The only ones that have worked for me perfectly are PCIe cards. External ones have been flakey, in my experience. I just wanted an alternate way to record that doesn't involve OBS, since I had a bad time with it before. If I come up with a better solution, I'll probably either edit this blog post or post a new one.
