3 ms·

Quicktime screen captures use H.264 Main@L5.2 variable-framerate (and normal 8-bit with 4:2:0 chroma subsampling), it's possible that Google are enforcing a tra

Quicktime screen captures use H.264 Main@L5.2 variable-framerate (and normal 8-bit with 4:2:0 chroma subsampling), it's possible that Google are enforcing a transcode because of some rules they have on decoder complexity / limiting quality of H.264? I know Google prefer their own VP* codecs everywhere. You could test whether the container format makes a difference by using the following FFmpeg commandline (e.g. if the output of this is any faster to ingest than the original .mov it could be that Google's ingest process sees some unexpected atom/table in the .mov that aren't used in .mp4? ffmpeg -i screen-capture.mov -codec:a copy -codec:v copy capture.mp4 Edit: typo in the original post (had codec:c rather than codec:a)

DaiPlusPlus 5y ago
I suggest running ffprobe first, just to make sure we know what the input really is. > 4:2:0 chroma subsampling It would be very un-Apple-like to make screen-recordings with chroma subsampling: that's the best way to make colorful hard edges look awful, and macOS is full of colorful hard edges.
- garblegarble 5y ago
  They are using 4:2:0. You'll get no argument from me that 4:4:4 (or at least 4:2:2) would be nicer, but I don't see any major issues visually with their fairly high bitrate capture encoding settings. Here's a mediainfo output for a Quicktime screen capture on the latest Big Sur release on an Intel Mac: https://pastebin.com/8SUZqMed https://pastebin.com/8SUZqMed Edit: posted wrong output, fixed pastebin output to show the .mov straight out of quicktime (previously had a remux via ffmpeg)