Increase video download buffering

[dylanforegger]

This is a beautiful piece of software. I have watched it improve over time tremendously. This is why I am submitting my suggestion to "increase video download buffering".

I use NewPipe to watch YouTube videos on my Android 7 smartphone. The Internet service I use is AT&T, which gives a nice 25 mbps download speed. However, sometimes the download speed can get as low as 3 mbps. When this happens, the YouTube video begins to hesitate intermittently. If I use the regular YouTube app, the playback is smooth.

A suggestion I have for upcoming versions of NewPipe is to increase video download buffer a little more before actually playing the video in order to alleviate the issue of hesitant playback.

The easiest way would be to change the predefined buffer amount directly in the source code. A more involved approach would be to allow the user to change these settings, increasing or decreasing the download buffer size incrementally.

Thank you for your efforts in creating a better world for us YouTubers. That feature of downloading videos to your Android device through the "Share" interface was ingenious.

Thanks again,
Dylan Foregger

[litetex]

@dylanforegger

Thank you for the feedback, however please fill out the issue accordingly to the template.

In the meantime there were various fixes for buffering problems, like #6510.
So please check if they fixed your problem.

Currently the minimum buffer time is 25s the optimal 50s.

However, sometimes the download speed can get as low as 3 mbps.

I watch videos in 1080p60 with 1mbps (megabyte not bit) and they mostly work fine.

The Internet service I use is AT&T, which gives a nice 25 mbps download speed.

Although your ISP may provide 1GBps that doesn't mean that the servers or network infrastructure in between can also provide that.

[Atemu]

This would require changes to LoadController. It was recently simplified in #7406 which no longer allows for modification of the buffer size.

Would you be fine with reverting your simplification in favour of making buffer size configurable @Redirion?

[Redirion]

that would require some sort of fully dynamic buffering based on the available internet speed. I don't think it is useful to just increase the buffer.

[Atemu]

As I understand it, the issue is that the connection problem is intermittent. They've got decent connection most of the time but it sometimes drops below video streaming levels.

If the buffer was larger, more of the video would be pre-downloaded with the regular speed and the user might not notice the intermittent speed drop because the video is played off the buffer during that time.

What we really need is to size the buffer according to RAM size. For example, I've got 8GB so I would have no problem with it using something insane like 4GB for buffering but obviously a user with just 6GB wouldn't want that. A user-configurable option for how much to buffer is the next best thing though.

[Redirion]

no that would not work. App processes have resource limits defined by ART (or on 4.4 Dalvik) which are much lower. The actual property variables are still called dalvik.vm.heap*.
For example on my Pixel 4a dalvik.vm.heapsize is 512mb while dalvik.vm.heapgrowthlimit is 256mb. This means that the whole app process including video playback, activity and the current circular buffer shall be within these 256mb, and should only rarely exceed them to the hard limit of 512mb. Everything above will cause the app process to be emergency trimmed or directly killed due to out of memory.

You can check the limits on your 8GB device by entering "adb shell" and use "getprop | grep dalvik".

I also think that it might cause some performance problems handling such a big circular buffer. There are reasons why the size is measured in seconds, not in minutes.

[opusforlife2]

@Redirion It's a bit confusing then why Google went for 50 seconds instead of, let's say, 200 MB. 50 seconds of an 8K video will probably be a huge amount of data. Will the buffer stop loading once the app reaches its heap limit?

[Redirion]

There should be an mb limit as well, I will check that

[Redirion]

Video Buffer increased from 13MB to 32MB in ExoPlayer 2.10. In 2.12 it was raised to even 128MB with a behaviour change that time buffers are not prioritized anymore to avoid OOM. So you can see that increasing the values here might cause a lot of issues even on devices like my Pixel 4a unless we forcefully disable higher resolutions on those.

Sources:
128MB and prio change: google/ExoPlayer@c16d0f6
32MB increase: google/ExoPlayer@6dd3d49

[opusforlife2]

So are you saying the entire buffer gets discarded once the memory consumption goes too high? That seems a bit weird. You'd think Google would code it in such a way that if the buffer hits the memory limit, the player would ensure to only buffer less than that amount from then on (only for that stream).

[Redirion]

it is like you said. The buffer is kept within the limits be it seconds or mb whatever of those two is reached earlier. The hard memory limits (dalvik vm) are in regard to the whole app process.

[Atemu]

App processes have resource limits defined by ART (or on 4.4 Dalvik) which are much lower. The actual property variables are still called dalvik.vm.heap*.
For example on my Pixel 4a dalvik.vm.heapsize is 512mb while dalvik.vm.heapgrowthlimit is 256mb. This means that the whole app process including video playback, activity and the current circular buffer shall be within these 256mb, and should only rarely exceed them to the hard limit of 512mb. Everything above will cause the app process to be emergency trimmed or directly killed due to out of memory.

This is apparently not true. There is currently a memory leak in the element messenger app with which it is able to erroneously use gigabytes of RSS on my device.

[Redirion]

"Homebrewed LineageOS"

[Atemu]

What exactly do you mean by that?

The relevant Dalvik heap settings are also 512M/256M on my device.

[opusforlife2]

Closing since DASH support has been added for much quicker playback start. Please open a new issue if the problem occurs again.

[Atemu]

@opusforlife2 this isn't about quicker playback start, this is about having a larger buffer to smooth out inconsistent connections. DASH support only helps filling the buffer quicker/with smaller delay but not how long it lasts.