zaps166
Cache/Buffer keeps getting deleted and needs to be redownloaded on any change like changing Subtitle,Audio streams.
Everytime you are streaming some video and qmplay has buffered some content, the buffer however big it is like even ~1GB, will be deleted and starts redownloading if you
- Enable, disable or change subtitle streams
- Change audio streams.
- Rewind to just few seconds back probably to the exact point where the buffer is deleted and now while seeking that the forward buffer however big it has already downloaded will also be deleted.
I understand like for a specific audio the video content needs to be in sync to that to present to the viewer but at least the already downloaded video content should clearly need not be deleted and redownloaded if only audio stream is changed.
On some level that is maybe necessary I don't know but deleting like 1GB already buffered video and audio after just disabling/enabling or changing a subtitle stream is clear resource wastage.
QMPlay2 needs to come up with better buffer management clearly.
Related to #670?
It seems related but my issue is related to any direct streaming not just youtube in general because then even yt-dl is also involved with it's own set of complexities and I don't remember seeing a youtube video where I had to change subtitles leading to this issue.
You can replicate my issue by simply visiting a direct url preferably with a non-youtube url first and then later you can try with that too if some things are common. You'll see that after just enabling/disabling a subtitle stream the whole buffer gets deleted and needs to be redownloaded, and same happens with audio streams too.
From my testing this doesn't seem to happen in other famous players and switching is a bit more smooth probably because they don't need to redownload that 5s of data because they haven't deleted it in first place.
I'm aware of this issue, it's annoying also for me. I'll try do improve it, but when I'll do it is unknown so far.
@zaps166 I'm watching a movie which is ~16GB and I'm using these settings you suggested above and for the first time I got notification from nohang about memory being low.
I'm on 8GB RAM and use various things for better memory management in Linux like zram and some oom-killer alternatives like nohang etc and qmplay2's memory consumption is shown as more than 2GB.
I understand that the downloaded data has to be kept somewhere if not disk so RAM it is but can something be done here since if something like firefox/chrome is open then 2-3GB is already consumed.
You can reduce the buffer. No need to set maximum. I don't want disk cache for now.
Install jemalloc and re-check with: LD_PRELOAD=/usr/lib/libjemalloc.so MALLOC_CONF=narenas:1,tcache:false,dirty_decay_ms:0,muzzy_decay_ms:0 QMPlay2
So I'm in an interesting situation - I tested with these variables you gave above and tested a 19GB file and everything worked perfectly and when I tested the same 16GB file I was having problems with, the memory usage again started going up with errors in terminal.
Sending you the exact url in mail to test the file.
Here is the error (the screenshot captures opening and running 2 direct urls -one was working perfectly without any memory leakage and other, the last one had memory leakage):
~350 MiB, not much... 🤔
as you can see from the pic, the video is just starting so with time everything keeps increasing including the RAM usage.
I went down the rabbit hole and used latest ffmpeg build from https://github.com/BtbN/FFmpeg-Builds/releases thinking that it might be the specific ffmpeg version error to decode that particular subtitle stream but same result. The error doesn't show in red though this time even though it's exactly the same error.
I think it can be a very specific case of some really bad encoding with that specific file with pgssub (which can include bugs of every single package/library included in encoding that file).
I think it can be a very specific case of some really bad encoding with that specific file with pgssub (which can include bugs of every single package/library included in encoding that file).
doesn't seem so because mpv do not present any such error.
Is it possible that while adding support for bitmap subtitle modification in the latest version this error was introduced? I'll check with more pgssub subtitle files.
I checked with one more file which has pgssub and same error in terminal so this appears to be specific to pgssub.
I noticed your video URL can't properly seek (also other players have issues).
as you can see from the pic, the video is just starting so with time everything keeps increasing including the RAM usage.
When QMPlay2 shows buffer of 3 GiB, it'll take over 3 GiB of RAM... It's how the cache is working - it's limited to time, not gigabytes. If you have buffered 30 min of video, it'll take some RAM (depends on video and audio bitrate).
I checked with one more file which has pgssub and same error in terminal so this appears to be specific to pgssub.
I have pgs subtitles (works correctly except aspect ratio), so this warning can be ignored? Also ffplay shows the same warning.
You're right. I checked with other really big files without any pgssub and same RAM usage without any error in terminal so the issue simply comes down to qmplay2 fetching all the buffer for smoother playback which results in it filling up the RAM.
I changed few settings and the situation is much better now with RAM usage stopped at 607MB.
Ok, but better don't set small local buffer size, keep default :smile:
120 seconds - 361 MiB - high bitrate stream + 28 MiB backward seek, almost 400 MiB for buffer. 607 MiB - contains buffer + decoder + GUI + other things in memory - good result. Is it with custom jemalloc config I gave you (it's slow and not recommended - only for testing)?
Yes I switched it back to 100 after realising that the Network Buffer length should be the one mostly responsible for this and is directly proportional to data being downloaded and thereby the RAM usage as cache.
No, not with jemalloc.
Ok. QMPlay2 shows you the size of the buffer, so your memory usage is backward + forward buffer + other data like decoder data, GUI data, other data.
If you buffer 10 min of high bitrate video stream, it'll use a lot of RAM (no disk cache, buffer limit is for seconds, not megabytes). Maybe I can add megabytes as an option in the future.
Smplayer has this setting specifically in size (MB) which is set as auto by default.
I understand that if I'm watching a really high quality stream of huge size like the ones available on sites we know, then of course cache is also going to be big, it's just that I never faced this issue all these years with other standard players like mpv, smplayer or vlc.
That's why after a better cache management qmplay2 will be the perfect player.
In my experience the majority of the players only cache ~2 minutes of forward cache but don't quote me on that whereas qmplay2 tends to download till the last byte available which might not be noticeable to >8GB RAM users who normally do not stream >~10GB Direct urls but in the long run a single size/time/ratio config for all types of files/streams is not the right approach.
I would suggest doing research on the most popular players like mpv, smplayer, vlc and potplayer maybe.
Buffer size in MiB (with auto - I guess depends on RAM size) can be added.
Default settings is ~10.5 min for entire cache with backward data which is ~700 MiB on 4k YouTube video, it's not much even for 8 GiB RAM. You can always lower the value
For now why not set network buffer length to 120 sec (2 min), backward rewinding to 75%, (also live stream to 5-10 sec)? This will create 210 sec (3.5 min) buffer.
Nowadays C++ IDE with clangd with few files open uses ~2GiB of RAM.
I've already set 120sec of forward cache as you can see; I'll apply the rest of them like this 👍.
I'm aware of this issue, it's annoying also for me. I'll try do improve it, but when I'll do it is unknown so far.
Is there any update on this?
Currently no motivation to do it, but I don't say it'll never be improved. Some day... 😄
It's about to not discard all buffer when one stream gets enabled, right?