WEBVTT - Quicktime 0:00:04.120 --> 0:00:07.160 Get in touch with technology with tech Stuff from how 0:00:07.200 --> 0:00:13.760 stuff Works dot com. Hey there, and welcome to tech Stuff. 0:00:13.800 --> 0:00:16.520 I'm your host, Johnathan Strickland. I'm an executive producer with 0:00:16.560 --> 0:00:18.760 How Stuff Works in my Heart Radio, and I love 0:00:18.840 --> 0:00:22.680 all things tech. And you know, guys are really enjoy 0:00:22.720 --> 0:00:26.040 watching video content on my computer or on my phone, 0:00:26.160 --> 0:00:33.320 and I watch a lot of stuff online like documentaries, movies, comedies, 0:00:33.479 --> 0:00:37.800 film criticism, web series, video game let's plays all this 0:00:37.920 --> 0:00:40.199 kind of stuff. And it's easy to take for granted 0:00:40.680 --> 0:00:42.479 that we can watch this kind of stuff on our 0:00:42.520 --> 0:00:46.320 devices on demand, wherever we are, whenever we want. But 0:00:46.400 --> 0:00:49.320 it wasn't that long ago when such a thing wasn't 0:00:49.320 --> 0:00:53.880 even possible, especially not without a specialized computer that would 0:00:53.920 --> 0:00:58.920 cost thousands or tens of thousands of dollars. But one 0:00:59.000 --> 0:01:05.039 collection of products, one software suite, really helped change all that. 0:01:05.800 --> 0:01:09.520 And this suite would be quick Time. Now, as we're 0:01:09.520 --> 0:01:11.760 going to see in this episode, it gets a little 0:01:11.760 --> 0:01:15.399 tricky to talk about quick time because Apple referred to 0:01:15.600 --> 0:01:20.360 many different components of quick time as quick time. But 0:01:20.400 --> 0:01:22.720 we're gonna build up to that. Just keep in mind 0:01:22.760 --> 0:01:25.160 that when we say quick time, it's more than just 0:01:25.400 --> 0:01:28.080 a video player. It's even more than just a video 0:01:28.319 --> 0:01:33.160 editing system or even a foul format. But we'll we'll 0:01:33.360 --> 0:01:36.640 get there. So the story of quick Time is closely 0:01:36.720 --> 0:01:40.360 tied to that of Apple and the Mac line of computers. 0:01:40.880 --> 0:01:45.000 Apple was really positioning Mac to be the computer for 0:01:45.160 --> 0:01:52.400 creative types, artists, musicians, filmmakers, and that was a calculated 0:01:52.440 --> 0:01:56.600 decision early on, and it paid off. Chances are, if 0:01:56.640 --> 0:02:00.000 you work in the creative industry, if you've been working 0:02:00.040 --> 0:02:02.240 in it for the last say, five to ten years, 0:02:02.280 --> 0:02:07.200 you've been working almost exclusively on Mac computers most likely. 0:02:07.240 --> 0:02:09.680 I mean, we've seen some changes in the more recent years, 0:02:10.120 --> 0:02:12.120 but for the longest time, it meant that if you 0:02:12.160 --> 0:02:15.240 were doing audio editing, video editing, you were working on 0:02:15.280 --> 0:02:19.480 a Mac. Well in the nineteen eighties, this sort of 0:02:19.520 --> 0:02:23.359 got started when you had different people at Apple really 0:02:23.520 --> 0:02:28.399 experimenting with how personal computers could work in this realm. 0:02:28.440 --> 0:02:31.800 There was an engineer at Apple named Steve Perlman who 0:02:31.840 --> 0:02:35.560 tackled the challenge of bringing video playback to personal computers. 0:02:35.800 --> 0:02:39.160 Perlman had been interested in film and television and video 0:02:39.240 --> 0:02:42.840 ever since childhood. He had experimented with clay animation while 0:02:42.840 --> 0:02:45.320 he was in school, and around that same time, which 0:02:45.360 --> 0:02:47.760 was in the nineteen seventies, he decided to build his 0:02:47.880 --> 0:02:51.280 own computer. In the mid nineteen eighties, he was fresh 0:02:51.280 --> 0:02:53.760 out of college and had already worked for companies like 0:02:53.840 --> 0:02:57.960 Colco and Atari, developing graphics, processing, hardware and all that 0:02:58.040 --> 0:03:02.200 on a liberal arts education, so he was largely self 0:03:02.360 --> 0:03:06.079 educated in many of those fields. He joined Apple in 0:03:06.200 --> 0:03:09.240 n and he headed up a project that eventually got 0:03:09.240 --> 0:03:12.040 the name quick Scan. He was part of a team 0:03:12.040 --> 0:03:17.680 of Mac engineers who were working on multimedia support. Multimedia 0:03:17.880 --> 0:03:20.800 was sort of a catch all term, and it essentially 0:03:20.919 --> 0:03:25.200 meant that you were working on software that could display 0:03:25.320 --> 0:03:28.160 more than one form of media, as the name would suggest, 0:03:28.200 --> 0:03:31.920 so maybe it could play audio and show text, or 0:03:32.000 --> 0:03:35.640 also show video or animation. So in the early days 0:03:35.640 --> 0:03:40.000 of multimedia, you couldn't just play digital video on a computer. 0:03:40.280 --> 0:03:45.600 The earlier versions of multimedia technology involved computers controlling external 0:03:45.880 --> 0:03:49.160 media playback devices like a laser disc player, so instead 0:03:49.200 --> 0:03:52.040 of having it native to your computer, you'd have to 0:03:52.200 --> 0:03:56.360 attach a totally independent piece of hardware and control it 0:03:56.800 --> 0:04:00.920 using specialized software and connections, and originally that's all you 0:04:00.960 --> 0:04:03.040 could do. You could just use a computer to control 0:04:03.080 --> 0:04:06.040 the player itself, maybe navigate to different chapters on the 0:04:06.120 --> 0:04:09.200 laser disk, that kind of thing that would end up 0:04:09.240 --> 0:04:12.360 pushing the analog video out to a television set. The 0:04:12.400 --> 0:04:15.960 laser disc player itself would Later on, engineers would develop 0:04:16.040 --> 0:04:18.640 a way to play video on a computer screen within 0:04:18.680 --> 0:04:22.440 a window using essentially was a television tuner, an analog 0:04:22.600 --> 0:04:25.880 tuner that you would plug into an expansion slot on 0:04:25.920 --> 0:04:29.520 a computer. But this was an analog connector, so we're 0:04:29.520 --> 0:04:33.880 not talking about digital media here. It's still an analog signal. 0:04:34.120 --> 0:04:37.839 And I've talked about analog signals versus digital signals in 0:04:37.880 --> 0:04:42.240 the past, but just as a quick refresher, analog signals 0:04:42.400 --> 0:04:47.840 scale to represent a specific value. UH. You would think 0:04:47.880 --> 0:04:52.159 of an analog signal as an analogy of whatever it represents, 0:04:52.480 --> 0:04:55.320 whether that's audio or video or whatever. That's why it's 0:04:55.320 --> 0:05:00.760 called UH. An analog signal, it's an analogy. They are continuous, 0:05:01.279 --> 0:05:05.840 these signals, they can be continuously variable, and a digital 0:05:05.880 --> 0:05:09.400 signal is different. It quantifies the information it is carrying 0:05:09.839 --> 0:05:13.239 in and changes it all into digits, into zeros or ones. 0:05:14.120 --> 0:05:18.200 So an analog thermometer might use liquid mercury to create 0:05:18.240 --> 0:05:21.800 an analogy of your body temperature. So you put the 0:05:21.800 --> 0:05:26.880 thermometer in your mouth. The liquid mercury will then expand 0:05:27.200 --> 0:05:29.160 based on how warm you are, and then you can 0:05:29.200 --> 0:05:33.080 read out the the reading on the thermometer. That's the 0:05:33.120 --> 0:05:38.320 analogy of your body temperature. A digital thermometer would quantize 0:05:38.440 --> 0:05:41.960 the heat measured by the device and then put it 0:05:42.000 --> 0:05:44.960 on a display. Now this does not automatically mean that 0:05:45.000 --> 0:05:48.120 one method is better than the other. The precision of 0:05:48.160 --> 0:05:52.400 the actual measurement is independent of whether it is digital 0:05:52.520 --> 0:05:56.000 or analog. That is a separate thing that has to 0:05:56.080 --> 0:06:00.160 be addressed on its own. But one thing to take 0:06:00.200 --> 0:06:04.159 away from this is that digital and analog are fundamentally 0:06:04.160 --> 0:06:07.560 different approaches, and you need different types of circuits in 0:06:07.680 --> 0:06:11.400 order to process the signals or generate these signals. You 0:06:11.400 --> 0:06:15.040 couldn't send a digital video feed to an analog TV 0:06:15.160 --> 0:06:17.680 tuner in a computer. It wouldn't be able to handle 0:06:17.720 --> 0:06:22.599 that information. One of the limiting factors of bringing video 0:06:22.800 --> 0:06:27.320 into the computer world was really the problem of data. 0:06:27.680 --> 0:06:32.400 How much information that video represents. If you wanted to 0:06:32.640 --> 0:06:36.240 create a color video, if you wanted to to to 0:06:36.400 --> 0:06:40.159 play a color video with sound as a digital file, 0:06:40.480 --> 0:06:42.839 that would require a lot of bits, all those zeros 0:06:42.839 --> 0:06:45.400 and ones in order to manage it, which means that 0:06:45.480 --> 0:06:50.680 file sizes would get incredibly large, particularly by the standards 0:06:50.720 --> 0:06:53.479 of the day, I mean by the nine standards. You 0:06:53.520 --> 0:06:56.320 were talking about computers that when they were you know, 0:06:56.480 --> 0:07:00.279 starting to creep towards the the megabyte storage as you 0:07:00.320 --> 0:07:04.159 were like thinking, this thing is is enormous. Well, these 0:07:04.160 --> 0:07:08.120 files would dwarf that. So you weren't just limited by 0:07:08.120 --> 0:07:10.800 hard drive size for storage, I mean that's one part, 0:07:11.520 --> 0:07:14.680 but you were also limited by how much data throughput 0:07:14.880 --> 0:07:17.600 the buses in your computer were able to manage. And 0:07:17.640 --> 0:07:20.960 a bus is essentially just a pathway. It's a think 0:07:20.960 --> 0:07:23.640 of it as like a highway that data can travel through, 0:07:24.200 --> 0:07:26.440 and the width of the highway tells you how many 0:07:26.480 --> 0:07:29.840 cars can go through at once. So if the bus 0:07:29.840 --> 0:07:33.680 has a lower throughput, if it's a narrower highway, then 0:07:33.680 --> 0:07:36.280 you get bottlenecks. You've got all these cars trying to 0:07:36.280 --> 0:07:38.960 get through, and we're assuming that all the cars can 0:07:38.960 --> 0:07:41.760 travel at the same speed. We're not taking all the 0:07:41.800 --> 0:07:44.720 other elements of traffic into account here, but if you 0:07:44.760 --> 0:07:48.160 have a narrower highway, then fewer cars can pass through 0:07:48.200 --> 0:07:51.440 in any given amount of time. So even if you 0:07:51.480 --> 0:07:54.040 have a very fast processor, it won't do you any 0:07:54.040 --> 0:07:57.080 good if the buses can't have that capacity to carry 0:07:57.160 --> 0:07:59.680 a lot of data for every given unit of time, 0:07:59.720 --> 0:08:03.080 like every second. So how much data are we actually 0:08:03.080 --> 0:08:09.720 talking about? Well, Apple's Advanced Technology Group or a t 0:08:09.960 --> 0:08:13.320 G had an animation team that were determined to create 0:08:13.360 --> 0:08:19.800 a computer animated short using Apple computers for all the 0:08:19.840 --> 0:08:24.760 different production side, they created a three minute presentation called 0:08:24.920 --> 0:08:29.120 Pencil Test, and it's an animated feature that features a 0:08:29.160 --> 0:08:32.560 cute little pencil icon that jumps off a MAX screen 0:08:32.640 --> 0:08:36.400 and it turns into a two dimensional figure inside our 0:08:36.520 --> 0:08:40.400 three dimensional world. And then we follow this little pencil 0:08:40.440 --> 0:08:43.800 graphic as it attempts to try and get back into 0:08:43.840 --> 0:08:46.640 the MAX screen. It's just trying to get home. Fund 0:08:46.679 --> 0:08:50.680 side note, Andrew Stanton worked on this piece. He would 0:08:50.760 --> 0:08:53.560 later go on to write and direct feature length computer 0:08:53.600 --> 0:08:58.600 animated projects at Pixar. Anyway, according to Bruce Leak, who 0:08:58.600 --> 0:09:02.599 would become the lead developed of quick Time, this animated 0:09:02.640 --> 0:09:08.040 demonstration required an enormous amount of effort and resources to produce. 0:09:08.679 --> 0:09:12.920 It took several minutes to render a single frame of animation, 0:09:13.000 --> 0:09:16.679 and there were five thousand frames to get through in 0:09:16.760 --> 0:09:20.439 those three minutes. So to do that, the team devoted 0:09:20.440 --> 0:09:24.520 a couple of dozen Apple computers to start rendering frames. 0:09:24.559 --> 0:09:26.959 Some of them could only render part of a frame 0:09:27.000 --> 0:09:28.880 at a time, and they would have to render another 0:09:28.920 --> 0:09:31.560 part of the frame and then assemble all of that 0:09:31.800 --> 0:09:34.480 at the end of it. Each frame took up about 0:09:34.520 --> 0:09:37.880 a megabyte of storage space, and these computers had between 0:09:37.960 --> 0:09:42.520 forty and eighty megabytes of storage. The entire video would 0:09:42.559 --> 0:09:48.040 represent five gigabytes of data, so this is an enormous 0:09:48.120 --> 0:09:52.040 file that far outstrips the storage capacity of the computers 0:09:52.080 --> 0:09:55.720 that are actually creating the animation. So to get around 0:09:55.720 --> 0:09:59.200 this problem, the team would load about one frames worth 0:09:59.240 --> 0:10:03.040 of animation of time onto a custom digital video storage 0:10:03.080 --> 0:10:07.920 machine that cost around a hundred thousand dollars. Then they 0:10:08.000 --> 0:10:12.760 would export those frames onto videotape, and they built the 0:10:12.880 --> 0:10:16.640 full Pencil Test animated video one hundred frames at a 0:10:16.720 --> 0:10:19.920 time onto videotape until they got all five thousand frames 0:10:19.920 --> 0:10:22.600 on there. This obviously was not something that you could 0:10:22.600 --> 0:10:25.520 load onto a floppy disk and then just plug into 0:10:25.640 --> 0:10:28.280 your average Mac in order to watch. Even though all 0:10:28.320 --> 0:10:30.920 the animation, all the music, all the production was done 0:10:30.920 --> 0:10:33.160 on Max, so you'd actually have to watch it on 0:10:33.240 --> 0:10:36.440 something other than a Mac computer. They couldn't handle playing 0:10:36.480 --> 0:10:39.160 this back, so something would have have to be done 0:10:39.240 --> 0:10:43.040 to manage this sheer amount of information. If future Mac 0:10:43.080 --> 0:10:46.040 computers were to have a practical means of playing video 0:10:46.120 --> 0:10:51.400 on screen, quick Scan would rely upon massively parallel graphic 0:10:51.600 --> 0:10:55.520 animation and video decompression chips. So, in other words, it 0:10:55.600 --> 0:10:58.719 required special hardware, these special chips that you would have 0:10:58.800 --> 0:11:02.360 to install into a comput eater, and Apple doesn't tend 0:11:02.480 --> 0:11:06.320 to like people opening up cases and and messing with 0:11:06.360 --> 0:11:10.280 stuff inside. Typically, the way you would get an upgrade 0:11:10.320 --> 0:11:12.280 on an Apple computer is that you would purchase it 0:11:12.360 --> 0:11:14.720 straight from Apple and you would have them install it, 0:11:14.840 --> 0:11:17.280 or you would just buy a new piece of hardware 0:11:17.280 --> 0:11:21.080 from Apple. So this was not something that would come 0:11:21.120 --> 0:11:24.120 standard with a Macintosh. It would be very, very expensive, 0:11:24.520 --> 0:11:28.760 and ultimately Apple decided that they weren't going to pursue 0:11:28.920 --> 0:11:33.280 quick Scan as a commercial product, but as part of 0:11:33.280 --> 0:11:38.840 the actual development, Perlmand created a video codec called Road Pizza, 0:11:39.000 --> 0:11:44.360 or at least informally called road Pizza. It's usually called 0:11:44.360 --> 0:11:48.640 the Apple video codec. But what is a codec. That's 0:11:48.640 --> 0:11:52.160 a word we used to describe a technology that can 0:11:52.440 --> 0:11:57.200 encode and decode a digital data signal. The word itself 0:11:57.320 --> 0:12:01.560 is a combination of coder and d coder code deck. 0:12:02.520 --> 0:12:06.319 It can be hardware. It typically is software the way 0:12:06.320 --> 0:12:08.200 we talk about today, but it can be a piece 0:12:08.200 --> 0:12:10.760 of hardware as well. And there are lots of different 0:12:10.800 --> 0:12:14.840 types of codex. There's not just one single version. Some 0:12:14.960 --> 0:12:18.080 are used to convert analog signals to digital signals or 0:12:18.200 --> 0:12:21.800 vice versa. Some are used as a compression technique to 0:12:21.880 --> 0:12:25.760 reduce the file size for digital information to make it 0:12:25.840 --> 0:12:29.840 manageable for the purposes of playback storage and transfers. But 0:12:30.000 --> 0:12:33.600 they all take some form of input and transform it 0:12:33.679 --> 0:12:36.080 in some way. If you have the same codec on 0:12:36.160 --> 0:12:38.800 two ends, like if one person has a CODEC on 0:12:39.240 --> 0:12:41.319 their machine and you have a codec on your machine, 0:12:41.320 --> 0:12:44.319 it's the same codec, then you can use that to 0:12:44.679 --> 0:12:47.800 encode information, send it to your friend. They receive it, 0:12:47.880 --> 0:12:49.760 they can then run it through the codec which will 0:12:49.880 --> 0:12:53.400 decode that information back into its original format, and then 0:12:53.440 --> 0:12:55.199 they can do whatever they need to do with it. 0:12:55.679 --> 0:12:58.440 And in the meantime, you can do stuff like compress 0:12:58.520 --> 0:13:03.600 it or change the style of signal. So interestingly, Apple 0:13:03.600 --> 0:13:07.960 would announce that it was working on a multimedia enabling product. 0:13:08.160 --> 0:13:10.680 They had a name for it, they called it quick Time, 0:13:11.000 --> 0:13:14.480 and they announced this in n at a conference, So 0:13:14.520 --> 0:13:19.640 this was public information, but behind the scenes, there were 0:13:19.720 --> 0:13:22.520 only a few people who were even aware that Apple 0:13:22.640 --> 0:13:26.760 was trying to pursue such a thing, and very few 0:13:26.800 --> 0:13:31.480 people were actually attached to the project. Bruce Leak would 0:13:32.440 --> 0:13:36.000 end up actually kind of volunteering for this. He heard 0:13:36.040 --> 0:13:40.280 about the project from this conference, didn't know anything else 0:13:40.320 --> 0:13:43.560 about it. He hadn't heard anything internally about it, but 0:13:43.720 --> 0:13:46.600 he had just started wrapping up work on a previous 0:13:46.640 --> 0:13:49.800 project he was in charge of over at Apple and 0:13:49.880 --> 0:13:54.080 thought that this was a really interesting challenge. So he 0:13:54.200 --> 0:13:56.560 said in a panel discussion in two thousand eighteen that 0:13:56.640 --> 0:13:59.319 he and others had to actually ask around about this 0:13:59.360 --> 0:14:01.640 because they all thought it was a cool project, and 0:14:01.760 --> 0:14:04.800 ultimately they ended up there because Apple had sort of 0:14:04.840 --> 0:14:07.280 made this commitment that they were going to create this 0:14:07.880 --> 0:14:10.480 this software suite, but they did not yet have a 0:14:10.559 --> 0:14:13.440 roadmap on how to actually get there. In fact, originally 0:14:13.760 --> 0:14:18.800 Apple was talking about collaborating with third parties to develop 0:14:18.960 --> 0:14:24.280 this multi media enabling platform. Ultimately, they would choose to 0:14:24.480 --> 0:14:27.320 not do that. They decided to do it all internally. 0:14:27.840 --> 0:14:31.800 Carlman's quick Scan would never become a commercial product, as 0:14:31.800 --> 0:14:35.240 I mentioned before, largely because it had that specialized chip, 0:14:35.280 --> 0:14:38.960 but the road Pizza codec lived on to become part 0:14:39.080 --> 0:14:42.720 of quick Time, so part of the quick Scan project 0:14:42.760 --> 0:14:46.760 would become an integral part of the quick Time suite. 0:14:47.280 --> 0:14:50.560 Much of what would become quick Time emerged from various 0:14:50.640 --> 0:14:54.280 research teams within Apple's Advanced Technology Group or a t G, 0:14:55.040 --> 0:14:59.960 including the compression methodology. So this wasn't necessarily one group 0:15:00.040 --> 0:15:03.520 for people who just started programming. They actually drew upon 0:15:03.560 --> 0:15:07.360 the expertise and the contributions of lots of different people 0:15:07.400 --> 0:15:10.640 at Apple who happened to be working on related technologies 0:15:10.680 --> 0:15:13.840 at the time. So let's talk about compression for a second. 0:15:14.000 --> 0:15:16.760 That's tricky stuff. Not only do you have to figure 0:15:16.800 --> 0:15:19.680 out how to maintain the integrity of the information you 0:15:19.720 --> 0:15:23.480 planned to store or to send while it takes up 0:15:23.600 --> 0:15:26.920 less space with video, you have another issue. You have 0:15:26.960 --> 0:15:29.920 to figure out an efficient way to unpack it. You 0:15:30.000 --> 0:15:32.960 have to how how to decompress it. Efficiently, because if 0:15:33.000 --> 0:15:35.240 it takes too long to decompress when you want to 0:15:35.280 --> 0:15:38.840 play the video back, you get delays in playback, and 0:15:38.880 --> 0:15:41.520 that is frustrating. No one would have wanted to use 0:15:41.600 --> 0:15:44.400 quick time if it took a really long time from 0:15:44.400 --> 0:15:47.560 pushing the play button to actually getting video to play back. 0:15:47.960 --> 0:15:50.880 So that was a big challenge. The other big challenge, obviously, 0:15:51.000 --> 0:15:54.760 is how do you compress stuff without losing too much data. 0:15:54.920 --> 0:15:58.840 That's the problem with lossy formats, and I've talked about 0:15:58.880 --> 0:16:03.080 that a lot in previous episodes. A lossy format is 0:16:03.160 --> 0:16:06.880 one in which you essentially get rid of any information 0:16:06.920 --> 0:16:10.800 that is deemed to be superfluous, unnecessary, what have you. 0:16:11.480 --> 0:16:15.280 All that gets tossed aside because if you can't see 0:16:15.320 --> 0:16:18.440 it or perceive it, then it doesn't really matter, and 0:16:18.480 --> 0:16:21.080 then you just keep the absolutely necessary stuff. In that way, 0:16:21.120 --> 0:16:26.160 you can shrink file sizes, but that obviously raises questions 0:16:26.240 --> 0:16:31.320 as to who determines what is acceptable for loss So 0:16:31.400 --> 0:16:33.640 these were big problems that they had to tackle, but 0:16:33.800 --> 0:16:35.880 they got to work on it. And I'll talk a 0:16:35.880 --> 0:16:39.000 little bit more about their development process in just a moment, 0:16:39.040 --> 0:16:42.400 but first let's take a quick break to thank our sponsor. 0:16:49.920 --> 0:16:52.440 During the development of quick Time, Leak and his team 0:16:52.520 --> 0:16:55.680 encountered lots of different challenges. One was just getting the 0:16:55.680 --> 0:16:58.640 timing right on video and sound and making sure that 0:16:58.680 --> 0:17:01.720 they would stay in synchronous station. As Leak would say 0:17:01.800 --> 0:17:06.200 in the February panel discussion at the Computer History Museum event, 0:17:06.920 --> 0:17:10.679 we think of video as playing back at thirty frames 0:17:10.800 --> 0:17:13.480 or sixty fields per second. I talked about that in 0:17:13.520 --> 0:17:17.440 the r c A podcasts recently, but Leak said, in reality, 0:17:17.480 --> 0:17:20.879 it's more like fifty nine point nine seven frames per second, 0:17:20.880 --> 0:17:25.399 which is really close, but uh, it can make a 0:17:25.440 --> 0:17:28.359 difference over time. If your video is just a few 0:17:28.400 --> 0:17:30.800 seconds or a couple of minutes long, the differences might 0:17:30.840 --> 0:17:34.520 not really get to be noticeable, but as videos get longer, 0:17:35.240 --> 0:17:38.520 that discrepancy can lead to the audio and video getting 0:17:38.520 --> 0:17:42.840 further and further out of synchronization, which becomes really distracting 0:17:42.880 --> 0:17:45.560 over time. And they wanted their tool to scale up 0:17:45.600 --> 0:17:48.560 so that they could be used for longer videos, so 0:17:48.600 --> 0:17:51.680 they had to be more precise when designing the encoding tools. 0:17:52.160 --> 0:17:56.760 Another challenge was reading information from c d s. Early on, 0:17:57.000 --> 0:17:59.760 as a computer would seek out information on a CD, 0:18:00.000 --> 0:18:01.840 you would actually have to find where in the c 0:18:02.040 --> 0:18:06.240 D the data was located. Everything else on the computer 0:18:06.280 --> 0:18:09.800 would just stop. Essentially, the computer is thing, hang on second, 0:18:09.840 --> 0:18:11.880 I'm looking for that for you, But you don't want 0:18:11.880 --> 0:18:14.600 that to happen while you're watching video either. So Apple 0:18:14.640 --> 0:18:16.639 engineers had to work really hard to come up with 0:18:16.680 --> 0:18:21.520 solutions that would allow for a CD ROM to seek 0:18:21.520 --> 0:18:24.439 out information in the background in anticipation of when it 0:18:24.440 --> 0:18:28.159 would need to pull that data for playback purposes. And 0:18:28.200 --> 0:18:31.560 so there was some hardware stuff they were working on, 0:18:31.640 --> 0:18:35.320 not just the software side. They also brought on an 0:18:35.359 --> 0:18:37.640 audio teams so that QuickTime would be able to work 0:18:37.680 --> 0:18:40.520 with multiple channels of audio, and that it would be 0:18:40.520 --> 0:18:43.760 able to work with different sample rates and sample sizes 0:18:43.800 --> 0:18:47.200 of audio and mix them all down to work with video. 0:18:47.640 --> 0:18:51.360 So this would involve converting all that audio into a 0:18:51.440 --> 0:18:54.840 single format that would work with the associated video files 0:18:54.880 --> 0:18:58.439 no matter what format the original audio is in. The 0:18:58.520 --> 0:19:01.480 result was a suite of soft where that was remarkably 0:19:01.800 --> 0:19:05.399 useful and innovative for the time. So, for example, if 0:19:05.440 --> 0:19:08.520 you were watching a video on your home machine and 0:19:08.600 --> 0:19:11.400 your processor didn't quite have the umph to keep up 0:19:11.440 --> 0:19:15.560 with demands, rather than have the video stall out or 0:19:15.720 --> 0:19:19.160 two worse, have the videos start to lag behind the audio. 0:19:19.720 --> 0:19:22.520 Quick Time would adjust the frame rate. You would get 0:19:22.560 --> 0:19:25.399 fewer frames per second. That would end up making the 0:19:25.440 --> 0:19:28.679 action a little more jittery and jagged, but the action 0:19:28.720 --> 0:19:31.800 would stay in sync with the soundtrack. So instead of 0:19:31.880 --> 0:19:35.080 the video slowing down with the same number of frames 0:19:35.400 --> 0:19:37.560 and the audio getting more and more out of sync, 0:19:38.400 --> 0:19:43.280 the video would just cut out, uh, interstitial pictures. So 0:19:43.320 --> 0:19:46.080 you might say, all right, well, to keep up with 0:19:46.200 --> 0:19:50.480 the audio, we're gonna cut frames two, three, We'll keep four, 0:19:50.600 --> 0:19:53.560 so we'll go from one to four to seven to 0:19:54.080 --> 0:19:58.760 ten or whatever. This does make it much more jittery, 0:19:58.800 --> 0:20:02.080 as I said, but at least you're sticking with the 0:20:02.119 --> 0:20:05.959 audio instead of having the audio quickly get ahead of 0:20:05.960 --> 0:20:09.200 what you're watching. Now, if you were using a then 0:20:09.240 --> 0:20:12.560 current Mac two C I system that would be the 0:20:13.480 --> 0:20:16.840 a standard Mac at the time that quick Time was released, 0:20:17.640 --> 0:20:19.840 you would be able to play a video at a 0:20:19.880 --> 0:20:24.399 blistering ten whole frames per second at a resolution of 0:20:24.400 --> 0:20:28.240 a hundred sixty by one pixels. And yeah, being a 0:20:28.320 --> 0:20:31.640 little facetious with that description, film plays back at twenty 0:20:31.680 --> 0:20:37.399 four frames per second um. If you have stop motion animation. 0:20:37.760 --> 0:20:40.440 A lot of stop motion animators would animate at twelve 0:20:40.480 --> 0:20:43.080 frames per second in order to kind of save a 0:20:43.160 --> 0:20:47.399 little bit on labor. But typically you want to stick 0:20:47.440 --> 0:20:50.520 too closer to twenty four and as I said, standard 0:20:50.560 --> 0:20:54.000 video is closer to thirty. They managed ten, but still 0:20:54.160 --> 0:20:56.760 it was a phenomenal achievement. Together, the team was able 0:20:56.800 --> 0:20:59.600 to meet the goal of getting a multimedia enabling product 0:20:59.640 --> 0:21:03.800 ready to ship within a year. Bruce Leak showed off 0:21:03.840 --> 0:21:07.000 the product at the Worldwide Developers Conference in May nine. 0:21:08.600 --> 0:21:11.840 The video he showed at that event was Apple's iconic 0:21:12.040 --> 0:21:14.760 nineteen eighty four commercial for the Macintosh, one of the 0:21:14.760 --> 0:21:17.760 most famous commercials of all time, directed by none other 0:21:17.840 --> 0:21:22.000 than Ridley Scott. The beta version for quick Time would 0:21:22.040 --> 0:21:25.200 become available in the summer of nineteen and the finished 0:21:25.200 --> 0:21:31.080 product followed on December two. The first third party product 0:21:31.160 --> 0:21:34.960 to feature the technology was a CD rom book on 0:21:35.160 --> 0:21:38.840 desk called From Alice to Ocean, which was about various 0:21:38.880 --> 0:21:45.280 locations across Australia. Sorry Australians, I didn't mean to butcher 0:21:45.359 --> 0:21:49.639 your accent. The original release of quick Time included three 0:21:49.680 --> 0:21:55.000 codex One was the Apple video codec, essentially Road Pizza 0:21:55.480 --> 0:21:58.240 and that one was meant for live video, The second 0:21:58.320 --> 0:22:02.359 codek was responsible for coding and decoding animation, and the 0:22:02.480 --> 0:22:06.720 third was a codec for eight bit images. Many many 0:22:06.760 --> 0:22:09.399 others would follow for a quick Time over the years. 0:22:09.880 --> 0:22:12.800 Quake Time also included a player, probably the most famous 0:22:13.600 --> 0:22:19.159 part of the quick Time suite. It also had a players. Essentially, 0:22:19.160 --> 0:22:21.960 it's a piece of software cabable of playing back files 0:22:22.040 --> 0:22:24.960 saved in the quick Time time file format. And this 0:22:25.000 --> 0:22:27.320 is where we start running into a problem, actually, or 0:22:27.320 --> 0:22:31.080 at least a frustrating issue. Apple began referring to the codec, 0:22:32.000 --> 0:22:35.880 the player, and the file format as quick Time, so 0:22:36.000 --> 0:22:40.560 all three of these different things got the same name. However, 0:22:41.040 --> 0:22:44.800 over time the software would change, and as digital archivist 0:22:44.880 --> 0:22:48.080 Becca Bender wrote in her paper Too Many quick Times, 0:22:48.240 --> 0:22:49.600 which by the way, is a great read. It's a 0:22:49.680 --> 0:22:52.040 very short read. I recommend you you seek it out. 0:22:52.680 --> 0:22:55.000 It makes it really tricky to have a meaningful conversation 0:22:55.040 --> 0:22:57.879 about quick Time. There are two different media players that 0:22:57.960 --> 0:23:00.439 have the name quick Time. I'll talk about those a 0:23:00.440 --> 0:23:04.480 little bit later. There are two different and actually incompatible 0:23:04.520 --> 0:23:08.000 file types, and they're they're both not only are they 0:23:08.040 --> 0:23:10.120 called quick Time, they both have the same file type 0:23:10.160 --> 0:23:13.080 designation of dot m o V, though, to make things 0:23:13.119 --> 0:23:16.080 even more confusing, they can also be dot QT. And 0:23:16.880 --> 0:23:19.800 there is a codec called quick time. Not all quick 0:23:19.840 --> 0:23:22.280 times are equal. And this the reason this is a 0:23:22.320 --> 0:23:24.359 big deal, you might wonder, well, why do you care? 0:23:25.400 --> 0:23:28.119 Is that should you ever need to access a specific 0:23:28.240 --> 0:23:31.840 video file from say an archive, Let's say, do you 0:23:32.000 --> 0:23:35.200 know of a digital video you need to get access 0:23:35.240 --> 0:23:38.320 to it? It's useful to know whether you'll be able 0:23:38.359 --> 0:23:41.639 to play it given particular software or equipment that you 0:23:41.680 --> 0:23:45.120 have available. And I'll talk more about that a little 0:23:45.119 --> 0:23:47.480 bit later. And while I'm on the subject of confusion, 0:23:48.320 --> 0:23:51.600 if you are a gamer, you're likely familiar with the 0:23:51.680 --> 0:23:55.360 concept of quick time events, but that is a different thing. 0:23:55.680 --> 0:23:58.920 Quick time events don't have anything to do with Apple's 0:23:59.040 --> 0:24:03.080 quick time. The QuickTime event quick time in those cases 0:24:03.200 --> 0:24:06.679 are two separate words quick time, the product from Apple 0:24:06.840 --> 0:24:09.760 is done as one word quick time. Now. Not only 0:24:10.480 --> 0:24:13.520 was QuickTime a pioneer product for computer video, it was 0:24:13.600 --> 0:24:17.479 the first Apple system software product to be sold on 0:24:17.560 --> 0:24:22.640 its own. Previous system software products would come pre installed 0:24:22.640 --> 0:24:25.719 on new hardware, which would leave out anyone who already 0:24:25.720 --> 0:24:28.359