Isn't that only relevant because you're using -c copy? Without transcoding, ffmpeg will just copy the stream from that start-time. But because video codecs store data as incremental updates to a keyframe, without transcoding, those first few seconds will be useless data. -noaccurate_seek looks for the keyframe so you do not have that useless data.
Though according to the ffmpeg docs on -ss, it should be doing noaccurate_seeks if you're doing stream copy.
Also I'm unsure about this, but I think the audio stream can be cut at a different location than the video stream, leading to the frozen frame, and different video players seem to handle it differently. I've got a clip I've made, with transcoded video stream but copied audio stream, that is 1:06 on Firefox with the extra audio at the beginning, but 1:03 on VLC, MPC, Chrome, and desynced in Edge. Extracting the audio with ffmpeg again gives a time of 1:04.02 compared to a video stream of 1:03.
Proper terms are i-frame and p-frame. https://en.wikipedia.org/wiki/Video_compression_picture_type...
Though according to the ffmpeg docs on -ss, it should be doing noaccurate_seeks if you're doing stream copy.
Also I'm unsure about this, but I think the audio stream can be cut at a different location than the video stream, leading to the frozen frame, and different video players seem to handle it differently. I've got a clip I've made, with transcoded video stream but copied audio stream, that is 1:06 on Firefox with the extra audio at the beginning, but 1:03 on VLC, MPC, Chrome, and desynced in Edge. Extracting the audio with ffmpeg again gives a time of 1:04.02 compared to a video stream of 1:03.