Problems with clip alignment in timeline

[Andy Neil]

What is your original source media and how is it being recorded? This problem you’re having looks similar to an issue I’d seen on FCP Legacy where footage was recorded with software that didn’t lock the frame rate or else FCP was confused about the frame rate and was showing a non-standard frame rate which created all sorts of edit point issues.

In particular, I was getting it with a low cost screen capture tool and it didn’t go away until I upgraded to Screenflow.

Andy

https://plus.google.com/u/0/107277729326633563425/videos

[Chris Alaimo]

Hi Andy,

Thanks for the reply! Your intuition is correct that this footage is pretty “non-standard”. It’s 1344×896 at a framerate of 59.88 fps. You are also correct that the recording software is not locking the framerate, but rather just taking what it is getting. If that’s really what’s causing the problem, what do I do about it? Run it through compressor and have it output a file with a constant framerate?

Thanks,

Chris

[Andy Neil]

[Chris Alaimo] “Run it through compressor and have it output a file with a constant framerate?
“

That’s exactly what I would do. I know it’s an extra step, but it saves headaches all along the rest of your pipeline. You can set up a Droplet or Watch Folder (if you know how to do that) to batch convert all your footage to usable files. If you’re recording off your computer monitor, then the software you’re using is probably using the refresh rate of your monitor (60 Hz) as the frame rate and that’s why it’s not standard.

I’d set up a custom Compressor setting for Pro Res at a progressive frame rate like 30p (if it’s screen capture) and then import and work in a 30p sequence inside FCPX. If you’re not sure 30p is the right frame rate (there’s 29.97p or 60p), you can run a test on like 30 seconds to see what looks best.

Good luck,

Andy

https://plus.google.com/u/0/107277729326633563425/videos

[Chris Alaimo]

Thanks, Andy. What it actually is is old video game console footage, line quadrupled through an upscaler and then captured with a capture device. So that’s why the resolution and framerate are odd.

Anyway, I will try “washing” the files through compressor and see if that helps. Thanks again!

[Jeremy Garchow]

What frame rate is your Project set to?

When you copy and pasted and found gaps, that seems like it’s a mismatch of frame rates. This happens when copying and pasting timelines edited in 25FPS and pasted in to 23.98 FPS.

Is the footage really 59.94p? I would think that if this is old console (TV) footage you’d need 29.97p.

The solution of washing the media through Compressor is definitely a good step, but I’m not sure if you need 59.94p footage. 29.97p will be perfectly fine, and more accurate.

[Chris Alaimo]

The project is set to 59.94. Most old game consoles output ~60fps. As I mentioned earlier, the footage in question has a framerate of 59.88, as that’s what that particular game runs at.

If I lowered the framerate of those clips to 30, I would lose the transparency effects used by most games, and the footage would look weird.

[Jeremy Garchow]

[Chris Alaimo] “Most old game consoles output ~60fps”

60 FIELDS per second, not frames. It’s 30 frames per second.

NTSC video is 60 fields or 30 frames. NTSC is not 60 frames per second.

[Chris Alaimo] “As I mentioned earlier, the footage in question has a framerate of 59.88, as that’s what that particular game runs at. “

But you ran it though a scalar and captured it with what kind of capture device? If you captured 720p, you will have true 60p. If you captured much else, you’d have wither NTSC or 1080 HD. Some 1080 HD can capture at 60p, but not much and would require dual link (or 3G) HDSDI. What was the scalar outputting?

[Chris Alaimo]

Sorry, I guess I wasn’t clear about the nature of the video signal that I’m working with. I’m actually not capturing NTSC video, it’s 15khz analog RGB, and is progressive scan at 60fps, not interlaced at 30. So this is the video signal as it comes out of the graphics chip(s) in the system, but before it goes into the video encoder chip to be turned into NTSC/PAL/ETC. Almost all game systems from the mid 80’s to the mid 90’s output a 15khz 240p RGB signal since both Japanese and European TVs are designed to accept it through a SCART connection. So even though, for example, PAL is the video standard in the UK, people weren’t displaying their games that way because they were set up for RGB. Here in the states, 99.9999999% of consumer TVs do not have RGB inputs, and so we played our games using NTSC-encoded video through RF, composite, or s-video.

