WEBVTT

00:00:00.240 --> 00:00:05.600
this journey begins over six months ago

00:00:03.600 --> 00:00:10.000
when i reached out to Intel about supporting us with some chips a

00:00:07.919 --> 00:00:13.840
low-power xeon to build the high-speed storage server for our new office that i

00:00:11.840 --> 00:00:21.199
first showed off here then a pair of their top of the line e5

00:00:17.199 --> 00:00:24.240
2699 v3 18 core xeon processors to build

00:00:21.199 --> 00:00:26.560
a network video rendering server also

00:00:24.240 --> 00:00:29.760
for the new office well as it turns out they couldn't send us the low power chip

00:00:28.240 --> 00:00:34.880
for the storage server so we bought our own but whatever the reason was they

00:00:32.559 --> 00:00:39.440
were able to honor our request for the pair of 4 500

00:00:37.840 --> 00:00:43.680
processors so it is with much thanks to Intel along

00:00:41.920 --> 00:00:49.120
with supermicro who provided a dual socket motherboard kingston who provided

00:00:45.440 --> 00:00:51.520
128 gigs of ddr4 ecc RAM and norco

00:00:49.120 --> 00:00:56.640
Noctua and fsp who provided our case cooling and redundant power that we are

00:00:54.000 --> 00:01:00.800
able to bring you these findings because you see the deal was this

00:00:58.800 --> 00:01:05.119
send us the chips and we'll make a video about how we're using them which sort of

00:01:03.120 --> 00:01:09.760
puts a lot of pressure on us to figure out not only if the concept of network

00:01:07.840 --> 00:01:14.320
rendering also known as a render farm works i mean that's been pretty standard

00:01:11.840 --> 00:01:21.360
stuff for years especially in animation but also to find a way to efficiently

00:01:17.759 --> 00:01:24.080
use those resources in our workflow

00:01:21.360 --> 00:01:28.479
so without further ado thanks to weeks of work by edsel and much patience from

00:01:26.240 --> 00:01:34.479
the rest of the team i am pleased to present our new editing workflow it's

00:01:32.000 --> 00:01:38.720
fast it has built-in redundancy for our files and to quote dimitri from hardware

00:01:36.960 --> 00:01:43.119
canucks who has already switched to it it brought the joy back to 4k video

00:01:41.759 --> 00:01:53.439
editing for me so here we go

00:01:53.439 --> 00:01:59.439
the logitech g303 features a lightweight design and advanced optical sensor with

00:01:57.680 --> 00:02:03.040
delta zero technology for precise tracking and RGB lighting to match your

00:02:01.520 --> 00:02:07.520
setup check out the link in the video description to learn more so the most

00:02:05.360 --> 00:02:12.480
obvious bottleneck in a video editor's daily life is waiting around for

00:02:10.080 --> 00:02:18.000
encoding tasks to complete outputting a finished ready to upload

00:02:15.120 --> 00:02:24.640
h.264 video file can take anywhere from 15 to 30 minutes for us with one pass

00:02:20.720 --> 00:02:26.480
vbr or even over an hour with two passes

00:02:24.640 --> 00:02:31.840
so that was the first thing we tried to tackle with the 36 core server machine

00:02:29.120 --> 00:02:36.160
for software telestream episode and sorenson squeeze desktop were the front

00:02:34.000 --> 00:02:42.080
runners initially telestream was intriguing thanks to its unique ability

00:02:38.400 --> 00:02:44.400
to split an encoding project into pieces

00:02:42.080 --> 00:02:50.400
processed them across many cores and then stitched them back together at the

00:02:46.480 --> 00:02:52.080
end regardless of the codec and sorenson

00:02:50.400 --> 00:02:56.560
due to its excellent handling of multiple concurrent projects also a time

00:02:54.400 --> 00:03:03.360
saver if you have many processing cores and its ability to utilize all cores for

00:02:59.599 --> 00:03:05.760
a single project with supported codecs

00:03:03.360 --> 00:03:10.400
so episode is a great concept but we abandoned it quickly due to stability

00:03:08.080 --> 00:03:14.640
issues sorensen on the other hand impressed the snot out of us the

