This Time Self-Hosted
dark mode light mode Search

The other big memory waste

Tonight I finally started the true 1.2 series branch on xine-lib’s repository; this branch is the merge of the nopadding and the ffmpeg_integration branches, which means it starts with two big improvements: 10MB memory saving and a simpler to upgrade FFmpeg snapshot, with handling for disabling uncommon decoders, just like Miguel wanted.

Now, if you looked well enough at the graphs you posted, you already know what I’m talking about, if you didn’t, well here there’s a new graph, created using the -pq option at xine so that the logo is not displayed once the mp3 finished playing, removing the spurious spike at the end of the graph.

29-11-06_1750

The yellow are you see it’s the memory created by _x_fifo_buffer_new called by _x_video_decoder_init function. That’s right, there’s a huge amount of memory allocated by the video decoder initialisation function when playing an audio only mp3.

Okay, so what the problem is here? First, as the code cannot tell if what is playing is audio only or contains video too beforehand, it has to initialise the video driver every time too; this is quite normal though, nothing to be a problem.

The problem is that the video initialisation initialise automatically also a number of buffers, by default 500, of size 8KB.. even if they never gets used. It also allocates a single memory area for the buffers, 2KB-aligned, which is not exactly the cheapest way to allocate memory.

Now, this in general should be okay, shouldn’t it? Most of the times you’re playing video with xine, and so it should be fine, but there are cases when using this method will just waste a lot of memory, especially if the user tried to be smart and increased the number of buffers to something that isn’t exactly sane…

I’ll now be working on checking if it’s possible to just allocate the buffers when they are needed; in that case the graph will certainly appear different, as the memory will increase less steeply, and would just run down together at the end.

Let’s return to work (although I should be finding a way to clean up the mess that is my home office here)…

Comments 2
  1. “The yellow are you see it’s the memory created by (…)”ehh, what does that mean?

  2. Of course I meant the memory *occupation* created by the function, it’s unfortunately not likely that a C function can create memory from nothing… it can eat memory for nothing good though!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.