[Andrew Kimery]

[Bill Davis] “The Pinterest lawyers had to back off and revise.

Be interesting to see if these folks have to do the same.

We’re entering the era where once you post anything, it’s instantly available to everyone – and the issues of who “creates” every part of every post creates a monstrous legal minefield that nobody has come even close to figuring out yet.

We’re dealing with 21st century behavior using rules created largely with 19th century legal thinking.

I don’t know Bill, I guess when I look at this I don’t see that complex of a situation. I don’t think the company behind WeVideo should automatically get any rights to the content that’s created with their software just like I don’t think Adobe should automatically get the rights to something that’s created using AE or PS, for example.

Now, all the people that contribute to the project, sure, that’s a potential problem but I guess I don’t see that as much different of a problem than if a bunch of people collaborated on a project in person (w/o signing any contracts or agreements) and then started arguing over who owned what.

Maybe the person that initially starts the project setups up the rights structure (creative commons, exclusive ownership, etc.,) and then everyone who comes on board has to acknowledged and agree to the rights before they are allowed access to the project?

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

When I’ve run into this problem it’s almost always one of four things.

1. ‘stuck’ Render files (FCP gets confused and plays back the wrong render file). Solution, empty your Render Files folder to fix it.

2. Corrupt Timeline. Solution, create a new Timeline and copy and paste you work from old timeline into new one.

3. Corrupt Project. Solution, create a new FCP project and copy and paste everything from the old to the new.

4. Corrupt media file. Solution, re-ingest the offending media file. Sometimes the metadata in the QT is bad and everything appears normal until you try and export the file from FCP.

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

I’m glad you decided to do away w/the shitty post ’cause I don’t really see the reason to write one.

Basically, I agree w/everything you said. In a situation where there is an unlimited budget, no deadline and no technological limitations there shouldn’t be a reason to work at anything less than uncompressed 4:4:4 for everything.

I’ve never had a chance to work on a project like that so I’ve got to find ways to do the best I can given the budget, time and tech limitations of whatever job I’m working with. What I find a bit bewildering is the attitude you and David are taking towards me w/o ever trying to learn more about the situation. It’s like saying I made an inferior choice by choosing a bike for particular job instead of a car w/o everything asking about the details of the job and why I thought a bike was a better choice.

[Rafael Amador] ” Not even Apple recommend it for post (see the Prores White Paper). LT is not ideal for stuff that will undergo further heavy processes.”