00:03:12.400 --> 00:03:18.000
software worked their support staff was professional and even as a trial

00:03:16.480 --> 00:03:22.720
customer we were escalated to engineering whenever we encountered more

00:03:19.680 --> 00:03:24.959
complex issues outstanding so next we

00:03:22.720 --> 00:03:29.440
tested a variety of different output formats and found that thanks to

00:03:26.959 --> 00:03:35.200
optimizations within premiere pro our projects could be exported very quickly

00:03:31.840 --> 00:03:37.599
by our editing workstations in dnxhd to

00:03:35.200 --> 00:03:42.560
our server where sorenson would utilize all CPU cores to output an h.264 master

00:03:40.640 --> 00:03:47.120
copy that was suitable for upload to youtube and other video sharing sites in

00:03:44.560 --> 00:03:51.040
a fraction of the time that adobe media encoder could do it and all of this

00:03:49.440 --> 00:03:56.159
while leaving the video editors computers free to work on other things

00:03:53.680 --> 00:04:00.720
instead of just sitting there barely usable while they encoded video so

00:03:58.480 --> 00:04:04.159
mission accomplished then right well

00:04:01.840 --> 00:04:08.560
you know how the rabbit hole is the discoveries we made about how

00:04:06.080 --> 00:04:11.280
dramatically a program's optimizations around a given codec could affect

00:04:10.159 --> 00:04:16.000
performance raised more questions than they answered

00:04:13.680 --> 00:04:19.680
and while premiere pro's claim to fame is that

00:04:16.880 --> 00:04:24.800
unlike competitors like avid and final cut it allows any video file you want to

00:04:22.320 --> 00:04:30.080
simply be plunked onto the timeline and edit it in real time it made us consider

00:04:27.919 --> 00:04:35.440
the way that 4k footage off our panasonic gh4 camera just

00:04:32.720 --> 00:04:41.199
seemed to chug as you scrub through it on the timeline even on six CPU cores

00:04:38.560 --> 00:04:46.960
and a 10 gigabit network connection maybe there's some merit then too going

00:04:43.840 --> 00:04:49.280
back to the old way so we devised a

00:04:46.960 --> 00:04:55.600
workflow that would utilize our copious amounts of CPU horsepower to transcode

00:04:52.479 --> 00:04:58.000
footage from whatever format our various

00:04:55.600 --> 00:05:03.040
cameras captured in natively to an intermediary or mezzanine codec that was

00:05:01.040 --> 00:05:08.800
compatible with all the programs in our workflow so for a number of reasons

00:05:05.600 --> 00:05:10.800
avid's dnxhd was chosen and would you

00:05:08.800 --> 00:05:16.240
look at that comparing pre-fetch latencies with

00:05:13.280 --> 00:05:20.479
native gh4 footage the delay when moving the playhead in premiere was reduced by

00:05:18.400 --> 00:05:25.919
nearly 25 times at 4k depending which program

00:05:23.120 --> 00:05:30.160
exactly was used for the trans code so it was at that point that the goal

00:05:28.160 --> 00:05:34.800
actually changed obviously we could just have the

00:05:32.479 --> 00:05:39.600
individual video editors convert all the footage off the cameras to our mezzanine

00:05:37.360 --> 00:05:43.520
codec when they're working but then we'd be right back where we damn well left

00:05:41.440 --> 00:05:46.800
off with highly skilled video editors staring at their barely functional

00:05:44.960 --> 00:05:52.080
computers waiting for a big queue of videos to transcode so no

00:05:49.039 --> 00:05:54.720
we needed a way to avoid that by using

00:05:52.080 --> 00:06:00.639
our overpowered hardware and the answer of course is to do the transcode at the

00:05:57.840 --> 00:06:05.520
time of ingest or when the footage is initially removed from the camera

00:06:02.960 --> 00:06:09.039
and here's some bad and some good news while squeeze desktop sorenson's low end

00:06:08.080 --> 00:06:15.199
offering can perform a task like this across many

00:06:11.680 --> 00:06:18.319
CPU cores because we dump so many video

