|Summary:||Weston does not record a session when no user action is performed|
|Product:||Wayland||Reporter:||Anu Reddy <anasuyax.r.nannuri>|
|Component:||weston||Assignee:||Wayland bug list <wayland-bugs>|
|Status:||VERIFIED FIXED||QA Contact:|
|i915 platform:||i915 features:|
Description Anu Reddy 2013-11-01 21:05:00 UTC
Comment 1 Anu Reddy 2013-11-01 21:53:33 UTC
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
Comment 2 Ander Conselvan de Oliveira 2013-11-14 12:25:49 UTC
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?
Comment 3 U. Artie Eoff 2013-11-18 18:53:57 UTC
(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.
Comment 4 Kristian Høgsberg 2013-12-17 18:59:52 UTC
commit e22f3bb5da5d22f1bb6056de1069f7f1c08cc62b Author: Ander Conselvan de Oliveira <firstname.lastname@example.org> 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