mirror of
https://git.ffmpeg.org/ffmpeg.git
synced 2026-10-24 02:09:03 +03:00
9badbee44d
In Chrome-branded builds, libavcodec/h274.c places 700,440 bytes of film grain buffers in chrome.dll's .bss (`film_grain_db` at 692,248 B and `init_slice_c::tmp` at 8,192 B), even though these buffers are only touched when software H.264 decoding encounters an H.274 Film Grain Characteristics SEI. On Windows, the PE loader pre-commits chrome.dll's entire .bss in every process. Move `init_slice_c::tmp` into `H274FilmGrainDatabase` (700,440 B total) and allocate `film_grain_db` on the heap via `ff_thread_once()` on the first call to `ff_h274_apply_film_grain()`. This is safe because: - `ff_h274_apply_film_grain()` is the sole entry point that accesses `film_grain_db`. Its callers in `h264_picture.c` and `vvc/dec.c` already handle negative error returns (`AVERROR(ENOMEM)`), and this CL updates `hevc_frame_end()` in `hevc/hevcdec.c` to propagate negative returns instead of asserting `ret >= 0`. - `init_slice_c()` is only called while holding `init_slice()`'s static mutex, so storing `tmp` in `H274FilmGrainDatabase` preserves the same thread safety without a large stack allocation. Impact (Windows x64 official Chrome-branded chrome.dll): - .data VirtualSize: 3,758,744 B -> 3,058,328 B (-684 KiB / ~-9.1 MiB at p50 process count). - Binary file size (.text/.data RawSize): +0 B.