WEBVTT

00:00:00.240 --> 00:00:05.759
have you ever noticed that after you upload an image to your favorite social

00:00:03.280 --> 00:00:09.280
media site it sometimes doesn't look quite as good as you thought it would

00:00:07.520 --> 00:00:13.519
specifically because the image was compressed or it had its resolution

00:00:11.679 --> 00:00:17.840
lowered well naturally it turns out that there are reasons that social media

00:00:15.599 --> 00:00:22.160
services do this as it's crucial for helping them manage the millions of

00:00:19.600 --> 00:00:26.960
images our selfie addicted society is uploading every day so how exactly do

00:00:24.480 --> 00:00:30.560
these large services get images to us quickly and how are they making

00:00:28.560 --> 00:00:35.120
improvements to try and keep the image quality as high as they can to answer

00:00:33.200 --> 00:00:39.680
that we spoke with nolan o'brien at twitter and we'd like to thank him both

00:00:37.360 --> 00:00:44.160
personally as well as twitter itself for help with this episode large services

00:00:42.000 --> 00:00:48.000
like twitter face enormous challenges trying to get images to so many

00:00:46.239 --> 00:00:52.960
different users the images that go through twitter's servers every day

00:00:50.320 --> 00:00:58.399
number in the billions with a b and they have to figure out how to quickly get

00:00:54.960 --> 00:01:00.320
them to their 330 million users even if

00:00:58.399 --> 00:01:03.840
those users are far away from twitter's data centers a large part of the

00:01:01.920 --> 00:01:08.560
solution is using content delivery networks or cdns which are distributed

00:01:06.720 --> 00:01:14.159
storage networks that you can learn more about here this way devices will have a

00:01:11.119 --> 00:01:16.400
semi-nearby server to pull images from

00:01:14.159 --> 00:01:21.200
but what about the images themselves well twitter uses both png and jpeg

00:01:18.960 --> 00:01:25.119
images both are compressed which saves bandwidth compared to using huge

00:01:23.040 --> 00:01:29.759
uncompressed images that can easily take up around 35 megabytes if shot with a

00:01:27.280 --> 00:01:34.400
typical smartphone camera however pngs use lossless compression meaning they're

00:01:32.079 --> 00:01:40.079
higher quality but take up significantly more space than a jpeg typically twitter

00:01:37.280 --> 00:01:44.720
will convert most images to jpeg if the png version has a high color depth

00:01:42.560 --> 00:01:49.600
meaning that if they support 16 bit or a little over 65 000 colors which actually

00:01:47.520 --> 00:01:53.920
isn't all that many considering modern displays support millions of colors

00:01:52.159 --> 00:01:58.320
additionally jpegs that take up more than five megabytes are also reduced in

00:01:56.560 --> 00:02:01.840
quality but hold on a second i use twitter all the time and i think the

00:01:59.600 --> 00:02:06.320
images look pretty decent how do they pull that off using so much compression

00:02:04.320 --> 00:02:12.160
keep in mind that twitter still supports jpegs up to about 16.7 megapixels or

00:02:09.520 --> 00:02:15.599
about 4.2 megapixels if you're uploading from mobile

00:02:13.440 --> 00:02:19.440
and when the service has to reduce to jpeg quality it does so by only about 15

00:02:18.400 --> 00:02:25.840
percent typically such a loss in quality isn't noticeable unless you're looking very

00:02:23.520 --> 00:02:29.120
closely yet still saves a significant amount of bandwidth and this is

00:02:27.120 --> 00:02:34.000
especially true since phone screens these days are very high resolution yet

00:02:31.440 --> 00:02:37.920
small in size so images can very easily be scaled down in resolution without a

00:02:36.000 --> 00:02:42.400
noticeable loss in visual fidelity many phone screens only have one red or blue

00:02:40.160 --> 00:02:46.080
pixel for every green so trying to show a super high resolution photo on them

00:02:44.319 --> 00:02:50.319
would be a waste as the phones can't even reproduce them accurately if you

00:02:48.080 --> 00:02:54.720
compare these images to original side by side on a high res desktop monitor you

00:02:52.959 --> 00:02:58.800
may notice a difference but for phone users who are often most impacted by

00:02:57.040 --> 00:03:03.280
speed constraints the compression methods we've mentioned so far are no

00:03:00.800 --> 00:03:07.840
brainers of course sometimes noticeable trade-offs even on mobile devices cannot

00:03:05.440 --> 00:03:12.159
be avoided many people use social media services without fast connections so if

00:03:10.400 --> 00:03:16.720
you're on a slow connection you might notice that twitter uses progressive

00:03:14.159 --> 00:03:21.599
jpegs meaning that a low quality version will fully load first while you wait for

00:03:19.440 --> 00:03:26.159
the higher res version contrasting with the slowly loading image from top down

00:03:24.319 --> 00:03:30.640
as you probably remember from the dial up era if you're old then you have to

00:03:28.480 --> 00:03:34.560
factor in how people use many different devices including some really old ones

00:03:33.040 --> 00:03:38.959
this is a big part of the reason you might have noticed that twitter header

00:03:36.080 --> 00:03:42.879
images often appear to be lower quality as they're capped at 500 pixels

00:03:40.959 --> 00:03:48.159
vertically to ensure that they can be shown correctly on legacy devices

00:03:46.400 --> 00:03:52.720
but what about all the space these pictures take up on twitter's servers

00:03:50.400 --> 00:03:57.840
well it turns out that storage isn't all that difficult to expand so the choices

00:03:55.519 --> 00:04:03.920
that social networks make with how they process images has less to do with drive

00:04:00.560 --> 00:04:05.599
capacity and more to do with how to use

00:04:03.920 --> 00:04:10.720
as little bandwidth as possible for the end user after all who has an extra five

00:04:08.239 --> 00:04:15.920
seconds to wait for the next zesty Linus beam to load am i right not me check out

00:04:13.439 --> 00:04:19.840
bitdefender total security 2020. their best-in-class security solutions for

00:04:17.680 --> 00:04:24.080
Windows mac Android and iOS have been awarded product of the year by av

00:04:21.840 --> 00:04:28.639
comparatives and protect over 500 million systems worldwide network threat

00:04:26.639 --> 00:04:32.320
protection detects attacks including botnets and stops them before they even

00:04:30.400 --> 00:04:36.160
begin it also prevents your sense of information from being sent in an

00:04:33.680 --> 00:04:40.639
unencrypted format nobody wants that you also get ransomware protection of vpn

00:04:38.400 --> 00:04:44.560
service parental controls and autopilot your personal automated security advisor

00:04:42.880 --> 00:04:49.360
that helps you tailor your bitdefender experience to your needs and all this is

00:04:46.639 --> 00:04:53.199
backed by comprehensive 24 7 support so check them out at the link below for

00:04:51.040 --> 00:04:56.400
more details as well as a special giveaway so thanks for watching guys if

00:04:55.040 --> 00:04:59.600
you like this video give it a like give us a subscribe and be sure to hit us up

00:04:58.160 --> 00:05:04.320
in the comments section with your suggestions for future topics that we

00:05:01.440 --> 00:05:04.320
should cover