WEBVTT 00:00.000 --> 00:12.680 Okay, hello everyone, my name is Hamiropola and today I'm going to talk to about FF Glitch. 00:12.680 --> 00:18.480 First, just a little intro about me, I joined the FF MPEG project in around 2006 and I was 00:18.480 --> 00:22.320 an active contributor and I'm a maintainer for about five years, then I left the project 00:22.320 --> 00:27.920 in 2011 but I didn't stop doing video related stuff and I didn't stop working with open 00:27.920 --> 00:36.640 source and in the past few years I've been working in this project called FF Glitch and 00:36.640 --> 00:41.240 today I'm going to present it to you. 00:41.240 --> 00:48.560 So FF Glitch is yet another FF MPEG fork created mostly to make Glitch art and as most 00:48.560 --> 00:52.840 of you know the hardest part in software engineering is company of both names so I just 00:52.840 --> 00:58.760 took FF MPEG and Glitch art and pushed them together and so it's called FF Glitch. 00:58.760 --> 01:04.040 Yet dear for making a FF MPEG for making Glitch art, you'll need a FF MPEG goes about 20 years 01:04.040 --> 01:05.380 back. 01:05.380 --> 01:09.640 Sometimes when working with FF MPEG I'd get glitches in the video output and I would 01:09.640 --> 01:15.040 spend hours playing with those glitches but those glitches were considered bugs and we had 01:15.040 --> 01:20.600 to fix the bugs and get rid of the glitches which I have always found very unfortunate. 01:20.600 --> 01:26.920 So FF Glitch was born as a project, a project where those glitches are considered features 01:26.920 --> 01:29.480 and not bugs. 01:29.480 --> 01:35.640 So what do we mean by glitch art in the context of FF Glitch? 01:35.640 --> 01:43.880 Some examples like SD card corruption or scratch DVDs, DVD reception issues, streaming connectivity 01:43.880 --> 01:50.400 issues and mostly data corruption in somewhere or another that create some interesting 01:50.400 --> 01:51.400 visual artifacts. 01:51.400 --> 01:59.280 For example, this is a classic JPEG glitch from early digital cameras, it's one of the 01:59.280 --> 02:03.040 oldest digital glitches that I could find in my photo library. 02:03.040 --> 02:08.680 This is a picture I took with Sony Cybershot all the way back in 2008 or rather these are 02:08.680 --> 02:12.720 two pictures that I took all the way back in 2008 with Sony Cybershot and thanks to 02:12.720 --> 02:18.480 five system corruption the two pictures got merged together. 02:18.480 --> 02:22.680 The decoder still managed to give us something, even though there are errors when traditionally 02:22.680 --> 02:29.920 to one from the different pictures but it generated something, it's an interesting artifact. 02:29.920 --> 02:33.360 Now I'm going to show you another example of a glitch art that was actually sent to me 02:33.360 --> 02:39.960 by Marvin Schult, often known as A-Pyret on FFMPG and VLC. 02:39.960 --> 02:45.360 This is a JPEG 2000 GPU based decoder glitch. 02:45.360 --> 02:50.000 It no longer reflects photographic reality like the previous example of the merge photos 02:50.000 --> 02:55.080 and it's something more abstract and more beautiful in my point of view and as a video nerd 02:55.080 --> 03:01.920 I'm always thinking to myself what is the decoder doing to generate that and I'm going 03:01.920 --> 03:07.240 to move a little bit away from image codex and I'm going to show you a glitch from video 03:07.240 --> 03:08.240 codec. 03:08.240 --> 03:13.000 For some going to show you the sample video that I use as input, it's a public domain 03:13.000 --> 03:16.040 video of cars in a highway, pretty straightforward. 03:16.040 --> 03:23.920 So the glitch is I found an experimental patch in the FFMPG development list from 2007 to 03:23.920 --> 03:26.800 add WMV3 and codey support. 03:26.800 --> 03:35.600 I found it in 2017 and tried rebasing it to the current code based FFMPG and it kind of failed. 03:35.600 --> 03:41.080 So in the next slide I'm going to show you the output of the video encoded, the WMV3 03:41.080 --> 03:49.000 encoder and let's see if we can spot the glitch, it's very, very subtle, there you go. 03:49.000 --> 03:54.680 That's the results from a broken experimental WMV3 encoder. 03:54.680 --> 03:58.800 The encoder is clearly generating a broken district but the decoder still manage to display 03:58.800 --> 04:01.240 something. 04:01.240 --> 04:05.240 Now that you have an idea of what I mean by glitch art in the context of FFG glitch, let's 04:05.240 --> 04:07.280 move on to the project itself. 04:07.280 --> 04:15.320 So early history of FFG, in 2015 I started following this Facebook group called the 04:15.320 --> 04:20.640 glitch artist collective which still exists and is also an Instagram and it's a group 04:20.640 --> 04:25.640 where glitch artist would share all kinds of things that have been working on and they 04:25.640 --> 04:28.240 would ask all kinds of questions. 04:28.240 --> 04:36.000 Now many of those questions were FFMPG related and I was happy to help whenever possible 04:36.000 --> 04:39.520 but there was one particular question that got my attention. 04:39.520 --> 04:43.560 This question was asked by Kasper who happens to be in the audience here today. 04:43.560 --> 04:46.640 It went something a little bit like this. 04:46.640 --> 04:51.760 Is it possible to edit the motion vectors in a video file? 04:51.760 --> 04:58.240 And that got me thinking it should be possible. 04:58.240 --> 05:01.520 If you're ethically you could just modify the bitstream of the video file, manipulate the 05:01.520 --> 05:04.640 motion vectors and still don't know if we've a valid file that could be played in any video 05:04.640 --> 05:08.960 place, even though it's not like the original file anymore. 05:08.960 --> 05:13.880 I just didn't think there are any tools around that could add at the time so I set 05:13.880 --> 05:16.840 out to create a bitstream editor. 05:16.840 --> 05:24.080 Well, I didn't read it from scratch, I wasn't really really keen on writing an entirely 05:24.080 --> 05:27.080 new bitstream parser and writer. 05:27.080 --> 05:30.000 FFMPG already had the code to do all of that. 05:30.040 --> 05:38.560 I could just reuse FFMPG and bend it a little bit for my purposes. 05:38.560 --> 05:42.320 It took me about two weeks to get the proof of concept working and it went a little 05:42.320 --> 05:45.320 bit something like this. 05:45.320 --> 05:49.000 In the first pass, I would decode the file normally. 05:49.000 --> 05:53.760 I would then export to decode motion vectors to a JSON file. 05:53.760 --> 05:59.560 Then I could modify the motion vectors in any script or any other tool that I wanted in 05:59.560 --> 06:06.080 the JSON file and in a second pass, I would decode the file again but this time while 06:06.080 --> 06:10.880 decoding I would replicate the bitstream and while I was replicating the bitstream, I would 06:10.880 --> 06:14.560 modify just the motion vector values. 06:14.560 --> 06:20.760 The file isn't reencoded, it's the decoder itself that's used to translate the bitstream. 06:20.760 --> 06:27.880 To achieve that, I kind of had to hack FFMPG, I had to hack the get bit context structure. 06:27.880 --> 06:32.200 What is the get bit context structure? 06:32.200 --> 06:36.760 It's a structure that's used to read values from a file or a stream and the video stream 06:36.760 --> 06:41.440 is basically just a sequence of bytes which is just a sequence of bits and this get 06:41.440 --> 06:45.200 big structure will read those bits. 06:45.200 --> 06:50.280 It has some functions such as get one bit, get n number of bits or get the variable and 06:50.280 --> 06:56.240 codes, get variable number of bits and to illustrate the get bit context working, I'm going 06:56.240 --> 07:00.400 to decode a chunk of an MPG for a p-frame with motion vectors. 07:00.400 --> 07:03.440 This is a p-frame with motion vectors overlaid. 07:03.440 --> 07:06.960 It's the example on the FFMPG track. 07:06.960 --> 07:12.200 Each error corresponds to a macro block and I'm going to decode the bitstream of one of 07:12.200 --> 07:18.160 those macro blocks just the beginning. 07:18.160 --> 07:22.440 We only need three bytes because that's where the motion vectors are going to be in the 07:22.440 --> 07:24.680 beginning of the macro block. 07:24.680 --> 07:28.360 Now let's see those bytes as bits, there's a representation. 07:28.360 --> 07:33.000 The first few calls to get bit context, they are not related to motion vectors, they are 07:33.000 --> 07:38.120 other flags inside or variable encodes inside the macro block. 07:38.120 --> 07:45.720 Then after that we decode the motion vector delta x with three calls to get bit context, 07:45.720 --> 07:51.600 then we decode motion vector delta y with another three calls to get bit context. 07:51.600 --> 07:56.880 Now how did I modify the get bit context to replicate the data for the proof of concept 07:56.880 --> 07:57.880 that I was writing? 07:57.880 --> 08:04.080 Basically, I shoehorn a put bit context inside the get bit context, so what is a put bit 08:04.080 --> 08:05.080 context? 08:05.080 --> 08:10.720 Similarly to get bit, it's a structure that you use to write values to a file string. 08:10.720 --> 08:15.400 It's usually used in the encoders, you allocate a buffer and then you just keep writing 08:15.400 --> 08:17.640 bits to it. 08:17.640 --> 08:24.640 Then has a function called put bits, really straightforward, so every time my get bit context 08:24.640 --> 08:30.160 would read a bit, I would replicate that into a separate buffer with a put bit context. 08:30.160 --> 08:33.800 Now let's go back, let's go again step by step, reading the bit string while performing 08:33.800 --> 08:37.800 the replication into a put bit context. 08:37.800 --> 08:45.720 So we start the same way again, read three values, now if you look at the bottom, the output, 08:45.720 --> 08:50.800 bits, as the bits are being read in the input, they're being replicated in the output. 08:50.800 --> 08:55.440 Then we read the first three fields, then we read the motion vector delta x, then motion vector 08:55.440 --> 09:00.480 delta y, and then after that there's that tray one over there, that's just the continuation 09:00.480 --> 09:05.360 of the macro block I didn't want to put anything after that. 09:05.360 --> 09:11.640 Basically I would just have a buffer that would completely replicate the file in the output. 09:11.640 --> 09:20.920 Now what would happen if instead of writing that value, I wanted to clear the motion vector 09:20.920 --> 09:26.480 delta x, I know from the impact for encoder and ffm, that I would need to write a put 09:26.480 --> 09:32.200 bits one instead of that chain that was there. 09:32.200 --> 09:37.080 And I'm going to do the same process again, but do the transplications, instead of copying 09:37.080 --> 09:43.600 all of that, I'm going to pause the replication and write the other bit. 09:43.600 --> 09:53.320 So it starts the same way, I'm replicating the first few bits, then I pause, I read the 09:53.320 --> 09:58.600 values of the get it context, but I don't write them after the output, I pause the replication, 09:58.600 --> 10:06.920 then I write the bit that I wanted, which is basically a zero, and then I restart the replication, 10:06.920 --> 10:07.920 and I keep going. 10:07.920 --> 10:13.280 So now I have a modified bitstream that has the x value for the motion vector of the 10:13.280 --> 10:17.800 delta is zero. 10:17.800 --> 10:22.920 And then replication has been restarted, I just keep on replicating everything else. 10:22.920 --> 10:26.760 The good thing with this approach is that the glitch file has a valid bitstream, so it can 10:26.760 --> 10:31.440 be decoded correctly by ffmpag, we'll see you too, or anything. 10:31.440 --> 10:37.560 And I don't need to edit the entire bitstream, I can just replicate most of it, and in 10:37.560 --> 10:41.720 a very specific part of the code, I edit a couple of values and then keep replicating 10:41.720 --> 10:42.720 afterwards. 10:42.720 --> 10:47.280 This way, I can add new features to ffmpag glitch incrementally, so if I want to change the 10:47.280 --> 10:56.440 DCT later, I can just hack some code inside the DCT writer and on and on and on. 10:56.440 --> 10:59.520 Now let's see some real usage. 10:59.520 --> 11:05.200 So now this is skipping forward, like the proof of concept was in 2016. 11:05.200 --> 11:13.280 This is after in 2020, I added JavaScript support using QuickJS to ffglitch. 11:13.280 --> 11:19.240 So this is actually what ffglitch would do between the first pass and the second pass. 11:19.240 --> 11:23.680 So there's the first pass, then you get frame with the motion vectors, you can edit 11:23.680 --> 11:28.800 them the way you want, and then the second pass goes on, and then you get the glitch 11:28.800 --> 11:33.080 output. 11:33.080 --> 11:37.880 What this code is doing, first check that the frame has motion vectors, because if we're 11:37.880 --> 11:41.680 in a knife frame that it has no motion vectors, then it's going to clear the horizontal 11:41.680 --> 11:47.520 element of all motion vectors, just loops through the 2DRA, and then that line this set 11:47.520 --> 11:51.040 the horizontal motion vectors is 0. 11:51.040 --> 11:52.720 And let's see the result. 11:52.760 --> 11:59.760 That's the same file from before, but with the horizontal movement removed. 11:59.760 --> 12:05.560 I'm going to show an example from a different script. 12:05.560 --> 12:11.320 Let's see if we can guess what this script is doing in this case. 12:11.320 --> 12:17.040 It's actually very simple, I'm just adding two vertically to all motion vectors. 12:17.040 --> 12:20.400 One of the color distortions that are seen, that's entirely on the decoder. 12:20.400 --> 12:25.440 It's a valid impact to a file, I just tweak the bitstream a little bit. 12:25.440 --> 12:29.880 So each codec may give different possibilities for a glitchart. 12:29.880 --> 12:35.040 For example, PNG is an entirely different codec, where it's entirely different ways, 12:35.040 --> 12:41.680 and it's a whole new way of doing glitchart for each codec. 12:41.680 --> 12:49.200 This is the just a simple PNG image of flower, picture directed long time ago. 12:49.200 --> 12:55.960 Then PNG, the way it works, it has a byte that specifies the filter type for each row, 12:55.960 --> 12:58.160 and then it has a byte for the row. 12:58.160 --> 13:02.560 If I just modify the first byte using effect glitch of each row, I'm going to change 13:02.560 --> 13:07.680 effectively, change the filter type, and with just a simple script, I can get this output 13:07.680 --> 13:09.680 out of it. 13:09.680 --> 13:19.400 Here's one good thing about a ff glitch, that it may seem like it's just a great glitchart, 13:19.400 --> 13:23.040 but since I have a good understanding of the codec, I have to read and I have to understand 13:23.040 --> 13:28.040 a lot of code, and that's a very very important point for me. 13:28.040 --> 13:32.080 What I really love is understanding how codec works. 13:32.080 --> 13:38.520 As a side project, as a side project with ff glitch, which in itself is already a side 13:38.600 --> 13:44.120 project, I started trying to describe codecs in the most simple and visual way that I could think of. 13:44.120 --> 13:50.000 So this is one simple description of a JPEG bitstream. 13:50.000 --> 13:55.480 The website itself is interactive, so you can see how each macro block gets encoded, passing 13:55.480 --> 14:02.120 through all of the DCT magic and how you don't need to understand what DCT does, it's just a box. 14:02.120 --> 14:06.360 And then you get the bitstream again, then you can see which parts use more bits to represent 14:06.360 --> 14:09.360 which parts use fewer bits. 14:09.360 --> 14:14.200 Unfortunately, this is a working progress, it's been installed for like four years, I would 14:14.200 --> 14:18.760 really like to finish it, but I don't know, I just haven't gotten around to it. 14:18.760 --> 14:25.640 And I'd love to do this for PNG and other image codecs and maybe even some video codecs. 14:25.640 --> 14:29.640 It shows that different codecs work in wildly different ways. 14:29.640 --> 14:35.040 So back to ff glitch, which codecs is its support currently? 14:35.040 --> 14:40.720 There's support for JPEG, MPG 2, MPG 4 in PNG, which I added last year. 14:40.720 --> 14:46.280 The features that each codec has, so some have DCT coefficients, some have motion vectors. 14:46.280 --> 14:49.400 In JPEG, you can change your quantization table, which is actually pretty interesting 14:49.400 --> 14:56.200 because as we're missing with the webcams that they send data encoded in JPEG, you can 14:56.200 --> 15:01.400 actually intercept the data just use the ff glitch to change the quantization table in the 15:01.400 --> 15:10.960 beginning and create a virtual webcam, and then you can just glitch stuff in real time. 15:10.960 --> 15:16.840 And ff glitch can modify not only the raw bits string, but it can also support modifying 15:16.840 --> 15:24.840 the container format, because since we are changing the size of the frames, this has 15:24.840 --> 15:28.520 to be reflected in the container as well, so that it knows how to find the frames correctly 15:28.520 --> 15:29.520 in the file. 15:29.520 --> 15:33.640 So ff glitch is going to fix up the indices, the sizes, checksons, and all of that, 15:33.640 --> 15:35.440 so that the files are still valid. 15:35.440 --> 15:41.280 Currently, AVI and Mover supported, but then I think it's already enough, I mean, we don't 15:41.280 --> 15:45.080 really need that much more than that just to make the chart, although it could be fun to 15:45.080 --> 15:47.800 try other formats. 15:47.800 --> 15:54.000 And ff glitch has a bunch of extra functionality built in, I had already mentioned scripting 15:54.000 --> 15:58.240 supports, throughput jfs, and then later added Python 3. 15:58.240 --> 16:05.920 There's HAD support of Sdl2, so that I can use a joystick or the keyboard or mouse. 16:05.920 --> 16:11.120 There's MIDI support of RT MIDI for controllers, such as this one, I'm going to, if there's 16:11.120 --> 16:18.040 time I'm going to demo it later, and network support using zeroing Q. Now, why did I 16:18.040 --> 16:24.760 add network support to this? I was getting lots of requests for different types of protocol 16:24.760 --> 16:29.280 in different types of devices, and it seemed easier to just implement zeroing Q support, 16:29.280 --> 16:31.280 so that people can write their own bridges. 16:31.280 --> 16:35.920 They can write their own code, a simple script that reads from their device, and then just 16:35.920 --> 16:38.560 talk back using zeroing Q. 16:38.560 --> 16:44.240 The idea is to give the two necessary for a glitch, I just to create more complex stuff. 16:44.240 --> 16:49.680 So ff glitch is basically three programs, or three binaries. 16:49.680 --> 16:54.760 There's ff edit, which is the new tool, which is going to edit or export, apply the changes 16:54.760 --> 17:00.400 to the bit string, it's the main tool for ff glitch, it's the MIDI MIDI stream editor, 17:00.400 --> 17:05.680 then there's ff live, which is actually just the ff play binary from ffmpeng. 17:05.680 --> 17:12.240 It has ff edit integrated into it, so we can glitch in real time, and then there's ffgc 17:12.320 --> 17:18.680 where gc stands for glitch artists collective, because in my tutorials I would tell people 17:18.680 --> 17:22.560 to use ffmpeng, and then they would say, oh, it's not working, because this feature doesn't 17:22.560 --> 17:27.240 exist, so that's a feature I added to ff glitch, so it's not in the real ffmpeng, so 17:27.240 --> 17:29.520 I just had to rename the binary. 17:29.520 --> 17:35.880 It has some extra functionality to make more broken videos, which wouldn't really be interesting 17:35.880 --> 17:41.760 in ffmpeng itself. 17:41.840 --> 17:45.680 ff live got to a point where it works in real time even on a Raspberry Pi, and I 17:45.680 --> 17:49.440 have spent a considerable amount of time optimizing it this past year, so that it runs 17:49.440 --> 17:57.040 well on arm, which means it's on other point, which is upstream into ffmpeng, because ff 17:57.040 --> 18:02.720 glitch is a full blown ffmpeng, so the way upstream anything, most of what I added is 18:02.720 --> 18:08.320 the layout side of the school process ffmpeng, so we won't want broken stuff in ffmpeng, 18:08.400 --> 18:11.680 but there's a lot of work that's common to both projects, and I've been doing, for example, 18:11.680 --> 18:18.160 I added some support for ffv4l2, there was new devices that weren't supported by ffmpeng, 18:18.160 --> 18:24.480 some bug fixes, just while I was writing the ffmpeng glitching, I found a couple of bugs 18:24.480 --> 18:30.560 in her png encoder, tests, tests are always welcome, and optimizations, like I said, 18:30.560 --> 18:35.920 ff live needs to be really fast, so it's optimizing it's funny, you know, it just 18:35.920 --> 18:39.360 went 10 hours in a row, writing assembly, it's a lot of fun, and it's rewarding. 18:42.000 --> 18:46.240 So I mentioned the rest of the ffmpeng, but the device I've really been working on is another one, 18:46.240 --> 18:52.880 is the orange ffmpeng, it's very, very powerful, and it has HDMI input and HDMI output, 18:52.880 --> 18:58.000 so what's good about that is that it works kind of like a guitar pedal, but for glitch art, 18:58.000 --> 19:03.200 now I can bring it with me with just a power bank, and then I plug HDMI in and HDMI out, 19:03.280 --> 19:07.760 unfortunately it didn't work for the presentation, because I wanted to have it here in the loop, 19:07.760 --> 19:16.960 but not today, and what's next for ffmpeng glitch, I'd like to add to the part for more modern 19:16.960 --> 19:22.640 codecs, such as hrc4, and if you want, I know this codecs will have many more features that will 19:22.640 --> 19:28.720 be fun to play with, but I'd also like to play around with older formats such as GIF and JPEG 2000, 19:28.720 --> 19:34.160 and especially interested in wavelet-based codecs. I'd like to add support for audio codecs, 19:34.160 --> 19:39.520 because the same principle holds with audio, you just modify the bitstream, should work the same way. 19:41.760 --> 19:47.600 Now, there's some people using it for vj, or for life performances, using ffmpeng glitch, 19:47.600 --> 19:52.320 and they've been asking me to support these frameworks, siphon and spout, I don't know if you've heard about them, 19:52.320 --> 19:56.960 I had never heard about them until a couple of months ago, but apparently every vj knows it, 19:57.520 --> 20:02.640 basically you can share it texture directly with other tools such as the Resolumenters Designer, 20:02.640 --> 20:06.480 and I think enough people have mentioned that first ffmpeng and them using it in ffg glitch. 20:08.560 --> 20:12.240 I've heard that it could be used for a stegonography to hide information inside a bitstream, 20:12.240 --> 20:16.640 but I haven't ever tried that yet. I've also heard that it could be used to test codecs, 20:16.640 --> 20:22.160 security in hardware decoders, kind of like how h26 farge is used, we could create a very, 20:22.160 --> 20:28.240 very specific bitstream that's going to break your decoder, most importantly I'd like to hear 20:28.240 --> 20:33.760 your contributions and your feedback, and your pull request as well. And since there's still time, 20:33.760 --> 20:41.440 I have a little gallery of some more examples using ffg glitch. So what I usually do is that I write 20:41.440 --> 20:47.600 small proofs of concept, small scripts like this one, the video from my cat in 2018, just to show 20:47.680 --> 20:51.680 how things work, and then I'll just pick up those scripts as examples and they either improve 20:51.680 --> 20:59.600 them or use them as is and try them with different. Yeah, it's very, very fun and try them with different 20:59.600 --> 21:05.600 videos. This is one of the first examples I saw in the wild, it's also from Casper and Tomacola, 21:05.600 --> 21:12.400 which is not here today. It was actually surprising because they had written this blog post with that 21:12.400 --> 21:16.080 and I hadn't heard about it for like Ambusta Yub, because there was a lot of social networks, 21:16.080 --> 21:19.440 and then someone's like, hey, how come you haven't seen that? They're using your software. 21:19.440 --> 21:25.840 Like, oh, I didn't know anybody was using it, but that was fun. There's a couple more from Tomacola. 21:25.840 --> 21:30.080 He did a lot of early work in ffmpeg of testing of different things. And then there was an 21:30.080 --> 21:34.960 okay, you can actually see the green bleeding from the top. That's the Yub green. Actually, 21:34.960 --> 21:40.400 the motion vectors try to fetch information from way too far above where they were not supposed 21:40.400 --> 21:43.680 to try to fetch anything. So then the decoder, that's actually a glitch in the decoder, 21:43.680 --> 21:49.440 the different decoder if they're going to give different results for that. This one's from 21:49.440 --> 21:58.880 Sebastian Béria. It's a scene from the series Dark and not how it almost let it go. 22:00.240 --> 22:08.240 It almost looks like a painting in the end, so that's just very beautiful. I just love watching 22:08.240 --> 22:12.000 stuff like that. That's why I would spend hours working on a glitch ffmpeg. 22:13.840 --> 22:19.120 Now I'm going to do some demos with ffmpeg. Hopefully, it's going to work. 22:21.440 --> 22:29.520 Let's see if this one works. Okay. This should work with the MIDI controller. 22:29.520 --> 22:34.880 So the MIDI controller here, and I can just modify in a little bit. 22:36.720 --> 22:42.720 And if I keep moving, you can see that I'm still here, but I'm just modifying the motion 22:43.040 --> 22:48.880 vectors in real time. And then there's also this feature, which basically resets the, and this is 22:48.880 --> 22:54.240 reseting in the decoder itself. So there's a kind of stuff that's changed in ffmpeg itself, 22:54.240 --> 23:01.360 but not kind of nobody's going to want something that's going to inject a macro blocks inside 23:01.360 --> 23:06.720 a p frame in normal ffmpeg. So this is the first example. There's another one that hopefully 23:06.800 --> 23:27.600 is going to work if internet connection here is good. It's, ah, no. Okay, so I have the live stream 23:27.600 --> 23:35.200 of the presentation. And I can glitch that as well. I don't know what the delay is, but yeah, 23:36.800 --> 23:40.960 so since you can just pipe stuff, you know, I can just, I could actually pipe this into 23:42.000 --> 23:46.720 streaming it to YouTube or something like that. It's quite interesting. There's this website called 23:46.720 --> 23:51.360 a webcam taxi that you can find webcam from all over the world. And I would have this one from 23:51.360 --> 23:56.000 this, these, these people playing pool in the Philippines, then I would just glitch that and then 23:56.000 --> 24:00.320 return submitted somewhere else. And the longer you leave it, the more the color saturate and 24:00.400 --> 24:08.960 have these kind of effects. So yeah, let's get to the presentation. And oh yeah, that's it. 24:08.960 --> 24:16.640 Thank you very much. Those are some, ah, of me. Thank you. 24:19.520 --> 24:24.240 If anybody's interested in talking about glitch art, let's go out for a beer later tonight. 24:24.240 --> 24:28.880 I would really love to have more hardcore developers doing glitch art stuff because right now it's 24:28.880 --> 24:34.960 only like a couple of us and it's a lot of fun to work with. Yeah, I think we'll have time for questions. 24:34.960 --> 24:44.400 Yeah. Okay. Anybody questions? No questions. Yes? How do you do the setting of the 24:44.400 --> 24:51.520 visual loss that you have to kind of be in your house? Yeah. Yeah. So it's, it's in the in the 24:51.520 --> 24:56.080 encoder. So there's, there's some code that I had to change in the encoder. So I send a 24:56.160 --> 25:02.080 MIDI command and then it just randomly sets i macro blocks inside a p frame and then at the end it 25:02.080 --> 25:09.360 clears everything with an i frame. Oh, yes. Okay. I thought you were just filtering about the 25:09.360 --> 25:12.720 encoding. Yeah. So the question was if, wait, what was the question again? 25:13.760 --> 25:19.200 Well, if you're just filtering the bits to the encoding, how did you reset macro blocks to there? 25:19.200 --> 25:23.920 Okay. So the question, if I'm just filtering the bits to how did I reset the macro blocks 25:24.000 --> 25:29.680 to there's initial state with that command right now? Actually, there was, there was a lot more code 25:29.680 --> 25:34.480 going on in ffclitch. So there is lots of code in ffmpeg as well in the encoder. I hacked the encoder as 25:34.480 --> 25:44.080 well so that I can selectively add i frame or just add i macro blocks inside an i frame. So I mean, 25:44.080 --> 25:48.320 I could spend a few more hours talking about everything that I mean, I even added pixel sorting 25:48.320 --> 25:52.400 so ffclitch because it was fun. No, just just to see if it could be, if it could be done live. 25:53.360 --> 25:57.520 So yeah, there's a lot more functionality that's documented in the website now. 25:57.520 --> 26:01.840 For many, many years, there was no documentation of ffclitch, but now there is. So you could go to 26:01.840 --> 26:05.760 the website and check it out. Thank you. Other questions? Yes? 26:10.000 --> 26:14.320 I have, so the question is what it would be like to do glitch art with the audio codex? 26:14.320 --> 26:20.480 I haven't tried it yet, but I assume it would be like noise music, which I also love, 26:20.560 --> 26:25.360 I know some some people don't, but I really enjoyed it. So this is something that I really 26:25.360 --> 26:29.600 want to get into. We're going to be fun to hack with MP3 files. 26:33.280 --> 26:34.000 Yes? 26:34.000 --> 26:38.000 For the way for this, we want to like check the x size. 26:40.000 --> 26:44.560 Yeah, I haven't, I haven't tried it. I think the first one I'm going to go with is a jpeg 2000 because 26:44.560 --> 26:50.000 that's not we already have. The question was a jpeg xx excess or something like that, 26:50.080 --> 26:52.000 which is I haven't really looked at yet. 26:54.240 --> 26:57.520 Okay, no more questions? Thank you very much. Bye. 27:06.400 --> 27:08.400 Oof. Good.