News:

11 March 2016 - Forum Rules

Main Menu

How to Determine Video Playback Speed?

Started by Xhojn, November 09, 2022, 09:26:25 AM

Previous topic - Next topic

Xhojn

Yo, I'm trying to figure out how to modify the speed at which the cutscenes in a Sega CD play? I couldn't see anything in the hacking guides about how to determine this?

Thanks!

FAST6191

Cutscenes need not be video (nothing wrong with having your existing sprites dance around on screen, indeed preferable in many ways) but assuming they are.

Simplest way is do a video capture, take it to a video editor and count the number of frames between changes (pick a reasonable point to do it rather than some static hold shot). You have your rate at that point. This would then be enough if you were ripping a video and did not know playback rate (similar can also be done for audio).

If doing it properly then assuming there is no metadata ( http://www.headbands.com/gspot/ is more PC/general video based but might have something, https://wiki.multimedia.cx/index.php?title=Category:Game_Formats is also good stuff at this point, as is http://wiki.xentax.com/index.php/Game_File_Format_Central ) to detail it you get to figure out how the video works. This can be more involved than many anticipate though.
Basic video is a glorified slideshow and more likely to be seen on older systems (motion jpeg being used up until the Wii mind you).
More advanced video will use further techniques to reduce the size (as well as things being similar within the picture they are similar from frame to frame, spatial which is why things get broken up into squares aka macroblocks and temporal approaches). In general parlance this brings in i-frames, p-frames (predicted frames, based on what will happen next) and b-frames (bidirectional predicted frames, a more advanced technique), and probably GOP (group of pictures, usually a forced end to prediction, or why sometimes a corrupted video will start by becoming good with the motion in the video and suddenly snap good again) every so many frames. This all dovetails... I can't say nicely but a bit with general approaches of most 2d video systems -- try to load a full "unique" frame of data every frame (so between 12 for low end animation, 17 for basic video*, 21-22 for it to be good, 24 is film, 25 is PAL and 30 is NTSC, though the latter two are sometimes doubled but that also brings in fields for interlacing) and even a DS will struggle so instead things play to that and will load things as tiles a lot of the time, possibly crashing down all the data they can to get within limits (limited colours for a start), possibly reducing resolution or effective resolution, probably adding some dithering.
Do also check the system does not have a preferred format (Microsoft encouraging the use of their formats, and occasionally even providing onboard chips for it).

I usually link https://www.cmlab.csie.ntu.edu.tw/cml/dsp/training/coding/mpeg1/ in scenarios like this and note that is MPEG1 (if you are now on the older side you may have encountered videos as MPG, this is that, or maybe on the DS as DPG for moonshell homebrew). Hopefully you don't have to do something newer.

Depending upon the system you may encounter wavelet compression (some places in the world allow for software patents *spits* and thus video has patents, commercial use not just being able to download it and use it/sell it, which means things do workarounds from time to time -- Google quite famously embracing/creating VP9 https://www.theregister.com/2015/09/08/microsoft_thanks_google_well_have_your_media_codec_for_edge/ ) but I will skip that one for now.
Hopefully you are not also dealing with interlacing as would have been common... actually until rather later than would have been ideal in games.

*why old war footage often gets sped up by bad editors.

Anyway so you then get to change the update rates at which images are presented to the screen after all the decoding gets done, assuming it is even possible if you are speeding up**.

**granted we then get introduced to the 3:2 pulldown some NTSC videos will use here or pulldown in general. Here frames might be repeated; film to PAL is easy enough if you speed up (most won't notice at least until you have them side by side), film to NTSC... someone will notice that so various fields might be replayed in a 3:2 pattern to make up the speed at the cost of some jerky motion (PAL folks tending to note it when they visit NTSC places). Hopefully it is not mixed footage (seen often enough where film is film but CGI was shot at 30fps or something and sorted out afterwards, one of the troubles with ripping DVDs).

Xhojn