Quicktime DVCProHD in Edius?

[SRsupport]

Brandon,

There is something weird going on.

EDIUS does not always open the file.

One time it does and another it comes up with a warning that it can't open it.

I had another test file which I tried once I got that warning and never tried again.
Today I got a warning but after opening it a few times it finally loaded.

I stand corrected the files do open in EDIUS, but not consistantly at least on my machine.



Strange

[alpi69]

I use 4.54 broadcast.
Maybe it depends what rendercodec is used. I will do some test tomorrow to see if I can open this in Edius.

BTW, I can´t use the original P2, because the FCP editor simply imported in FCP and then formatted the card. FCP of course made these movs out of it.

[STORMDAVE]

DVCPROHD is always included with FCP...so there is just one type of DVCPROHD codec under OSX.

[THoff]

True, but there are at least two fairly common ways of producing DVCProHD QuickTime files: using FCP/FCS, and using the Focus Enhancements FS-100 DTE device.

It is conceivable that the QuickTime wrappers that the FS-100 produces are subtly different from what QuickTime itself outputs, so I think it is important to note the workflow if we are trying to track down a potential problem.

[Jerry]

QT for Windows will not play DVCPRO HD QT files.

EDIUS Broadcast (must be Broadcast), however, should be able to load them - it magically unwraps the QT and uses the Canopus HD codec for decoding.

Saw the color bars, at least on my machine (EDIUS Broadcast v4.54)

Ok, I got it to open in Broadcast....provided that the file was only 5 frames of Color Bars. Opened every time I tried. Preset was 1280x1080 DVCPROHD.

[THoff]

OK, I downloaded the file and had no problems whatsoever using it in Edius. For what it's worth, I'm using QuickTime Pro V7.4.

[pjsssss]

I got the exact same finding as Jerry

[STORMDAVE]

Sweet!

One downside is that (Sorry to repeat) again, there is the QT issue with Edius, the luminance/color shift...maybe it doesn't touch the DVCPROHD files, not sure.

[pjsssss]

Dave, I used your test footage and then dropped some SMPTE Bars created within Edius and I could see no difference at all with the naked eye. I did not measure them.

[STORMDAVE]

Dave, I used your test footage and then dropped some SMPTE Bars created within Edius and I could see no difference at all with the anked eye. I did not measure them.

I'm not at my machine right now, but try putting the Mov file on track one then the SMPTE Bar on the top...open up the scopes and turn off and turn on the top track to see if anything changes in the scopes. If nothing changes, then my guess was right, EDIUS just unwraps these files without going through the QT engine...so great stuff for people who need this unadvertised feature! :)

By the way, QuickTime 7.4 is horrible, I hope you guys stay away from it until Apple releases a new version.

[pjsssss]

OK let me retract my statement. The scopes do show a slight change and after really looking at the areas it indicates, I can see a slight change visually.

[STORMDAVE]

OK let me retract my statement. The scopes do show a slight change and after really looking at the areas it indicates, I can see a slight change visually.

There we go :)

I forgot to post this today, but here's the TGA that I saved to my laptop for testing purposes...it is an exact extract from the FCP timeline, so you can compare it in EDIUS...no need for the EDIUS SMTPE, so we can rule out all the possibilities.

[THoff]

Blame QuickTime -- Apple handles the gamma inconsistently:

http://docs.info.apple.com/article.html?artnum=93794

[STORMDAVE]

Blame QuickTime -- Apple handles the gamma inconsistently:

http://docs.info.apple.com/article.html?artnum=93794

I know about the QT issues...but in apps such as AE, the resulting renders are fine if you use the right codec.

[SRsupport]

Yes but EDIUS is using the quicktime engine for qt. So the shift is not the fault of EDIUS.
(that is as far as my info goes)