Google DeepMind CEO Demis Hassabis talks about AI’s momentum, from new models to the Game Arena benchmark.
This release includes several bug fixes, performance improvements, and new features. Read on to find out more, and as always please check out the full release notes for a comprehensive overview of changes in this release.
This release introduces a scrubbing mode in ExoPlayer, designed to optimize performance for frequent, user-driven seeks, like dragging a seek bar handle. You can enable it with ExoPlayer.setScrubbingModeEnabled(true). We've also integrated this into PlayerControlView in the UI module where it can be enabled with either time_bar_scrubbing_enabled="true" in XML or the setTimeBarScrubbingEnabled(boolean) method. Media3 1.8.0 contains the first batch of scrubbing improvements, with more to come in 1.9.0!
Extending the initial support for VOD in Media3 1.6.0, HlsInterstitialsAdsLoader now supports live streams and asset lists for all your server-guided ad insertion (SGAI) needs. The Google Ads Manager team explains how SGAI works. Follow our documentation for how to integrate HLS interstitals into your app.
MetadataRetriever has been significantly updated - it's now using an AutoCloseable pattern and lets you retrieve the duration of media items without playback. This means Media3 now offers the full functionality of the Android platform MediaMetadataRetriever but without having to worry about device specific quirks and cross-process communication (some parts like frame extraction are still experimental, but we'll integrate them properly in the future).
try { MetadataRetriever.Builder(context, mediaItem).build().use { val trackInfo = it.retrieveTrackGroups().await() val duration = it.retrieveDurationUs().await() } } catch (e: IOException) { handleFailure(e) }
There were several other improvements and bug fixes across ExoPlayer and playback related components. To name just a few:
The MediaSession module has a few changes and improvements for notification handling. It's now keeping notifications for longer by default, for example when playback is paused, stopped or failed, so that a user has more time to resume playback in your app. Notifications for live streams (in particular with DVR windows) also became more useful by removing the confusing DVR window duration and progress from the notification.
The media session demo app now also supports playback resumption to showcase how the feature can be integrated into your app! It allows the user to resume playback long after your app has been terminated and even after reboot.
We are continuing to add optimizations for faster trim operations to Transformer APIs. In the new 1.8.0 release, we introduced support for trimming using MP4 edit lists. Call experimentalSetMp4EditListTrimEnabled(true) to make trim-only edits significantly faster.
val transformer = Transformer.Builder(requireContext()) .addListener(transformerListener) .experimentalSetMp4EditListTrimEnabled(true) .build()
A standard trimming operation often requires a full re-transcoding of the video, even for a simple trim. This meant decoding, re-encoding the entire file, which is a time-consuming and resource-intensive process. With MP4 edit list support, Transformer can now perform "trim-only" edits much more efficiently. Instead of re-encoding, it leverages the existing encoded samples and defines a "pre-roll" within the edit list. This pre-roll essentially tells the player where to start playback within an existing encoded sample, effectively skipping the unwanted beginning portion.
The following diagram illustrates how this works:
As illustrated above, each file contains encoded samples and each sample begins with a keyframe. The red line indicates the intended clip point in the original file, allowing us to safely discard two first samples. The major difference in this approach lies in how we handle the third encoded sample. Instead of running a transcoding operation, we transmux this sample and define a pre-roll for a video start position. This significantly accelerates the export operation; however this optimization is only applicable if no other effects are applied. Player implementations may also ignore the pre-roll component of the final video and play from the start of the encoded sample.
CodecDBLite optimizes two elements of encoder configuration on a chipset-by-chipset basis: codec selection and B-frames. Depending on the chipset, these parameters can have either a positive or adverse impact on video quality. CodecDB Lite leverages benchmark data collected on production devices to recommend a configuration that achieves the maximum user-perceived quality for the developer’s target bitrate. By enabling CodecDB Lite, developers can leverage advanced video codecs and features without worrying about whether or not they work on a given device.
To use CodecDbLite, simply call setEnableCodecDbLite(true) when building the encoder factory:
val transformer = Transformer.Builder() .setEncoderFactory( DefaultEncoderFactory.Builder() .setEnableCodecDbLite(true) .build() ) .build()
The Composition Demo app has been refreshed, and is now built entirely with Kotlin and Compose to showcase advanced multi-asset editing capabilities in Media3. Our team is actively extending the APIs, and future releases will introduce more advanced editing features, such as transitions between media items and other more advanced video compositing settings.
Adaptive-first: Editing flows can get complicated, so it helps to take advantage of as much screen real estate as possible. With the adaptive layouts provided by Jetpack Compose, such as the supporting pane layout, we can dynamically adapt the UI based on the device’s screen size.
Multi-asset video compositor: We’ve added a custom video compositor that demonstrates how to arrange input media items into different layouts, such as a 2x2 grid or a picture-in-picture overlay. These compositor settings are applied to the Composition, and can be used both with CompositionPlayer for preview and Transformer for export.
Please get in touch via the Media3 issue Tracker if you run into any bugs, or if you have questions or feature requests. We look forward to hearing from you!
A look around the world of open source
by
What exciting open source events and news are you hearing about? Let us know on our @GoogleOSS X account.
Beginning this week, you'll see us testing a new Google Finance, reimagined with AI at its core. Here’s what to expect:Research your finance questions with AI: Now, you …
The Beta channel is being updated to OS version 16328.42.0 (Browser version 139.0.7258.86) for most ChromeOS devices.
If you find new issues, please let us know one of the following ways:
Visit our ChromeOS communities
General: Chromebook Help Community
Beta Specific: ChromeOS Beta Help Community
Interested in switching channels? Find out how.
Andy Wu
Google ChromeOS
Hi everyone! We've just released Chrome Beta 140 (140.0.7339.7) for iOS; it'll become available on App Store in the next few days.
You can see a partial list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.
Chrome Release Team
Google Chrome
Posted by Toni Heidenreich – Engineering Manager