Gh! you are right.

> This probably breaks heap profiling?
Kinda. 
This has no effect on just --enable-heap-profiling (as it uses the pseudo stack stuff form TRACE_EVENT)
Instead this kinda breaks --enable-heap-profiling=native. I say "kinda" because dskiba implemented some tricky fallback that resorts on stack-scanning. But even when this works, it will not attribute the allocations to the right source, but to the last call that had a frame.

+ OWNERs for ffmpeg - is ffmpeg non-functional with -fno-emit-frame-pointers, or is this code just a performance optimization? The only time "default_stack_frames" throws in "-fno-omit-frame-pointer" is

using_sanitizer || enable_profiling || is_debug || current_cpu == "arm64"

We care about the enable-profiling case, where we really, really want frame pointers to have fast stack walks.

This has been this way for as long as I've been on the team > 5 years. https://cs.chromium.org/chromium/src/third_party/ffmpeg/BUILD.gn?l=204 explains why; and I have verified that statement in the past; though not recently (~3 years). In the past playback has been unacceptably slow for software decoded video. Linux has no hardware decode so would be most affected, other platforms would probably be fine since we'd either be using the hardware decoder for h264 decoding or libvpx (which may have similar exclusions to ffmpeg).

Some of the code may not even compile without this flag due to register pressure, but feel free to experiment and see what happens. 

as per c#5, give to erikchen@ to experiment.