![\"\"](\"\/images\/dape.png\")
\nThe API is moving to the next phase: a Chromium Origin Trial. I will also be presenting a year of work at the upcoming BlinkOn 21<\/a>.<\/p>\n After months of development and testing in Chromium, Container Timing is ready for real-world testing. We will run an Origin Trial from Chromium 148 to 153. You can register for the trial<\/a>.<\/p>\n Until now, developers have had to manually enable the Why is this important? We have been internally testing and evolving the API, but now we need feedback from real-world users. The Origin Trial will allow web developers to use the new API in production and experiment with it.<\/p>\n Please provide your feedback at the WICG Container Timing issue tracker<\/a>.<\/p>\n Next week, April 20th and 21st, the Chromium community will gather for BlinkOn 21. I\u2019ll be giving a lightning talk summarizing the updates over the last year.<\/p>\n I will keep a close eye on the BlinkOn Slack channels during the event, so feel free to reach out to discuss the roadmap, implementation details, or any API feedback.<\/p>\n The Origin Trial is a key step toward finalizing the specification. Real-world feedback from the trial itself and from BlinkOn 21<\/a> discussions will feed into the standards working group discussions, and we expect the specification to evolve from there.<\/p>\n If you build with Container Timing during the trial, please share what you find<\/a>: what works, what does not, and what is missing. That input will shape the final API.<\/p>\n You can also test locally by enabling the This work is part of the collaboration between Bloomberg<\/a> and Igalia<\/a>. Thanks!<\/p>\n \n Introducing gst-pop<\/a>, the GStreamer Prince of Parser \u2014 a tool to make interaction with GStreamer easier, global, and remotely accessible.<\/p>\n GStreamer<\/a> is an open-source multimedia framework started in 1999. It lets you build pipelines of interconnected elements to stream, encode, decode, and manipulate media. The core idea is simple: a source element produces data, passes it through one or more transform elements, and delivers it to a sink. For example, here is a pipeline that decodes an MP3 audio file:<\/p>\n For more than 20 years, GStreamer has relied on its in-house toolbox to demonstrate the power\nof its pipelines. As this toolbox is used in thousands of projects and serves as a reference\nimplementation, modifications and enhancements are deliberately kept minimal to maintain stability.\ngst-pop was created to go beyond these limitations.<\/p>\n Accessible over the network, via CLI arguments, or through D-Bus, gst-pop aims to provide\na multi-pipeline-capable command-line tool.<\/p>\n With a simple invocation of As demonstrated in the blog post related to GstPipelineStudio<\/a>, it will be possible to connect to a remote pipeline or launch new pipelines through the GStreamer GUI. If a GUI is not available\non the platform, it will soon be possible to use a web interface to control GStreamer, offering\neverything GStreamer can provide and more, limited only by your imagination.<\/p>\n gst-pop (or its alias It can also provide information on a media file using GStreamer\u2019s discovery interface using And of course, it can serve as an alternative to the The possibilities are vast: provide multimedia services such as transcoding, media analysis, or remote playback to your setup using the power of a remote machine, all controllable from your terminal or a GUI such as GstPipelineStudio<\/a>.<\/p>\n The tool is written in Rust for memory safety and reliability and provides client libraries in both Rust and C, offering all the flexibility needed for your existing applications. It is available on Linux (deb, rpm or docker), MacOS, and Windows, see the release page<\/a>.<\/p>\n Give it a try and let us know what ideas you might have \u2014 we have plenty coming, so stay tuned.<\/p>\n As usual, if you would like to learn more about gst-pop, GStreamer, or any other open multimedia framework, please contact us<\/a>!<\/p> ","author":{"name":"St\u00e9phane Cerveau","uri":"https:\/\/blogs.igalia.com\/scerveau\/"}},{"title":"Igalia WebKit Team: WebKit Igalia Periodical #62","link":{"@attributes":{"rel":"alternate","type":"text\/html","href":"https:\/\/blogs.igalia.com\/webkit\/blog\/2026\/wip-62\/"}},"id":"https:\/\/blogs.igalia.com\/webkit\/blog\/2026\/wip-62\/","updated":"2026-04-07T17:07:37+00:00","content":"\n Update on what happened in WebKit in the week from March 31 to April 7.<\/p>\n \nSupport for iOS dialog light dismiss, a new API to obtain page icons,\nWebKit nightly builds for Epiphany Canary produced by\nGNOME GitLab, and more conservative checks for MPEG-4 Audio object types\nare all part of this week's edition of the WebKit periodical.\n<\/p>\n A new API to obtain page icons<\/a> (a.k.a. \u201cfavicons\u201d) has been added to the GTK port. The new functionality reuses the recently added Added iOS support for dialog light dismiss<\/a>, part of the experimental GStreamer-based multimedia support for WebKit, including (but not limited to) playback, capture, WebAudio, WebCodecs, and WebRTC.<\/p>\n<\/div>\n canPlayType() is now more conservative regarding MPEG-4 Audio object types<\/a>. This primarily affects AAC extensions: In the past, as long as there was an AAC decoder installed, WebKit was accepting any codec string that started with canPlayType() now also reports support for Dolby AC-4<\/a> in systems with a decoder capable of handling it.<\/p>\n <\/div>\n The GStreamer WebRTC backend now<\/a> rejects SDP including The WebKitGTK nightly builds for Epiphany Canary are now handled entirely by the GNOME GitLab<\/a> infrastructure, many thanks to them! The previous approach was not optimal, producing release builds without debug symbols. With the new builds, it is now easier to get crash stack traces including more information.<\/p>\n <\/div>\n That\u2019s all for this week!<\/p>\n<\/div> ","author":{"name":"Igalia WebKit Team","uri":"https:\/\/blogs.igalia.com\/webkit"}},{"title":"St\u00e9phane Cerveau: Introducing GstPipelineStudio 0.5.1","link":{"@attributes":{"rel":"alternate","type":"text\/html","href":"https:\/\/blogs.igalia.com\/scerveau\/introducing-gstpipelinestudio-0-5-1\/"}},"id":"https:\/\/blogs.igalia.com\/scerveau\/introducing-gstpipelinestudio-0-5-1\/","updated":"2026-04-07T00:00:00+00:00","content":"\n New version of GstPipelineStudio is out!<\/p>\n After months of improvements and intermediate releases since October 2024, it\u2019s time for an official announcement for 0.5.1<\/a>.<\/p>\n GstPipelineStudio provides a visual interface to GStreamer, the marvelous Swiss Army knife of multimedia pipelines. But what is GStreamer exactly?<\/p>\n GStreamer<\/a> is an open-source multimedia framework started in 1999. It lets you build pipelines of interconnected elements to stream, encode, decode, and manipulate media. The core idea is simple: a source element produces data, passes it through one or more transform elements, and delivers it to a sink. For example, here is a pipeline that decodes an MP3 audio file:<\/p>\n GStreamer is written in C, with a growing ecosystem of plugins in Rust and bindings for languages such as Python and C++. It ships with many command-line tools to build and test pipelines, but validating ideas still requires writing C\/Rust\/Python code or using the command line. That\u2019s where GstPipelineStudio comes in \u2014 providing a visual interface to help newcomers discover and adopt GStreamer, and skilled developers debug their pipelines.<\/p>\n The GstPipelineStudio project started in 2021 with the idea to provide the same environment that brought me to multimedia: GraphEdit on Windows with DirectShow. Indeed, DirectShow and GStreamer share the same idea of plugins sharing data. As I started to implement a DVB decoder with DirectShow, the graphical interface made it easier to validate which filters to use. But DirectShow only works natively on Windows, unlike GStreamer which can run everywhere \u2014 Linux, macOS, Windows, iOS, Android, and even low-power devices such as a Raspberry Pi.<\/p>\n GstPipelineStudio aims to work on all these platforms, easing GStreamer adoption where its use was not always obvious, such as on Windows.\nGStreamer is based on GLib, a cross-platform toolkit that abstracts system calls and provides a common base layer. For the GUI, since Rust was offering very good bindings, GTK was the natural choice to achieve cross-platform support.\nThere was an attempt to create a GUI using Qt, named pipeviz<\/a>, which has been a great inspiration for GPS, but the Qt Rust bindings were not mature enough, unlike those for GTK.<\/p>\n The first official release of GPS was 0.3.4, and you can read its official blog post<\/a> published in 2023. Since then, we have been devoted to providing new features\nto bring GPS to another level.<\/p>\n A first revision, GPS 0.4.0, came out before Christmas 2024 with a refreshed interface \u2014 including zoom on the graph\nand contextual menus on any element or pad of the pipeline. The versions of GStreamer and GTK have also been updated to get the latest plugins and features from both frameworks.\nA new icon has also been introduced to let GPS dive into another dimension.<\/p>\n 0.5.1 is here, and it brings a game changer: the dot file reader.\nPreviously, it was possible to open a command-line pipeline or save\/open pipelines with an XML-based format, but now you can also open the generated dot files, the native format in GStreamer, to display a pipeline graphically. This is still a beta version as it can only display\nhigh-level pipelines such as those described with the command line. Nevertheless this is a great improvement and allows users to see their pipeline and manipulate it.<\/p>\n Here is the list of other improvements you\u2019ll find in this release:<\/p>\n The remote pipeline introspection is a new way to connect to the WebSocket tracer available in GStreamer, pipeline-snapshot.\nIn addition to dot file loader, it allows you to visualize a pipeline directly in GPS from an external process running with the tracer.<\/p>\n As you may know, GStreamer pipelines can be very complex, so one dream was to be able to visualize them live. There is already a mini tool in GStreamer named Now with GPS, you can directly create a WebSocket server and let the tracer connect to it and provide available dot files to be displayed.<\/p>\n For example, to visualize a running pipeline in GPS:<\/p>\n The pipeline graph will appear in GPS once the tracer connects.<\/p>\n These dot files are converted to GPS pipelines, making it possible to modify them. That\u2019s a first step for real interaction with GStreamer pipelines \u2014 and there are more features coming in the pipeline<\/em>.<\/p>\n In parallel, a new tool named GstPrinceOfParser<\/a> (gst-pop) has also been implemented. This tool allows remote control of all pipelines instantiated locally or over the network.\nIt is a multi-pipeline daemon accessible through WebSocket or D-Bus, aiming to centralize all GStreamer options in one tool for launch<\/a>, inspection<\/a>, and discovery<\/a>. GstPipelineStudio will be able to control this daemon, making gst-pop the backbone of the GStreamer GUI. A blog post will come soon, stay tuned\u2026<\/p>\n A new tracer is under development: a WebSocket server that will allow you to inspect and interact with the current pipeline \u2014 modify the play state (pause, seek), fetch the logs, and of course see the current dot representation, all from the GstPipelineStudio interface.<\/p>\n In addition, more features are on the way: a new look and feel based on libadwaita on Linux\/macOS\/Windows, better localization, an auto-plug feature, seek and step-by-step playback, and bug fixes on demand.<\/p>\n We hope you\u2019ll enjoy this new version of the tool and please feel free to propose\nnew features with an RFC here<\/a> or merge requests here<\/a>.<\/p>\n Stay tuned for the next GStreamer Spring hackfest 2026<\/a> coming soon (end of May) where new features and deeper interaction with GStreamer pipelines will be discussed.<\/p>\n As usual, if you would like to learn more about GstPipelineStudio, GStreamer, or any other open multimedia framework, please contact us<\/a>!<\/p> ","author":{"name":"St\u00e9phane Cerveau","uri":"https:\/\/blogs.igalia.com\/scerveau\/"}},{"title":"Miyoung Shin: Extension Migration Progress Update \u2013 Part 1","link":{"@attributes":{"rel":"alternate","type":"text\/html","href":"https:\/\/blogs.igalia.com\/mshin\/2026\/04\/02\/extension-migration-progress-update-part-1\/"}},"id":"https:\/\/blogs.igalia.com\/mshin\/?p=161","updated":"2026-04-02T11:32:34+00:00","content":"\n Following up on my previous post, I would like to share an update on the progress of the Extension migration work<\/strong> that has been underway over the past few months.<\/p>\n\n\n\n To briefly recap the motivation behind this effort: Igalia’s long-term goal is to enable embedders<\/strong> to use the Extension system without depending on the Currently, some parts of the Extension system still rely on the As a short-term milestone<\/strong>, we focused on migrating the Extension installation implementation<\/strong> from Chromium supports several formats for installing Extensions. The most common ones are zip<\/strong>, unpacked<\/strong> and crx.<\/strong><\/p>\n\n\n\n Each format serves a different purpose:<\/p>\n\n\n\n During this migration effort, the code responsible for supporting all three installation formats has been successfully moved to the As a result, the Extension installation pipeline is now significantly less dependent on the To support this migration, several patches were introduced to move installation-related components into the For readers who are interested in the implementation details, you can find the related changes and discussions here:<\/p>\n\n\n\n These links provide more insight into the design decisions, code changes, and ongoing discussions around the migration.<\/p>\n\n\n\n Below is a short demo showing the current setup in action.<\/p>\n\n\n\nThe Origin Trial #<\/a><\/h2>\n
ContainerTiming<\/code> feature flag in Chromium to test the new API. With the Origin Trial, early adopters can enable the API in production for a subset of their users by including the trial token. More information on how to use origin trial tokens<\/a>.<\/p>\n\n
A year in review at BlinkOn 21 #<\/a><\/h2>\n
Wrapping up #<\/a><\/h2>\n
ContainerTiming<\/code> feature flag in Chromium, while you wait for your Origin Trial registration<\/a> to be approved.<\/p>\nThanks #<\/a><\/h2>\n
![\"Igalia\"](\"https:\/\/blogs.igalia.com\/dape\/img\/igalia_-_500px_-_RGB_-_Feb23-580x210.png\")
\n<\/source><\/a> ![\"Bloomberg\"](\"https:\/\/blogs.igalia.com\/dape\/img\/Bloomberg-logo-580x117.png\"){kind=logo}
<\/a><\/p>\nReferences #<\/a><\/h2>\n
\n
GstPrinceOfParser: An All-in-One Tool to Play With GStreamer on Any Platform #<\/a><\/h1>\n
What is GStreamer? #<\/a><\/h2>\n
filesrc --><\/span> mp3dec --><\/span> audiosink<\/code><\/pre>\nA Unified Interface for GStreamer #<\/a><\/h2>\n
gst-pop<\/code> (or its alias gst-popd<\/code>), you can run a daemon that accepts\nmultiple pipelines simultaneously, accessible through D-Bus or WebSocket via the pipeline\nID. You\u2019ll be able to control, query, and get information about each pipeline \u2014 all of that\nover a remote network, secured with API key authentication and origin validation to prevent unauthorized access.<\/p>\nRemote Element Inspection #<\/a><\/h2>\n
gst-pop-inspect<\/code>) is also capable of listing the elements on a local or remote host, inspecting their capabilities, and providing a remote way to interact with your GStreamer installation.<\/p>\nMedia Discovery #<\/a><\/h2>\n
gst-pop-discovery<\/code>, offering an easy and remote-capable media discovery system for your setup.<\/p>\nPlayback #<\/a><\/h2>\n
gst-play<\/code> tool, with gst-pop-play<\/code>, allowing you to instantiate as many playback sessions as you need, with the ability to use any sink you want.<\/p>\nCross-Platform and Language Support #<\/a><\/h2>\n
Examples #<\/a><\/h2>\n
# Start the daemon<\/span>
gst-pop
# Launch a pipeline<\/span>
gst-pop launch videotestsrc !<\/span> autovideosink
# Inspect an element<\/span>
gst-pop inspect videotestsrc
# Discover media info<\/span>
gst-pop discover file:\/\/\/path\/to\/video.mp4
# Play a media file<\/span>
gst-pop play file:\/\/\/path\/to\/video.mp4
# Create a pipeline with the client<\/span>
gst-popctl create \"videotestsrc ! autovideosink\"<\/span>
# List pipelines on a remote daemon<\/span>
gst-popctl list
# Play the pipeline with ID 0<\/span>
gst-popctl play 0<\/span>
# Stop the pipeline with ID 0<\/span>
gst-popctl stop 0<\/span>
# Run via Docker<\/span>
docker<\/span> run -d<\/span> -p<\/span> 9000<\/span>:9000 ghcr.io\/dabrain34\/gstpop:latest<\/code><\/pre>\nCross-Port \ud83d\udc31<\/h2>\n
WebKitImage<\/code> class and provides access to multiple page icons at once through the added WebKitImageList<\/code> type, allowing applications to better choose an icon that suits their needs. Changes to the WebKitWebView.page-icons<\/code> property are guaranteed to be done once per page load, when all icon images are available to be used. This new API has been also enabled for the WPE port<\/a>, and the plan is to deprecate the old page favicon functionality going forward.<\/p>\n <\/div>\n closedby<\/code> attribute implementation.<\/p>\n <\/div>\nMultimedia \ud83c\udfa5<\/h3>\n
mp4a<\/code>. Now it only accepts codec strings that correspond to object types that have widespread support. This can prevent accidental playback of newer formats like xHE-AAC, which many decoders don't yet support \u2014 for example, as of writing, FFmpeg support for xHE-AAC is only very recent and still incomplete.<\/p>\nrtpmap<\/code> attributes in the disallowed range of 64-95 payload types. Compliance with RFC 7587 was also improved.<\/p>\n <\/div>\nInfrastructure \ud83c\udfd7\ufe0f<\/h2>\n
GstPipelineStudio 0.5.1 #<\/a><\/h1>\n
Your GStreamer Pipelines, at a Glance #<\/a><\/h2>\n
What is GStreamer? #<\/a><\/h2>\n
filesrc --><\/span> mp3dec --><\/span> audiosink<\/code><\/pre>\nThe Story Behind GstPipelineStudio #<\/a><\/h2>\n
What\u2019s New in 0.5.1<\/a> #<\/a><\/h2>\n
\n
Remote Pipeline Introspection #<\/a><\/h2>\n
gst-dots-viewer<\/code> which creates a web server to display pipelines in a browser from the $XDG_CACHE_DIR<\/code> folder, see the blog post<\/a> from Thibault about it.<\/p>\n\n
ws:\/\/localhost:8080<\/code>)<\/li>\npipeline-snapshot<\/code> tracer:<\/li>\n<\/ol>\nGST_TRACERS<\/span>=<\/span>\"pipeline-snapshot(dots-viewer-ws-url=ws:\/\/localhost:8080)\"<\/span> \\<\/span>
gst-launch-1.0 videotestsrc !<\/span> autovideosink<\/code><\/pre>\nComing in 0.6.0 #<\/a><\/h2>\n
Background<\/h1>\n\n\n\n
\/\/chrome<\/code> layer<\/strong>. In other words, we want to make it possible to support Extension functionality with minimal implementation effort using only \/\/content + \/\/extensions<\/code>.<\/p>\n\n\n\n\/\/chrome<\/code> layer. Our objective is to remove those dependencies so that embedders can integrate Extension capabilities without needing to include the entire \/\/chrome<\/code> layer.<\/p>\n\n\n\n\/\/chrome<\/code> to \/\/extensions<\/code>. This phase of the work has now been completed, which is why I\u2019m sharing this progress update.<\/p>\n\n\n\n
\n\n\n\nExtension Installation Formats<\/h1>\n\n\n\n
\n
\/\/extensions<\/code> layer.<\/p>\n\n\n\n\/\/chrome<\/code> layer, bringing us closer to enabling Extension support directly on top of \/\/content + \/\/extensions<\/code>.<\/p>\n\n\n\nPatch and References<\/h2>\n\n\n\n
\/\/extensions<\/code> layer and decouple them from \/\/chrome<\/code>.<\/p>\n\n\n\n\n
https:\/\/issues.chromium.org\/issues\/358567092<\/a><\/li>\n\n\n\n
https:\/\/chromium-review.googlesource.com\/q\/myid.shin@igalia.com<\/a><\/li>\n<\/ul>\n\n\n\n
\n\n\n\nDemo<\/h1>\n\n\n\n