This section discusses the recording quality settings, optional tweaks, and trade-offs.
Although everyone wants the best video quality for the application recording, setting the appropriate video quality requires careful consideration and understanding the trade-offs of different settings.
The higher the quality, the more demanding the recording in terms of CPU load, memory footprint, energy consumption (battery life), and network traffic is.
The primary way to set the video quality is by selecting one of the presets available in the application dashboard. Dashboard settings affect all new recordings.
There are three preset values of Low/Medium/High (see the project settings). Technically, this option sets primarily the video bitrate, which affects the video image quality and size of the video data. For most projects, Medium has the best price-performance ratio. When the application is used in an environment where data size that is sent from the application matters, Low might be the best option. For apps where the high image quality of the recordings is important, and data size does not matter much, High can be used.
The current settings are:
|Low||80 000 bits/s||~ 0.5 MB per minute|
|Medium||160 000 bits/s||~ 1 MB per minute|
|High||320 000 bits/s||~ 2 MB per minute|
The real data size depends on many factors (how complex the UI is, how often it changes significantly) and tends to be a fraction (½ or ⅓) of the maximum size.
Technologically, this setting affects the memory footprint of the SDK, its CPU load, and primarily the size of the data that the SDK sends over the network.
Frame rate (in frames per second, or fps) states how often Smartlook takes a snapshot of the screen. The higher the frame rate, the smoother the recording of UI changes. The trade-off is, however, higher CPU load and energy consumption. For analyzing user interaction in a common application, the default fps value (2fps) is quite sufficient. Higher fps makes sense in dynamic apps like games.
We recommend setting the frame rate for the project on the dashboard.
Alternatively, it can also be set as one of Smartlook setup options. This is particularly useful for debugging and finding the optimal value for the application. In production releases, this option should not be used.
The configured frame rate, however, is its maximal value. In order to reduce the footprint, Smartlook watches the real changes in the UI and takes snapshots only when the UI is not idle. While working well in most apps, this kind of optimization, known as adaptive frame rate, may not work perfectly in some edge cases with technologies that are used to create UI. If the adaptive frame rate algorithm produces unsatisfying results, it can be switched off by the respective Smartlook setup options (see API reference).
On top of taking snapshots of the screens for the video recording, Smartlook can also present the UI in the form of several types of wireframe sketches.
Different rendering modes use different amounts of CPU, memory, and produce video data of different sizes. The difference is individual for each application and depends on the way the application UI is structured. There is not always a direct relation between the simplicity of the visual presentation and resources load.
Read more about rendering modes in the Rendering Modes: Handling Sensitive Data at the Whole Screen Level.
Updated almost 2 years ago