Allow customizing LoadControl with CompositionPlayer

[niklasfejes]

Version

Media3 1.6.1

More version details

I’m having a problem where some images refuse to play when included in a Composition that is played through CompositionPlayer. From what I can tell, the images have to be quite large (~50MP) and have some kind of EXIF meta data to trigger. (Possibly related to HDR or ICC Profile.)

When using androidx.media3 1.6.1, I get the following log printed every 10 ms, and otherwise no indication of an error:

Target buffer size reached with less than 500ms of buffered media data.

Rolling back to 1.5.1, I additionally get an error log and the player pauses itself:

playerFailed [eventTime=4.64, mediaPos=0.00, window=0, period=0, errorCode=ERROR_CODE_FAILED_RUNTIME_CHECK
	androidx.media3.exoplayer.ExoPlaybackException: Unexpected runtime error
		at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:721)
		at android.os.Handler.dispatchMessage(Handler.java:105)
		at android.os.Looper.loopOnce(Looper.java:232)
		at android.os.Looper.loop(Looper.java:317)
		at android.os.HandlerThread.run(HandlerThread.java:85)
	Caused by: java.lang.IllegalStateException: Playback stuck buffering and not loading
		at androidx.media3.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:1224)
		at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:562)
		at android.os.Handler.dispatchMessage(Handler.java:105)
		at android.os.Looper.loopOnce(Looper.java:232)
		at android.os.Looper.loop(Looper.java:317)
		at android.os.HandlerThread.run(HandlerThread.java:85)
	]

Some other things I’ve noticed:

• If I strip all EXIF data, the same image works just fine
• The images I’ve seen the problem with are all captured on a Pixel 8/9 device, and are not modified otherwise
• Rendering the exact same Composition object to file with a Transformer works without issues
• Can be reproduced in the demo app by including the problematic image

There’s a minimal repro code here: https://github.com/niklasfejes/compplayer-bug-repo

Of interest may be the CompositionPlayer logic located in ReproVideoPlayer.kt, and an example image that causes the playback to fail in the assets dir.

Devices that reproduce the issue

• Google Pixel 8 Pro running Android 15
• Qualcomm 8750 device running Android 15
• Qualcomm 8550 device running Android 13

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

1. Include the image in the Edit in the composition demo
2. Preview the Edit

Expected result

The edit plays successfully

Actual result

The playback stops when reaching the image

Media

https://github.com/niklasfejes/compplayer-bug-repo/blob/main/app/src/main/assets/testimage_nogps.jpg

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[icbaker]

I can repro this with just ExoPlayer without CompositionPlayer by adding testimage_nogps.jpg to the main demo app's media.exolist.json.

[icbaker]

The Target buffer size reached logs are happening because DefaultLoadControl uses ~13.1MB as the default min buffer size:

media/libraries/exoplayer/src/main/java/androidx/media3/exoplayer/DefaultLoadControl.java

Lines 106 to 110 in a4c1012

	/**
	* The buffer size in bytes that will be used as a minimum target buffer in all cases. This is
	* also the default target buffer before tracks are selected.
	*/
	public static final int DEFAULT_MIN_BUFFER_SIZE = 200 * C.DEFAULT_BUFFER_SEGMENT_SIZE;

JPEG images are loaded as a single sample, so since we can't fit the provided 13.8MB image into the buffer, loading can never complete.

Raising this buffer threshold to ~26MB allows the image to be loaded, but then the demo app crashes on my Pixel 7a when trying to display it in the demo app (full exception below):

Canvas: trying to draw too large(200540160bytes) bitmap.

This also happens when trying to play the testimage_stripped_exif.jpeg with an unmodified demo app, and so is presumably not relevant for your CompositionPlayer use-case.

I think stripping the Exif happens to drop this image size below this 13.1MB buffer threshold (to 12.9MB) - and there's nothing actually magical about removing the Exif data.

---

I'm not sure if CompositionPlayer allows you to customize the LoadControl used by the underlying ExoPlayer instances (which would unblock you by allowing you to boost this buffer size). It doesn't look like, based on the fact it needs to be passed to ExoPlayer.Builder.setLoadControl and the player instantiation here doesn't call that method:

media/libraries/transformer/src/main/java/androidx/media3/transformer/CompositionPlayer.java