00:06:15.199 --> 00:06:21.280
clips off our sd cards at a time it just

00:06:18.319 --> 00:06:26.720
wasn't stable enough with our workload so we turned to their server offering

00:06:24.000 --> 00:06:31.039
which operated much more smoothly to automatically monitor our video file

00:06:28.880 --> 00:06:37.280
dumping folders and transcode everything we dropped in them so the benchmark was

00:06:33.280 --> 00:06:40.319
a folder of 41 video files totaling 16.7

00:06:37.280 --> 00:06:42.479
gigs and by prioritizing multiple tasks

00:06:40.319 --> 00:06:47.199
this could be processed in about 14 minutes a small price to pay even on a

00:06:45.680 --> 00:06:52.319
video that needed to be edited immediately for the improved timeline

00:06:49.440 --> 00:06:58.479
performance but unfortunately time wasn't the only price the server version

00:06:56.319 --> 00:07:05.440
requires a Windows server operating system to run on top of and costs 5 000

00:07:02.960 --> 00:07:09.840
plus yearly maintenance fees and furthermore despite the assurance we

00:07:07.840 --> 00:07:14.080
received from sorenson's engineers that there shouldn't be any gamma or color

00:07:11.919 --> 00:07:19.280
shifts using quicktime as a wrapper between squeezes dnx

00:07:15.840 --> 00:07:22.720
export and premier's import it was there

00:07:19.280 --> 00:07:24.240
and very difficult to compensate for so

00:07:22.720 --> 00:07:29.759
it was back to the drawing board somewhat which led us to a conversation

00:07:27.199 --> 00:07:35.120
with blackmagic design where they said that cineform could also be a great

00:07:32.880 --> 00:07:40.000
mezzanine codec an option that had been dismissed early on due to its limited

00:07:37.599 --> 00:07:43.520
compatibility with most software including sorensen squeeze although they

00:07:41.840 --> 00:07:48.880
had said they could add compatibility with the next yearly release

00:07:46.080 --> 00:07:52.479
so could we quickly transcode our footage to cineform it turns out that

00:07:51.599 --> 00:07:58.000
yes even with only 30 CPU utilization

00:07:55.599 --> 00:08:03.440
effectively 10 and a half of our 36 course adobe media encoder yes back to

00:08:00.800 --> 00:08:08.639
that again managed to kick sorensen's ass converting to cineform versus

00:08:05.599 --> 00:08:11.840
sorenson converting to dnxhd and all of

00:08:08.639 --> 00:08:13.919
this without a significant loss in

00:08:11.840 --> 00:08:17.919
quality regardless of whether we're working with native 4k footage for

00:08:16.240 --> 00:08:23.440
better green screen and punch in performance or settling for up sampling

00:08:20.879 --> 00:08:27.280
1080p footage for our finished project by the way please see this video for

00:08:25.360 --> 00:08:31.840
more details about the benefits and the drawbacks of 4k

00:08:29.599 --> 00:08:36.240
so that's all fine and good Linus but does cineform deliver the answer again

00:08:35.120 --> 00:08:42.240
yes while file sizes are significantly

00:08:39.200 --> 00:08:45.680
larger especially at 4k than even the

00:08:42.240 --> 00:08:48.640
source files timeline performance is

00:08:45.680 --> 00:08:55.440
better than even dnxhd thanks to an extraordinarily poorly documented

00:08:51.279 --> 00:08:59.040
feature of cineform it's GPU accelerated

00:08:55.440 --> 00:09:02.640
so even though dnxhd also performs like

00:08:59.040 --> 00:09:05.040
a champ it can eat 50 to 60

00:09:02.640 --> 00:09:10.000
of a 12 core xeon while scrubbing through footage while cineform is using

00:09:07.760 --> 00:09:15.600
the fancy titan x graphics cards that NVIDIA sent us for our workstations to

00:09:12.240 --> 00:09:18.320
keep CPU usage much lower

00:09:15.600 --> 00:09:24.800
so then here is the process that we finally settled on we're using adobe

00:09:21.279 --> 00:09:27.279
prelude 2015 to ingest our footage

