WEBVTT 00:00.000 --> 00:14.560 Oh, so hello everyone, welcome to the 2025 edition of the Geistreamer State of the Union 00:14.560 --> 00:21.200 presentation. So just in case Geistreamer is a multimedia framework, which is based on graph, 00:21.200 --> 00:27.120 and that can be extended with plugins. But this is not a point of the presentation, 00:27.120 --> 00:33.120 it's to update you on what's going on. So Geistreamer is actually 25 years old, which is kind 00:33.120 --> 00:40.160 of nice because fuzz them is also 25 years old. So it always matches. It has had over 2000 00:40.160 --> 00:48.160 contributors with the other little facts there. So quite a big project. And despite his age, 00:48.160 --> 00:55.200 it's still pretty active. So on of the course of 2024, it's up till now. We have had around 00:55.200 --> 01:04.000 50 contributors per month, which for a total around 300 patches per month on the project, 01:05.040 --> 01:11.760 getting merged. And in terms of releases, so we've released three bug fix releases on 122 01:11.760 --> 01:18.400 since last fuzz them. So I'm not released to release. I'm using the last fuzz them. 13 bug fixes on 01:18.480 --> 01:25.440 124. And we actually released 125.1. Don't be fooled. It's not a real release. It's a 01:25.440 --> 01:30.480 development release. You shouldn't use that in production. But that means that we are very, 01:30.480 --> 01:37.920 very close to 126. Geistreamer rust. It also has the same releases, but it also has this 01:37.920 --> 01:45.120 releases cycle on crates.io. So for that we had 14 releases of the Geistreamer bindings and 18 01:45.200 --> 01:51.200 releases of the plug-ins there. Just know that not all plug-ins go forward because they don't change 01:51.200 --> 01:59.200 every release. So we don't want to put out crates.io. In terms of GitLab, what does that mean? 01:59.200 --> 02:06.960 So in terms of merge requests, it's 1200 merge request, which on the mono repo, which 400-ish 02:07.920 --> 02:15.120 got actually backported. So massive amount of fixes that get back into the stable tree, 02:15.120 --> 02:21.600 just to make stable better. And a couple of backports also in 128. 02:21.600 --> 02:31.280 160 merge requests on the rust mining. 380 merge requests on the rust plug-in rust is a growing 02:31.280 --> 02:35.520 part of Geistreamer is no longer optional. If you want all the features of Geistreamer 02:35.600 --> 02:42.160 you need to include this plug-in pack now. And it's now well integrated in most Linux distribution. 02:43.760 --> 02:49.280 It'll mention I don't do usually, but 230 merge requests on our build system this year. It's 02:49.280 --> 02:57.120 getting a nice re-haul. It will get to that a bit later. So yeah, security fixes. It was a big year 02:57.120 --> 03:03.520 in terms of security fixes. So security fixes comes in different banners. There are actually 03:03.520 --> 03:09.760 from a bunch of researchers, which help us do that. So we have a revamped process actually to handle 03:09.760 --> 03:16.720 these and make the patch and co-review those patches in a private GitLab protected GitLab 03:16.720 --> 03:24.000 tree. So it's much better, I think, now and it gets through the CI and everything. And we managed 03:24.000 --> 03:30.560 to handle 29 security fixes. 25 on the GitLab security lab banner. I don't know if it's all 03:30.640 --> 03:37.280 that company, but and then two were reported under the Java and security notes and one under 03:37.280 --> 03:41.520 the zero-day initiative, which has been there for a much longer amount of time. 03:42.720 --> 03:49.360 And we get into what actually changed inside Geistreamer. So my organization is not perfect, 03:49.360 --> 03:55.120 but it's an approximation and it doesn't cover everything there's too much. So let me start. 03:55.120 --> 04:00.000 So at the very core of Geistreamer we have libraries, helpers, and stuff. And that a structure 04:00.000 --> 04:07.680 and we're trying to reduce the memo lock that we do all over the place. And Geistreamer 04:07.680 --> 04:15.360 DQ is one of them. It's a replacement for most of our usage of the Q from GeLab. And it uses 04:15.360 --> 04:22.400 a vector, but it implements the Q logic. And it's using a multi-QQ, everything that Q has been 04:22.480 --> 04:30.000 important to use that. The messages have always had a detail structure in there. It was just 04:30.000 --> 04:37.840 hidden, so not with nothing anymore. Tag list, new tags coming. We now have the ability to place 04:37.840 --> 04:43.920 caps structure into caps. Something we've talked about for years, but nobody ever implemented it 04:43.920 --> 04:50.560 finally happened. So now you can have caps within your caps. And we target using that within the 04:51.520 --> 04:56.080 AI domain where you need to negotiate the tensor format, but you still have the original picture 04:56.080 --> 05:02.800 format and you need to match these things. That's a melting pot of serializer, the serializer, 05:02.800 --> 05:08.480 so a lot of stuff goes through the pipeline parser, which is text, you need to transform that into 05:08.480 --> 05:14.640 object and back into text. So there was some stuff that was not serializable. And there's this 05:14.640 --> 05:20.480 new thing, the GSTID string, I had to read it because I have a hard time remembering, but it's an 05:20.480 --> 05:27.360 optimization over the quark to try and get rid of the locking actually as much as possible. That was 05:27.360 --> 05:34.400 implicated there, not getting into details. In terms of libraries, so we have higher-level libraries 05:34.400 --> 05:39.360 for video for audio for stuff like this. So in the video library, there's the Ancillary Metadata, 05:39.360 --> 05:46.000 which gained yet more, and so you did a metadata formats. Something that haven't been touched 05:46.000 --> 05:51.360 for years, the navigation event. Now it has been improved to have mouse double click and scrolls. 05:52.720 --> 05:58.960 The video converter is being worked to do better 10 bits support, has more 10 bit formats. 05:59.680 --> 06:05.520 And one of very cool fix because it's a bug that has been around for a while is there's been a 06:05.520 --> 06:10.960 rework of the deadline calculation with the QS event, which is the thing that decides to drop frames 06:10.960 --> 06:15.200 ahead of time within your pipelines so that you don't waste too much CPU when you're late. 06:16.240 --> 06:22.560 And yeah, now it behaves as we expect, meaning that if it's truly, truly late, it will at least 06:22.560 --> 06:28.800 render one frame per second. So it's not going to drop everything and confuse users. 06:29.680 --> 06:36.320 But every video filters, a few properties, this one got mentioned one 24, so you can 06:37.200 --> 06:43.200 basically clip your data when it goes into video rate that goes out of the segment when you have 06:43.200 --> 06:51.360 segment seeks and stuff. The audio cutter was calculating an audio level in RMS, but it was 06:51.360 --> 06:56.000 keeping for itself. So now it's being exposed to the audio level meta, so you don't need to kind of 06:56.560 --> 07:04.800 combine it with the level element in ways more cycle. Right-and-pitch has implementation for reverse playback. 07:07.840 --> 07:14.240 Yeah, more format in video clips. The bangles of really have this new feature where they're 07:14.240 --> 07:20.960 used for like subtitles or clock sync or stuff like this and you can actually tell it like what's the 07:21.920 --> 07:28.320 on-included render delay for your display and you can compensate for it and can be kind of 07:28.320 --> 07:31.840 useful if you do calorie care or stuff like this, there might be other use cases, I'm not the 07:31.840 --> 07:39.040 world. But and then the volume, the volume always had this limitation that NX was the maximum 07:39.040 --> 07:44.720 again that you put on the volume and we actually removed that because it's floating point 07:44.880 --> 07:52.320 out and then if you're in and it's just going to cap. And now the audio converter can do more than 07:52.320 --> 07:58.720 64 channel and there's a really interesting feature on scale tempo which is the fit down feature 07:58.720 --> 08:04.560 where you can create buffers that are too large for the duration that they're supposed to be and 08:04.560 --> 08:10.800 the scale tempo thing will resample. Well, we'll kind of convert them to make them make the things 08:10.800 --> 08:18.000 peaks faster but fit the window. This is interesting for cases where you do a text to speech 08:18.000 --> 08:23.280 but the combination of all these things like with translation from one language another but 08:23.280 --> 08:29.440 one translated it doesn't fit so you can make it speak faster. I think it's interesting. I didn't 08:29.440 --> 08:36.720 know about it before I prepared this slide so there's quite some work actually on adding analytics 08:37.040 --> 08:44.320 metadata supports and also AI supports native in g streamers so that different frameworks can 08:44.320 --> 08:51.680 change between each other and can negotiate between each other. So we now have design documents 08:51.680 --> 08:57.200 so when we add stuff we can document it and we can actually challenge it with the others. There's 08:57.200 --> 09:04.480 this segmentation meta that got added the tensor meta the tensor decoder which were already separated 09:04.480 --> 09:10.240 from the execution of your inference is now separate but now it's outside of OIDNX so it's no 09:10.240 --> 09:17.440 longer specific to one stack and we know that Intel on stack is starting to use that so that's 09:17.440 --> 09:23.360 quite interesting so we have a second vendor that is using it. You can do some rotation when you do 09:23.360 --> 09:28.560 object detection so that you can have a rectangle and squeak it so you reduce the surface. 09:28.640 --> 09:38.960 Yeah we have this element that that was written it is basically converter that converts the 09:38.960 --> 09:45.360 relation meta data from your AI research into on-vift meta data and then using on-vift means 09:45.360 --> 09:50.160 that you can stream it over RTP and then you can take that back on a remote machine like your 09:50.160 --> 09:56.960 server or whatever and you can put the logic somewhere else. So you do the AI you send the results 09:57.120 --> 10:03.920 somewhere else and then you recover it through RTP. Original buffer it's an interesting one so 10:03.920 --> 10:10.480 when you do AI you always have to scale down and crop to a square or something and you always have 10:10.480 --> 10:15.200 the need to recover the original image to put back the meta data on the original image so that's 10:15.200 --> 10:22.880 exactly what it does so it will save the buffer in its own meta data and then once you're done it 10:22.880 --> 10:28.720 will restore the original image getting rid of the small one from the that was used for the AI and 10:28.720 --> 10:35.200 then it will reapply the meta data and apply some transform to it of course if it's a resolution bound. 10:36.640 --> 10:41.680 And there's a lot of work done on the Python binding to the ideas that Python is the 10:41.680 --> 10:47.440 predominant language for AI stuff so it's mostly at the control level because it's not that 10:47.520 --> 10:56.400 performance inside G streamer itself as a plugin. Stream containers yeah a lot is going on there 10:58.160 --> 11:04.000 so stream containers that's basically impact TS is a went before MKV so a lot of future got added 11:04.000 --> 11:12.160 into MPGTS it has a segment seeking where you can have a stop time and loop back on some zones it's a 11:12.320 --> 11:18.320 bit difficult with things like MPGTS it's not meant for that there's GPEG access as being map 11:18.320 --> 11:28.880 PS meta data I'll skip that one more and so every data including AES there's a it's not complete 11:28.880 --> 11:36.560 but it's support for synchronous KLV streams there we have a custom just from a specific mapping for 11:36.560 --> 11:42.320 VP9 so you can actually put some VP9 there it's not illegal but it's going to be ignored by 11:42.320 --> 11:48.560 most player because there's no spec for it there's a provisional spec for AV1 that has been implemented 11:48.560 --> 11:57.200 and VVC has been added and the I thought it was provisional that's what they said in the 11:57.200 --> 12:06.000 comment message they lied I need to read more than the message than next time I saw MP4 it's a bit 12:06.000 --> 12:11.040 confusing because it's being rewritten really in in Ross but there's one in C it has gained some 12:11.040 --> 12:16.640 C I ain't simple grouping and you are going I don't know the laggerit lossless video support 12:17.440 --> 12:24.320 more MPG video one mapping and I'll compress audio and hopefully before the release but I'm not sure 12:24.400 --> 12:29.920 there was a lot of work that was spending for on compressed video in there and then on the 12:29.920 --> 12:36.480 Ross side the reason for the rewrite was because the old one was difficult for fragmented MP4 not 12:36.480 --> 12:41.360 ugly so they wrote a new one but the new one is good so they started to write more and it's 12:42.160 --> 12:47.040 probably eventually going to replace and as you can see most of the list there are features that are 12:47.040 --> 12:52.640 just to get back to parity or more over the engine so I can predict that eventually 12:53.280 --> 12:59.040 this will take over and the sign of that the dash 12:59.920 --> 13:05.440 max are basically as changes preference and prefer the the Ross implementation now 13:06.400 --> 13:10.720 the reason it was not is because it was missing all these things which was very useful 13:12.320 --> 13:22.160 not a work in D3D 12 API this year it really became the default not D3D 11 anymore so it has a 13:22.240 --> 13:28.800 GST Libs helper for the shader which are the same it's been split in his own library so there's 13:28.800 --> 13:36.480 helper library to do HLSL yeah new feature new capture it has the IPC source and sync like the 13:36.480 --> 13:43.440 D3D 11 one there's some feedback when you do plug-in of your GPU I've never tried that in my life 13:44.000 --> 13:49.920 something I should someone made it a me made it compile by removing feature on a Ming 13:49.920 --> 13:56.480 DW so that's kind of nice it's integrated into convert frame that's something related to 13:56.480 --> 14:03.840 on sync when you get the sample anyone to convert it to something yeah let's keep this one 14:03.840 --> 14:08.480 map mapping support even though there has been some regression reported we'll have to check if we keep 14:08.560 --> 14:16.080 that one as a default and more scale or more scaling and interlacing feature just to complete the 14:16.080 --> 14:24.480 portrait some nice feature something that can be annoying with things in D3D but they added an option 14:24.480 --> 14:30.160 that once you close the window it doesn't throw an error I think I think it's nice we should probably 14:30.320 --> 14:39.440 generalize that one to do and yeah of course this is the same guy you did the new navigation event 14:40.400 --> 14:47.200 in the navigation API so it's got implemented there so it's my it's more complete it has color balance 14:47.200 --> 14:54.800 implementing the color balance API HDR capture more pixel formats what else oh until he 14:54.800 --> 15:01.760 has him in the swap chain sync element there's a VPH encoder so our legacy is covered and 15:03.200 --> 15:08.480 yeah it's just oh yeah the rain the rain got got turned into primary for most of these elements 15:08.480 --> 15:13.200 so they become like the decoders are primary they're gonna be picked by gentle plugger 15:14.160 --> 15:21.600 more window stuff web view too which is kind of the windows widget for web view is like the 15:21.680 --> 15:31.840 the WPE of windows it's been implemented yeah the right QSV and other things I mean they there's a lot 15:31.840 --> 15:38.880 of places where they actually just added interlacing to make sure that it can be used with D3D 12 15:40.160 --> 15:45.360 and yeah and there was there has been some maintenance in the D3D 11 element too because that's 15:45.440 --> 15:55.520 not going away and then we can move to a big block the codex domain which includes many things so 15:55.520 --> 16:02.880 I've started splitting with the parser and the software codex one of the why change we did is that 16:02.880 --> 16:09.840 initially we had a v1 and we didn't really clearly define what a v1 was and it's actually multiple 16:09.920 --> 16:16.960 packing format organization of your AV1 streams so now we've pretty much explicitly set a TU alignment 16:16.960 --> 16:22.880 on the element that didn't specify anything so it's it's very clear what you're actually streaming 16:24.080 --> 16:30.160 TU is time unit for those that are not aware H6X4 pars now supports the AVCD codex 16:30.160 --> 16:39.840 configuration we attempted to implement a backlog to fix some AU splitting issues was a failure we 16:39.840 --> 16:46.240 reverted it hopefully we're going to have time to look at that again this year VVC parser with the 16:46.240 --> 16:51.520 typefinder and the mime type has been merged so it's not complete yet there's going to be more work 16:52.160 --> 16:58.720 but at least the basic is there you can parse it it exists you can find it so so it's start and you 16:58.880 --> 17:06.640 can mix it into MPEGDS I'll see EVC that's kind of a supplemental layer on top of legacy codex 17:06.640 --> 17:12.400 so it works with any codex it's a MPX standard and has been implemented software the 17:12.400 --> 17:23.440 color and then color the hardware part is to do and the SVT GPExS software codex has been added 17:23.440 --> 17:31.680 including interlay support and someone enable the m101 matrix on compressed video support 17:31.680 --> 17:39.600 that is implemented in an FFMPEG and also we expose the color roomy three out of David decoder 17:40.400 --> 17:45.520 and yeah a final one a bit special so we have a fake decoder now it's called a fake video deck 17:45.520 --> 17:50.160 you can give it anything you want and it's going to decode it right and it's going to generate 17:50.160 --> 17:57.360 you a snake pattern this is very nice for a unit test where you basically just need something that 17:57.360 --> 18:04.400 moves you need the video but you don't need the real decoder. Vulcan VAM SDK so basically all the 18:04.400 --> 18:12.880 accelerators so the Vulcan video support is progressing slowly we got an h265 decoder now 18:13.600 --> 18:22.560 and there's more work pending the VA encoders is mostly feature complete so GPG VPA VP9 18:23.280 --> 18:28.080 the rate controls are I've been enable render delay to optimize the performance 18:28.080 --> 18:35.600 unfortunately we add to these able the i 965 encoders that are on maintained by Intel 18:35.600 --> 18:41.200 and are just too crashy we would have to implement the legacy code to make them work losing the 18:41.200 --> 18:52.640 M above and we decided not to do that we now have a VVC decoder and yeah that's it the past processor 18:52.640 --> 18:57.600 has interpolation enabled but it's limited to iHD it's the only driver that implement that 18:58.240 --> 19:07.280 and Intel folks did the same thing in msdk framework on the before I'll side both plugins now 19:07.280 --> 19:14.640 implement the dma drm caps negotiations so you can negotiate dm above with a dm with a drm format 19:14.640 --> 19:21.360 from the next drm not the right management thing and modifier so you can actually effectively 19:21.360 --> 19:28.880 negotiate an opaque format enabling compression notably the dec 400 from VVNTE or fbc from arm 19:29.520 --> 19:36.560 that's now possible there's still some refinement to do but it's a lot better so 19:36.640 --> 19:44.960 126 to look forward there was some stuff in 124 now it's a lot more usable in complete in in the next version 19:47.840 --> 19:52.960 we implemented what we called dynamic frame rate in g3 mer011 on the before l2 state full 19:52.960 --> 20:01.200 and remade codec the native implementation has been added so it reduces the amount of interaction with java 20:01.200 --> 20:09.520 engine making it faster and more profiles and stuff we remove the magically implementation 20:09.520 --> 20:15.360 because they dropped it on their site so we dropped it they actually use the the Android and decay now 20:16.160 --> 20:22.400 and on macOS traded output got enabled that took a while actually more rainfall 20:22.480 --> 20:30.240 hvc alpha and hlg there that's me move on a bit faster so in our tp streaming 20:31.360 --> 20:36.320 we have a bunch of new features i'm not going to name them all but i think it's good to mention 20:36.320 --> 20:45.120 that synchronization has been improved quite a lot and bigger feature also the renegotiation 20:45.120 --> 20:51.440 and web rtc been i think that that's kind of very useful and was missing it's probably also 20:51.440 --> 20:56.800 helps in making it more compliant more web compliant implementation 20:59.920 --> 21:08.960 more streaming rtmp2 which replaces the rtmp plugin basically they implemented ideas from live rtmp 21:09.440 --> 21:17.680 so you can actually add commons i mean it's more like an IPC the rtmp protocol so you need to 21:17.680 --> 21:22.400 be very flexible so it adds a bit flexibility and there's the line network authentication that 21:22.400 --> 21:27.600 I did you plug in the rust side queen i think it's queen i don't know the pronounce it 21:27.600 --> 21:33.840 which implemented quick protocol sourcing sync pretty nice and payg live source 21:34.400 --> 21:41.040 which basically is a wrapper that wraps an MPKS source reads the PCR and generate a 21:41.040 --> 21:47.680 clock from the PCR and that let you basically play back the thing on sync with the incoming string 21:48.880 --> 21:56.560 the transmitter clock basically in that years hlsmulti variant that's basically the fourth 21:56.560 --> 22:02.240 implementation of an hls sync but this one is it's specialized you can see by his name so 22:03.040 --> 22:07.760 i'm not an expert i'm not gonna go too far but it's there it's new you can use it 22:09.600 --> 22:14.320 oh i skipped the lyrics so you can you can actually ingest the lyrics from a Spotify 22:15.040 --> 22:23.200 which is nice if you do a karaoke of course we got a rewrite ongoing that was announced 22:23.200 --> 22:27.520 two years ago when hearing about the rtp stack and this is pretty active 22:28.240 --> 22:34.000 the initial RTP been got merged there's an RTSP client that has been written 22:35.280 --> 22:40.000 of course if you want to rewrite you need to write everything so payloaders are being rewritten 22:40.560 --> 22:47.520 so a really big set of it got written and then we got to web RTC so there's 22:49.440 --> 22:52.080 you need to kind of layer it up 22:53.040 --> 23:01.200 a v1 in the raw has been added and yeah you can actually change your your resolution and 23:01.200 --> 23:06.480 framerate dynamically and there's more support for different encoders which we 23:06.480 --> 23:16.720 unfortunately have to wrap individually to support this may accelerator yeah 23:17.040 --> 23:22.720 what should i mention is why i need to skip a little bit so you'll find dmb of support in gls 23:22.720 --> 23:31.280 think then dmb of support in wailin some improvement on the qt where you can actually do the 23:31.280 --> 23:36.400 color convert at the same time your render that's quite nice we should generalize this one too 23:38.320 --> 23:45.200 gtk for the gtk for paintable as gain dmb of past true so you can actually get the dmb of 23:45.280 --> 23:52.240 straight into gtk and gtk will try to use a hardware plane so it will actually internally 23:52.240 --> 23:58.320 create a subsurface and do all this stuff for you making it probably one of the most flexible and 23:58.320 --> 24:04.320 performance thing we have so far in the on the lean excite at least so watch that out it's really nice 24:05.360 --> 24:15.120 and yeah and yeah that that was possible with the ability to pass true dmb of in the 24:15.440 --> 24:24.480 gl sink wrapper video capture there was a bunch of issue in the qml six source now it's usable 24:25.040 --> 24:30.560 i don't think it's perfect but it's usable and it actually uses the downstream pull that you provide to it 24:31.360 --> 24:37.440 which has been a key in being able to do zero copy to the to encoder through that that sink 24:37.520 --> 24:47.200 there's support for the adja capture cards capture and output cards decling ones got improved with 24:47.200 --> 24:54.640 HDR you can now in image frame image freeze and life sink you can actually pass compressed data 24:54.640 --> 25:02.640 so i frame only compressed images because there was no reason not to there's this new q which is called 25:02.720 --> 25:09.680 god buffer which basically queues a minimum of one gap there's a tracer that i think is pretty nice 25:09.680 --> 25:16.320 in rust that will output basically a point in your stream into a pickup and then you can 25:16.320 --> 25:25.200 analyze the pickup with a tool like wire shark or other tool and yeah there's also a new elements 25:25.200 --> 25:31.840 that let you modify the group IDs in the streams that's more of the issues because oh and 25:32.000 --> 25:35.040 disrumrated in services i've gained a reverse playback this year 25:38.480 --> 25:44.720 much time I got okay so in the close captioning i think it's just moving to rust quite quickly 25:44.720 --> 25:52.400 last year there was like one one logo no it's only this and yes mostly c a seven o eight implementation 25:52.960 --> 25:58.800 and with backward compatibility so i think it's quite a full feature and there's integration with 25:58.880 --> 26:05.280 the transcriber so the transcriber bin is a bin that let you transform text into speech speech into text 26:05.280 --> 26:11.600 and most of the implementation are of course using cloud-based AI system to do so but it doesn't 26:11.600 --> 26:21.200 have to and it also transformed the text into close caption so it's a nice little adapter there well 26:21.280 --> 26:28.880 it's not little um as i said there was a lot of changes in the rehaul of the the cross platform 26:28.880 --> 26:35.840 build system that we use this is used mostly to produce like windows, android, macOS images where we need 26:35.840 --> 26:40.880 to build the dependencies also in order to make those binary while on Linux we rely on distribution 26:41.520 --> 26:47.600 to take care and yeah basically there was a lot of plug is not enabled for a long time or because 26:47.600 --> 26:56.160 there's a new rust support was not everywhere so it's been added where possible and yeah small 26:56.160 --> 27:01.520 feature lip prox is now a dependency that we build so that you can do prox see if there's still something 27:01.520 --> 27:09.120 you do in 2025 and yeah last but not the least i wanted to mention the work we do on it is happening 27:09.120 --> 27:15.600 on arc just in time compiler so it's a byte code language that get translated into s i md 27:16.400 --> 27:23.040 and there's two developers that are pretty active on refactoring cleaning up, optimizing, 27:23.040 --> 27:28.800 improving the cache usage and they have actually a bunch of ideas to make it better and one of 27:28.800 --> 27:34.080 them important change which is one of the cause of disabling arc and making all the software stuff 27:34.080 --> 27:41.760 really slow is that it can detect s elinex and no exact flag which would otherwise crash 27:41.840 --> 27:49.440 as usual if you need help you want to reach to us you want to talk to us we got this course 27:49.440 --> 27:53.600 which is the forum which has been very active i didn't extract any statistic on it but i think 27:53.600 --> 28:00.160 would be nice in the future we're preactive on metrics we have dedicated channel for different 28:00.160 --> 28:08.080 subjects there's channels for newcomers if you feel that is to kind of impressive you can file bugs 28:08.080 --> 28:14.160 there in github if you find any issues just remember an issue is not a support ticket we got the 28:14.160 --> 28:18.720 forum for that so it's because you think something is broken in github or it doesn't matter if 28:18.720 --> 28:24.320 it's true or not that's our job to tell you just don't confuse the support from that and it 28:24.320 --> 28:30.560 makes our life a little easier we're not as big group of maintainer but we have a quite big amount of 28:30.560 --> 28:39.040 issues and issue reporting and major requests to deal with and that's it we should have about five 28:39.040 --> 28:46.480 minutes for questions i believe and thank you 28:51.120 --> 28:55.120 yes 28:55.120 --> 29:04.720 so the question is if i can and elaborate on what is the synchronization improvement in 29:04.720 --> 29:14.640 RTP been partially because i was not involved but it's related to the synchronization the 29:14.640 --> 29:22.720 flux synchronization in RTPC feedback so best will be to go look at the yeah but i don't i don't 29:22.720 --> 29:27.360 have the i didn't dig into the details for that one this year do you have anything a 29:27.360 --> 29:39.360 timid that you would add right but part of the comments i've read there was like 29:39.360 --> 29:44.880 cases where it will integer overflow which doesn't it's not a security issue but it's a 29:44.880 --> 29:51.360 statistic problem yeah so there was bits of that and it would break other mechanisms 29:51.360 --> 29:56.880 that depends on having the right the right value there and it's i think i think some of this 29:56.880 --> 30:02.560 is quite visible now that people uses it in browser with static statistics graph something we never 30:02.560 --> 30:08.560 made any effort on before except from pexip which do that in their own property system so we don't 30:08.560 --> 30:15.760 necessarily see it if we're doing something wrong yeah other questions 30:21.360 --> 30:46.960 yeah going I would call the RTP been in a work in progress mostly not i think the features 30:46.960 --> 30:52.960 like that implemented are oh yeah sorry so the question is uh basically our usable is the new 30:52.960 --> 30:58.880 RTP been in in the rough implementation um my belief for what i've seen and what i've got a 30:58.880 --> 31:05.760 report i haven't used it myself mostly a hardware accelerator guy but what has been implemented 31:05.760 --> 31:13.040 has been done as well as possible so it's new code but it should be fairly usable but it's missing 31:13.120 --> 31:19.120 feature and when we speak about RTP we speak about a lot of feature we speak about hundreds and 31:19.120 --> 31:27.040 hundreds of pages of spec for all these these features so this is going to take some time i think the 31:27.040 --> 31:32.880 transition to to and sorry a question about when we'd be the transition will be when we can actually 31:32.880 --> 31:38.320 put that back into a browser and the test actually shows us that it's good enough for a browser 31:38.880 --> 31:43.840 i think that that would be the right answer i'm making up maybe some developer won't agree with 31:43.840 --> 31:51.360 me so just take it with a grain as well of salt that's my belief the main point of the new 31:51.360 --> 31:57.440 RTP been is also to address some of the performance issues when you do multiple sessions actually 31:57.760 --> 32:11.760 concrete yeah that's a good question because okay so for the GPEG access from SVT implementation 32:11.760 --> 32:18.000 traditionally these are made for our PC server the actually specifically made for Intel server 32:18.800 --> 32:23.840 so that's something that i would be curious to check myself too so thanks for the question 32:23.840 --> 32:36.960 i don't have an answer for you but it's a good question really really yeah so do i know 32:36.960 --> 32:45.760 what explicitly changed for the NVMM cooler work basically the caps negotiation for the NVMM 32:45.760 --> 32:52.080 caps feature has been completed and is usable now so basically in two caps you can you can open 32:52.160 --> 32:58.880 the parenthesis and have memory column NVMM and that comes with a bunch of APIs that you need 32:58.880 --> 33:05.600 to use specific to Nvidia and these these are being I have been added there's a big benefit 33:05.600 --> 33:11.280 when you use actually the the downstream basically stack from from in the 33:11.280 --> 33:27.680 yeah so i'll repeat to measure i heard correctly so if we have an initiative to 33:28.320 --> 33:35.200 be able to translate GSM into web assembly right i believe it's something that has been 33:35.200 --> 33:44.160 attempted in the past but it's extremely difficult because GSM is the framework the real hard task 33:44.160 --> 33:51.120 is done by dependencies by library so when we speak about web assembly of GSM you don't just have 33:51.120 --> 33:56.800 the GSM code base that would be really easy you actually need to pull all the dependencies and this is 33:56.800 --> 34:03.280 a hundreds of library which are built differently with different languages so i think it's a big 34:03.280 --> 34:08.960 feat you can probably make it with a subset of plugins that that you want to use but i think it's 34:08.960 --> 34:20.080 gonna be really difficult how that will be really nice so Tim was saying that there's a project 34:20.080 --> 34:26.640 that started and they they actually being made a website in post of the result and the difficulties 34:26.640 --> 34:38.000 or they're good things they managed to do so something to search time is up thank you very much