From page 5 of the PR White Paper (which I am familiar with:
“Apple ProRes 422 (LT): Like Apple ProRes 422 (HQ) and Apple ProRes 422, the new Apple ProRes 422 (LT) codec supports full-width 10-bit video sequences, but at a target data rate even lower than these siblings. Apple ProRes 422 (LT) weighs in at 100 Mbps or less, depending on the particular video format. It balances incredible image quality with small file sizes, and is perfect for digital broadcast environments where storage capacity and bandwidth are often at a premium.
Apple ProRes 422 (LT) is ideal for live multi-camera and on-location productions where large amounts of footage are acquired to disk. The low data rate of Apple ProRes 422 (LT) also makes it an excellent choice for transcoding complex camera codecs like AVCHD.”

Every thing Apple says PR LT is good for describes part of the workflow at the last job I had. A lot of live event coverage with same day edits where getting your coverage up before your competitors is paramount. Workflows where getting a 10min export down to 7min is a big deal, where TBs of footage are being generated (at ProRes LT settings) on location and external HDDs are shuttling between locations so that everything ends up in the centralized storage ASAP.

I agree that PR LT isn’t good for heavy processing in post and even stated so earlier in this thread. Sure, if you are doing a lot of manipulation in post PR LT isn’t going to hold up but if you are doing little to no manipulation is stays together just fine in my experience. That doesn’t mean you shouldn’t test it in your own workflows, but in the workflow I tested it in it worked just fine. It exceed the quality of the previous workflow (DVCPro HD based) while not exceeding the storage and time limitations that were beyond our control.

I would love it too if someone regularly did comprehensive codec round ups. And not just codec roundups but compared different NLEs and compression software to see how they each handled a variety of codecs in common transcoding scenarios.

Like I said before, I always strive to maintain the highest quality I can given the limitations of the job. I’ve worked on prime time shows where no one batted an eye at renting two 40TB Avid ISIS’s for redundancy and I’ve worked on low budget documentaries where post was held together by superglue and bailing wire. It both cases I helped setup and/or maintain the highest quality possible given the situation.

In a perfect world I’d maintain a perfect workflow but we don’t live in a perfect world. 😉

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

If someone’s looking at a 10th gen copy of this work it’s going to be derived from the HDCAM deliverable and I’d say that the HDCAM tape (1440×1080, 3:1:1 8-bit, interlaced) is a already a step down from the source ProRes LT footage (full raster, 4:2:2, 10-bit, progressive). And for pieces where a master QT exists, a 100th gen copy of the file is going to look exactly like the master QT (assuming no data corruption happens during one of the copies). It’s not like BetaSP where every analog step away from the master tape is a notable step down in quality. Sure, if the generation pipeline looks something like QT Master->HDCAM SR->HDCAM->DVCProHD->Blu-ray->Torrent->YouTube->DVD then the end product will look far worse than the Master. But at that point it doesn’t matter if the Master was PR LT or PR Regular.

We all have practical limitations, like budgets, and the trick is to do the best you can with what you have (I hear 5k RAW is sweet, but how many have the means to handle it cradle to grave?). At the old gig there wasn’t a budget to build two new 100TB Xsans (one mirroring the other like they have now) so the option was either staying in DVCPro HD or moving to ProRes LT (better quality at about the same file size). I guess turning away work would’ve been a way to decrease our data footprint and allow us to use ProRes regular but that just sounds like a bad idea to me. 😉

I even walked the exact same footage in ProRes regular and ProRes LT through our post cycle (editing, rendering, exporting, tape layoff, web compression, etc.,) during the evaluation process and saw no difference between the two in our workflow. In other situations the results might not be the same, but in our workflow they were. Trying to get a 6 figure corporate expenditure approved for little to no gain just didn’t seem worth it. Using those funds to buy a bunch of Ki Pros so we didn’t have to use Cineform or XDCAM EX/HD for field capture, now that was money well spent. Sure, if someone is being stingy over a few hundred, or even a couple thousand bucks that can be short sighted, but in the situation I’m talking about it would’ve been hundreds of thousands of dollars to sufficiently upgrade the storage.

To further derail this thread, why do you keep equating PR LT w/tossing away half your data (especially when the sources being discussed are of lesser quality than PR LT)? PR LT, like PR regular, is full raster 10-bit, 4:2:2 it’s just about 30% smaller in data rate. Sure, 30% could be a difference maker but when the source footage is 4:2:0, 8-bit and nearly 1/4th the data rate of PR LT I’m not immediately convinced that bigger is better. That’s not to say I wouldn’t choose regular PR just to be safe (I cut a DV-sourced doc in a PR timeline and did PR exports) but there’s certainly a point of diminishing returns. I mean, I doubt you work exclusively in Uncompressed even though, on paper, it should provide a better quality master than any flavor of ProRes or DNxHD. 😉

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

Sascha,

Why not pick some visually intensive segments of the concert (like where there are a lot of fast lighting changes) and do some tests with different settings to see if there is a difference or not? Sometimes different settings result in a visual loss of info and sometimes they result in just an ‘on paper’ loss of info (where technically data has been lost but visually it looks exactly the same).

David,
Why the hate for LT? I’ve used LT in workflows where I’ve personally tested LT footage against regular ProRes (used scopes, broadcast monitor and large client monitor for evaluation) and found no difference in quality for our particular needs (including broadcast). And before you accuse us of being cheap, we generated about 2-3 TB a week of new data and upgrading an 40TB Xsan w/25 clients attached isn’t an inexpensive process.

LT won’t hold up as well when it comes to processing (like I wouldn’t use LT for green screen) but for our workflow of record LT, minimal if any post processing, layoff to HDCAM, it works great.

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

Everything was in focus? That’s a problem I’d like to have. Many times all I get in focus is the wall just behind my subject.

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

Good stuff. I needed a good laugh after a long day.

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

[Walter Soyka] “Correspondingly, Apple’s insistence on selling complete closed systems worked fabulously in the 1970s and early 1980s, but nearly killed the company by the 1990s.”
Apple started licensing their OS in the 90’s and that’s typically seen as one of their bigger misfires of that era. When Jobs came back one of the first things he did was kill the clones.

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

[Erik Lindahl] “It scary but I think if Apple put 100% effort on iOS-devices today they get X million back from that. If they put 100% effort on MacPro’s they’d get perhaps 1/10th of that back.”

I think 1/10th is way too generous. Apple sold more iDevices in 2011 than they sold Macs in the entire history of the company! And those devices are going to generate 10’s of billions of dollars in revenue in App Store sales alone.

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)

[Andrew Kimery]

Didn’t realize it was already discussed. I guess that’s what I get for not coming here every day. 😉

Anecdotal I know, but I’ve seen similar things so I guess I’m inclined to believe the author. Something I said in another thread, was that a friend of mine works with IT of a large insurance company they are having to find ways to support iPhones and iPads basically out of necessity because so many of their employees want to use these personal devices for work. They don’t want to carry around a work-issued BB (or laptop) and an personal iPhone (or iPad) they just want to use their personal device for everything because that is the device they enjoy using most. I’ve seen the same thing happen at other large companies I’ve worked for where people are pushing back against having a work issued BB because they prefer using Apple’s devices.

-Andrew

2.9 GHz 8-core (4,1), FCP 7.0.3, 10.6.6
Blackmagic Multibridge Eclipse (7.9.5)