Andrew Kimery
Forum Replies Created
-
Thanks for the article, Bill.
James’ mandate to only shoot in 4K and higher resolution and the ‘Mac Pro in a bag’ travel kit is certainly on the opposite side of the spectrum from the ‘I shot, edited and delivered using only my iPad’ stories that get a lot of Internet buzz. I think this is a good example of how the changes we are seeing in the industry are more along the lines of the an expansion of industry into new realms as opposed to the new replacing the old.
I wonder what James’ take on the iMac Pro is and what he’d like to see in the next Mac Pro.
-Andrew
-
[andy patterson] ” What about Lenovo, Dell, MSI, Asus and HP? “
What about them? Are they about to launch new computers that people have been clamoring for for years?
[andy patterson] “It is up to the end users to boycott Apple until they offer the price/performance of the competition. Asus, MSI and Lenovo all have to be competitive or they will go bankrupt. Apple not so much.”
The only time Apple has tried to price down to the competition they nearly went bankrupt (the Clone years). By not competing on specs alone Apple wisely avoid the race to the bottom that cratered the personal computer market. While Dell, HP, MSI, etc., are forced to compete mainly on price because they all get their main parts and OS from the same venders Apple markets a wholistic experience that can only be provided by them. Sony tried to do something similar with it’s VIAO line but it wasn’t sustainable.
[andy patterson] “why doesn’t the new iMac Pro keyboard come with the touch bar? “
IIRC the touch bar is powered by an ARM CPU running iOS so putting that into a wireless keyboard probably isn’t practical at this point in time.
-
[Bill Davis] “This to me is a logical progression of the changes I’ve experienced over the past six years. “
I think it boils down to Shane’s point that different parts of the industry require different solutions. I think for people working in commercials, trailers, corporate, etc., you are correct that ‘locked’ means more ‘locked for now’ as opposed to ‘locked for good’. I used to work at a place that did a lot radio and TV commercials for touring artists and the same basic spots, with minor tweaks/updates, would get used for years and years. It’s was a continuous update cycle as opposed to starting from scratch every time.
On the flip side, once a movie, TV show, episode of web series, etc., goes out the door it’s done. Iron Man 2 isn’t a re-release of the first Iron Man with a few changes, it’s a whole new movie from the ground up.
-
[Bill Davis] “Well, right now the FiO Approve/Needs Work tagging system could easily grow into something to manage versions – and really, all you’d need for QC is for someone to watch the deliverable version on line and vet that the file confirms to your requirements. No need to download it, really.
Further, if it’s just matching a distribution requirement checklist – a machine learning system should easily be able to compare the deliverable to your last export and only flag it if it differs. “
QC’ing a relatively low res proxy stream of the high res master wouldn’t allow you to catch things like banding, gamma shifts, sync, odd motion characteristics, etc., because you wouldn’t know if those anomalies existed in the master itself or were only present in the proxy stream you were monitoring. A person, and possibly machine learning in time, could certainly compare a low res reference export to the final master export the cloud service creates to make sure there are no discrepancies in the edit, L3rds, etc.,.
-
[Oliver Peters] “You seem to be talking about an online-quality editing system with all the media in the cloud. That’s quite a pipe dream.”
I don’t think Bill is talking about that. Going back to his rendering example, I think what Bill’s brainstorming is a function where you can selectively export portions of the timeline at ‘master quality’ resolution and have them uploaded to a cloud-based service in the background. The service would need to sync w/the NLE to make sure all the chunks ended up in the right order (and older chunks were correctly replaced by newer versions if changes were made). Once you upload your audio splits (either made by you or given to you by a rerecording mixer) you can set your audio configs, choose the texted/textless version, etc., and queue up all the different versions you need then hit the ‘go’ button.
It’s an interesting idea, though still very impractical for long form projects given the current state of Internet service in the US and the limitations of cloud hosting companies (ex. Vimeo Pro only lets you upload 20gig/week). Also, there’s no way for you to QC the final output without downloading it and watching it yourself, which pretty much negates the whole point of having a cloud-based service generate and deliver your files for you.
-
[greg janza] “I just exported a tv show for a local channel today and the encoder preset I used to make the master for them was a custom preset that the station sent me.”
That’s awesome. I wish more people would do that.
I had something similar a few years ago where I was trouble shooting a very weird playback bug with the deck op. Long story short, after lots of trial and error he made a custom setting in AME that worked w/his playback system and emailed it to me.
[Bill Davis] “That tells me they don’t view file size as a stopper.
And as someone lucky enough to have Consumer fiber at home – I can vouch that bigger pipes make a multi Gig video upload faster and easier for me today than a 30 min audio upload was in my youth.”
If Frame isn’t concerned about file sizes then they really need to get rid of the file size limits on user accounts. ????
With regards to fiber, only about 10% of the users in the US have access to fiber so the ‘just get a bigger pipe’ solution is a none starter. I think the vast majority of users would find 100gig-1TB uploads problematic considering the current state of Internet access across the US (and it’s about to get much worse) both in terms of upload speeds (which for cable tend to top out around speeds of ‘up to’ 20Mpbs and much less for DSL) and data caps. Of course you could upgrade to a business account to avoid the caps, but then you’ve got to pay a lot more money to get the same upload speed.
Again, for short form this isn’t really an issue, but when you go from content lengths of 60sec to 60min to 120min then all of a sudden problems of scale start to appear.
-
[Oliver Peters] “But they would also need to supply other spec info that affects the master before encoding, like loudness compliance, as well as captioning.”
Exactly, still lots of pre-export details to comply with, but having an “Export for Netflix” button would, to Bill’s point, simplify things for editors/AEs.
-
[Bill Davis] “So the simple answer is that you send to your distribution service a “digital master” created from the largest, pixel densest, least destructively encoded footage pool you can – and then let the big processing guns in the cloud handle the rest. “
For :30 spots this seems viable (aside from Oliver’s concerns). For long form content you are talking about uploads that can span the range from hundreds of gigs to over a TB depending on the settings (ex. a 90min 23.98 UHD movie in ProRes XQ is 1.2 TB). Most people will need faster Internet pipes for that. ????
Of course the genesis of this branch of the thread wasn’t that file delivery is inherently complicated, it’s that FCPX/Compressor currently can’t export a common format w/closed captions like the other major NLEs can which makes Don’s current workflow unnecessarily complicated.
I was half kidding when I said it, but I’m digging my idea about companies sending export presets for editors to use. Obviously this wouldn’t be viable in all cases (like Don’s or where the client doesn’t have the tech knowhow to do it), but if Netflix can write up a 53 page deliverables guide I’m sure they can make some export presets to go with it. 😉
-
[Bill Davis] “Check again.”
Will do. Thanks Bill.
[Bill Davis] “If Telestream Episode can fix this on your desktop – shouldn’t a virtual Episode-like system be able to fix it better, faster and more directly in the cloud?
Why should it be your job? It’s “automatable.” Right now.
Asking EVERY editor to become a transcoding expert is silly.”
But what file do you send to Telestream-in-the-cloud to begin with? That’s the crux of this. In this scenario the editor isn’t tasked with creating a bunch of different transcodes, just one file out of the NLE that will then be sent to the client so they can generate a bunch of different transcodes.
If the client wants a 23.976 4K ProRes 4444 and I export my ‘master’ as 720p60 MPEG2 then upload it to Telestream so it can make the 4K ProRes file the client’s probably not going to be too happy with the results. Unless clients start supplying export presets that can be imported into NLEs (or Compressor/AME) then editors will still need to have enough technical knowledge to generate a master file out of their NLE that adheres to client specifications (or pay someone w/that knowledge).
-
[Bill Davis] “I’m just asking WHY. What’s the point? “
Because Snapchat doesn’t want a DCP, HBO doesn’t want a vertical video and Netflix thinks it can deliver superior quality and performance to its customers by handling encoding and distribution inself rather than ‘rebranding’ a YouTube/Frame.io/Vimeo stream and sending that to your house when you fire up the Netflix app?
[Bill Davis] “Multiple organizations all doing basically the same thing in different ways “because that’s the way we’ve traditionally done it.””
You mean like Frame.io, Vimeo, YouTube, Whipster, Kollaborate, Media Silo, etc.? ????
Even the new companies you mention are part of the ‘problem’ because you must deliver files to their servers and their servers alone. By that I mean, my YouTube, Vimeo and Frame.io accounts aren’t interlinked and interchangeable. I can’t ‘drag’ a video from Vimeo over to Frame.io.
Having been on the content receiving side, not just the creation and send to the client side, it’s pretty obvious that a one-size-fits-all solution isn’t practical.