WEBVTT 00:00.000 --> 00:07.000 Hi, good morning. 00:07.000 --> 00:11.000 Welcome to my G-streamer talk. 00:11.000 --> 00:16.000 First of all, hi, I'm Tim, I work on G-streamer. 00:16.000 --> 00:18.000 G-streamer, you might ask. 00:18.000 --> 00:19.000 What is G-streamer? 00:19.000 --> 00:21.000 It's a multimedia framework. 00:21.000 --> 00:25.000 It's cross-platform open source, free software. 00:25.000 --> 00:29.000 It does anything you would expect from a multimedia framework. 00:29.000 --> 00:34.000 It does audio processing, video processing, subtitles, captions, 00:34.000 --> 00:37.000 metadata, and you can do exciting stuff with it. 00:37.000 --> 00:40.000 And you can chunk it, stop it around. 00:40.000 --> 00:41.000 You can edit it. 00:41.000 --> 00:42.000 You can decode it and code it. 00:42.000 --> 00:45.000 You can stream it, read it from file, write it to a file. 00:45.000 --> 00:47.000 Mixer, do apply effects. 00:47.000 --> 00:49.000 Whatever your heart desires, basically. 00:49.000 --> 00:54.000 Run analytics, that sort of thing. 00:54.000 --> 00:56.000 All right, so what have we been up to? 00:56.000 --> 00:58.000 I've got way too many slides, by the way. 00:58.000 --> 01:02.000 This is more like the speed dating equivalent of the talk. 01:02.000 --> 01:07.000 Yeah, we released a new major feature release, 1.28. 01:07.000 --> 01:11.000 We have one of those every nine to 12 months. 01:11.000 --> 01:13.000 Yeah, and this one is brand new. 01:13.000 --> 01:15.000 Was released just a couple of days ago. 01:15.000 --> 01:17.000 Release notes are on the website. 01:17.000 --> 01:20.000 If you haven't read them yet, you're not the only ones. 01:20.000 --> 01:23.000 But you can feel loads of features. 01:23.000 --> 01:27.000 And I'm going to work through some of the bits we've been working on. 01:27.000 --> 01:29.000 There's way too much stuff. 01:29.000 --> 01:32.000 And I should also say, I'm keeping it very, very high-level, 01:32.000 --> 01:35.000 just sort of to wet your appetite to see if there's something that's of interest 01:35.000 --> 01:37.000 and then you can dive into the race notes. 01:37.000 --> 01:41.000 Or you can check out the Gstreamer Conference talks. 01:41.000 --> 01:46.000 The videos are all online, and you have lots of great talks about all of these topics here 01:46.000 --> 01:49.000 in much, much more detail. 01:49.000 --> 01:50.000 Yeah, number one codex. 01:50.000 --> 01:53.000 We've got support from our codex. 01:53.000 --> 01:54.000 H266. 01:54.000 --> 01:57.000 There's a latest impact codec. 01:57.000 --> 02:00.000 Then we've got enhancement codex. 02:00.000 --> 02:05.000 LCEVC, sort of like a multi-layer codec thing. 02:05.000 --> 02:07.000 We've got support for that. 02:07.000 --> 02:09.000 We used to have H264 already. 02:09.000 --> 02:11.000 And now we've got enhancement layers. 02:11.000 --> 02:14.000 In combination with H265 and H266 as well. 02:14.000 --> 02:17.000 And we can decode and code that. 02:18.000 --> 02:22.000 An impact H audio is a new audio codec from the front, 02:22.000 --> 02:23.000 over people. 02:23.000 --> 02:25.000 And we've got support for that. 02:25.000 --> 02:30.000 So we're now plus maxing and demuxing into the MP4 container. 02:30.000 --> 02:35.000 There has been a whole bunch of work around and salary metadata. 02:35.000 --> 02:38.000 So that can be captions, sort of in broadcasting captions. 02:38.000 --> 02:39.000 That is the bottom of your TV. 02:39.000 --> 02:41.000 But it can also be generic metadata. 02:41.000 --> 02:43.000 All kinds of metadata is sent around. 02:43.000 --> 02:46.000 That's sort of quite important in broadcasting workflows. 02:46.000 --> 02:49.000 So if you watch a football game or something, 02:49.000 --> 02:52.000 you might have, for example, the game score as a metadata 02:52.000 --> 02:55.000 in the stream and things like that. 02:55.000 --> 02:57.000 You can put anything in there. 02:57.000 --> 03:00.000 And we've got whole infrastructure around that. 03:00.000 --> 03:02.000 So you can attach it to buffers in the pipeline. 03:02.000 --> 03:03.000 You can split it out. 03:03.000 --> 03:06.000 And you can write it into the MXF container, 03:06.000 --> 03:09.000 which is used for film and reproduction workflows. 03:09.000 --> 03:12.000 You can capture it on sort of decling capture cards. 03:12.000 --> 03:15.000 And you can send it out again. 03:15.000 --> 03:19.000 And you can send it over RTP with a new payload. 03:19.000 --> 03:23.000 That's in the payload as we have. 03:23.000 --> 03:27.000 RTP is sort of, it's a really old protocol. 03:27.000 --> 03:31.000 It's kind of the workhorse for, you know, 03:31.000 --> 03:35.000 ingesting a stream into it like a streaming server. 03:35.000 --> 03:37.000 Unfortunately, it just doesn't go away. 03:37.000 --> 03:38.000 It should. 03:38.000 --> 03:41.000 But it doesn't, everyone uses it. 03:41.000 --> 03:45.000 So the container format that's, that's used underneath is FIV. 03:45.000 --> 03:47.000 And it is really bad. 03:47.000 --> 03:50.000 And old, but, you know, as I said, it sticks around. 03:50.000 --> 03:53.000 So, yeah, but people, you know, 03:53.000 --> 03:56.000 it only has a very limited range of codex support. 03:56.000 --> 03:58.000 But people want to continue using it. 03:58.000 --> 04:03.000 So, you know, there's like an enhanced RTP as a V spec now. 04:03.000 --> 04:06.000 So you can actually put more than video codex into FIV. 04:06.000 --> 04:08.000 Like, ASUS X5 and everyone. 04:08.000 --> 04:11.000 And you can actually have more than one audio track. 04:11.000 --> 04:14.000 You can have multiple audio tracks and multiple video tracks. 04:14.000 --> 04:18.000 So it's all very exciting for those of you who still use RTP. 04:18.000 --> 04:20.000 And we support that industry one now. 04:20.000 --> 04:22.000 Or, I should say, I think the AV1 support 04:22.000 --> 04:23.000 is not actually merged yet. 04:23.000 --> 04:25.000 I think that's in, in GitHub. 04:25.000 --> 04:30.000 But it is a rebase on top of the, um, the latest code. 04:30.000 --> 04:34.000 You can create HLS streams with the streamer. 04:35.000 --> 04:38.000 Basically, just, you know, write stuff into FIV directory. 04:38.000 --> 04:39.000 FIVs and playlists. 04:39.000 --> 04:41.000 And you can point your web server to it. 04:41.000 --> 04:44.000 And just, you know, server to web browser. 04:45.000 --> 04:48.000 Yeah, we've got support for single media file. 04:48.000 --> 04:51.000 I'll put now in, which is quite, you know, quite useful. 04:51.000 --> 04:54.000 If you just create a stream for video and demand. 04:54.000 --> 04:55.000 It's not a live stream. 04:55.000 --> 04:57.000 And then you don't have to manage like, you know, 04:57.000 --> 05:00.000 a million little stream fragments files. 05:00.000 --> 05:02.000 But, you know, you can just have one file. 05:02.000 --> 05:05.000 And the playlists will just sort of point into the, um, 05:05.000 --> 05:08.000 the chunks of the file, which is much, much easier to handle. 05:08.000 --> 05:09.000 And you can also buy it. 05:09.000 --> 05:12.000 I frame only playlists for, um, 05:12.000 --> 05:14.000 seeking and, you know, like, like, 05:14.000 --> 05:17.000 trick modes, fast forward, fast reverse playback. 05:17.000 --> 05:19.000 Thanks like that. 05:19.000 --> 05:22.000 There's a lot of work going on around, um, 05:22.000 --> 05:27.000 speech to text, um, 05:27.000 --> 05:31.000 conversion text translations into different language. 05:31.000 --> 05:33.000 And also, uh, speech synthesis. 05:33.000 --> 05:36.000 So you can, you know, you can pick up the, 05:36.000 --> 05:39.000 the, the audio converted to text translated into different language. 05:39.000 --> 05:42.000 And then have that generated, again, into audio, 05:42.000 --> 05:44.000 and you'll feed it out. 05:44.000 --> 05:46.000 Uh, you brought it into a file or stream it out, 05:46.000 --> 05:47.000 basically. 05:47.000 --> 05:50.000 So then you've got to translate it, uh, audio track. 05:50.000 --> 05:52.000 Um, you can do exciting things without, 05:52.000 --> 05:54.000 well, exciting and slightly scaring. 05:54.000 --> 05:56.000 But you can do things like voice cloning. 05:56.000 --> 05:58.000 So you can clone, you know, 05:58.000 --> 06:01.000 voice, and then translate it, and then he speaks Spanish. 06:01.000 --> 06:04.000 And it sounds like to improve just speaking for, like, Spanish. 06:04.000 --> 06:06.000 Um, yeah. 06:06.000 --> 06:10.000 So we support lots of stuff, um, in that area, 06:10.000 --> 06:12.000 and it's unhappy development. 06:12.000 --> 06:15.000 And also cool stuff, like, you know, if you translate things, 06:15.000 --> 06:18.000 and often it takes more time for the translated language, 06:18.000 --> 06:20.000 that it takes in the original, right? 06:20.000 --> 06:23.000 And you can't have a problem because you go out of sync, 06:23.000 --> 06:25.000 or you kind of have to drop stuff somewhere. 06:25.000 --> 06:27.000 So we can, we can speed up the audio if you, 06:27.000 --> 06:30.000 you detect, like, it goes out of sync because the translated language 06:30.000 --> 06:31.000 just takes longer. 06:31.000 --> 06:34.000 Um, then you can speed it up and catch us up and you, 06:34.000 --> 06:36.000 you know, you get back into sync again. 06:36.000 --> 06:38.000 It sounds a bit funny, but, you know, works. 06:38.000 --> 06:39.000 Um, yes. 06:39.000 --> 06:41.000 Also, if you enter karaoke, um, 06:41.000 --> 06:43.000 we also have an audio source separation, 06:43.000 --> 06:44.000 and then it's based on DMUX. 06:44.000 --> 06:47.000 It's like a library engine, um, 06:47.000 --> 06:49.000 that's often used for that sort of thing. 06:49.000 --> 06:50.000 Um, that's used for the karaoke, 06:50.000 --> 06:52.000 but also if you have, like, a, you know, 06:52.000 --> 06:54.000 the stream where you want to filter out the background audio 06:54.000 --> 06:58.000 on you just want the voice right so you can then run speech detection 06:58.000 --> 07:00.000 on that voice and translate it. 07:00.000 --> 07:02.000 So it helps with that as well. 07:02.000 --> 07:06.000 Um, and then it takes, you might have, um, 07:06.000 --> 07:10.000 being to Daniel's talk yesterday in the, um, 07:10.000 --> 07:11.000 of media dev room. 07:11.000 --> 07:14.000 Um, yeah, we've got a lot of support for, you know, 07:14.000 --> 07:16.000 object detection, inference, all of that. 07:16.000 --> 07:19.000 We've got, yeah, look, I mean, that doesn't area 07:19.000 --> 07:21.000 that's being worked on quite a lot. 07:21.000 --> 07:23.000 We've got more inferencing elements. 07:23.000 --> 07:26.000 We've got more support in, in on X in the runtime. 07:26.000 --> 07:28.000 More matters, um, 07:28.000 --> 07:31.000 tenser decoderers, uh, they can be auto plugged now as well. 07:31.000 --> 07:33.000 And we have a batch meta, um, 07:33.000 --> 07:36.000 plus a splitter and combined elements for that. 07:36.000 --> 07:38.000 That existed already because, I mean, 07:38.000 --> 07:41.000 with the analytics stuff, everyone, like used to do their own thing. 07:41.000 --> 07:43.000 You know, Nvidia has, have their own thing, 07:43.000 --> 07:45.000 Intel has their own thing. 07:45.000 --> 07:47.000 Um, and as I'll have their own thing. 07:47.000 --> 07:50.000 So, you know, the hope is sort of to provide basic, 07:50.000 --> 07:54.000 infrastructure upstream, and then maybe in 10, 20 years, 07:54.000 --> 07:58.000 you know, the other people can move towards that as well. 07:58.000 --> 08:00.000 I hope that's last. 08:00.000 --> 08:04.000 Um, well, can, well, can, is like the latest and greatest sort of 08:04.000 --> 08:07.000 low-level video API, um, for rendering, 08:07.000 --> 08:10.000 but it's also got, well, in video, um, which can be used 08:10.000 --> 08:13.000 for hardware accelerated decoding and encoding. 08:13.000 --> 08:17.000 Um, and yeah, we've got support for more decoders, 08:17.000 --> 08:20.000 everyone in the combined particular, um, 08:20.000 --> 08:24.000 H64 encoders, um, and the H65 decoder can do 08:24.000 --> 08:25.000 HDR now. 08:25.000 --> 08:28.000 Let's 10 bit decoding. 08:28.000 --> 08:33.000 GTQML integration, um, but security took it, of course. 08:33.000 --> 08:35.000 We've got various elements for that. 08:35.000 --> 08:37.000 We've got QML five elements for that as well, 08:37.000 --> 08:40.000 but QT6 is what we're working on at the moment. 08:40.000 --> 08:42.000 So there's a new render source element, 08:42.000 --> 08:45.000 so you can, you know, render a scene and have that, um, 08:46.000 --> 08:49.000 be captured into the pipeline as a video, basically. 08:49.000 --> 08:53.000 Um, and there's a GL overlay, so you can overlay something on top of 08:53.000 --> 08:56.000 a video using the, you know, GL rendering, basically. 08:56.000 --> 09:00.000 And you can, now, not only have like a scene-rath description, 09:00.000 --> 09:03.000 but you can actually put a QT quick item in there, 09:03.000 --> 09:05.000 which gives you more flexibility. 09:05.000 --> 09:07.000 Um, 09:07.000 --> 09:12.000 Weirland is basically what you render to on a modern Linux desktop, 09:13.000 --> 09:15.000 hopefully. 09:15.000 --> 09:17.000 Um, 09:17.000 --> 09:22.000 yeah, so the colour, um, there's been a lot of work on the colour management side of things, 09:22.000 --> 09:25.000 um, HDR support, although that, um, 09:25.000 --> 09:28.000 very exciting also a new full screen output property. 09:28.000 --> 09:31.000 Additionally, we haven't added these because we, you know, 09:31.000 --> 09:35.000 think it should be done via the, um, API, but we've relented. 09:35.000 --> 09:37.000 So there you have it. 09:37.000 --> 09:40.000 Um, there's something called UDMA Buff support, 09:40.000 --> 09:45.000 basically the, you know, way how you send video buffers, 09:45.000 --> 09:50.000 very efficiently between, um, subsystems of the kernel. 09:50.000 --> 09:53.000 Um, and UDMA Buff is basically like a user map, 09:53.000 --> 09:55.000 a little variant of that. 09:55.000 --> 09:58.000 And that's quite useful if you have, you software decoding, 09:58.000 --> 10:00.000 like you might need to do AV1 software decoding, 10:00.000 --> 10:03.000 if you don't have a hardware x-way to the AV1 decoder. 10:03.000 --> 10:06.000 Um, and then you can avoid some memory copies, 10:06.000 --> 10:08.000 if, if you can use UDMA Buff. 10:08.000 --> 10:10.000 So you have support for that. 10:10.000 --> 10:14.000 Um, if you're using GNOME, you might notice that, um, 10:14.000 --> 10:17.000 um, I don't know, you probably know Totten, maybe. 10:17.000 --> 10:19.000 Um, and it's finally getting replaced. 10:19.000 --> 10:22.000 As a new midi player video player in the GNOME, 10:22.000 --> 10:26.000 it's called Showtime and it uses all the cool news stuff. 10:26.000 --> 10:29.000 We have, um, added in the last few years. 10:29.000 --> 10:33.000 So it's all very efficient, uh, you know, zero copying, 10:33.000 --> 10:36.000 output viable kernel OpenGL, 10:36.000 --> 10:38.000 and, you know, UDMA Buff support. 10:38.000 --> 10:40.000 And they use something called GDK4 Paintable Sync, 10:40.000 --> 10:42.000 which is based on GDK4, 10:42.000 --> 10:45.000 that the toolkit that GNOME uses, um, 10:45.000 --> 10:47.000 that lives in the rust plug and, 10:47.000 --> 10:49.000 so you can use that as well in your application. 10:49.000 --> 10:50.000 And it's, it's all very nice. 10:50.000 --> 10:52.000 And it looks very slick as well. 10:52.000 --> 10:54.000 Um, compared to Totten. 10:54.000 --> 10:56.000 Um, 10:56.000 --> 10:58.000 AMD Hip. 10:58.000 --> 11:00.000 Um, Hip is sort of, 11:00.000 --> 11:01.000 it's very similar to Prudah. 11:01.000 --> 11:04.000 It's like, you know, for, for graphics programming, 11:05.000 --> 11:07.000 pixel modifications, basically. 11:07.000 --> 11:10.000 But the idea is that with Hip is that it, you know, 11:10.000 --> 11:12.000 Prudah is Nvidia specific. 11:12.000 --> 11:14.000 So if you don't have Nvidia hardware, then, 11:14.000 --> 11:15.000 yeah, it doesn't pipe anything. 11:15.000 --> 11:17.000 So Hip is very, very similar, basically. 11:17.000 --> 11:20.000 Um, but the idea is that if you run on AMD hardware, 11:20.000 --> 11:22.000 you know, it uses, um, 11:22.000 --> 11:24.000 the, the, the, the, the, the, the, 11:24.000 --> 11:26.000 rock and underlying rock and engine, 11:26.000 --> 11:27.000 and, you know, that worked perfectly. 11:27.000 --> 11:29.000 And if you running on Nvidia hardware, 11:29.000 --> 11:31.000 there would be like the, a very, um, 11:32.000 --> 11:33.000 thin translation layer. 11:33.000 --> 11:35.000 And then we would run on cooler, basically. 11:35.000 --> 11:37.000 So you get like the best of both worlds. 11:37.000 --> 11:38.000 And, you know, with two of the, 11:38.000 --> 11:40.000 because, um, graphic cards, 11:40.000 --> 11:41.000 then there's out there. 11:41.000 --> 11:42.000 So we've got to plug in for that. 11:42.000 --> 11:44.000 And we've got a few elements that were the usual things, 11:44.000 --> 11:47.000 you know, like conversion, some scaling, 11:47.000 --> 11:48.000 etc. 11:50.000 --> 11:52.000 Uh, language findings. 11:52.000 --> 11:54.000 So Gistima is written in C and Rust, 11:54.000 --> 11:57.000 but you can use it from lots of different languages. 11:57.000 --> 11:58.000 It's perfectly fine. 11:58.000 --> 12:00.000 You can write your application in Python and Ruby. 12:00.000 --> 12:03.000 And, you know, Rust here, of course, C plus plus, 12:03.000 --> 12:04.000 whatever your hard advice, 12:04.000 --> 12:08.000 um, because we've got language findings for most of these languages. 12:08.000 --> 12:10.000 Um, one thing, well, first of all, 12:10.000 --> 12:12.000 we've got new go bindings, 12:12.000 --> 12:13.000 where newish go bindings, 12:13.000 --> 12:15.000 but I think they're much more usable in the show now. 12:15.000 --> 12:17.000 And they're called go GST. 12:17.000 --> 12:20.000 They're externally maintained, but I think they're quite good. 12:20.000 --> 12:23.000 Um, and quite exciting as well for some people, 12:23.000 --> 12:26.000 um, who are not quite ready to jump on the Rust band 12:26.000 --> 12:28.000 working here is the C plus plus bindings. 12:28.000 --> 12:30.000 We used to have C plus plus bindings, 12:30.000 --> 12:32.000 but they're all kind of bit rotten and I don't know what 12:32.000 --> 12:33.000 it contains so many more. 12:33.000 --> 12:36.000 We had two sets, actually, and they're both not contained anymore. 12:36.000 --> 12:40.000 Um, but there's a lot of people who want to provide C plus plus. 12:40.000 --> 12:43.000 Um, but they're now C new C plus plus bindings, 12:43.000 --> 12:45.000 uh, based on a new, um, 12:45.000 --> 12:47.000 sort of infrastructure, and gnome, called peer, 12:47.000 --> 12:50.000 and they had us only bindings, and they, um, don't use the STL, 12:50.000 --> 12:52.000 and all those are very cool. 12:52.000 --> 12:53.000 Yeah. 12:53.000 --> 12:56.000 Lots of Python bindings improvements, 12:56.000 --> 12:58.000 uh, bindings, of course. 12:58.000 --> 13:01.000 Please remember, we love Rust for a few love Rust. 13:01.000 --> 13:05.000 Please come, um, trying to pull back source. 13:05.000 --> 13:08.000 It's like an element that sort of allows you to, um, 13:08.000 --> 13:10.000 to have a pull back source. 13:10.000 --> 13:12.000 You have, have a primary stream, and then it drops out 13:12.000 --> 13:13.000 for some reason. 13:13.000 --> 13:15.000 The network goes away, um, your, you know, 13:15.000 --> 13:17.000 graphic, your card doesn't deliver anymore. 13:17.000 --> 13:19.000 You cycle goes away from your capture card. 13:19.000 --> 13:21.000 Then you can sort of switch to background stream, 13:21.000 --> 13:23.000 and then if the primary signal comes back, 13:23.000 --> 13:24.000 you can switch back and, etc. 13:24.000 --> 13:27.000 But before that only worked for raw audio video, 13:27.000 --> 13:28.000 uncompressed audio video. 13:28.000 --> 13:31.000 So now it can also handle encoded output, 13:31.000 --> 13:33.000 which makes it much more flexible. 13:33.000 --> 13:36.000 And you can, uh, you know, if you have multiple stream, 13:36.000 --> 13:37.000 you have backup file. 13:37.000 --> 13:39.000 You can select good streams you want to, um, 13:39.000 --> 13:42.000 to use for the backup. 13:42.000 --> 13:44.000 Um, so then here's a little bit, uh, 13:44.000 --> 13:46.000 we've got some new element for VMath. 13:46.000 --> 13:48.000 VMath is a, uh, 13:48.000 --> 13:50.000 it's a framework by Netflix. 13:50.000 --> 13:52.000 Um, and basically, 13:53.000 --> 13:55.000 it tries to give like a perceptual, 13:55.000 --> 13:58.000 video quality of the score for your video. 13:58.000 --> 14:00.000 So if you, if you encode the video, 14:00.000 --> 14:02.000 then you can, let's give decoded and see like, 14:02.000 --> 14:03.000 well, you know, 14:03.000 --> 14:06.000 how would that framework rate the encoding? 14:06.000 --> 14:07.000 Um, and, you know, 14:07.000 --> 14:09.000 how would a human, 14:09.000 --> 14:11.000 perceive the encoding is a good, 14:11.000 --> 14:12.000 it's not good. 14:12.000 --> 14:13.000 You know, you can get some metrics for things. 14:13.000 --> 14:14.000 So quite interesting. 14:14.000 --> 14:16.000 We've got a new plugin for that. 14:16.000 --> 14:17.000 Um, 14:17.000 --> 14:19.000 a new webkit plugin as well, 14:19.000 --> 14:21.000 that uses the, uh, 14:21.000 --> 14:23.000 the embedded webkit platform API, 14:23.000 --> 14:25.000 which I think gives you more acceleration. 14:25.000 --> 14:27.000 Support, open gl, 14:27.000 --> 14:28.000 and, 14:28.000 --> 14:30.000 for a little bit. 14:30.000 --> 14:32.000 And super exciting. 14:32.000 --> 14:33.000 So I wrote it. 14:33.000 --> 14:34.000 And you, I've cast think element with, 14:34.000 --> 14:35.000 A.A.P support. 14:35.000 --> 14:37.000 It's similar to shoutcast, 14:37.000 --> 14:38.000 uh, 14:38.000 --> 14:39.000 shout to send, 14:39.000 --> 14:40.000 but shout to send, 14:40.000 --> 14:42.000 they're not going to add A.A.P support ever, 14:42.000 --> 14:44.000 because it's, you know, 14:44.000 --> 14:46.000 a proprietary format, 14:46.000 --> 14:47.000 or a lot of the price, 14:47.000 --> 14:49.000 but royalty, 14:49.000 --> 14:50.000 uh, 14:50.000 --> 14:52.000 Petting Royc and come load. 14:52.000 --> 14:54.000 So they're not going to add that, 14:54.000 --> 14:55.000 but need to add a client, 14:55.000 --> 14:57.000 and that's written rough. 14:57.000 --> 14:58.000 And which else, 14:58.000 --> 14:59.000 tracing in the bugging, 14:59.000 --> 15:00.000 lots of work going on there. 15:00.000 --> 15:02.000 If you've ever used, 15:02.000 --> 15:03.000 um, 15:03.000 --> 15:05.000 we have a mechanism to jump pipeline grass. 15:05.000 --> 15:06.000 It's a sort of dot file. 15:06.000 --> 15:09.000 And then you can render it into an SVG or a png, 15:09.000 --> 15:11.000 and you can see like a beautiful, 15:11.000 --> 15:12.000 you know, 15:12.000 --> 15:14.000 what your pipeline looks like basically. 15:14.000 --> 15:19.880 basically, which is very cool, but it's also very tedious. But, yeah, we've got a cool 15:19.880 --> 15:24.840 new feature where you can basically just be in these things to a web browser and, you 15:24.840 --> 15:29.600 know, then you just say like, I want a new graph and then it just pop up in a web browser 15:29.600 --> 15:35.720 and you can click on it and yeah, lots of stuff there. Very cool. Also for those who are 15:35.720 --> 15:43.000 writing plugins, we've got a sort of a logging system that's very, very chatty. And we've 15:43.000 --> 15:47.560 got more mechanisms now, basically, to find tune the logging output a little bit. Because 15:47.560 --> 15:52.100 sometimes you get a lot of spam, like some kind of warning is repeated like a million times 15:52.100 --> 15:56.580 just because get some packet loss somewhere and then it's just, you know, clutter your 15:56.580 --> 16:01.260 logs and you don't want that. Yeah, so we kind of have a mechanism now we can say like, 16:01.260 --> 16:06.900 you know, don't print this more than once a second or only printed once ever, things like 16:06.900 --> 16:12.500 that. So you can reduce that log message down a little bit. So if you, if you suffer from 16:12.500 --> 16:16.500 that, let us know if we can look at the code in question, maybe make use of that 16:16.500 --> 16:24.780 new API. And geistrum editing services is a library that basically provides you what you 16:24.780 --> 16:33.020 would need to, for a video editor basically. And yeah, lots of work going on there in recent 16:33.020 --> 16:40.580 times and lots of new features and also performance improvements. It's got new APIs to sort 16:40.580 --> 16:48.660 of manage threads better so that, you know, video elements can share threads if you do 16:48.660 --> 16:54.740 video processing and scaling and all of that. We across that form, so we don't just support 16:54.740 --> 17:02.540 the nodes, we support Windows, Android, iOS, Mac OS, etc. On Windows, Direct 3D12 has seen 17:02.540 --> 17:08.380 lots of new elements and lots of performance improvements. We've got a compositor, a Tish ID 17:08.380 --> 17:15.380 wall, a UV remap and an interlaced element. There's also like a Windows IPC element so 17:15.380 --> 17:21.020 you can actually send, you could use to send raw video buffers and audio buffers to 17:21.020 --> 17:25.780 different process on your system. So you can split up pipelines and you can, you know, 17:25.780 --> 17:29.380 have different applications that one independently and that one crashes the other 17:29.380 --> 17:35.020 to the works. But that only used to handle uncompressed video audio and actually I'm not sure 17:35.020 --> 17:38.820 if it handled audio, but it handled uncompressed video. But now you can send anything over 17:38.820 --> 17:43.900 as basically that's been made generic, which is quite cool. There are about a 3D and 17:43.900 --> 17:50.140 audio API from Windows and we support all of them. But now we basically worked on our 17:50.140 --> 17:56.580 was RP support and made that really great. It's got dynamic audio device switching, it's 17:56.580 --> 18:01.580 got more exclusive mode features, more negotiation features, so we're basically switching 18:01.580 --> 18:07.780 only to that now. The device provider will only advertise me, if you use it in the 18:07.780 --> 18:13.940 app. Apple MacOS and iOS, we've got more hardware curated decoding, we did decoding, more 18:13.940 --> 18:19.300 encoding features, can do HDR now. And we have something called navigation event handling, 18:19.300 --> 18:24.740 so if you have, you know, like mouse pointer movement across the video window, you can send 18:24.740 --> 18:29.300 that through the pipeline and other bit of a pipeline can do things like render menus or, 18:29.300 --> 18:32.460 you know, if you have a stream of web browser, then you can interact with the web browser 18:32.460 --> 18:38.900 that you've rendered and find that. But we support that now. And right, the hardware provided 18:38.900 --> 18:46.820 video that has seen some love. Several is sort of a matter of the system we have that 18:46.820 --> 18:51.700 we used to produce binary packages for Windows, Android, MacOS, etc, because on these systems 18:51.700 --> 18:56.220 you can't just install all the plugins and the libraries that we need to depend on, so 18:56.260 --> 19:01.020 we have to build everything ourselves and put that. So that's how it's so robust. 19:01.020 --> 19:07.740 Yeah, a couple of, well, we have a new Windows installer so it might not look like 9080s anymore, 19:07.740 --> 19:14.700 which is nice. We've got an R64, we'll put on Windows now. We will provide Python 19:14.700 --> 19:20.860 wheels on macOS and Windows so you can just install Gistreamer using PEP basically, which 19:20.940 --> 19:27.500 is quite cool to get started and we also ship GDK4. So if you are GDK4 hacker or you want 19:27.500 --> 19:34.060 to use it on Windows on Mac, you can use that now and use binary packages. All right, 19:34.060 --> 19:41.820 so I have a few minutes. What's coming up? Lots of Rust things, as I said, we love Rust, 19:41.820 --> 19:45.820 we add lots of new things in the Rust plugins. That's where most of the cool stuff happens, 19:46.140 --> 19:53.180 you know, apart from the analytics things of course. Yeah, media over Quake or Mark, I don't know, 19:53.180 --> 19:58.380 it's cool like that anymore, but it's sort of, you know, the ideas WebRDC is very, very complicated, 19:58.380 --> 20:04.620 sort of the made new things called Mark and it's yeah, quite exciting. But I think the spec is 20:04.620 --> 20:08.940 still very much in flux, but we have support for that. It's not merged yet, but it's a good lab, 20:08.940 --> 20:15.500 but hopefully that will then soon. We're putting more things to Rust, WebRTCsack is going to 20:15.500 --> 20:23.740 go Rust. Yeah, we've got the ISE bits already, the Rust library, which also has a C-refer, 20:23.740 --> 20:28.220 and we're going to drive the new Rust RTP Stack further, which has been sponsored by this 20:28.220 --> 20:33.340 or when Tech Fund a few years ago, more RTP payloads are going to be ported and in general, 20:33.340 --> 20:38.220 we're trying to improve scalability so you can run more pipelines in parallel, like thousands, 20:38.220 --> 20:46.380 tens of thousands of pipelines. Impact the ASCOS Rust as well. We're going to work in a complete 20:46.380 --> 20:52.780 rebuke of the impact the SD maxer, which will hopefully improve reliability, especially when 20:52.780 --> 20:58.940 they're sort of changes and the timing at the time domain, the clock changes. If programs 20:58.940 --> 21:06.700 which has happened, or you know, we want to make that much smoother than or designs or sort of little 21:06.700 --> 21:12.540 citrus, I think, should be fine, usually. And more little bit of stuff coming, especially, 21:12.540 --> 21:17.660 you know, like video formats for sciencey people, geo intelligence all about, they like, 21:17.660 --> 21:22.540 you know, fancy things, floating point numbers, complex numbers, find integer, so you can run 21:22.540 --> 21:27.900 and I let you take some of these things. That's coming up, I'm just working on that. 21:28.780 --> 21:33.420 And we have more speech and translation features, hopefully coming up, we support a lot of cloud 21:33.500 --> 21:38.700 services. Some of those you can run on site, speech medics, but it's still proprietary and 21:38.700 --> 21:43.340 you interact with it. If you think some API, it's just that the API sits on your own, that work 21:43.340 --> 21:47.500 and not on some other network, but you know, still, I mean, we open source people, we kind of want 21:47.500 --> 21:53.020 open source stuff. So I think, yeah, the new focus would be on local processing, so you can actually 21:53.020 --> 21:59.340 run speech detection and translation, et cetera, on your own computer, on your local system. 21:59.340 --> 22:05.900 So, you know, things like whisper, et cetera, I think, we'll be next. More formats, of course, 22:05.900 --> 22:11.420 every two, well, it was supposedly supposed to be out at the end of last year, but 22:12.380 --> 22:22.700 sure it's coming. HDR10 plus support is coming for a 6,5 and 81. Playback's luck, some improvements, 22:22.780 --> 22:30.540 a timeshift element plus if you want that. By the year I input, so you can have not just, you 22:30.540 --> 22:34.780 can, you can, you could have like multiple subtitles, for example, a lot of subtitles, 22:34.780 --> 22:42.620 as input, so lots of changes there. Cracing and debugging, hopefully, well, there's support for 22:42.620 --> 22:47.740 something, the rust world, there's something called the tracing crate, so we'll have more integration 22:47.740 --> 22:53.900 for that. And also, hopefully, you know, we'll have something like, so you can do per pipeline, 22:53.900 --> 22:59.180 the bugging, or per been the bug logging, because currently, if you enable the debug log, 22:59.180 --> 23:04.860 it's just the bug logs for everything in your process. And if you run 20 pipelines, it will drop 23:04.860 --> 23:09.500 20 pipelines, the debug logs, something you pipelines on you, and that's not always great. 23:10.540 --> 23:16.380 So hopefully, you know, we find ways to fine tune that. More things coming up, TVOS, 23:16.380 --> 23:22.860 what to ask in the vision of S support, and for me too hard to add, I'm in thought, and support for 23:22.860 --> 23:28.140 digital design content. And that's all I've got. Thank you very much. 23:32.140 --> 23:39.260 Thank you. Go, so any questions, can you put your hand up, action, and we pass the 23:39.260 --> 23:42.780 microphone so that people online and being recorded can take this up? 23:49.660 --> 23:56.460 So yeah, you mentioned we're adding support for a hip, but which is an abstraction of 23:56.460 --> 24:02.380 kuda, but is there the equivalent of kuda stream, and are we planning to have an integration for that, 24:02.940 --> 24:09.420 in the pipeline, when you have multiple island that are just, there's a change there. 24:09.420 --> 24:14.380 So I think I'm going to quote half of the question, are you asking about the hip part, or the kuda stream part? 24:14.380 --> 24:19.820 The hip part, are we going to have the equivalent of this in hip and, 24:21.660 --> 24:26.300 and I don't know what we're going to ask. You have to ask them, I'm not sure what his plan is actually on. 24:32.380 --> 24:56.700 Yes, hello. I have a question about the Vulkan video stuff, so we're using WebGPU, the RustWGPU 24:56.780 --> 25:04.860 GPU, great to render, and right now we're letting G-streamer create an OpenGL context for us, 25:05.420 --> 25:09.980 and we in the future would like to go all log, and so the whole pipeline is broken. 25:10.860 --> 25:16.220 Is that possible now from 128, or is there still stuff we need to wait for? 25:18.620 --> 25:23.340 I'm not an OpenGL, but I want to give you a wrong information, but 25:23.900 --> 25:33.500 so who should we ask? Matthew Waters, Sebastian Dweger, Sunker, Sunker, Sunker, Sunker, 25:34.620 --> 25:38.540 we'll jump on the matrix. All right, so that's good, she's there. 25:44.140 --> 25:45.420 The other side of the room again. 25:45.420 --> 25:56.860 Thank you, thank you. That's the link where all the G-streamer conference talks are for how 25:56.860 --> 26:05.420 the browser was of course done. I thought the speech to text and translation 26:05.420 --> 26:10.460 things running locally sounds very interesting, and from missing, is there a timeline for that? 26:10.780 --> 26:20.860 I mean, I think the first bits are going to land very, very soon, like weeks, rather than months, 26:22.220 --> 26:24.140 and then there's always more to, I guess. 26:32.540 --> 26:36.700 It's quite, it's a little bit tricky because you have to, I mean, just, you know, on the whisperside, 26:37.020 --> 26:39.660 I mean, it's not just the detection, but you wanted low latency as well. 26:42.060 --> 26:49.180 Yeah, the tricky to make that right. So are there any plans to make simpler command line tools? 26:49.180 --> 26:55.260 So for example, with FFMPEG, you just type of FMPEG input file and then output file with the right 26:55.260 --> 27:00.620 extension, I would do the right thing with just saying default. I don't know if there is already 27:00.620 --> 27:06.780 something like that with Gstreamer, I know that GST launch allows it, but with complex syntax. 27:08.220 --> 27:13.100 I mean, some of these exist already, so there's something called GST Transcoder, which allows 27:13.100 --> 27:18.940 you to, you know, basically, for the transcoding use case to have a simpler pipeline syntax. 27:20.620 --> 27:26.860 So, you know, that doesn't work for you. Then there is the GES launch bit for the editing services. 27:26.940 --> 27:31.820 So you can do everything, GST, the editing services library can do, but otherwise, you know, 27:31.820 --> 27:36.700 write new tools for specific use cases and submit them. But I mean, I think it's a good goal. 27:36.700 --> 27:38.940 It's just that, you know, don't have time again. 27:41.180 --> 27:46.700 I found a question about the synchronicity of the different streams. So if Gstreamer can 27:46.700 --> 27:51.820 accumulate so many streams, for example, captions or the metadata, how synchronized are there 27:51.820 --> 27:57.020 with the real image data and is there some guarantees that Gstreamer cares for or how is it working? 27:57.980 --> 28:02.780 We have a very, very good sort of timing and synchronization model. So it's basically, you know, 28:02.780 --> 28:07.420 if your input is good, it will be perfectly synchronized. So, I mean, you know, we have the, 28:07.420 --> 28:13.740 we have clocking, we have clocks in the pipeline, we have the time stems. You can attach 28:13.740 --> 28:18.860 metadata to both of us. So, I mean, everything will be perfectly synchronized as long as, you know, 28:19.260 --> 28:25.420 right times then, I put on things. And the, you know, the elements sort of honor the chosen 28:25.420 --> 28:32.780 clock for the pipeline. So it should always be perfect. So if I, if I have a, for example, 28:32.780 --> 28:37.580 submit a data, attach to specific frames, can I be sure they will arrive at the same frame 28:37.580 --> 28:43.180 at the receiving site? Yeah, I mean, if it's attached to the frame, then it will always, you know, 28:43.180 --> 28:51.260 be carried with the frame. Okay, cool, thanks. All right, probably out of time now.