[Robert Hutchings]

Excellent Kevin.

CatDV is a great product. Keep up the good work.

Hope you guys continue to monitor this forum.

Who knew I’d get the product manager on the line!

Robert Hutchings
TPT Twin Cities Public Television

[Robert Hutchings]

Thanks Kevin for taking the time with a detailed answer. Very helpful.

We will be using the CatDV worker node to help automate basic entry into CatDV. Your answer has convinced me to let the worker node take care of creation of the proxies also.

We will be putting the full res media from each reel acquired from the field into a separate folder. So media from reel 1001 will go into a folder called 1001 on our server. We have set our XDCams to number the files on each reel not with the standard Cxxxxx numbering system that repeats file names from reel to reel but with the FREE numbering system that will number files sequentially starting at 00000 up to 99,999. The numbers will bridge over reel changes IOW they won’t restart at 00001 every time there is a reel change.

When we bring the files in using the Sony XDCam Transfer software, the software will add the reel number to the file title. First file will be 1001_00001, next file on that reel will be 1001_00002 etc etc. First file on reel 1002 might end up being called 1002_00086. Next file from that reel will be called 1002_00087. So each file will get a discrete name/number bridging over multiple reels.

A few questions and to confirm the use of the worker node for creation of Proxies:

Can we indeed control how these proxies are named by the worker node?
Obviously we would like them named exactly the same as the high res file so we can use them for offline purposes outside of CatDV using Final Cut Pro.

I assume we would also have control over the location of these proxies ie. we can tell the worker node where to put the proxies? Possibly in a single location if they have unique file names.

Are these proxies then the proxies that are linked to the CatDV catalogue of the full res media?

Thanks.

Robert Hutchings
TPT Twin Cities Public Television

[Robert Hutchings]

Thanks all, for taking the time to respond.

Our tests confirm that the 35Mb/sec is a peak rate and not an average, in that the data rate never spikes above 35Mb/sec (without audio). Data Rate readings for various XDCamEX clips in Final Cut are consistently 4.3 MB/sec with two channel audio and 4.5 MB/sec with four channels of audio no matter what the content.

An exception to this is a clip of black video that we generated that predictably came through with a very low data rate. This is a VBR codec after all. Interestingly and also predictably a clip of black in XDCamHD 422 50Mb/sec, which is CBR, came through at a full 7.1 MB/sec.

We also were able to lower the data rate of the XDCamEX codec by greatly blurring via a blur filter all the detail out of what was a highly detailed still image. This blurred clip weighed in at 2.6 MB/sec.

As part of the test, we also edited another clip together going frame by frame to ensure there was a radical change ie. each frame was a unique frame radically different than the preceding frame. This clip came in, true to specs, at the 35Mb/sec.

As to comparing 35Mb vs 50Mb: Our tests show very little difference between the two. I suspect the difference would become more apparent with rapid motion etc. XDCamHD 422 at 50Mb noticeably outperforms HDCam. I believe this is most significantly due to the scaling to 1440 of HDCam as opposed to the full raster XDCamHD 422 where no scaling is necessary. HDCam really suffers from this scaling and alternately I assume XDCamEX benefits greatly from not having to change frame size.

[Robert Hutchings]

I am also trying to get HD captions on Line 9 to pass through. Mapping line 9 to line 1 of clip video. Can’t seem to find a formula that works. Line 9 seems to get transfered to line 1 video on the ingest but not going back to line 9 on the export to an XDCam deck. Any tricks and helpful hints to make this work would be appreciated. I am doing no rendering, simply splicing and dicing some things together. Being able to do this without destroying the captions is high priority for broadcasters these days.

Robert Hutchings
Director/editor
Twin Cities Public Television

[Robert Hutchings]

Yes. A500.

Our HDCam decks do recognize RP188 embedded timecode.

[Robert Hutchings]

I tested directly out of our Varicam via HD-SDI and the AJA utility read the embedded timecode like a champ.

But no dice on an SDI delivered SD signal looped thru a digibeta deck.

Thanks to both of you for the education and suggested reading materials.

Robert Hutchings
Director/editor
Twin Cities Public Television

[Robert Hutchings]

Thanks Matt. Sync is good on the footage I have seen so far from the 900. I just wanted to make sure there was no VTR menu item that might affect this. Yesterday I did an exhaustive read of the manual and was unable to find mention of such. So I assume Panasonic has set audio to be dead on right out of the box.

[Robert Hutchings]

OK just discovered the reason for the render time discrepancy. Coming out of the FCP and sending the clip to Motion. The motion project opens up defaulted to 8 bit in the project Properties. Command-J. Set bit depth to 16 bit and the render times out of Motion match the ProRes (HQ) render times on the FCP time line.

[Robert Hutchings]

OK I realize I

[Robert Hutchings]

Thank You.