Slight drift when recording video

I’ve been using SSNES a lot lately, mostly for video recording in both filtered hi-res and original-res through played back bsv-input-files. And that’s been working GREAT! Not once did I encounter an input-file that didn’t replicate exactly what I had… well… “put in” (unlike some memories I have with that and ZSNES back in the days).

All right, so first of all: THANK YOU SO MUCH FOR SSNES AND ALL THIS AWESOME FUNCTIONALITY!! It has been very helpful for recording SNES-footage and I’ll keep using it a lot! Though, now that I’ve come to trust input files and was recording longer sessions, I discovered that the audio and the video in the file that gets created (mkv, h264/flac) get out of sync over time. Well, not just “over time”, there’s always a little error with timecodes, but it was already noticeable after around 10 minutes. So I recorded a long session of the Tetris Attack Intro playing over and over again for almost three hours to see what was going on. I did this with both SSNES 0.9.3 and 0.9.4, no change, here are the results:

The resulting video was: 612372 frames total = 2h50m06s12fr = 10206.2s

while the audio was only: 326472192samples @ 32000HZ = 2h50m02s256ms =10202.256s

so after around three hours the audio is already ~4 seconds behind! What I’m doing right now to get around this is to first demux the mkv, then change the tempo of the audio by 10202.256/10206.2 and then remux and finally encode all of it. What I also noticed during encoding through FFMPEG is that a different framerate from container and videostream gets reported, FFMPEG says:

“Seems stream 0 codec frame rate differs from container frame rate: 120.00 (120/1 ) -> 59.94 (60000/1001)”, which leads to an automatic encoding at 59.94 frames and frames being dropped if I don’t force it to stay at 60 with “-r 60”

Anyway, at the moment it works for me like this, but I wonder if this could be fixed to sync up perfectly from the start.

Functionality for this is implemented already as of 0.9.2 (I think), but it relies on libsnes to do the right thing.

Essentially, it relies on the libsnes implementation to report values for FPS and sample rate correctly. If it’s not set, it defaults to SNES’s values (60.099 fps / 32040.5 Hz). Which implementation are you using? Not all of them are tweaked for timing accuracy yet as we do it more on a case by case basis.

“Seems stream 0 codec frame rate differs from container frame rate: 120.00 (120/1 ) -> 59.94 (60000/1001)”, which leads to an automatic encoding at 59.94 frames and frames being dropped if I don’t force it to stay at 60 with “-r 60”

Known quirk with FFmpeg.

You should join #ssnes on freenode so we can discuss this more.