VLC use alot of CPU during paused state
What's vlc doing when paused example a song? still decoding ? qt4 events?
e.g, when mp3 is paused, there's continuous cpu consumption of about average 3-5% (max 9%) on Vista on amd dual core machine.
Activity
added Component::Core: Input Difficulty::guru + 1 deleted label and removed Component::Bindings: LibVLC (native API) Status::will not fix labels
changed milestone to %Bugs paradize
This is not very friendly to power management. Unfortunately, this is really hard to fix.
Especially on the video output side... we need to refresh the video when paused in at least two circumstances:
- The OSD is fading in or out.
- The video window got damaged by the windowing system.
There are currently no provision in the video output for signaling damages. Instead, VLC just pushes the image at regular short interval to avoid persistent damage.
-
This bug is dependent on bug #541.
-
The CPU usage on my machine is 140% (1.4 cores) when pausing a video, so we are not talking about some negligible CPU usage, but about something that can be the major reason for draining the battery.
I understand courmisch's concerns, but I for one would much prefer sacrifying OSD fading updates to save CPU power.
I believe you would get signals about window damage, if the area is not a video out area. So how about simply making a snapshot of the last image in the video area, then tear down the video area and present the snapshot as a non-video area while paused? Even if this is not possible I would still prefer damaged areas over having 1.4 CPU cores run full speed.
Original author:
++. this is sorely needed, especially since bookmarks don't persist when vlc is quit. so there's no way to continue watching a video later except by pausing or manually seeking to the same time, if you can remember it. this is the only reason i still use mplayx- it supports both persistent bookmarks and has negligible cpu usage while paused.
-
Replying to [comment:9 ]:
I understand courmisch's concerns, but I for one would much prefer sacrifying OSD fading updates to save CPU power.
That's only part of the problem; actually that is covered more specifically in bug #541. There are other issues, at least in the input thread that also cause the CPU to wake-up in paused state.
I believe you would get signals about window damage, if the area is not a video out area.
Of course you do. But VLC does not handle them, and that would require patching a dozen different video output plugins. Again, this is covered by bug #541.
So how about simply making a snapshot of the last image in the video area, then tear down the video area and present the snapshot as a non-video area while paused?
That's not how video rendering works. Screenshooting is extremely slow actually. This would have a massive performance impact. Instead, you need to keep a reference to the last frame, and be ready to render it again any time.
Even if this is not possible I would still prefer damaged areas over having 1.4 CPU cores run full speed.
VLC does not do that in pause state. It just wakes up a few times per second to refresh the screen and check a few other things.
-
Replying to [comment:11 courmisch]:
Replying to [comment:9 ]:
I understand courmisch's concerns, but I for one would much prefer sacrifying OSD fading updates to save CPU power.
That's only part of the problem; actually that is covered more specifically in bug #541. There are other issues, at least in the input thread that also cause the CPU to wake-up in paused state.
I do not see how #541 is relevant if you tear down all the playing infrastructure when paused. Simply emulate 'pause' as screenshot+'stop', and 'resume' as 'start'+'seek'.
I believe you would get signals about window damage, if the area is not a video out area.
Of course you do. But VLC does not handle them, and that would require patching a dozen different video output plugins. Again, this is covered by bug #541.
Why? We assume you stop and tear down the video output plugins. The plugins will not be running while paused, thus they will not be required to handle any window damage when paused.
So how about simply making a snapshot of the last image in the video area, then tear down the video area and present the snapshot as a non-video area while paused?
That's not how video rendering works. Screenshooting is extremely slow actually. This would have a massive performance impact. Instead, you need to keep a reference to the last frame, and be ready to render it again any time.
Paying a massive performance impact for one single frame once is highly preferable to using 1.4 CPU core constantly. Please note that I am not suggesting the normal playback should be done using screenshooting.
We do not need to keep a reference to the last frame when pausing. We need to keep a reference to the time stamp, and when the user resumes playing again, we render from that time stamp - just like we would do if the user had seeked to that time stamp.
Maybe you can enlighten me why you believe the following will not work:
When the user pauses (e.g. by pressing space): Record time stamp Take screenshot of current frame Tear down everything as if the user had pressed 'stop' Show a still photo of the screenshot (not using the video out plugins) If possible: Ask the window manager to deal with damage Go to sleep
When user resumes (e.g. by pressing space again): Start playing as if the user had pressed 'play' Seek to the time stamp recorded earlier as if the user had seeked to that position Continue playing from there
The above is basically what I do manually to avoid paying the 1.4 CPU core when paused, so I am quite puzzled why that should be hard to do automatically.
Even if this is not possible I would still prefer damaged areas over having 1.4 CPU cores run full speed.
VLC does not do that in pause state. It just wakes up a few times per second to refresh the screen and check a few other things.
So how do you explain that VLC in paused state on my old system used 140% CPU power?
(On my new faster laptop it is down to 10%, but still massive compared to waking up a few times per second. In stopped state it takes 0.0%, which sounds more like what you describe).
Original author: ole tange
-
Replying to [comment:12 ole tange]:
I do not see how #541 is relevant if you tear down all the playing infrastructure when paused. Simply emulate 'pause' as screenshot+'stop', and 'resume' as 'start'+'seek'.
Again, that is not how multimedia pipelines work. Until you can provide a working patch that demonstrate how to fix #2656 (closed) without first fixing #541, I will have to assume you don't know what you are talking about.
Why? We assume you stop and tear down the video output plugins. The plugins will not be running while paused, thus they will not be required to handle any window damage when paused.
So we loose not only the paused video frame on display, but also the reference video frames for decoding after we resume from pause, oh and the pending audio buffers too.
Paying a massive performance impact for one single frame once is highly preferable to using 1.4 CPU core constantly. Please note that I am not suggesting the normal playback should be done using screenshooting.
Massive impact? VLC occupies between 0.3% and 0.7% CPU in paused state. The only issue is that waking up the CPU screws up power management, especially on mobile devices. This is a non-issue for a desktop system, and a very minor issue for a laptop.
We do not need to keep a reference to the last frame when pausing. We need to keep a reference to the time stamp, and when the user resumes playing again, we render from that time stamp - just like we would do if the user had seeked to that time stamp.
You seem to think that you know better than VLC developers how to develop a multimedia pipeline. I will be waiting for your patch, and in the mean time I will assume you have no clue what you are on about.
Meanwhile, if someone with a clue would fix #541, that would be very welcome.
-
Replying to [comment:13 courmisch]:
Replying to [comment:12 ole tange]:
I do not see how #541 is relevant if you tear down all the playing infrastructure when paused. Simply emulate 'pause' as screenshot+'stop', and 'resume' as 'start'+'seek'.
Again, that is not how multimedia pipelines work. Until you can provide a working patch that demonstrate how to fix #2656 (closed) without first fixing #541, I will have to assume you don't know what you are talking about.
It would be more helpful if you pointed out which step in the algorithm shown that would not work. So I ask you again to enlighten us: Which of these steps are impossible/hard to implement?
When the user pauses (e.g. by pressing space): Record time stamp Take screenshot of current frame Tear down everything as if the user had pressed 'stop' Show a still photo of the screenshot (not using the video out plugins) If possible: Ask the window manager to deal with damage Go to sleep
When user resumes (e.g. by pressing space again): Start playing as if the user had pressed 'play' after pressing 'stop' Immediately seek to the time stamp recorded earlier as if the user had seeked manually to that position Continue playing from there
Why? We assume you stop and tear down the video output plugins. The plugins will not be running while paused, thus they will not be required to handle any window damage when paused.
So we loose not only the paused video frame on display, but also the reference video frames for decoding after we resume from pause, oh and the pending audio buffers too.
Assuming we can make a screenshot of the last frame, then we do not lose the paused video frame on display.
The reference video frames and the pending audio buffers will lost, but they will be refilled just like they would have been, had the user seeked manually to the time stamp.
So that addresses your concerns.
Massive impact? VLC occupies between 0.3% and 0.7% CPU in paused state.
If that was true I would not be commenting on this bug. Maybe that is true on your system. It is not true on mine.
On my system VLC occupies 10% of a 2.2 GHz CPU when showing a video in paused state. That is roughly 20 times more than what you experience.
On my old system it was 140% of a CPU.
Do you want me to file a new bug report on that?
We do not need to keep a reference to the last frame when pausing. We need to keep a reference to the time stamp, and when the user resumes playing again, we render from that time stamp - just like we would do if the user had seeked to that time stamp.
You seem to think that you know better than VLC developers how to develop a multimedia pipeline.
Maybe this is where the miscommunication is. I am not suggesting implementing this into the multimedia pipeline. I am suggesting tearing down the pipeline on 'pause' (just like it is currently done on 'stop') and re-creating it on 'resume' (just like it is currently done on 'play'+'seek').
I do not claim to know better, but you have yet to explain why 'pause' could not be implemented as specified. Referring to #541 seems only relevant if you want to keep the pipeline running when on 'pause', but it is irrelevant as the procedure I have sketched does not use video out plugins and tears down the pipeline.
If you do not want to address the algorithm proposed, then please explain why you do not want to address why the procedure that works if I do it by hand cannot be automated.
Original author: ole tange
-
Seriously, please read the OP's report before you comment on someone else's bug report. Where does it say 140% CPU? Nowhere. It says 3-5% on a computer that is at least 5 years old as of now. This bug is about VLC waking up a little during pause (which is bad for power management). This bug report is NOT about busy waiting or consuming large amounts of CPU during pause.
If you think your proposal fixes this bug, you are welcome to post a patch. I don't think your proposal is practical, or even relevant. And I have neither time, nor motivation, nor duty to explain all the details.
assigned to @Courmisch
changed milestone to %3.0.0
