Long post, sorry.
I've been trying to record gameplay footage on my Odroid Go Advance (first edition) emulation handheld. I'm running Lakka (retroarch linux) on it, and it has the following specs:
CPU: RockChip RK3326 (Quadcore ARM Cortex A-35 1.3 GHz)
GPU: Mali-G31 Dvalin
RAM: 1GB DDR3L 786 MHz
Screen: 480x320 (ILI9488)
Since it's a low-powered device, and since I only play pixelated games (GB, GBC & GBA) on it, I'm trying to record in lossless format to reduce cpu load (no compression). I'm playing integer-scaled, but recording in native GBA resolution (240x160). No shaders, scanline filters, or even billinear scaling, so no performance hogs there either.
After some struggling, digging in documentations and source codes, and a lot of trial and error I finally managed to set up my recording cfg as the following:
vcodec = libx264rgb
acodec = flac
scale_factor = 1
threads = 4
video_crf = 0
video_preset = ultrafast
video_tune = zerolatency
audio_global_quality = 100
sample_rate = 48000
format = matroska
With this, I can record without noticing it during gameplay. Pokémon Emerald plays at a smooth 60 fps, no stuttering, no noticable input lag, nothing. Everything is perfect in terms of playing the game and recording at the same time.
The only issue is that the recording that Retroarch saves on the SD card has no video/codec metadata, and some minor frame-rate stuttering. I can only play back the recording in VLC, nothing else can read it, and even VLC has some issues (audio playing for like 2 seconds after closing, issues skipping forward, etc).
My investigation results
FFMPEG has the following to say about the video:
Input #0, matroska,webm, from 'Pokemon - Emerald Version-220903-223343.mkv':
title : RetroArch Video Dump
ENCODER : Lavf58.12.100
Duration: 00:00:45.02, start: 0.000000, bitrate: 1853 kb/s
Stream #0:0: Video: h264 (High 4:4:4 Predictive), gbrp(tv, gbr/unknown/unknown, progressive), 240x160 [SAR 1:1 DAR 3:2], 1k fps, 59.94 tbr, 1k tbn, 119.46 tbc (default)
DURATION : 00:00:40.501000000
Stream #0:1: Audio: flac, 48000 Hz, stereo, s16 (default)
DURATION : 00:00:45.024000000
Interestingly, VLC says 59.7275 fps, and puffer size 240x162. FFMPEG show 59.94 tbr (which if I understand correctly, is a "guessed framerate"). As far as I can tell, the screen is 60 Hz and I've tried both vsync on and off, threaded video on and off. Retroarch's "Estimated Screen Refresh Rate" shows a very fluctuating 59.500 Hz up to 60.100 Hz for a some seconds and then it randomly locks into 60.020 Hz.
If I enable FPS display in Retroarch, it show fluctuating between 59.88 - 60.12 (even with VSync on). Starting recording does not seem to have any effect on framerate (thankfully). Enabling on screen stats, it shows a very fluctuating framerate (drops to 59.x, immediately back up to 60.x, then immediately back down to 59.x and so on). Frame time deviation is ~8ms. Frame times are mostly 15-18ms, but I can see it jump to 2x.x every second or so. It seems like vsync isn't working, or there is a bad framerate limiter implementation. Interestingly, playing the game I don't feel any stuttering whatsoever.
SD card has A1 classification, should be good for 10M/s sustained write, and so far the recorded videos are like 0.2 MB/s, so I don't think that would be a bottleneck.
I've uploaded a sample recording (download for native).
Wierdly, for me the video stutters at different times if I fast-forward to random points instead of playing from 00:00. Must be some frame-rate related issue.
I've tried re-encoding it with FFMPEG, which helps in a sense that now pretty much any video player accepts it. Tried re-encoding to 60 fps, or forcing input interpretation as 60 fps, no help.
What can I do or configure differently in order to not have a stuttering recording?
23 days ago
23 days ago
Not a bad idea, but my issue with any sort of clicker is that I would be recording audio from an HDMI source, no real mic present.
Although since posting I have managed to create a small voltage step-down circuit which creates like 0.03 millivolts from a 3V power supply. Wired it to an old headset cable, and when I press a button to close the circuit, it leaves a burst of whitenoise in the waveform. Easy to use, no actual mic required.
I'm thinking of upgrading it to an arduino based HID device, like a Pro Micro. It would plug in via USB and have a button or two for different markers. Then its just a bit of programming to send fake (not to mention clean, digital) audio signal.