When adding more threads adds more problems - Thread-sharing between elements in GStreamer.
Action | Key |
---|---|
Play / Pause | K or space |
Mute / Unmute | M |
Toggle fullscreen mode | F |
Select next subtitles | C |
Select next audio track | A |
Show slide in full page or toggle automatic source change | V |
Seek 5s backward | left arrow |
Seek 5s forward | right arrow |
Seek 10s backward | shift + left arrow or J |
Seek 10s forward | shift + right arrow or L |
Seek 60s backward | control + left arrow |
Seek 60s forward | control + right arrow |
Decrease volume | shift + down arrow |
Increase volume | shift + up arrow |
Decrease playback rate | < |
Increase playback rate | > |
Seek to end | end |
Seek to beginning | beginning |
Share this media
Download links
HLS video stream
You can use an external player to play this stream (like VLC).
HLS video streamWhen subscribed to notifications, an email will be sent to you for all added annotations.
Your user account has no email address.
Information on this media
In GStreamer we liberally use threads everywhere: for parallelizing processing on multiple cores, for decoupling processing of different pipeline parts, for timers and for blocking operations. A normal GStreamer pipeline can easily have dozens of threads interacting with each other.
In this presentation the topic is not that using threads is hard and about all the thread-safety problems that potentially exist: by the design of GStreamer this is relatively well-handled already.
Instead the topic is the bad scalability of using a new thread for everything. If every pipeline you create uses 10 threads, and you'd like to run 100s of them on the same machine, you can easily end up using all your system resources (both CPU and memory) just for these threads while not being able to do the actual data processing fast enough or in time.
An experimental set of GStreamer elements will be introduced to show a potential solution to this problem for specific use-cases by sharing a fixed number of threads between different elements, and similar approaches to other existing elements (e.g. the RTP jitterbuffer).
Afterwards results of that approach in one specific scenario will be presented, and in the end potential future development will be discussed and what could be changed in GStreamer core for 2.0 to integrate such approaches in a cleaner and lower-overhead way to make GStreamer more scalable.
Sebastian Dröge (slomo) is a Free Software developer and one of the GStreamer maintainers and core developers. He has been involved with the project since more than 10 years now. He also contributes to various other Free Software projects, like Debian, Rust, GNOME and WebKit. While finishing his master's degree in computer sciences at the University of Paderborn in Germany, he started working as a contractor for GStreamer and related technologies. Sebastian is one of the founders of Centricular, a company providing consultancy services, where he's working from his new home in Greece on improving GStreamer and the Free Software ecosystem in general.
Apart from multimedia related topics, Sebastian has an interest in digital signal processing, programming languages, machine learning, network protocols and distributed systems.
Other media in the channel "GStreamer Conference 2018"
- 29 viewsClosing SessionOctober 29th, 2018
- 126 views, 3 this yearUsing GStreamer for Servo's WebAudio implementation in RustOctober 29th, 2018
- 356 views, 8 this yearExperiences with gstreamer/webrtcOctober 29th, 2018
- 183 views, 4 this year, 1 this monthWhat's new with GStreamer & Rust.October 29th, 2018
- 152 views, 7 this yearDiscovering Video4Linux CODECsOctober 29th, 2018
- 351 views, 12 this yearMicrosoft Teams ConnectorOctober 29th, 2018