Vout blitting frames unnecessarily

added Component::Core: Video output Severity::minor Type::bug Version::master git labels

changed milestone to %0.8.5-test3

This is simply not how VLC works. It implies that the display layer has knowledge about the input status, which in the current design is simply not the case. In order for this to change MASSIVE changes are needed to the core. These all fall under the inputbuffer/synch code and frameaccurate search/playback tickets. This in itself is years of work. After that we can start worrying about something as trivial as unnecessary blitting.

added Difficulty::guru Status::will not fix labels

removed milestone %0.8.5-test3

closed

This ticket is part of #29 (closed).

I don't think it would be that hard to avoid this particular problem. It's trivial for the video output to know about the status of its parent input (if it is actually an input vout and not a visualization vout, but that is also easy to know), and it would not be very hard to suspend the vout thread while the input is in pause.

Suspending it when the input does not have anything to read is harder, it requires the modification of input to handle buffering at stream level instead of es_out and detection of buffer underrun/clock control. I definitely think we should at least try something for 0.8.6 here.

We can't just avoid these problems forever, we have to face them and try fixing them. They are the top 1 priority bugs. If we don't work on them, I think VLC is doomed.

added Difficulty::hard label and removed Difficulty::guru Status::will not fix labels

changed milestone to %0.8.6

reopened

(btw, I reopen because I think the ticket is valid, even if it should ultimately be merged)

changed milestone to %Features paradize

added 1 deleted label

Isn't this fixed for 1.2 ?

I certainly hope it is not fixed in 1.2. It would probably not be very hard to keep the vout thread in sleep while the decoder is paused, and OSD is not fading in or out.

But... the video output plugins and core have to deal with "damaged" windows. That is to say, they need to tell the core when the current picture has been damaged due to change in the stacking or layout of the window. Otherwise, the video window will look corrupted/stale until playback resumes. In fact, the lack of support for damage handling is a bug of its own.

Don't get me wrong, polling in the vout thread is a bug and should be fixed. But it is far more complicated than Zorglub describes.

Vout blitting frames unnecessarily

Child items 0

Activity