CPU Tone Mapping
CPU tone mapping performs the picture conversion on the general-purpose processor rather than running the mapping on a GPU.
A CPU tone mapper processes reconstructed pictures in system memory. Its work follows the picture grid and processing representation, even if the source's compressed file is small.
Count the picture work before the compressed bytes
| Grid and rate | Picture positions per second |
|---|---|
| 1920 × 1080 at 24 fps | 49,766,400 |
| 3840 × 2160 at 24 fps | 199,065,600 |
| 3840 × 2160 at 60 fps | 497,664,000 |
These are input sizes, not measured CPU throughput. Each position can require component conversion, transfer-function calculations, curve evaluation, and output preparation. The chosen implementation determines how those operations are combined or accelerated with vector instructions and threads.
Float RGB storage and memory traffic
FFmpeg's CPU tonemap filter operates on floating-point RGB in linear light. A suitable surrounding path interprets the incoming HDR signal, supplies that working representation, runs the mapping, and prepares the final output format.
For a 3840 × 2160 picture with three 32-bit float components, the logical sample storage is:
3840 × 2160 × 3 × 4 = 99,532,800 bytes, about 99.53 MB per picture before padding.
At 24 fps, one full read and one full write of that representation account for approximately 4.78 GB/s of logical traffic. Additional passes can require more; cache reuse and implementation choices change the physical traffic. This is a storage calculation, not a benchmark or a required network bitrate.
The example explains why an operation's cost includes memory access as well as the scalar curve formula. A decoded working picture can be much larger than the compressed data used to deliver it.
Keep the other CPU jobs visible
An Emby transcode can also decode, rescale, render subtitles, convert audio, and encode. A high total CPU reading covers those jobs together. To locate a bottleneck, inspect the actual stages and whether their completed-picture rate keeps up with the source.
A hardware encoder at the end does not move all earlier filtering to the GPU. Conversely, software decoding can feed GPU presentation; the Windows FAQ describes that combination. A transfer between system and device memory may be needed at that boundary.
When frames already occupy system memory and the required software path is supported, CPU mapping avoids introducing an additional device-transfer stage solely for the curve. When a supported GPU path can keep frames accessible across several operations, its residency changes the traffic picture. The playback-path article locates those choices within the session.