WEBVTT 00:00.000 --> 00:10.000 Hello everyone, I'm happy to see this many people this morning, also a bit intimidated. 00:10.000 --> 00:13.000 I'm just filling in for somebody else, so this is going to be a bit shorter. 00:13.000 --> 00:19.000 I'm going to talk about why I wrote it in P4MUPSA and why it's kind of painful, but also fun, maybe. 00:19.000 --> 00:24.000 First about me, my name is Dennis, I'm a software engineer from Germany. 00:24.000 --> 00:28.000 My day job is working at Twitch, but more importantly for this, 00:28.000 --> 00:31.000 and one of the main contributors to OBS Studio. 00:31.000 --> 00:35.000 I've also done a couple of things for, for example, another open source project. 00:35.000 --> 00:38.000 And I do know what an MP4 file is. 00:38.000 --> 00:44.000 If you don't, MP4 is probably the most common most widespread media container, 00:44.000 --> 00:49.000 so it contains audio and video streams you can click play, and works a little bit of history. 00:49.000 --> 00:53.000 It kind of is based on what Apple created in the 90's called, 00:53.000 --> 00:57.000 and file format or MOV. 00:57.000 --> 01:01.000 And then the ISO, the International Standards Organization, they took it, 01:01.000 --> 01:05.000 and extended it into MP4, and then now abstracted it further into, 01:05.000 --> 01:11.000 what's called ISO BMFF for based media file format and the CMAF, which is not relevant here, but it exists. 01:11.000 --> 01:12.000 But also what is OBS? 01:12.000 --> 01:17.000 It's free and not so a select streaming and recording solution, GPLPQ. 01:17.000 --> 01:20.000 We have first party packages for Windows, Linux, and MacOS. 01:20.000 --> 01:25.000 And also, tens of millions of users at this point with a massive variety of skill levels, 01:25.000 --> 01:26.000 which is going to be important. 01:26.000 --> 01:30.000 And that also means it's mostly used without backup recording, 01:30.000 --> 01:34.000 so one of our highest priorities is avoid data loss. 01:34.000 --> 01:37.000 And also we have tons of different use cases. 01:37.000 --> 01:39.000 Game streaming is a big one, of course, twitching all that, 01:39.000 --> 01:43.000 but these days it's everything from features recording lessons 01:43.000 --> 01:48.000 to we heard about doctors recording ultrasound machine outputs or all kinds of stuff. 01:49.000 --> 01:51.000 So that brings us to the problem. 01:51.000 --> 01:54.000 To produce faster useful for most users, we need MP4, 01:54.000 --> 01:57.000 to avoid data loss we can't use MP4. 01:57.000 --> 02:00.000 And the reason for that is the structure of MP4. 02:00.000 --> 02:03.000 It's going to be simplified, but the basic thing is, 02:03.000 --> 02:07.000 MP4 consists of these boxes or atoms in the Apple terminology. 02:07.000 --> 02:09.000 They contain different things. 02:09.000 --> 02:14.000 The most important one for us is the media data box, which has all the media data in it, 02:14.000 --> 02:17.000 but it is by definition unstructured. 02:17.000 --> 02:21.000 You only can get meaning to what's in it from the movie box, 02:21.000 --> 02:27.000 the MOV box at the end, which contains descriptions of where all the samples are, 02:27.000 --> 02:29.000 how long they are and all that. 02:29.000 --> 02:32.000 And it is at the end because that's how most MP4 files are written, 02:32.000 --> 02:34.000 but that is also the main problem, 02:34.000 --> 02:38.000 because if you stop writing before you write it, 02:38.000 --> 02:41.000 like you lose power, your storage is for whatever, 02:41.000 --> 02:43.000 you file is toast. 02:44.000 --> 02:47.000 You can't really recover it without a lot of work. 02:47.000 --> 02:51.000 There are some methods, you can do some horistics to detect all the video data 02:51.000 --> 02:54.000 and try to get it together, but it's very difficult on most users, 02:54.000 --> 02:55.000 I'm not going to figure out. 02:55.000 --> 02:58.000 So since we can't use MP4, what have we been doing? 02:58.000 --> 02:59.000 Yes. 02:59.000 --> 03:02.000 So until 2019, we've been just using FLV, 03:02.000 --> 03:04.000 because that's what we throw over our team, 03:04.000 --> 03:06.000 for live streams, why not dump it to disk? 03:06.000 --> 03:08.000 I can't believe it took until 2019, 03:08.000 --> 03:11.000 it's a format that is supported by nothing. 03:12.000 --> 03:14.000 And I also didn't support back then, 03:14.000 --> 03:16.000 didn't support multiple video tracks and all that. 03:16.000 --> 03:20.000 So in 2019, when we also wanted to multiple audio tracks, 03:20.000 --> 03:24.000 we switched to MKV, which is much more modern open format, 03:24.000 --> 03:29.000 but it also has this use, Apple and Adobe. 03:29.000 --> 03:31.000 They don't support it. 03:31.000 --> 03:34.000 And that, again, makes the problematic for all users. 03:34.000 --> 03:35.000 They also cut a lot of things, 03:35.000 --> 03:38.000 so you can't drag it into disk or whatever. 03:38.000 --> 03:43.000 It's a nice format of theory and practice, it's just not really for us. 03:43.000 --> 03:46.000 Now, MP4 has an extension or an update to it, 03:46.000 --> 03:50.000 called the Fragmented MP4, which sounds like it would be great for us. 03:50.000 --> 03:53.000 In this case, instead of having the movie books at the end of all the data, 03:53.000 --> 03:56.000 you have a smaller one at the very beginning, 03:56.000 --> 03:59.000 that only contains the absolutely necessary data 03:59.000 --> 04:01.000 to initialize here to the coder, 04:01.000 --> 04:04.000 but it doesn't contain any information about the actual media samples. 04:04.000 --> 04:08.000 Those are all stored in the movie Fragment box, the MOLF1. 04:08.000 --> 04:10.000 And this one is the sort of every fragment, 04:10.000 --> 04:14.000 and every fragment is essentially decodable independently. 04:14.000 --> 04:18.000 So this means if your file is now concatenated, 04:18.000 --> 04:22.000 this dice or whatever, you can still play it back up until that point, 04:22.000 --> 04:24.000 so you only use a couple of seconds. 04:24.000 --> 04:26.000 But, again, we have problems. 04:26.000 --> 04:27.000 Windows. 04:27.000 --> 04:30.000 Microsoft doesn't really support it. 04:30.000 --> 04:33.000 If you open a Fragmented MP4 file with the default Windows media player, 04:33.000 --> 04:35.000 it'll play it like a stream. 04:35.000 --> 04:37.000 You can't see it just play it like a live stream. 04:37.000 --> 04:39.000 It also doesn't show the duration and explorer and whatnot, 04:39.000 --> 04:41.000 but it's not just Windows. 04:41.000 --> 04:45.000 So it's also not supported by some other software. 04:45.000 --> 04:48.000 The venture resolve used to just spread up crash to the desktop, 04:48.000 --> 04:51.000 if you even navigate to a folder that has one in it. 04:51.000 --> 04:54.000 And it's also really slow, 04:54.000 --> 04:56.000 because in order to get the full duration, 04:56.000 --> 04:59.000 the player will generally read every single Fragments, 04:59.000 --> 05:01.000 or the Fragment header, at least. 05:01.000 --> 05:04.000 And if you own a network share, or a mechanical hot roof, 05:04.000 --> 05:06.000 that is really slow. 05:06.000 --> 05:09.000 Yeah. 05:09.000 --> 05:13.000 And that's also a good end of work. 05:13.000 --> 05:16.000 So it's a terrible user experience. 05:16.000 --> 05:19.000 And we tried and we reverted back to MPV. 05:19.000 --> 05:22.000 But this is where I had an idea. 05:22.000 --> 05:25.000 What if we just, you know, do both? 05:25.000 --> 05:27.000 We write it as Fragment header, 05:27.000 --> 05:29.000 let's say, let's do that before movie box. 05:29.000 --> 05:30.000 Everybody's happy, right? 05:30.000 --> 05:32.000 Well, no. 05:32.000 --> 05:35.000 Dispect us agrees. 05:35.000 --> 05:38.000 And they are right, because you can only have one movie box. 05:38.000 --> 05:41.000 So I came up with a bit of a trick. 05:41.000 --> 05:44.000 You have that free Adam there at the beginning. 05:44.000 --> 05:45.000 I didn't explain it earlier, 05:45.000 --> 05:46.000 but it's essentially a placeholder. 05:46.000 --> 05:50.000 FFMP users, so when the data box in the normal 05:50.000 --> 05:52.000 and before gets too large, 05:52.000 --> 05:55.000 you need to have a longer header with an extended size field. 05:55.000 --> 05:57.000 It's essentially sacrificial eight bytes. 05:57.000 --> 05:59.000 So you can overwrite to get the larger size header. 05:59.000 --> 06:03.000 But we can abuse it a little bit here and get creative. 06:03.000 --> 06:06.000 Because again, just overwrite it with an M data header. 06:06.000 --> 06:10.000 And turn the entire file into a giant data box 06:10.000 --> 06:12.000 that by definition has no structure. 06:12.000 --> 06:14.000 And then slap the movie box at the end. 06:14.000 --> 06:16.000 Now, we have the file that works normally. 06:16.000 --> 06:20.000 If writing dies, okay, we still have the Fragment 06:20.000 --> 06:22.000 that file you can re-max it with FFMP or OBS. 06:22.000 --> 06:25.000 Get it normally before, but if writing succeeds, 06:25.000 --> 06:27.000 we have a normal looking MP4, 06:27.000 --> 06:29.000 and the players will be normally wiser. 06:29.000 --> 06:32.000 So, why do it ourselves? 06:32.000 --> 06:35.000 Why not try to upstream the TFMP? 06:35.000 --> 06:37.000 That's painful, sometimes. 06:37.000 --> 06:40.000 But I'm mailing this shavings side. 06:40.000 --> 06:43.000 It might not be accepted because it's kind of niche. 06:43.000 --> 06:47.000 It also could take a wall before you get merch, 06:47.000 --> 06:50.000 like we talked a month, maybe years, until attack us out. 06:50.000 --> 06:52.000 Into Ali, et cetera, I think there. 06:52.000 --> 06:54.000 And we ship Ubuntu LTS packages, 06:54.000 --> 06:56.000 and we want to have this available for you 06:56.000 --> 06:58.000 in less than eight years. 06:58.000 --> 07:01.000 So, doing natively, 07:01.000 --> 07:03.000 we can have a lot more flexibility. 07:03.000 --> 07:06.000 We can do a lot of experimentation. 07:06.000 --> 07:09.000 It might be fun, and I might learn something, 07:09.000 --> 07:11.000 which I'm not too afraid of. 07:11.000 --> 07:14.000 So, this is a little high level of view. 07:14.000 --> 07:17.000 It's just a piece of code, just for illustrative purposes. 07:17.000 --> 07:20.000 So, I'm very much still followed the FFMP example, 07:20.000 --> 07:23.000 because what they do is fundamentally very simple. 07:23.000 --> 07:25.000 And, you know, that makes sense here for us as well. 07:25.000 --> 07:28.000 We just have one method for each box type. 07:28.000 --> 07:30.000 It's largely based on the ISO spec. 07:30.000 --> 07:32.000 I had to look at FFMP and G-pack, 07:32.000 --> 07:36.000 which is another open source project for dealing with media files. 07:36.000 --> 07:38.000 Because I don't have the latest ISO spec, 07:38.000 --> 07:41.000 it's all pay world, I'll rent about that later. 07:41.000 --> 07:45.000 And, yeah, so I had to use them as references for some stuff 07:45.000 --> 07:48.000 that's not documented or poorly documented elsewhere. 07:48.000 --> 07:50.000 But, I strictly limited it to what we need. 07:50.000 --> 07:52.000 So, it's only the code, so it'll be a supported only 07:52.000 --> 07:54.000 experimentation on keyframes. 07:54.000 --> 07:57.000 And, also, use the opportunity to get us some new fun features. 07:57.000 --> 07:59.000 No, we have like chapter markers, so people can hit the button 07:59.000 --> 08:02.000 and then in the editor, they see like the marker 08:02.000 --> 08:04.000 and for highlights and stuff like that. 08:04.000 --> 08:07.000 So, the end result was one big aspect request. 08:07.000 --> 08:09.000 It's about 2,900 lines for just the mixer, 08:09.000 --> 08:12.000 the rest is like your eyes, stuff, and all that crap. 08:13.000 --> 08:16.000 Took a few days, then the review took about a month. 08:16.000 --> 08:19.000 And then it was mostly done with a couple dark fixes, 08:19.000 --> 08:21.000 but it's been mostly stable. 08:21.000 --> 08:26.000 But, one fun thing at hand, like this was made 29th to this later. 08:26.000 --> 08:29.000 Somebody submitted a patch to FMP to the same thing. 08:29.000 --> 08:32.000 Pure coincidence, I've not talked to Martin before, 08:32.000 --> 08:36.000 and he cited Apple having apparently done something similar. 08:36.000 --> 08:38.000 After a bit of deliberation on mailing, 08:38.000 --> 08:41.000 it was really quickly and renamed to also use hybrid, 08:41.000 --> 08:44.000 which is, to tell him I came up with, I didn't lobby for that. 08:44.000 --> 08:46.000 But, I think I have all the OBSs so huge. 08:46.000 --> 08:48.000 People are going to call it that. 08:48.000 --> 08:50.000 Let's just do the same in FMP. 08:50.000 --> 08:52.000 So, yeah, you can do it in FMP now. 08:52.000 --> 08:56.000 I think it's maybe in the 7th point, one tag, I'm not entirely sure. 08:56.000 --> 08:59.000 But, yeah, if you set that, it'll do the pretty much the same thing. 08:59.000 --> 09:04.000 Small details, but yeah, you can do stay recording with FMP as well now. 09:05.000 --> 09:08.000 So, some fun ideas, what to do with that. 09:08.000 --> 09:11.000 I wanted to have a demo, but I ran out of time. 09:11.000 --> 09:14.000 So, the first one, somebody on FMP is not really hybrid, 09:14.000 --> 09:16.000 because it's not both at the same time. 09:16.000 --> 09:19.000 So, I think it might not do it anyway. 09:19.000 --> 09:22.000 So, what we can do with streaming with HLS. 09:22.000 --> 09:24.000 We have this thing called Bidrange. 09:24.000 --> 09:27.000 We can point into offsets into a file, 09:27.000 --> 09:30.000 rather than just having entire thoughts for each of the segments. 09:30.000 --> 09:33.000 So, what we could do is have an HLS playlist 09:33.000 --> 09:36.000 and point into the hidden area of the file, 09:36.000 --> 09:38.000 and stream it like a normal HLS file. 09:38.000 --> 09:41.000 But at the same time, you can use the file for progressive download, 09:41.000 --> 09:42.000 and it'll be a normal NB4. 09:42.000 --> 09:45.000 You can also do server-side concatenation. 09:45.000 --> 09:49.000 It's something I talked about with a friend who had a use case of 09:49.000 --> 09:51.000 essentially recording directly to update storage, 09:51.000 --> 09:54.000 but still wanting a file that works well. 09:54.000 --> 09:56.000 In these cases, it's a bit more complicated, 09:56.000 --> 09:58.000 because it's not using Google Cloud Storage, 09:58.000 --> 10:00.000 but with Google Cloud Storage, you could just write the new header 10:00.000 --> 10:03.000 and tell the Cloud Storage to concatenate the server-side, 10:03.000 --> 10:07.000 and you just get a new file that is progressive for all intents and purposes. 10:07.000 --> 10:09.000 You could also do this on the fly. 10:09.000 --> 10:11.000 I think it's not exactly the same, 10:11.000 --> 10:12.000 but Vimeo does something like this, 10:12.000 --> 10:15.000 where they only store video-in-set-mended formats. 10:15.000 --> 10:17.000 But when you download it, they on the fly do concatenation, 10:17.000 --> 10:19.000 which is pretty cool. 10:19.000 --> 10:22.000 So, what to come? 10:22.000 --> 10:25.000 Well, I'm also going to do MOV or QuickTime support, 10:25.000 --> 10:27.000 because ProRes, people want ProRes, 10:28.000 --> 10:30.000 at a time go track, and a couple of fun things in there, 10:30.000 --> 10:32.000 not too important. 10:32.000 --> 10:34.000 And last night's audio is hard. 10:34.000 --> 10:36.000 We already heard about that earlier. 10:36.000 --> 10:39.000 Priming samples are one example that I went into, 10:39.000 --> 10:41.000 so most audio encoders like AAC or Opus. 10:41.000 --> 10:43.000 They will have the number of samples at the beginning 10:43.000 --> 10:47.000 that are silent to prime the encoder decoder. 10:47.000 --> 10:49.000 And it obviously didn't really care about that, 10:49.000 --> 10:52.000 so we had some audio-desync with some encoders. 10:52.000 --> 10:53.000 They had to fix. 10:53.000 --> 10:54.000 I also found a similar bug-in-effort fan pick, 10:54.000 --> 10:56.000 that provided some solos at least. 10:57.000 --> 10:58.000 Videos are too. 10:58.000 --> 11:00.000 We already heard about frame-reordering earlier, 11:00.000 --> 11:01.000 which is the devil, 11:01.000 --> 11:04.000 and makes all of this more complicated than needs to be. 11:04.000 --> 11:06.000 And before it's pretty simple though, 11:06.000 --> 11:08.000 the spec is huge. 11:08.000 --> 11:10.000 There's a lot of crap in there you don't need. 11:10.000 --> 11:12.000 There are things in there like, 11:12.000 --> 11:15.000 hey, why not use an edit list to cut out part of the video 11:15.000 --> 11:18.000 and reference an entirely different file for these media samples. 11:18.000 --> 11:19.000 Things that nobody really implements, 11:19.000 --> 11:23.000 but they had higher aspirations from writing the spec, I guess. 11:23.000 --> 11:26.000 And yeah, also I learned that days of hard work 11:26.000 --> 11:28.000 can be summarized in like five minutes, 11:28.000 --> 11:31.000 one minute if somebody knows what 94 is. 11:31.000 --> 11:34.000 All right, some thanks. 11:34.000 --> 11:35.000 At the same time back of course, 11:35.000 --> 11:37.000 they have a lot of cool stuff. 11:37.000 --> 11:39.000 They document the undocumented. 11:39.000 --> 11:41.000 I wish they had some more comments in their code, 11:41.000 --> 11:43.000 but hey, it's what it is. 11:43.000 --> 11:45.000 GPAC is also great. 11:45.000 --> 11:48.000 MP4 box in general is super great for dealing with MP4. 11:48.000 --> 11:51.000 It was a bit too much for what we wanted to do. 11:51.000 --> 11:54.000 But they probably have the most complete feature settings, 11:54.000 --> 11:56.000 including some of the more niche things that are in the spec 11:56.000 --> 11:58.000 that nobody else implements. 11:58.000 --> 12:00.000 Apple's old documentation is also great. 12:00.000 --> 12:04.000 They have some good examples for how priming samples work and how to deal with that. 12:04.000 --> 12:06.000 And then I don't want to thank the AI so, 12:06.000 --> 12:09.000 because the paywalling of these specs is really annoying. 12:09.000 --> 12:10.000 MP4 alone. 12:10.000 --> 12:14.000 You basically need three different documents 12:14.000 --> 12:16.000 that are all like 200 euros or so, 12:16.000 --> 12:17.000 maybe 300 euros, 12:17.000 --> 12:20.000 just to get audio and video working. 12:21.000 --> 12:23.000 And if you want to stuff like PCM, 12:23.000 --> 12:24.000 it's a separate document. 12:24.000 --> 12:25.000 If you want to have, 12:25.000 --> 12:26.000 I don't know, 12:26.000 --> 12:27.000 CMF and Dash compatibility. 12:27.000 --> 12:29.000 That's another document that's expensive. 12:29.000 --> 12:31.000 It's a whole mess and it's really annoying that 12:31.000 --> 12:33.000 what is arguably the most common, 12:33.000 --> 12:36.000 most important format is not accessible. 12:36.000 --> 12:38.000 It's a little fun fact. 12:38.000 --> 12:40.000 If you want PCM and MP4, 12:40.000 --> 12:42.000 the spec for that is so short. 12:42.000 --> 12:43.000 The free preview you can do, 12:43.000 --> 12:45.000 or not it's actually an entire thing. 12:45.000 --> 12:48.000 So I recommend doing that. 12:49.000 --> 12:52.000 And with that, I'm already at the end here. 12:53.000 --> 12:55.000 If you want to complain about a house or MP, 12:55.000 --> 12:57.000 you can reach me there. 12:57.000 --> 12:59.000 That's another thing I've been involved in, 12:59.000 --> 13:01.000 that people don't like. 13:01.000 --> 13:02.000 But hopefully, overall, 13:02.000 --> 13:04.000 I think I gave you an idea of how this works 13:04.000 --> 13:05.000 and why we did it. 13:05.000 --> 13:08.000 And hopefully, we solved some uses issues. 13:08.000 --> 13:09.000 And with that, 13:09.000 --> 13:11.000 I am at the end. 13:12.000 --> 13:13.000 Thank you. 13:19.000 --> 13:20.000 All right. 13:20.000 --> 13:22.000 Any questions or remarks? 13:22.000 --> 13:23.000 Sure. 13:23.000 --> 13:26.000 I just like to add that I am the Martin that you mentioned. 13:26.000 --> 13:27.000 Oh, nice. 13:27.000 --> 13:29.000 And it's not that you're making, 13:29.000 --> 13:30.000 you know, 13:30.000 --> 13:32.000 I've heard this meant for this whole feature, 13:32.000 --> 13:35.000 because having also done the same thing, 13:35.000 --> 13:39.000 it's nice that somebody can present it in a nice way. 13:39.000 --> 13:40.000 Thank you. 13:40.000 --> 13:42.000 Thank you for also getting it into FFM pick. 13:42.000 --> 13:44.000 I know I was so that, 13:44.000 --> 13:45.000 Oh, repeat the question. 13:45.000 --> 13:48.000 Yeah. So the person here is Martin 13:48.000 --> 13:51.000 from who contributed this to FFM pick, 13:51.000 --> 13:52.000 who said, 13:52.000 --> 13:54.000 it's nice that I explained it here. 13:54.000 --> 13:55.000 And I will also say, 13:55.000 --> 13:57.000 it's nice that you contributed to it to FFM pick, 13:57.000 --> 13:58.000 because it's just, 13:58.000 --> 13:59.000 you know, 13:59.000 --> 14:00.000 it's what everybody uses. 14:00.000 --> 14:04.000 And I didn't want to deal with the politics and mail-in-linguists. 14:06.000 --> 14:08.000 Anything else? 14:08.000 --> 14:11.000 No. 14:11.000 --> 14:12.000 Cool. 14:12.000 --> 14:14.000 Oh. 14:14.000 --> 14:15.000 If you have a little minute, 14:15.000 --> 14:17.000 can you go back and explain a little bit more 14:17.000 --> 14:19.000 to the actual trick that you used for it? 14:19.000 --> 14:20.000 Oh, sure. 14:20.000 --> 14:22.000 Right. 14:22.000 --> 14:25.000 I regret making this animated now. 14:25.000 --> 14:28.000 All right, let's go from this. 14:28.000 --> 14:30.000 As I mentioned, 14:30.000 --> 14:32.000 so actually let's go even further back, 14:32.000 --> 14:36.000 because I think the graphic for the full thing is super important. 14:37.000 --> 14:39.000 Where is it? There we go. 14:39.000 --> 14:40.000 So as I mentioned, 14:40.000 --> 14:41.000 in the MP4 file, 14:41.000 --> 14:43.000 as it is produced by FFM pick, 14:43.000 --> 14:45.000 and actually recommend it to be done this way, 14:45.000 --> 14:46.000 by the Apple spec, 14:46.000 --> 14:48.000 instead of this free box here. 14:48.000 --> 14:50.000 And the reason is that the MDAT box, 14:50.000 --> 14:52.000 by default, only has a 32-bit size. 14:52.000 --> 14:54.000 So you can only stop to forget about its data. 14:54.000 --> 14:57.000 But if you want to have more than that, 14:57.000 --> 14:58.000 you would have to either over it, 14:58.000 --> 15:00.000 entire file or the trick that came up with is to have 15:00.000 --> 15:02.000 the free box here that's eight bytes. 15:02.000 --> 15:05.000 So you can then overwrite this with the 64, 15:05.000 --> 15:06.000 64-bit size header, 15:06.000 --> 15:07.000 to store up to, 15:07.000 --> 15:08.000 I don't know how to memorize it, 15:08.000 --> 15:09.000 I can't memorize it. 15:09.000 --> 15:12.000 And what I figured is, 15:12.000 --> 15:14.000 why don't we overwrite the, 15:14.000 --> 15:18.000 got them it? 15:18.000 --> 15:19.000 Why don't we overwrite 15:19.000 --> 15:21.000 the free box with an MDAT header, 15:21.000 --> 15:23.000 but just in a fragmented file. 15:23.000 --> 15:28.000 So all of this becomes an MDAT box. 15:28.000 --> 15:31.000 And now everything in here is essentially invisible, 15:31.000 --> 15:34.000 unless you are partially doing something that it shouldn't. 15:34.000 --> 15:37.000 But then we have the movie box that still indexes the samples 15:37.000 --> 15:39.000 that are in here. 15:39.000 --> 15:43.000 And that allows us to have this resilient format 15:43.000 --> 15:46.000 that is still fail-safe. 15:46.000 --> 15:48.000 And one of the fun things about this, 15:48.000 --> 15:49.000 the way we do it, 15:49.000 --> 15:51.000 the feedback doesn't because we don't 15:51.000 --> 15:53.000 interleaf samples as much in this way. 15:53.000 --> 15:55.000 This actually has negative overheads 15:55.000 --> 15:57.000 once you go past a certain duration, 15:57.000 --> 16:00.000 because the movie box is smaller. 16:01.000 --> 16:03.000 And so if I read it out there, 16:03.000 --> 16:05.000 it doesn't go by the hybrid format, 16:05.000 --> 16:06.000 and it can read that. 16:06.000 --> 16:07.000 Yeah. 16:07.000 --> 16:09.000 Yeah, as long as it's spec compliant, 16:09.000 --> 16:10.000 it just reads the movie box, 16:10.000 --> 16:11.000 and then it gets later, 16:11.000 --> 16:14.000 and it knows everything that's not in there. 16:14.000 --> 16:17.000 Yeah, so the movie box is really the main part of the, 16:17.000 --> 16:19.000 and before it contains everything 16:19.000 --> 16:21.000 from the codec description to the samples, 16:21.000 --> 16:22.000 like the offsets into the file, 16:22.000 --> 16:24.000 the duration's and all that. 16:24.000 --> 16:25.000 It doesn't matter what else you have in the file, 16:25.000 --> 16:28.000 it just goes to the start of the data. 16:28.000 --> 16:29.000 Yeah, like you can, 16:29.000 --> 16:30.000 I guess I said, 16:30.000 --> 16:32.000 they have some acceleration with the spec. 16:32.000 --> 16:34.000 Technically, you could reference URLs 16:34.000 --> 16:35.000 in different files as well, 16:35.000 --> 16:36.000 and pull data from there. 16:36.000 --> 16:37.000 It's just that I don't, 16:37.000 --> 16:38.000 I think it doesn't implement it, 16:38.000 --> 16:40.000 and I think GPAC doesn't even, 16:40.000 --> 16:41.000 so you can't really use it. 16:41.000 --> 16:43.000 They also find other fun things in the spec, 16:43.000 --> 16:44.000 like compressed boxes, 16:44.000 --> 16:45.000 because those things get quite hefty, 16:45.000 --> 16:47.000 like four megabytes is not unheard of. 16:47.000 --> 16:49.000 So they introduce compression, 16:49.000 --> 16:51.000 but Chrome doesn't support it, 16:51.000 --> 16:52.000 so it doesn't matter. 16:52.000 --> 16:53.000 Okay. 16:53.000 --> 16:54.000 Cool. 16:54.000 --> 16:57.000 I'm happy to give you a bit of a longer break then. 16:57.000 --> 16:59.000 I'm going to have a longer break then.