Capturing PAL video via QuickTime

Question

Level 1

65 points

Capturing PAL video via QuickTime

When I record from my videocamera using QuickTime, I cannot get it to record at full size. Even "device native" is at reduced size. The frame size is 384x288 but I need it at 720x576. This is a PAL video camera.

Normally I would use FinalCut to capture the media, however there are some weird tape errors with this particular tape, and it keeps stopping recording. QuickTime allows me to keep capturing (it ignores the errors) but it won't give me the same frame size

Dual 2.5ghz G5, Mac OS X (10.4.8), 4gb RAM, 250gb HD

Posted on Nov 1, 2006 1:45 AM

Reply

Answer 1

Jon Walker

Level 6

19,489 points

Nov 1, 2006 4:56 AM in response to istara

Even "device native" is at reduced size. The frame size is 384x288 but I need it at 720x576. This is a PAL video camera.

Does sound strange. However, would point out that PAL would actually be 768x576/720x576 (rectanguar/square) pixels, so it appears you are actually be getting the "quarter" frame here. Would normally expect this with a capture and conversion to either MPEG-4 or H.264 in QT Pro but not using "Dvice native." Could even be a bug that recognizes PAL but only partially supports it. Unfortunately, as I don't have a PAL device/source, I can't really try to duplicate your workflow.

Since QT Pro capture frame rate is "iffy" (i.e., dependent on CPU power for the capturing platform), I normally recommed using an alternate dedicated utility -- Vidi (free) -- where consistency and stability are required. Not sure if it ignores dropped frames (which I assume may be your problem), but don't recollect having this problem with old tapes known to cause problems with Apple editor captures. You might give it a try and see if it solves both of your problems here.

Reply

Answer 2

istara Author

Level 1

65 points

Nov 1, 2006 5:25 AM in response to Jon Walker