I run it through a device that line multiplies the signal, but does nothing to the framerate. I called it an upsaler, but that’s really not accurate because it isn’t scaling, just multiplying (I do also own an upscaler, that takes video signals and scales them to 720p or 1080p). The particular game that I was capturing runs at an oddball resolution of 336×224, at (almost) 60fps progressive. I line multiply it 4x, so I get an output resolution of 1344×896, which is what my capture device captures it at, at a detected framerate of 59.88.

Here’s a little video I shot for Twitter last week that clearly shows the resolution and framerate on the capture screen:
https://twitter.com/CGQuarterly/status/1019042322049204226

The monitor has 15khz RGB inputs on the back, so that’s what’s being displayed on the CRT screen. The video signal comes back out of that monitor, into the line multiplier, and then into my capture device.

Finally got the OSSC happy with R-Type, which it turns out runs at an oddball resolution. Time to re-record all of the gameplay footage while I rock out. pic.twitter.com/oPhrJ4gxFt

— Classic Gaming Quarterly (@CGQuarterly) July 17, 2018

[Jeremy Garchow]

[Chris Alaimo] “The video signal comes back out of that monitor, into the line multiplier, and then into my capture device.”

That video signal is just passing ‘NTSC’ video and audio, as evidenced by the CRT TV.

RGB is color, and has nothing to do with frame rate or “resolution” of which were lines in TV, including old console games. RGB simply carries color differently than, say, composite or s-video. SCART was a connector that allowed all of this to be bundled in to one cable, and didn’t define any resolution, only signal (audio/video/etc).

15KHz is only SD. If you are saying 240p, that’s just 480i doubled, meaning it’s writing each line twice (at 30fps). It’s still interlaced, or more accurately Progressive segmented frames (Psf), and you are getting nothing more than NTSC/PAL video (at best) out of that rig.

The scalar, or whatever that is, is quadrupling the lines is obviously amending and converting the signal from analog to digital, and doesn’t stick to “tv” standards because it doesn’t have to since it’s used for computers which are, for the most part, resolution and frame rate agnostic. It might be sending “~60fps” to the computer, but it’s certainly not receiving a 60p analog video input.

You would probably be able to rewrite the frame rate in those video files and be just fine (Cinema Tools used to do it, but that is long gone). If you could tell your capture software to write the header at 59.94 (or 60.0), those files would also work better in FCPX. Perhaps there’s a way to tell the software to lock the frame rate to a more standard frame rate? Or try capturing in a more standard “tv friendly” format?

[Chris Alaimo]

This is not an NTSC video signal. The video signal is not 480i doubled, and it is not interlaced. It is a 240p signal running at 60 frames per second. You are correct that RGB is color, and in this case it refers to the fact that the separate red, green, and blue video signals are carryed over separate lines in the video cable. It is colloquially referred to in the retrogaming/retrocomputing communities as “RGB video” but its proper name is “RGB analog component video”, not to be confused with Y/Pb/Pr component, which is much different. It is similar to VGA, except that it syncs at 15khz and it has a single combined sync signal instead of separate h-sync and v-cync. It is the exact same type of video signal that the Commodore Amiga and Apple IIGS computers put out, which requires a special 15khz RGB display, much like the display that I have here.

https://en.wikipedia.org/wiki/Component_video#RGB_analog_component_video

This is not a “CRT TV”. It is a 15khz RGB monitor. There is no way for me to pass this signal to a consumer TV without making modifications to the TV to allow it to accept an RGB signal. There are 4 connections on the back of my monitor, one for each color and one for the composite sync line, which a “CRT TV” does not have. The monitor has an output for each input, and this is how I am able to pass the signal on to my line doubler.