performance differences of a .r3d Prores transcode versus one from an HDV source

[Paul Ramsbottom]

Here's an oddity.

I'm testing a marginally suitable FCP system. If I transcode on capture some 1080 HDV footage to Prores422, it pays back fine. If I try and play a .r3d originated Prores422 file, I see some choppiness on playback.

Rather strange, or to be expected?

 

[Fredrik Harreschou]

ProRes is a variable bit rate codec, where the amount of compression varies based on frame rate, interframe differences and motion interpolation. Is the motion very different in the clips you are testing with? The increased latitude of the R3D file format itself *could* make a difference, but I have no real experience to conclude with this.

On the other hand, do NOT underestimate computer gremlins. They never sleep...

 

[Noah Kadner]

Well for one thing it's probably 2K vs. 1080p and most likely the datarate is much higher with the R3D derived footage than something coming from HDV which starts at a very low 25-35Mbit. If you find your drives overwhelmed by ProRes' datarates- upgrade to a RAID.

Noah

 

[Fredrik Harreschou]

He is transcoding both clips to ProRes. The inherent compression of HDV doesn't really apply to his issue.

EDIT: Heh heh, you completely changed your post in less than two minutes...

 

[Alexander Ibrahim]

Well for one thing it's probably 2K vs. 1080p and most likely the datarate is much higher with the R3D derived footage than something coming from HDV which starts at a very low 25-35Mbit. If you find your drives overwhelmed by ProRes' datarates- upgrade to a RAID.

Noah

Noah;

You are off base here.

A ProRes file will have roughly the same data rate at a given resolution and frame rate regardless of the source material. It doesn't matter if it was generated from an .r3d, HDV or any other source.

Both ProRes 422 and ProRes 422HQ play fine from commodity external firewire drives.

The bit about different resolutions (2K vs 1080p) is more relevant- but it isn't data rate that might prove to be a problem.

The ProRes decoders are optimized for how most people will use them: 1080p & 720p. SD resolutions and 2K are not optimized. I don't know why, I have no special insight or access.

Screens are most commonly 1920x1200... in other words they can play unscaled 1080p.

2K footage might assault both these weaknesses. It has slightly worse performance due to being scaled AND due to ProRes's computational inefficiencies at the 2K frame size.

I am looking at processor utilization vs. Megapixels per second. Its an observation.

Its also an observation that applies almost entirely to "bubble" systems. That is systems just barely qualified for 1080p ProRes editorial. My PowerMac Dual G5 2.7GHz is just such a system, and I see similar issues regularly if I am not careful.

Somewhat newer systems have less trouble. I've never had an issue with any Mac Pro system and ProRes footage. Also late model Core 2 Macbook Pros behave better than earlier units.

So... to answer Paul, you are not alone. If the footage is 2K, try rendering it out to 1920 horizontal and see if the issues go away.

If you are seeing this is in all 1920 footage on a 1920 display, then you may simply need an upgrade- probably to your video card or processor, although in some bubble cases RAM upgrades help, if you have less than 4GB total on your system.

 

[Fredrik Harreschou]

Where do you get the 2K vs 1080 part from? The OP never mentioned this...?

 

[Alexander Ibrahim]

Where do you get the 2K vs 1080 part from? The OP never mentioned this...?

Actually the OP never mentioned resolutions {edit} of the ProRes files {/edit} at all.

So, I guessed.

I based my guess on what I've seen from clients in the edit suite and what I've seen others do in the field with HDV and RED.

Its still a guess.

The HDV stuff is almost certainly 1440x1080i or PsF, up-converted to ProRes 1920x1080p. The RED stuff was probably shot at 4k and down-converted to 2k.

So, all I can do is report some of the instances where I've seen similar problems on my systems.

There is the possibility that the HDV was converted to ProRes at 1440x1080, and of course the possibility that the RED footage is any of a variety of resolutions.

If any of these turn out to be the case, there is a good chance, in my opinion, that the causation of his issues is related to what I experienced, and can be similarly determined.

Well, that's my reasoning anyway. Do you find that I've made a mistake?

 

[Uli Plank]

Is the HDV source progressive ?

 

[MichaelP]

Make sure to scale your R3D to 1920x1080 to ensure ~same ProRes file size after transcode.

Michael

 

[Noah Kadner]

Ha- lighten up, Alexander I'm not 'off base' here any more than I'm as in the dark as you are about what's really going on. We need more information from the original poster. It's easy enough to create ProRes files with very different data rates depending on their sources and how they are being encoded. Perhaps one clip is ProRes and the other is ProRes HQ. That plus likely 1440x1080 HDV vs. 2K frame size could easily account for the differences in data rates. And ultimately, that's how it goes anyway. You either have a machine with good enough specs to handle ProRes at 2K from RED playback or you need to upgrade. Let's have some more details from the op please...

Noah

 

[Paul Ramsbottom]

Thanks guys

Thanks guys

I really appreciate the considered feedback and apologies for being incomplete with my first post and then being slow to follow-up.

The HDV originated clip was shot at 1080/60i. It's actually a very long clip with a variety of motion and has audio. All of it plays without issue.

The Quicktime properties of the HDV ProRes422 transcode show it to be 1440x1080 (1920x1080) with pixel and actual sizes of 1920x1080. A framerate of 29.97 and a 126.39 mbits/s data rate.

The .r3d was scaled to 1920x1080 (not 2K as some folks had speculated) and has a framerate of 23.98 and a datarate of 102.73. I haven't done the arithmetic sitting here but I'm guessing the lower datarate is because of the 23.98 framerate and also because this clip has no audio.

Like Alexander, I'm editing this on a Dual 2.7ghz G5. I use a dedicated XServe RAID for storage. The first stupid thing I realized is that I had dropped this 23.98 clip into a 29.97 HDV timeline. I know that shouldn't matter with FCP 6.0.6 but apparently it does because changing my settings to a 1920x1080 23.98 HDV project definitely helped some (from what I have just read, changing them to an uncompressed 1920x1080 23.98 project is the way to go).

I also had a long overdue hardware upgrade which I finally got around to this weekend, and now have 8GB of ECC RAM installed (up from 6GB, and a mix of ECC and non-ECC chips) and a new GPU, the Ati Radeon X800XT which is the fastest AGP card that Matrox has qualified with the MXO box I use with my 23 inch ACD for grading.

With all of that done, and with a reset of my fiber channel controllers (one of them has been giving me grief) and a restart, I have now been able to get this clip playing back almost without interruption. There is one part right at the very end (where someone on screen moves very quickly) where I see some jerkiness but that's almost certainly due to the 23.98P framerate. Every once in a while I see some dropped frames, which shouldn't be happening. I also notice much better performance when I have all the files on my RAID.

So... to some extent I have solved this, although I naturally remain curious about why my HDV-originated ProRes plays like butter, with all those system deficiencies in place. It would be nice to know that I had a few millimeters of headroom on this 'bubble' system. Also wondering about the result if that choppy file had audio as well.

Oh... the life of a budget digital film-maker. It would be nice to think that a studio full of the very latest gear would alleviate all these little niggles but I think we all know that won't be the case

Thanks again..

Paul.

www.abeofilms.com

 

[Uli Plank]

While FCP can handle different codecs and sizes in the timeline, it doesn't handle differen framerates well.