John Heagy
Forum Replies Created
-
[Walter Soyka] “I drive a manual, but I like to ironically refer to it as a “standard.””
Nice!
[Walter Soyka] “I rely on tools from a broader ecosystem, I find not just reference movies, but QuickTime as a whole to be quite a bit less appealing.”
Understood, and I’d be all for a ProRes.mxf as there is a mxf ref.mov equivalent (MXF OP1b) that I would embrace. I don’t know of any apps that support MXF OP1b.
From speaking to developers at NAB is seems Apple is making clear which QT API calls are going away, indicating to me that the entire API is not going away. Of all the processes that would suffer from calling a 32 bit QT API the creation of a 64k QT ref.mov would not be one of them. Hint… Hint.. Adobe!
John
-
No worries.
I’m a soldier in what seems to be a loosing battle to keep ref.mov supported. I’m quick to defend or correct the many misconceptions that plaque it.
Seems ref.mov may be heading down the same road as manual transmissions are in cars.
It’s something Apple has deemed too difficult to use and therefore must be purged despite it’s usefulness to people who do understand and benefit from it.
Next apple will remove or hide Terminal the way they did ~/Library
John
-
[Vince Becquiot] “You could use Animation or PNG, or even uncompressed,”
Uncompressed yes… animation or PNG no, because that would force a YUV to RGB color space conversion.
John
-
[Walter Soyka] “However, I think that QuickTime reference movies are 8-bit, so 10-bit material (or higher) in a reference movie would be truncated by QuickTime’s decoder as it was passed to Premiere.”
Most all our ProRes recordings, and FCP7 exports, are done using ref.mov and I can assure you they all retain their 10bit goodness. Reference movie exports are “lossless” but it really doesn’t make sense to think of it that way. It’s more like a an alias/link tho changes can be made in the wrapper that affect scale.
We use ref.mov extensively. It’s an advanced concept for advanced workflows and needs a solid shared environment to really take advantage of it… and we do.
No Adobe product has ever exported ref.mov so I don’t expect it ever in Premiere. A real shame really.
Avid still supports it.
John
-
[Chris Borjis] “Reference exports can
cause you major pain later.”Only if one doesn’t understand them.
It’s a powerful tool that can speed exports and save space.
It sounds like the ref movie worked. A self contained will be no better.
John
-
[Maurice Coombs] “Any thoughts on using DVCPROHD?”
m2t is an MPEG2 format so I’m gonna guess it’s 1440×1080 in which case you do not want to go with DVCProHD as it’s 1280×1080.
ProRes supports 1440×1080. Consider rewrapping as a standard .mpg via MPEG Streamclip or .mov via ClipWrap.
John
-
Yes I understand that and we run all our 4 channel files thru an episode job that adds another 4 just so we can play them back on a KiPro. We would prefer not to do that. Please add 4 channel playback where the file only has 4 channels.
-
[Jeremy Garchow] “Our SAN doesn’t restrict without using a system called ProjectStore”
I’d guess your SAN looks exactly like a internal/external drive to the OS.
We are using Xsan but NFS shares act the same as far as FCPX is concerned.
-
[Oliver Peters] “The important media factor is the bandwidth of the SAN at the server location. That’s the same as if you had the remote clients living on shared storage at the facility without Anywhere. “
That’s what I was talking about. Now tiny proxy streams needs full bandwidth from the SAN for every remote request. I’d prefer to keep offline and online storage independent. I’d encode to a high quality proxy and then let Anywhere stream tiny versions of that.
-
One thing not mentioned is the stress on storage streaming any size format derived in realtime from the high rez will have.
In typical offline online workflows there are more offline stations than online. That’s the case with us certainly. Online storage is sized based on the final conform needs. Now it has to accommodate the many offline streams. Since these are rendered in real time by Mercury, that means full high rez realtime bandwidth is required for even the smallest format delivered.
I wouldn’t consider Anywhere using the high rez but instead using an encoded offline format like ProRes proxy. I’d then have Anywhere deliver tiny versions to remote stations rendered in realtime from the PR proxy.
John