Wow - thank you so much for that Vidi link - it works beautifully so far, hopefully it will ignore dropped frames. For some reason Final Cut will not work with .dv files properly (they are bright red on the timeline, meaning that they won't even preview before rendering). Thanks for that tip on framerate.

However a brilliant (also free) app called MPEG StreamClip does the final conversion for me, it is just fantastic. Unlike QuickTime you can save Presets in it, so I have one.

Thanks for the pixel advice - it seems that QT is using square pixels. I'm also getting very strange results with its captured files when I try to increase their size to 200% (making them perfect DV PAL size) in Final Cut Pro.

Before increasing, they are quarter-sized in the Canvas window, and play at quarter size.

After increasing, they are full size in the Canvas window when the timeline cursor is resting over them. When played, they show up as eight times size in the Canvas! I simply cannot figure out what is going on, I have never seen anything like it. My workaround here is using MPEG Streamclip to pre-convert.

I think that I will use Vidi from now on though, at least until my camera is fixed and stops putting weird, invisble errors onto (brand new) tapes.

"old tapes known to cause problems with Apple editor captures"

Thing is, this was a brand new tape. I wish there was a workaround for the Final Cut issue. I've tried to set it to ignore errors and carry on recording, but it won't.

Reply

Answer 3

istara Author

Level 1

65 points

Nov 1, 2006 5:41 AM in response to istara

EDIT: Having tested with Vidi, it appears to record using square pixels, interlaced and as .dv.

When I convert this using MPEG Streamclip to QuickTime in the exact PAL DV specifications that FinalCut captures at (and therefore doesn't need to render) the result is, as far as I can tell, perfect. ie: identical to a clip captured by Final Cut.

It is much, much better than recording with QuickTime and converting those clips through MPEG Streamclip. That produced a good quality but significantly less crisp image.

Reply

Answer 4

Jon Walker

Level 6

19,489 points

Nov 1, 2006 6:43 AM in response to istara

Having tested with Vidi, it appears to record using square pixels, interlaced and as .dv.

Square/rectangular pixels is a characteristic of the display device -- not data. Vidi sets the "current display" setting for the data to display on a square pixel monitor at the correct aspect ratio. Editors work nativley at the rectancular equivalent of the correct aspect ratio as it will be handled on a TV. If you want rectangular pixel eqivalents, simply reset horizontal scaling to 720. Interlaced is the default setting in Vidi. Use the de-interlace option if that is what you want. As for use of DV compression format, that should be the native format for your device unless you are using an HD camera and not downconverting in the camera.

It is much, much better than recording with QuickTime and converting those clips through MPEG Streamclip. That produced a good quality but significantly less crisp image.

Since original data was quarter frame, you were merely "blowing up/enlarging" each pixel to 4 times its normal size while not actually increasing "image resolution." Basically, it simply makes for a "pixelated" or "fuzzy" image since no new data is actually added.

Reply

Answer 5

istara Author

Level 1

65 points

Nov 1, 2006 6:48 AM in response to Jon Walker

"Since original data was quarter frame, you were merely "blowing up/enlarging" each pixel to 4 times its normal size"

Interestingly, that quarter size video was the same data rate as the full size video that QuickTime captures.

"As for use of DV compression format, that should be the native format for your device"

The device is a Sony PD150/PD170 camera, using DVCam tapes. So I am guessing that when Final Cut captures, it is converting that to QuickTime as it captures?

Reply

Answer 6

Jon Walker

Level 6

19,489 points

Nov 1, 2006 8:20 AM in response to istara

Interestingly, that quarter size video was the same data rate as the full size video that QuickTime captures.

DV compression video data rates are basically fixed at 25 Mbps for DV (DV25) and DVCPRO25 while DVCPRO50 is twice that rate. Total data rates vary by actual audio/video content and audio bit length used (usually 16-bit/48.0 KHz).

The device is a Sony PD150/PD170 camera, using DVCam tapes. So I am guessing that when Final Cut captures, it is converting that to QuickTime as it captures?

Nearly all editors work natively in DV format since it allows "frame" level editing. Main problem routinely encountered is capturing in iMovie (or iMovie file compatible application) and then importing the file to FCE/FCP. (This requires re-rendering of the audio.) QT format may require this strategy but since it is not part of my normal workflow, I don't know for sure. In addition, the importation of other QT compatible formats automatically invokes a conversion of the source file to the DV format. HDV is additionally compressed with MPEG in order to lower the typical 100-120 video data rate to more compatible DV/FireWire data rates for capture by your editor (or user set to to downconvert to DV during export).

Reply

Answer 7

istara Author

Level 1

65 points

Nov 1, 2006 8:40 AM in response to Jon Walker

"DV compression video data rates are basically fixed at 25 Mbps for DV (DV25) and DVCPRO25 while DVCPRO50 is twice that rate."

Do I have something wrong in my settings then? Because clips captured by Final Cut (as DV-PAL) have a Data Rate of 3.6 MB/sec.

I should be upgrading to FCP 5 in the near future, which I am hoping will solve various glitches. And also in the near future we are probably upgrading to HD, so that will be a whole new ballgame to get to grips with. I'm hoping my G5 will cope with it.

Reply

Answer 8

Jon Walker

Level 6

19,489 points

Nov 1, 2006 9:13 AM in response to istara

Do I have something wrong in my settings then? Because clips captured by Final Cut (as DV-PAL) have a Data Rate of 3.6 MB/sec.

DV data rates are "device controlled." There are no user "data rate settings" for capture. Either you are referring to the exporting of media here or you are referring to a compression format other than DV.

EDIT: Oops, you said 3.6 MB/sec. Believe that equates to about 28.8 Mbps for combined audio and video. So this does look about right. Sorry, we were using different scales here -- you in bytes (big "B") and I in bits (small "b").

Reply

Answer 9

istara Author

Level 1

65 points

Nov 1, 2006 9:44 AM in response to Jon Walker

Oops yes - bytes and bits - sorry about that!

Though I was starting to imagine increasing my captured video at about eight times the quality (yeah right!)

Reply