Activity › Forums › Creative Community Conversations › NLEs and NAB – Oliver Peters
-
Chris Kenny
April 14, 2013 at 6:21 pm[Franz Bieberkopf] “… tangentially, I’m interested to see how Adobe Anywhere scales down (rather than up), appealing more to smaller groups, and wonder if they’re be developments in that direction over the next few years. Is that the end run around puck-expectant Apple?”
Adobe Anywhere does one better than Avid’s solutions by allowing the centralized infrastructure used for collaborative workflows to be built with commodity hardware. But ideally you want little or no centralized infrastructure to be required at all. Adobe doesn’t quite seem to be there yet. That’s still anyone’s game — though we might see Avid sit it out (to their long term detriment) since so much of their revenue appears to come from offering expensive proprietary solutions to this problem.
—
Digital Workflow/Colorist, Nice Dissolve.You should follow me on Twitter here. Or read our blog.
-
Oliver Peters
April 14, 2013 at 8:58 pmI spent some time with Adobe product managers discussing the nuts and bolts of Anywhere. The general pieces are:
1) Centralized shared storage with the bandwidth to handle multiple streams of high-res video
2) Enterprise-grade Windows servers (with redundant back-up) to handle the streams
3) Additional dedicated server for the Adobe Mercury Steaming Engine
4) Adobe software
5) High-end NVIDIA GPUs for real-time effects processing at the central locationTypically, you’ll need 1 server (not counting back-up) for every 10 concurrent users, so if you are trying to service 30 users at once, then this is a 3-4 server infrastructure. Not counting Adobe software and support, this sounds like you are in the $100K range with 16TB-32TB of storage. The servers are definitely NOT Mac-Minis. 😉
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Chris Harlan
April 14, 2013 at 9:07 pm[Craig Seeman] “very good observation on NLE at NAB. “
Quite enjoyed it myself.
Oliver–one question: I got a quote at the EditShare booth that puts the release of Lightworks Mac in the next few weeks or month. Why do you think “end of the year?”
-
Oliver Peters
April 14, 2013 at 9:23 pm[Chris Harlan] “Oliver–one question: I got a quote at the EditShare booth that puts the release of Lightworks Mac in the next few weeks or month. Why do you think “end of the year?””
Me, too, but I’m skeptical. I think it’s a bit of a grey area with them when something is out of beta and actually a released product.
It’s all vaporware until something ships 😉 From what I could tell, AJA was the only vendor (of those we routinely discuss here) that decided to only show products actually shipping now.
As far as Lightworks Mac, they are in an alpha version now. The next stage is with a closed group of beta testers. Then an official public beta.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Chris Kenny
April 14, 2013 at 9:42 pm[Oliver Peters] “1) Centralized shared storage with the bandwidth to handle multiple streams of high-res video
2) Enterprise-grade Windows servers (with redundant back-up) to handle the streams
3) Additional dedicated server for the Adobe Mercury Steaming Engine
4) Adobe software
5) High-end NVIDIA GPUs for real-time effects processing at the central locationTypically, you’ll need 1 server (not counting back-up) for every 10 concurrent users, so if you are trying to service 30 users at once, then this is a 3-4 server infrastructure. Not counting Adobe software and support, this sounds like you are in the $100K range with 16TB-32TB of storage. The servers are definitely NOT Mac-Minis. ;-)”
As nearly as I can tell, this is basically a ‘thin client’ model for video editing — all of the processing of video footage occurs on a centralized server (which obviously needs to be very powerful to do that for multiple clients concurrently), and the results are streamed to the client.
This is a very interesting model, and it may be very attractive for some users, but I think there are a whole bunch of use cases where it’s missing the mark a bit. Here’s the thing: today’s client systems aren’t all that thin. I am, in general, pretty damn happy with the performance I get editing, on, say, a 15″ Retina MacBook Pro. If the client system has the computational resources to do the job, duplicating those resources on the server and doing the job there instead is wasteful.
The tricky question with processing on the client is, of course, where does the footage come from? You can’t exactly stream uncompressed HD, or even common offline editing codecs like ProRes, over the Internet. I see, broadly, two approaches to this problem.
First, you could simply stream H.264 footage to the client (either converted live by the server, or transcoded in advance on the server — the latter obviously lets you get away with a less powerful server) and have that processed locally. This wouldn’t be 100% pixel accurate with respect to results, but then neither is just monitoring compressed footage, which Adobe’s approach involves. This would also still require things like final exports to be processed on the server, since the client won’t have access to full quality media anymore that it does with Adobe’s thin client scheme.
The other approach is to just simply ignore this problem. Don’t even try to solve it. Add features that make it easy for users to share project data, and let users work out how to share media. This probably means you can’t share media files over the Internet (generic file sharing schemes like AFP or NFS aren’t going to work for streaming editorial media to NLEs over the Internet). But it would still likely work fine for users with shared LAN/SAN storage. You could also simply give each remote user collaborating on the project an identical drive with all of the editorial media, totally eliminating the need to send media over the network at all.
—
Digital Workflow/Colorist, Nice Dissolve.You should follow me on Twitter here. Or read our blog.
-
Oliver Peters
April 14, 2013 at 9:54 pm[Chris Kenny] “As nearly as I can tell, this is basically a ‘thin client’ model for video editing — all of the processing of video footage occurs on a centralized server (which obviously needs to be very powerful to do that for multiple clients concurrently), and the results are streamed to the client.”
Yes. The example they use and have demonstrated is being connecting via a MacBook Air. The Premiere Pro software on the MBA is really only an interface for the work being done on the server.
[Chris Kenny] “You can’t exactly stream uncompressed HD, or even common offline editing codecs like ProRes, over the Internet. I see, broadly, two approaches to this problem.”
In Anywhere, that’s where the Mercury Streaming Engine comes in. All compositing of multiple streams is done at the server. The MSE is sending a single stream to the client system and that stream is throttled by available bandwidth (plus some local caching like with AE), just like the settings on the Premiere Pro timeline now. When you pause, a full-res image is sent to the system, since only 1 frame needs to be sent. This means that while you are tweaking settings on a filter, in theory, you are watching it at full res. When you hit play, the composite is done in real time at the server and the editor gets a reduced-resolution image via MSE. A LAN would give you better performance than a mediocre wireless connection at Starbucks.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
John Heagy
April 14, 2013 at 11:24 pmOne 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
-
Oliver Peters
April 15, 2013 at 1:04 am[John Heagy] “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.”
MSE works with native media at the server, as I understand it. That can be ProRes or AVC-Intra, but also H264 if that’s what was ingested. But this only lives at the server. The remote station is receiving streamed media for “live” playback during editing, not local storage. Resolution is throttled per bandwidth without the need to generate actual proxy media. MSE is effectively creating edit “proxies” on-the-fly.
Since the final “master” exists by publishing at the server, there’s no need to actually transmit full bandwidth ProRes to the remote station. 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. Anywhere and the streaming engine allows you to move the process outside of the facility if you like.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Lance Bachelder
April 15, 2013 at 1:41 amI totally agree that Apple is way too secretive in just about everything they do – but can’t argue with success…
As far as FCPX – after talking with the Apple guys at NAB, I get the feeling that they know it’s not done yet and are playing it extra close to the vest until the last of the missing features are back in. At least they were open enough to admit they know the issues and are working on them – won’t know until the next rev how close they’re getting…
Lance Bachelder
Writer, Editor, Director
Downtown Long Beach, California
https://www.imdb.com/name/nm1680680/?ref_=fn_al_nm_1 -
John Heagy
April 15, 2013 at 5:00 am[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.
Reply to this Discussion! Login or Sign Up