4f5e360180
Define common_inc which includes both public_inc and the project root directory. The project root directory will allow access to config.h and all the shared/ headers. Replacing all custom '.', '..', '../..', '../shared' etc. include paths with common_inc reduces clutter in the target definitions and enforces the common #include directive style, as e.g. including shared/ headers without the subdirectory name no longer works. Unfortunately this does not prevent one from using private libweston headers with the usual include pattern for public headers. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> |
||
---|---|---|
.. | ||
main.c | ||
meson.build | ||
README | ||
wcap-decode.c | ||
wcap-decode.h |
WCAP Tools WCAP is the video capture format used by Weston (Weston CAPture). It's a simple, lossless format, that encodes the difference between frames as run-length encoded rectangles. It's a variable framerate format, that only records new frames along with a timestamp when something actually changes. Recording in Weston is started by pressing MOD+R and stopped by pressing MOD+R again. Currently this leaves a capture.wcap file in the cwd of the weston process. The file format is documented below and Weston comes with the wcap-decode tool to convert the wcap file into something more usable: - Extract single or all frames as individual png files. This will produce a lossless screenshot, which is useful if you're trying to screenshot a brief glitch or something like that that's hard to capture with the screenshot tool. wcap-decode takes a number of options and a wcap file as its arguments. Without anything else, it will show the screen size and number of frames in the file. Pass --frame=<frame> to extract a single frame or pass --all to extract all frames as png files: [krh@minato weston]$ wcap-snapshot capture.wcap wcap file: size 1024x640, 176 frames [krh@minato weston]$ wcap-snapshot capture.wcap 20 wrote wcap-frame-20.png wcap file: size 1024x640, 176 frames - Decode and the wcap file and dump it as a YUV4MPEG2 stream on stdout. This format is compatible with most video encoders and can be piped directly into a command line encoder such as vpxenc (part of libvpx, encodes to a webm file) or theora_encode (part of libtheora, encodes to a ogg theora file). Using vpxenc to encode a webm file would look something like this: [krh@minato weston]$ wcap-decode --yuv4mpeg2 ../capture.wcap | vpxenc --target-bitrate=1024 --best -t 4 -o foo.webm - where we select target bitrate, pass -t 4 to let vpxenc use multiple threads. To encode to Ogg Theora a command line like this works: [krh@minato weston]$ wcap-decode ../capture.wcap --yuv4mpeg2 | theora_encode - -o cap.ogv WCAP File format The file format has a small header and then just consists of the individual frames. The header is uint32_t magic uint32_t format uint32_t width uint32_t height all CPU endian 32 bit words. The magic number is #define WCAP_HEADER_MAGIC 0x57434150 and makes it easy to recognize a wcap file and verify that it's the right endian. There are four supported pixel formats: #define WCAP_FORMAT_XRGB8888 0x34325258 #define WCAP_FORMAT_XBGR8888 0x34324258 #define WCAP_FORMAT_RGBX8888 0x34325852 #define WCAP_FORMAT_BGRX8888 0x34325842 Each frame has a header: uint32_t msecs uint32_t nrects which specifies a timestamp in ms and the number of rectangles that changed since previous frame. The timestamps are typically just a raw system timestamp and the first frame doesn't start from 0ms. A frame consists of a list of rectangles, each of which represents the component-wise difference between the previous frame and the current using a run-length encoding. The initial frame is decoded against a previous frame of all 0x00000000 pixels. Each rectangle starts out with int32_t x1 int32_t y1 int32_t x2 int32_t y2 followed by (x2 - x1) * (y2 - y1) pixels, run-length encoded. The run-length encoding uses the 'X' channel in the pixel format to encode the length of the run. That is for WCAP_FORMAT_XRGB8888, for example, the length of the run is in the upper 8 bits. For X values 0-0xdf, the length is X + 1, for X above or equal to 0xe0, the run length is 1 << (X - 0xe0 + 7). That is, a pixel value of 0xe3000100, means that the next 1024 pixels differ by RGB(0x00, 0x01, 0x00) from the previous pixels.