00:09:24.800 --> 00:09:31.920
automatically dumping the raw files off of the camera to a local storage array

00:09:29.839 --> 00:09:36.720
on the machine in case of an emergency and then queuing up transcode jobs for

00:09:34.640 --> 00:09:43.360
each of those clips in media encoder 2015 to send to our network share we

00:09:40.000 --> 00:09:44.880
then use media encoder 2014 which is

00:09:43.360 --> 00:09:50.560
included with your creative cloud license by the way to monitor the watch

00:09:47.680 --> 00:09:56.480
folders that we export our finished jobs into and turn those into h.264 files

00:09:54.640 --> 00:10:00.480
ready for publishing on websites like youtube vessel yooku billy billy and

00:09:59.360 --> 00:10:06.800
facebook and while hitting both instances of media

00:10:03.440 --> 00:10:10.399
encoder we've seen CPU usage as high as

00:10:06.800 --> 00:10:13.760
90 percent but that doesn't mean that

00:10:10.399 --> 00:10:16.959
you need a multi-thousand dollar network

00:10:13.760 --> 00:10:19.839
render machine to utilize this workflow

00:10:16.959 --> 00:10:24.560
all we've demonstrated here is that it's scalable to that kind of hardware for a

00:10:22.160 --> 00:10:29.279
small team you could easily take advantage of this on a smaller scale

00:10:27.120 --> 00:10:32.399
with a low power networked machine if you just wanted to improve your timeline

00:10:31.440 --> 00:10:36.959
performance and not sit around waiting for exports

00:10:34.959 --> 00:10:41.120
on your main station while something else works on that in the background

00:10:39.519 --> 00:10:47.040
speaking of things that run in the background tunnelbear is an easy to use

00:10:44.000 --> 00:10:48.959
privacy app for mobile desktop and

00:10:47.040 --> 00:10:54.800
browser so they got support for iOS Android mac pc and chrome it allows you

00:10:51.760 --> 00:10:57.040
to tunnel to 14 different countries

00:10:54.800 --> 00:11:02.480
allowing you to browse the internet as if you're in that country it works for

00:11:00.000 --> 00:11:05.839
accessing things like geo-blocked websites

00:11:03.760 --> 00:11:08.959
the apps are super easy to use so you just like pick your country and turn

00:11:07.440 --> 00:11:13.760
tunnel bear on and your internet connection gets fully encrypted and you

00:11:11.360 --> 00:11:17.920
don't have to be technical to use or install tunnelbear and if you get stuck

00:11:15.839 --> 00:11:23.600
you can contact their friendly support bears that are standing by 24 hours a

00:11:21.519 --> 00:11:28.959
day they've got a plain english privacy policy and they've got 5 million users

00:11:26.880 --> 00:11:33.200
that trust them already so you can try it out for free tunnelbear actually

00:11:31.120 --> 00:11:36.959
gives you 500 megs of data for free every month and an extra gig if you

00:11:35.040 --> 00:11:42.240
tweet at them but if you need more prices for unlimited plans start at 699

00:11:39.760 --> 00:11:46.480
a month so head over to tunnelbear.com LTT linked in the video description to

00:11:44.320 --> 00:11:52.560
try it out today thanks for watching guys if this video sucked

00:11:48.959 --> 00:11:53.519
come on this was a lot of work

00:11:52.560 --> 00:11:58.959
but if it was awesome please hit that like button

00:11:57.200 --> 00:12:02.640
get subscribed or even consider supporting us directly by using our

00:12:00.560 --> 00:12:06.160
affiliate code to shop at amazon buying a cool t-shirt like this one or with a

00:12:04.640 --> 00:12:10.880
direct monthly contribution through our community forum which you should definitely join links up there and now

00:12:09.600 --> 00:12:16.320
that you're done doing all that stuff you're probably wondering what to watch next so click that little button up in

00:12:14.000 --> 00:12:22.720
the top right to check out luke's video where he goes through the ins and outs

00:12:19.680 --> 00:12:24.959
of password protection that is

00:12:22.720 --> 00:12:27.519
protecting your passwords making it so other people don't have them

00:12:27.519 --> 00:12:31.000
see you next time