Steps:
1.	Wayland Compositor running (e.g. Weston)
2.	Start recording with <Super> + r 
3.	Wait for 20 seconds
4.	Stop recording with <Super> + r and exit 
5.	From command line encode the recorded session. Observe number of frames = 1 frame
6.	Play back the video 
7.	Observe recorded session time as 0sec and file size 10KB

User expectation is Weston would record all sessions. 


Actual Result :
Weston would not record the session when no actions are performed.


Environment:

wayland (HEAD) heads/1.3-0-g84247b7
drm (HEAD) libdrm-2.4.46-0-gc6d73cf
mesa (HEAD) remotes/origin/9.2-0-g7ab2b8c
libva (HEAD) libva-1.2.1-0-g88ed1eb
intel-driver (HEAD) 1.2.1-0-g8f306e3
weston (HEAD) remotes/origin/1.3-0-g98562c3

I'm not sure about what recording path this bug is about.

   <super> + 'r'  activates the software based recording
   <super> + <shift> + <space> followed by 'q' activates the libva based recording

The former encodes the first frame and after that encodes only the differences from the previous frame. In that case, it is natural that only one frame was recorded. The latter actually records frames continuosly even if there is no activity.

It would be good to include Weston's output to stdout to the report to clarify things. Also, what is the name of the file that has only 10KB and what is the command line you're using for encoding the frame?

(In reply to comment #2)
> I'm not sure about what recording path this bug is about.
> 
>    <super> + 'r'  activates the software based recording
>    <super> + <shift> + <space> followed by 'q' activates the libva based
> recording
> 
> The former encodes the first frame and after that encodes only the
> differences from the previous frame. In that case, it is natural that only
> one frame was recorded. The latter actually records frames continuosly even
> if there is no activity.
> 
> It would be good to include Weston's output to stdout to the report to
> clarify things. Also, what is the name of the file that has only 10KB and
> what is the command line you're using for encoding the frame?

This bug relates to the software based recording path (as indicated by the "steps" above) which produces a capture.wcap file.

The command that we use to transcode the frames is:

wcap-decode --yuv4mpeg2 ./capture.wcap | vpxenc --target-bitrate=1024 --best -t 4 -o session.webm -

The issue here is that the recording should at least encode the last frame when the user stops the recording (even if nothing changed) so that the "time" difference is captured.  I assume this would allow the final transcoded video stream to playback the same frame for the given length of time.

commit e22f3bb5da5d22f1bb6056de1069f7f1c08cc62b
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date:   Tue Dec 17 14:18:01 2013 +0200

    screenshooter: Record one extra frame when recording stops
    
    If the compositor hasn't been rendering for a while when the recording
    stops, the time difference between the last rendered frame and that
    moment won't be in the encoded video. Fix that by forcing one extra
    frame to be recorded when the user presses the recorder key binding.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=71142