mirscreencast still captures (forces composition) even if there are no clients rendering

Bug #1294362 reported by Alberto Aguirre
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Triaged
Medium
Unassigned
mir (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

mirscreencast still captures content (blank of course) when no clients are attached to the mirserver or when clients have not posted any content.

That maybe ok for a single screenshot but possibly not desired for continuous screencasting.

CompositingScreencast runs it's display compositor separately from the multi-threaded compositor, driven by capture requests of the mirscreencast surface. The CompositingScreencast compositor happily obliges even if it means there's no new content.

Either the screencast capture should be driven by the multi threaded compositor or the CompositingScreencast should hook into scene changes via scene's set_change_callback

Tags: screencast
Changed in mir:
importance: Undecided → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Sounds like a fix would resolve bug 1294361 too.

summary: - mirscreencast still captures even if there are no clients rendering
+ mirscreencast still captures (forces composition) even if there are no
+ clients rendering
Changed in mir:
status: New → Triaged
tags: added: screencast
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

I think it's OK (even preferred) for screencasting to capture at a steady rate (as much as possible at least), regardless of whether something is changing on screen or not. What's the point of a screencast with an unstable frame rate (e.g. frameN from frameN+1 being 2 seconds apart because nothing changed)? Screencasting does not fall under the same performance/power restrictions we have for normal compositing.

The alternative would be to timestamp frames (which I think was brought up at some point in our stand-ups), although I am not sure how easy it would be to convert the resulting stream to something watchable.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I'm undecided on this. Obviously dynamic frame rate (just observing real frames as they're scheduled) is most efficient but we cannot feasibly join up the resulting frames into a steady video without building-in support for variable-framerate video format encoding to the tooling. I think that would limit our options, aside from being quite complicated.

So yeah, we probably want to force capture at a steady frame rate.

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

Variable-framerate is a non-issue in most containers - all of them have duration tables built-in. I don't see why this would be "quite complicated".

I also disagree on the performance restriction since that's actually what's driving the submission of this bug especially on embedded devices with massive screen sizes such as the N10.

Revision history for this message
Alberto Aguirre (albaguirre) wrote :

Just thinking about this more, we should allow both options. So maybe this bug should be an enhancement request to optionally capture only at scene changes.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It's complicated because linking to external video encoding libraries would be unacceptable. Hence we would have to do the encoding ourselves, making variable-framerate more complicated than constant frame rate.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

- unacceptable
+ undesirable

I said that because Mir is growing dependencies too fast. But sometimes they're necessary.

Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.