Lines 821 to 848 in 7368949

	ExoPlayer.Builder playerBuilder =
	new ExoPlayer.Builder(context)
	.setLooper(getApplicationLooper())
	.setPlaybackLooper(checkNotNull(playbackThread).getLooper())
	.setRenderersFactory(sequenceRenderersFactory)
	.setHandleAudioBecomingNoisy(true)
	.setClock(clock)
	// Use dynamic scheduling to show the first video/image frame more promptly when the
	// player is paused (which is common in editing applications).
	.experimentalSetDynamicSchedulingEnabled(true);
	boolean disableVideoPlayback = false;
	for (int j = 0; j < editedMediaItemSequence.editedMediaItems.size(); j++) {
	if (editedMediaItemSequence.editedMediaItems.get(j).removeVideo) {
	disableVideoPlayback = true;
	break;
	}
	}
	CompositionTrackSelector compositionTrackSelector =
	new CompositionTrackSelector(
	context,
	/* listener= */ this::onVideoTrackSelection,
	/* sequenceIndex= */ i,
	disableVideoPlayback);
	compositionTrackSelector.setSequence(editedMediaItemSequence);
	playerBuilder.setTrackSelector(compositionTrackSelector);
	ExoPlayer player = playerBuilder.build();

---

Full exception

FATAL EXCEPTION: main
Process: androidx.media3.demo.main, PID: 17588
java.lang.RuntimeException: Canvas: trying to draw too large(200540160bytes) bitmap.
	at android.graphics.RecordingCanvas.throwIfCannotDraw(RecordingCanvas.java:266)
	at android.graphics.BaseRecordingCanvas.drawBitmap(BaseRecordingCanvas.java:94)
	at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:556)
	at android.widget.ImageView.onDraw(ImageView.java:1428)
	at android.view.View.draw(View.java:24877)
	at android.view.View.updateDisplayListIfDirty(View.java:23727)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at android.view.View.updateDisplayListIfDirty(View.java:23718)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at androidx.media3.ui.PlayerView.dispatchDraw(PlayerView.java:1810)
	at android.view.View.updateDisplayListIfDirty(View.java:23718)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at android.view.View.updateDisplayListIfDirty(View.java:23718)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at android.view.View.updateDisplayListIfDirty(View.java:23718)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at android.view.View.updateDisplayListIfDirty(View.java:23718)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at android.view.View.updateDisplayListIfDirty(View.java:23718)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at android.view.View.updateDisplayListIfDirty(View.java:23718)
	at android.view.View.draw(View.java:24608)
	at android.view.ViewGroup.drawChild(ViewGroup.java:4556)
	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:4312)
	at android.view.View.draw(View.java:24880)
	at com.android.internal.policy.DecorView.draw(DecorView.java:787)
	at android.view.View.updateDisplayListIfDirty(View.java:23727)
	at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:694)
	at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:700)
	at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:798)
	at android.view.ViewRootImpl.draw(ViewRootImpl.java:5726)
	at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:5378)
	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:4377)
	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2977)
	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:10429)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1415)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1424)
	at android.view.Choreographer.doCallbacks(Choreographer.java:1024)
	at android.view.Choreographer.doFrame(Choreographer.java:953)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1398)
	at android.os.Handler.handleCallback(Handler.java:991)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loopOnce(Looper.java:232)
	at android.os.Looper.loop(Looper.java:317)
	at android.app.ActivityThread.main(ActivityThread.java:8787)
        at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:591)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:871)

[icbaker]

While looking at this, I also noticed that DefaultLoadControl.DEFAULT_IMAGE_BUFFER_SIZE is currently set to 128kB. This seems very small for an image. It looks like it was probably copy-pasted from text and metadata in d05c15d. It's likely we didn't notice this because I suspect DEFAULT_MIN_BUFFER_SIZE is often used instead (since many/most image playbacks will only have an image track for each LoadControl).

I've sent a change for review which increases this to 26MB, which should also help with this issue (without needing to customize LoadControl on CompositionPlayer), because that will be used in preference to the 13.1MB DEFAULT_MIN_BUFFER_SIZE value.

[icbaker]

The commit linked above should resolve the Target buffer size reached error (in both ExoPlayer and CompositionPlayer) for images up to ~26MB.

I'm going to modify this issue to track the possible future enhancement of allowing setting a custom LoadControl (or maybe LoadControl.Factory or something) on CompositionPlayer.

[niklasfejes]

Thanks for the quick and detailed investigation, this explains a lot of what's going on.

An acceptable workaround for me right now is to just resize any image that is above the size threshold in a preprocessing step, that should probably improve playback performance a bit as well.