https://gstreamer.freedesktop.org/conference/2026/
The conference will take place at the Impact Hub Prague in Prague 5 - Smíchov.
The call for presentations is now closed, but you can still submit lightning talks.
Submit your talk or lightning talk proposal now!
We want to hear from you, what you are working on, what you are using GStreamer for, what difficulties you have encountered and how you solved them, what your plans are, what you like, what you dislike, how to improve things!
New to GStreamer or haven’t contributed code yet? Not a problem! We especially want to hear from you if you’re new to GStreamer, haven’t presented at the conference before, or haven’t had a chance to contribute upstream code yet.
The initial submission needs to be only a couple of sentences or paragraphs describing the talk you want to give and the desired length of your talk.
You will still be able to edit and refine your talk proposal after the initial submission, so there’s no need to hold off until the last minute to get it perfect.
Please allow at least 5 minutes for questions at the end as well.
Talks will be reviewed and slots allocated on a rolling basis, so make sure to submit your proposal sooner rather than later!
Lightning talks can be submitted until the day of the conference.
Talks can be on almost anything multimedia related, ranging from talks about applications to challenges in the lower levels in the stack or hardware.
You can request a slot for one of the following durations:
including questions.
Submit your talk or lightning talk proposal now!
Registration will open soon. See the main conference page for updates.
Follow us @GStreamer on Mastodon or Bluesky, our Discourse Forum, or the GStreamer Events channel on Matrix for the latest updates and to stay connected. Or check the main conference website (see above).
Open Space
This talk will take the usual bird's eye look at what's been happening in and around GStreamer in the last release cycle(s), current challenges and look forward at what's next in the pipeline.
Open Space
As the GStreamer framework continues to be a leading tool for building complex video analytic pipelines, the need for seamless interoperability across vendor components is more critical than ever. While the GstAnalytics library, introduced in GStreamer 1.24, provides a flexible foundation for representing AI-driven metadata, its very flexibility has resulted in slight differences between various implementations, hindering the creation of truly plug-and-play analytics pipelines.
This talk presents a collaborative effort by Intel, Collabora, and Milestone Systems to develop a unified convention for GstAnalytics metadata, ensuring consistent interpretation and consumption across the ecosystem. We will introduce a comprehensive set of guidelines that standardize the use of GstAnalytics relations for linking object detections, classifications, keypoints, and segmentation data.
Daniel Morin will present key challenge in this effort: striking the right balance between specificity and generality, where the convention needed to be concrete enough to guarantee interoperability between independently developed component, yet general enough to avoid over-fitting to a specific industry use-cases.
To demonstrate the power of this standardized approach, we will cover two significant industry adoptions:
1. Intel's DL Streamer: We will showcase how Intel has transitioned its DL Streamer framework from custom metadata formats to this new GstAnalytics convention, enabling broader compatibility with the GStreamer ecosystem.
2. Milestone Systems' License Plate Recognition Integration Case Study: We will present a practical development use case exploring the challenges and lessons learned while integrating analytics components from multiple vendors. By combining components from Intel DL Streamer and Milestone within the same container, we will discuss the requirements and design decisions involved in enabling analytics metadata produced by one vendor to be consumed by another.
Through a demonstration (recorded video) of a complete License Plate Recognition (LPR) solution using the pipeline vmssrc → gvamotiondetect → vmslpr → gvatrack → vmsmetadataexpose, we will show how GstAnalytics metadata serves as a common language between elements.
Attendees will leave with a clear understanding of the new GstAnalytics proposed conventions, the integration challenges encountered, and see firsthand how industry leaders are building the next generation of seamless, cross-vendor video analytics workflows.
Large Conference Room
This talk gives an overview of the synchronization primitives used in GStreamer 1.0 pipelines: pad tasks, refcounting, push and pull call chains, serialized flow...
Then it uses these basic concepts to explain the special case of flushes: how they're supposed to work and why.
Open Space
Modern devices come with multiple different hardware components that can be used for inference workflows: CPU, NPU, iGPU, dGPU, etc. The APIs to access them differ not only between the individual components and hardware vendors, but also between different platforms. To complicate the situation further, multiple hardware vendors provide extension libraries on top of GStreamer for accessing their specific hardware as efficiently as possible.
When writing applications, developers either have to implement a custom abstraction layer or, more often, lock into a single hardware/platform which increases maintenance costs and limits deployment.
Since the Analytics API was introduced to GStreamer in 1.24, this situation has considerably improved. Many inference framework-agnostic tensor decoders for different models were introduced, as well as new model-agnostic metadata for inference results and overlay and tracking elements. Together with the onnxinference and tfliteinference elements and the newly added whisper.cpp and llama.cpp elements, GStreamer can be used to develop write once, run anywhere inference pipelines.
This talk will provide an overview of the current state of inference in GStreamer, discuss possible future developments, and show how GStreamer can be used to develop cross-platform inference pipelines.
Abstract:
Live video streaming has become part of our daily lives. Apart from entertainment and surveillance, it is used across industries as part of perception systems for both human and non-human operators. Most commercial camera products are not designed for safety critical environments and may pose hazards that make them unfit for use in railway. We present our way to the world's first SIL2 H.265 camera and how GStreamer has accompanied our journey from building HMIs to functionally safe camera systems.
The talk covers the following topics:
- Why we need functionally safe cameras
- Safety hazards encountered in video streaming
- SIL 2 ISP
- SIL 2 H.265
- Stream safety supervision (FPS, latency)
- Using GStreamer and V4L2 for zero-copy streaming
- Reliable transport of auxiliary safety meta data
The webrtcbin element was first proposed upstream a little less than a decode ago and presented 9 years ago at the GStreamer conference. In that past decade, every* web browser has grown support for WebRTC and thus has the functionality for real-time audio/video streaming.
We will look at some of the existing challenges the current webrtcbin design has faced and discuss some potential solutions. Some of which have already been implemented in a new set of elements called webrtcbin2.
Large Conference Room
WirePlumber is the default session and policy manager for PipeWire, responsible for deciding which audio and video streams get connected to which devices or applications, and under what rules. In 2026 its internals got a significant update, and this talk will cover the biggest changes.
First, a new permission manager lets WirePlumber grant or restrict what each client is allowed to see and do on the PipeWire graph, using simple matching rules instead of specific pieces of logic scattered across scripts. This gives WirePlumber a proper, centralized way to sandbox untrusted or restricted clients.
Second, WirePlumber's policy logic runs as scripts, which can occasionally take a while to execute. This could stall the graph objects that WirePlumber runs locally. Now those objects run on their own separate thread, isolated from scripting, so audio and video keep flowing smoothly no matter what the policy layer is doing.
Finally, streams and stream links are now modeled as first-class objects instead of being bundled into a single abstract session item object. This makes it much easier to reason about what's actually flowing through the graph, in addition to allowing nodes to support multiple streams easily.
This talk explains why each change was needed and what it means for anyone building on top of PipeWire.
The purpose of this talk to show and demonstrate the use of Gst-Audit on a running Gstreamer Pipeline and explain its architecture, from the binary injection to the React frontend passing through the REST endpoint and JS bindings.
This talk presents the implementation of Digitally Signed Content (DSC) within GStreamer to ensure trustworthy video authenticity. We'll demonstrate our new dscsigner element, which generates cryptographic signatures for coded bitstreams, alongside dscverifier, which verifies video authenticity in real-time. The presentation covers the integration of JVET supplemental enhancement information (SEI) messages at the NAL unit level, highlighting our parser and inserter elements (such as h266seiinserter) supporting H.266/VVC, H.265/HEVC, and H.264/AVC standards. Finally, we’ll showcase how these plugins provide authenticity and provenance for RTP-based streams through C2PA.
Open Space
In this talk, we will share our experience enabling production-grade Edge AI solutions on top of GStreamer. The discussion goes beyond building working video analytics pipelines and focuses on what it takes to turn them into enterprise-ready systems that can be deployed, operated, monitored, and extended reliably at the edge. We will address this through two complementary dimensions: enterprise-grade deployment and the evolution of Vision AI from classical computer vision toward VLM- and agentic AI-driven workflows.
The enterprise-grade deployment dimension focuses on microservice-style operation: dynamic stream and pipeline lifecycle management, integration with cameras and messaging infrastructure, remote diagnostics, latency tracing, and operational observability.
The Vision AI dimension focuses on the evolution from traditional CV workloads toward VLM and agentic AI scenarios. These workloads introduce new requirements for AI model integration, external AI services, dynamic pipeline reconfiguration, event- or prompt-driven processing, and short-term retention of selected data for retrospective analysis.
Rather than presenting a finished framework, the talk is intended to open a community discussion: which capabilities should remain application-specific, which could become reusable plugins or conventions, and which gaps might be addressed in the GStreamer base repository or surrounding ecosystem.
Proposed 30-minute timeline:
5 min — Introduction and background: why GStreamer is a strong foundation for Edge AI, and how Intel is using it today.
10 min — Enterprise-grade deployment: operating GStreamer-based pipelines as reliable edge services.
10 min — Vision AI evolution: implications of CV, VLM, and agentic AI workflows for model integration, pipeline flexibility, and GStreamer abstractions.
5 min — Summary and Q&A: key takeaways and discussion points for reusable conventions, plugins, or base-repository additions.
In video conferencing, network conditions and how they are handled can directly impact the perceived quality at the receiving end. To measure this degradation, the correspondence between reference and presented frames must be tracked across hosts in various configurations. Rather than relying on in-band visual markers, which can be fragile under poor channel conditions, we present a GStreamer-based approach that gives every frame an explicit identity, carried as buffer metadata through the pipeline and as an RTP header extension over the wire. We show per-frame quality trajectories under network congestion, and how quality changes when frames are duplicated or dropped.
At Pexip, we run a custom GstTracer in production as an always-on profiler that measures per-element CPU to drive our capacity planning. This talk covers why we chose the Tracing API over pad probes, and how we made the hooks light enough to leave on in production.
Large Conference Room
A personal retrospective on two decades of building with GStreamer — from the first tool I ever wrote, through the toolbox of utilities that grew around it, to the debugging tricks learned the hard way. Ends with a look at recent work, including GstPipelineStudio (GPS).
This presentation will explore Fluendo's ongoing efforts to provide support for the Dolby audio ecosystem within GStreamer. We will start with an overview of Fluendo's new proprietary Dolby decoders (AC-4 and EAC3). Next, we will delve into the open-source aspect of the work, detailing Fluendo's recent OSS contributions. Finally, the session will conclude with an outlook on the future, presenting Fluendo's plans for open-source and proprietary developments.
At GStreamer Conference 2024 I proposed GStreamer as the ideal nervous system for feeding AI brains with data. As Python is the dominant language in AI, a new Python framework, gst-python-ml, was introduced to easily connect PyTorch models with GStreamer pipelines, with support for object detection, tracking, local speech to text and local text to speech.
This talk covers the many new features that have arrived since then, including segmentation, depth and pose estimation, OCR, optical flow, vision-language captioning, Whisper, and LLMs local and remote. PyTorch is now just one of fifteen different inference backends including ONNX, OpenVINO, LIteRT and MIGraphX, allowing us to support every conceivable ML model with ease. The framework is in active use, powering many of Collabora’s ML demos.
Along the way, we will view live demos of new vision and language features, all running on a humble consumer GPU, with a focus on sport analytics.
Open Space
In this talk we'll go over the struggles of maintaining a "complicated" GStreamer application and dealing with the hangs and crashes that come with large deployments. This year we built an automated pipeline that captures crash and hang dumps from our clients' machines, resolves them against the exact GStreamer build they were running, and uses commercially available AI models to point our team in the right direction. Instead of a pile of support tickets, we get triaged, deduplicated reports.
Game engines serve a broad community of creators, but multimedia needs can outgrow the capabilities and extensibility of their built-in players. As part of an independent exploration of how GStreamer could help, and following earlier community efforts in this area, I have been developing experimental plugins for Unity, Godot, and Unreal Engine to explore both the opportunities and the practical barriers.
After a brief overview of how game engines prepare and deliver media across target platforms, this talk shares progress from that investigation, using cross-platform hardware-accelerated VP9 playback and video with transparency as concrete targets. Selected examples from Android and Apple platforms will illustrate graphics interoperability challenges and the improvements they motivated in GStreamer. I will also share lessons about runtime integration and authoring workflows, with brief examples of audio integration and timed text in Unreal as a step toward accessibility.
The talk will close with the work needed for dependable adoption: extending automated testing to mobile platforms with Remote Check, and remaining questions about runtime overhead and compact builds tailored to a game’s needs. The aim is to share findings and invite collaboration toward media support that game creators can extend and depend on.
Large Conference Room
Many devices today ship with hardware-protected Digital Rights Management (DRM) pipelines built on GStreamer. Too often, developers assume that DRM is destined to remain proprietary and that the only way forward is with hacks and downstream workarounds. In practice, this leads to heavily diverging forks, making upgrades difficult, pinning products to ancient GStreamer versions, and exposing systems to severe security threats.
In this talk, Nicolas will walk through the emerging upstream architecture for hardware-protected DRM and Secure Video Path (SVP) on ARM devices using OP-TEE. Attendees will learn what is already in place upstream, what components are still in progress, the technical hurdles encountered along the way, and the strategies being used to solve them.
GStreamer has been able to produce MPEG-TS for decades, but the MPEG-TS it produces isn't always great. Why is that? What would it take to fix?
Open Space
gstreamer-zig is an effort to create GStreamer bindings that feel native to Zig rather than a thin wrapper around the C API. The project aims to preserve GStreamer's concepts and flexibility while embracing Zig's modern language features and style. This lightning talk will briefly introduce the project, highlight some of the design choices and challenges involved, and show how GStreamer development can look in an idiomatic Zig application.
GStreamer has had a Media Source Extensions (MSE) implementation for 3 years now but has seen basically no adoption. For a project we recently needed an API that allowed more control than just "play this file", and ideally would be able to share one implementation of a custom streaming protocol across platforms: iOS and tvOS, Android, and the web. MSE appeared as an ideal candidate for this.
The existing implementation, extracted from WebKitGTK, turned out to have many shortcomings. We ended up writing a new implementation from scratch, added React Native bindings on top, and used it to build applications for all these platforms while using the same media processing code in all of them.
This lightning talk will introduce the new implementation, how it differs from the existing one, the current status and future upstreaming plans. At this point the new implementation should be a good choice for projects that have similar requirements, and we hope that it can also be used as a basis for an MSE implementation in the browser engine Servo in the future.
Analyzing and fixing certain bugs in complex legacy software can be a time-draining endeavour: a fix of one or two lines of code can take many rounds of formulating and testing hypotheses. When such a round is costly due to a heavy build process and resource-constrained targets, this cost is exacerbated.
This talk is about how we have set up LLM agents to work autonomously taking over this busy work so humans can work on the important stuff.
Did you know GStreamer now has an official Python wheel?
While GStreamer is evolving rapidly, SoC-based embedded products rely on versions supported by the SoC manufacturer.
For this reason, it is impossible to immediately adopt the latest version; this is a reality faced by all teams developing embedded products, such as TVs, set-top boxes, and mobile devices.
In this reality where using older versions is unavoidable, we introduce three strategies for managing your data to avoid drifting away from the upstream. By sharing our company's actual version management strategies, we aim to share practical policies with the community and provide an opportunity to refer to the strategies of various GStreamer participants.
GStreamer already has all kinds of elements to use proprietary, cloud-based services for transcription and translation. Cloud services are not always an option for privacy and cost reasons.
In the last months, Mathieu and I have been working on adding a local option for this: a whisper.cpp-based speech-to-text element and a llama.cpp-based LLM text transformation and translation element.
This lightning talk will introduce both, show how they can be used for a minimal offline transcription and translation pipeline, and outline future extensions to complete GStreamer's speech support with local options.
For my hobby photobooth, I built a GStreamer source plugin for digital cameras. It can capture live previews and trigger photo exposures. I'll show how little effort this took by using libgphoto2 and its Rust wrapper.
A quick introduction to Vulkan Video Samples, the Khronos reference encoder and decoder.
As a continuation of my talk last year on Threadshare, this presentation will sketch a few improvements implemented to facilitate Threadshare integration with WebRTC Bin 2.
Threadshare is a set of elements that leverage an asynchronous executor to reduce thread overhead and context switching costs.
A short story about GStreamer and machine vision on the road.
LiveArenaSports produces around 250,000 live sport broadcasts a year from roughly 2,500 arenas across Europe, Australia and New Zealand, mostly grassroots and lower-tier games, with no production crew at all.
To take on the higher tiers, we have built a new production platform with GStreamer at its core. It covers what a manual crew does: multicam switching, replays and slow motion, graphics overlays, commentary mixing and ads. It is fully API-driven, scales horizontally, and runs in the cloud or on edge servers in the arena.
In this lightning talk I'll briefly show how GStreamer fits into the system, and what comes next
Servo is a web browser engine that uses GStreamer for playback. In this lightning talk we'll quickly go through the current status and plans for the near future.
Let's play!
I will briefly present the new whisper transcriber, GStreamer's first transcriber that does not rely on a third party service.
Many applications using GStreamer opt for spawning multiple pipelines, potentially inter-connected . Using large log levels to investigate an issue that happens in a single pipeline has unwelcome consequences (performance, disk usage when stored).
In this talk I will present a new tracer that sorts logs per pipeline, and can be configured with varying, per-pipeline log levels.
Open Space
A follow up to last year's mpeg-ts talk, explaining the investigation and implementation of writing a mpeg-ts crate and demuxer in rust
The challenges and lessons learnt from using GStreamer in a highly-scalable streaming application.
Large Conference Room
This presentation covers some of the different ways in which GStreamer is used inside WebKitGTK and WPE to implement the multimedia features of the web engine. Common design patterns in WebKit will be introduced, as a basis to understand the design of the modules to be presented next: Regular and Media Source Extensions video playback, Encrypted Media Extensions using the Thunder/OpenCDM framework and WebAudio. A less detailed overview of MediaStream and WebRTC will be presented at the end.
Open Space
IPConfigure has shipped GStreamer WebRTC in production video management products since 2018. This talk will outline the evolution of our WebRTC implementation, from hand-rolled pipelines that predate webrtcbin to our full migration onto it in 2022. It will also cover what actually breaks when you stream from on-premise recorders to browsers across networks you don't control: ICE and STUN failures from enterprise and carrier networks, browser bugs including one where Safari silently drops connectivity checks for candidate pairs it reports as active, and the gap between what surveillance cameras encode and what browsers will accept. Attendees will leave with failure signatures they can recognize in their own deployments and the diagnostic workflows we use to isolate them.
The goal of real-time media processing is to minimise latency. It's the enemy, and hides in many places.
Where? Well, let's investigate, and see what tools we have to fight it with. We'll kill it with fire, or just maybe... learn to be friends?
Abstract:
Offshore crane operations have traditionally required operators to work directly on platform cabins in hazardous environments—involving complex offshore logistics, high infrastructure costs, and extended periods away from home. Palfinger, in partnership with Aker BP, is transitioning these operations from physical cabins to onshore Integrated Operations Centers.
While remote teleoperation solves logistics and safety challenges, it introduces strict technical requirements: operators lose direct physical sensation and must rely entirely on visual feedback. Safe control demands real-time feedback (<200ms), continuous multi-angle situational awareness, sensor feedback (wind speed, hook height, load weight, and active alarms), and absolute system reliability.
To meet these demands, Palfinger has built a high-performance visual system centered around a GStreamer processing engine. GStreamer handles multi-camera ingestion, hardware-accelerated video decoding, and composition across multi-monitor desks and videowalls. By integrating a dynamic layout engine, operators can hot-swap visual perspectives on the fly—switching between detailed inspection views and wide-angle operational grids seamlessly. Furthermore, native overlay blending pairs live video frames with crane sensor telemetry, while embedded pipeline probes continuously monitor latency, frame delivery, and automated backup failovers.
This talk will explore this system and its use of GStreamer, as well as the difficulties faced in building it. I will demonstrate how combining high-throughput video compositing, real-time telemetry integration, and proactive stream monitoring allows operators seated miles from their crane to control heavy offshore machinery with confidence and precision, as if they were sitting in the cabin.
Takeaways:
Large Conference Room
Evaluating the performance of GStreamer-based visual AI pipelines on heterogeneous hardware is a complex systems engineering challenge. Simple metrics like raw TOPS are insufficient for understanding real-world performance, which is heavily impacted by codec complexity, model architecture, and concurrent system resource contention across the CPU, GPU, and NPU.
This presentation will demonstrate how the benchmarking challenges have been directly addressed in the Visual Pipeline and Platform Evaluation Tool (ViPPET), an open, GStreamer-based utility.
Specifically, we will show how developers can use the tool to determine the maximum concurrent stream density for a given hardware.
It will cover four aspects of the tool for flexible initial benchmarking:
•Data Ingestion & Pipeline Customization - using custom media assets, image sets, and live camera feeds to test realistic input scenarios.
•Pre-built Vision AI Workloads - Leveraging optimized, out-of-the-box pipeline templates (e.g., Object Detection, Tracking, and Pose Estimation) as baseline references.
• Performance Analysis - Measuring true throughput (FPS), end-to-end pipeline latency, and correlating these with real-time CPU, GPU, and NPU utilization.
• Enhanced user experience, e.g. advanced view and simplified view on GStreamer pipeline.
The usual talk about the recent developments on both GstVA and GstVulkan
We implemented a ringbuffer element to keep hundreds of video frames in a GStreamer pipeline and only emit buffers to the sink when requested. While its implementation was straightforward, we found out that other components, such as Video4Linux2 and PipeWire, are not primarily designed for keeping large amount of frames in memory for extended periods.
Specifically, we extended PipeWire to track buffer ownership across clients in order to improve how buffers are queued back to the V4L2 driver.
This presentation details our journey and lessons learned and will cover the following topics:
Open Space
We developed streaming infrastructure for Remote Train Operation (RTO) based on our SIL2 camera system. Cameras are installed in the cabin of a train and safely stream to a wayside driver desk where trains are controlled remotely. In the process, we encountered challenges in providing reliable streaming over lossy local and wireless (5G) networks. Finally, we overcame several challenges of using OpenMAX in GStreamer.
This presentation covers the following topics:
At Spiideo, we work with sports clubs and leagues to help them analyze and broadcast games. We install cameras at their venues and process the video to add object detection and autofollow capabilities, ingesting 4K H.264/H.265 video over SRT.
We do not control the network infrastructure at these sites, and we're not going to ask sports clubs to open all "ephemeral outgoing UDP ports" on their firewall. We wanted to give customers a single address and a single UDP port to open instead.
This led us to implement SRT multiplexing in srtsrc (gst-plugins-bad). This talk is about how that implementation works, how it's held up in production, and the other work required to ingest video at scale and feed it into the rest of our processing pipeline.
Large Conference Room
To gain cross-platform capabilities in our video processing pipelines, we at Veo Technologies decided to convert our custom GPU-dependent GStreamer elements from CUDA to Vulkan. Today, several of our production video processing pipelines run entirely on GstVulkan, processing hundreds of thousands of sports recordings every week, having performance parity with the CUDA pipelines.
In this talk, we will share our experiences with using GstVulkan in production: which strategies we used, which challenges we ran into, and what we gained.
ICE (Internet Connectivity Establishment) is a widely used standard for NAT (Network Address Translation) hole punching used extensively within the realm of WebRTC and in some cases SIP.
librice is a sans-IO library that handles the intricacies of ICE and has some new tricks up its sleeve. We will discuss the current state of librice, the work in progress and design decisions that have been made and where we see ourselves looking into the future.
Open Space
IP cameras nominally share common protocols, but in practice every manufacturer and model deviates in its own way. Drawing on our experience building the Orchid VMS, this talk covers what a video management system must tolerate to work with the broadest possible range of devices, and the per-manufacturer and per-model workarounds we manage through a quirks system when tolerance alone isn't enough. We'll also discuss the interoperability patches we've contributed upstream to GStreamer's rtspsrc and our upcoming migration to rtspsrc2.
In the last months, there has been a lot of reporting on LLM-based tooling easily finding dozens of security vulnerabilities in open source software. Projects like the Linux kernel or curl are well known to have been hit by this heavily, with many discussions about the usefulness and validity of these reports and how this flood of reports can be handled. As GStreamer is used in many safety critical areas and has to handle all kinds of complex data formats coming from untrusted sources, GStreamer is a natural target and affected by this as well.
Just this year alone >80 security vulnerabilities were already fixed while in the previous years we only had a handful of security vulnerability reports to process.
This talk will give an overview of what the situation looks like nowadays for GStreamer: what kind of reports come in and which areas are affected most, how many of the reports are false positives or of low quality, how we process them, and how are we trying to improve the situation for the future.
Large Conference Room
This talk will give an update on the work done over the last year in GStreamer and GStreamer Editing Services (GES), most of it now upstream or on its way there.
We'll start with the work done to give GStreamer a proper color correction story: the new float video formats, what is needed to composite and grade in scene linear, and the OpenColorIO integration we are working on.
This talk will also present the work done around performance and the tooling we have been adding in GStreamer to make it simpler (custom spans in the core
tracer, rendered in Perfetto, and a better gst-dots-viewer): where the time was spent during complex timeline editing, and what we changed as a result, from the way GES selects the compositor and the converters around it so that a single memory type can be kept end to end, to making GES fully thread safe, to the allocation queries we still drop and why.
We'll also show what came out of compiling the whole GES stack to WebAssembly to run it in the browser, decoding through WebCodecs and rendering through WebGL, and discuss all the roadblocks we still have.
Don't panic!
A short high-level overview of what we know and don't know about the shape of GStreamer 2.0 and how we might get there.
Plus a panel discussion to bounce around ideas and identify priorities, and also collect input from the audience.
Let's explore ways to have a "new" GStreamer without breaking API for existing users/applications.
GStreamer's negotiation system is a powerful and unique mechanism, with some shortcomings that have been identified over the years.
In this talk I will present various experiments I have been implementing for testing new, non-backwards compatible design ideas, with the goal of retaining the capabilities of the existing system and addressing its shortcomings.
GStreamer 1.0 is 14 years old now. It has served us well, but it carries a lot of historical baggage, and even though we have always managed to move forward, that has a cost: the default threading model uses far more threads than necessary, and the threadshare plugin has shown we can do much better, caps negotiation is left to each element, with base classes helping only so much, and is hard to debug on failures, the allocation query has its limitations and is serialized with the data flow, changing the pipeline topology while it is running is way too complex and error prone, everything is built on GObject, which newcomers have to understand first, making the GStreamer learning curve even steeper, and many details and design choices deserve a second look with all the experience we have gained since 1.0.
We have been saying "we'll fix that in 2.0" for years, and I think there is now a consensus in the community that it is time to start thinking about it
seriously: after years of collecting ideas, we start to have a view of where we want to go and we have been writing it down in a shared document, Rust has become the natural language the community is moving towards, with almost all newly written plugins in it, and several of us have started exploring what a new core could look like. This talk will present the research I have been doing on that subject and the APIs I have been experimenting with. All of this is very early stage, but I hope it can give us a basis for discussion.
The goal of the talk is to expose these ideas, see what people think, continue the discussion during the hackfest right after the conference, and hopefully start working on it together.
GStreamer Hackfest @ ImpactHub
GStreamer Hackfest @ ImpactHub