Out of memory playing high bitrate MKV

[master255]

Maybe Google doesn’t watch movies through its own media player?
Just replace link in demo app to:
[link removed]

and play more then 3 minutes.
I used:
releaseVersion = '2.10.7'
releaseVersionCode = 2010007

My device Galaxy S8+ Android 8.0.0. This is reproduced on all devices.
Files:


LogCat.txt

Please fix this. I want to watch a movie and my multi-million audience wants watch too.

[ojw28]

The linked file is 70GB, and the server it's hosted on is so slow (at least from our office) that it would take over a day for us to download it. Do you have access to a faster server to host the content on, to help us reproduce what you're seeing?

Regarding the content itself: 70GB is pretty excessive for a movie. That's about 5x the bitrate that premium streaming services cap out at for 4K HDR. It's likely that this isn't a memory leak, and is just that the extremely high bitrate of the file results in the player requiring a large amount of memory to buffer the content.

[master255]

@ojw28 , This is a very fast server. Outgoing Internet speed 200Mbps. 4 core processor i7 8650U, SSD with 1700 Megabit outgoing speed. And he is busy only with the fact that he gives you this file.

The file size is large. Since it has a lot of different audio tracks. In general, this is a standard MKV file. Big bitrate. Yes. But this is 4k quality. Streaming services cut quality and their users cannot watch movies in full quality. This is full quality and it does not work.
Please download the file and check its operation on the local network.
I think in any case should not be a crash?
What will you do when there are 8k movies? Which size is 4 times larger? 400GB? And the video bitrate is 240 megabits?
OK. Do not answer. Just fix the memory leak.
I am very upset by this bug.

[ojw28]

This is a very fast server. [...] Please download the file and check its operation on the local network.

This is not the case when requesting the file from where I am. Perhaps it's only fast within your own region. Not being able to obtain the file within a reasonable amount of time restricts our ability to reproduce this issue.

In general, this is a standard MKV file. Big bitrate. Yes. But this is 4k quality. Streaming services cut quality and their users cannot watch movies in full quality. This is full quality and it does not work.

Nothing beyond ~1080p is perceptible to the human eye for a (normal sized) phone. Trying to play a 70GB 4K stream on a phone is already very excessive, let alone 8K. It's negative to the user because it unnecessarily drains their battery, consumes network and storage, takes longer to download, etc, for a quality increase that they cannot perceive. It's also worth noting that top end phones are capping out at ~512GB storage. The idea that someone would want to consume ~80% of their entire storage on a 400GB 8K video, to play on a 1440p display, on current hardware, seems rather unrealistic. I'm guessing your users are trying to play this type of stream because they either don't know it's a bad idea or because that's what's available, but if they did have a choice they'd be much better off downloading a 5Mbit/s 720p encoding.

[master255]

@ojw28 , And where does the phone? The bug indicates that it occurs on any device. My bug reproduces perfectly on a Sony 2019 TV with 4k screen. A telephone is like a demonstration that a more powerful device than a TV has the same problem. Because the phone is more powerful than the TV.
Right now, my phone is compressing a 70GB mkv file into a zip archive. Zip archiver works wonders. Compresses a 70GB file on a phone with 64GB of memory :-D

[master255]

Yes. Russia is a harsh country :-)

[master255]

@ojw28 , The file is ready. Unpack the packed file and test it over the network (WiFi 5G)
[link removed]

"More slow" server (2GB file):
[link removed]

I got exactly the same error just now, using this file.
If a 2 GB file is small, then I can send a 5 GB, 10 GB file..... To get the result.
My miracle phone is ready to generate :-)

[ojw28]

The fact that your 70GB file can be compressed by 97% using ZIP is pretty good evidence that the file isn't sensible. It means you can compress the video down to 3% of its size in a completely lossless way. Except in weird edge cases, I'd expect ZIP to achieve roughly 0% additional compression on a media file.

The file is also unwatchable using VLC on my Linux development workstation, which has 28 CPU cores clocked at 2.6GHz and 128GB if RAM. Perhaps there's some optimization problem (e.g. VLC on Linux / this type of architecture). But what is clear is that the bitrate of this file severely limits its portability for playback across devices.

I will order an SD card capable of holding the file, so I can test playback on a Galaxy S8 (the one I have access to does not have sufficient physical storage for the file).

[master255]

@ojw28 , This file is trimmed inside. Therefore, it compresses well. VLC on Android does not have a memory leak and plays the file normally.
I repeat again - the problem appears on the network. You must place the file on the local network, and not on the drive to the device.

[ojw28]

This file is trimmed inside. Therefore, it compresses well.

Ah, thanks!

I repeat again - the problem appears on the network. You must place the file on the local network, and not on the USB flash drive to the device.

ExoPlayer doesn't really do anything that would cause a significant difference in memory consumption between local playback and playback over the network, so I'd expect to see the same behavior in both cases. Have you tried local playback and explicitly not observed the issue in that case, or have you just not tried?

[master255]

@ojw28 I did not check it locally. Only over the network.

[master255]

@ojw28 , Yes! I just tested the file locally. There is a problem with local playback too.

[ojw28]

There isn't a memory leak here. The player is just running out of memory trying to reach its target buffer duration of 50 seconds of media. The simplest way for you to fix this in your app is to configure the DefaultLoadControl in your app to enforce a total buffer size in bytes as part of the policy. Calling DefaultLoadControl.Builder.setPrioritizeTimeOverSizeThresholds(false) when building your DefaultLoadControl will achieve this, and hence will fix the OOM error in your app.

Reassigning to @tonihei to consider how we can change the default policy to be more sensible. We should be careful not to significantly change behavior for "normal" bitrate files in whatever change we make.

Bit of an aside, but it might also be worth considering to what extent we can have the policy behave differently for local vs network based playbacks. There's little value in having a large buffer for local playbacks.

[master255]

@ojw28 , Very good answer! I will try to configure a local buffer. Glad it's not a memory leak!
I hope you will deal with the automation of setting the maximum buffer.
Many thanks!

[master255]

I just tested this setting. Everything works perfectly! There are no memory problems. Thanks.