4 ms·

Oh, interesting! I guess the reason why I've assumed somethings off is because both Google Drive, Youtube etc. seems to take 10x longer do encode MOV files vs

Oh, interesting! I guess the reason why I've assumed somethings off is because both Google Drive, Youtube etc. seems to take 10x longer do encode MOV files vs. raw MP4. So you are saying there shouldn't be a difference then?

DaiPlusPlus 5y ago
> seems to take 10x longer do encode MOV files vs. raw MP4 > So you are saying there shouldn't be a difference then? There should be no difference if the video coding (codec aka "video format" aka "compression-standard" ) is already one of the standards (e.g. AVC, HEVC, etc). For example, AVC video in a RIFF file[1] should be able to be converted to AVC video in an ISO BMFF (aka QuickTime MOV) file without performing any transcoding at all, so it should take however long it takes for your computer to literally copy bytes from one file into another. The evidence suggests that Apple's screen-recordings are made using the "ProRes 4444" codec, which explains why other programs need it to be transcoded, and why YouTube takes longer: https://support.apple.com/en-us/HT202410 https://support.apple.com/en-us/HT202410 [1] I believe this is theoretically possible, if utterly impractical
- matthewmacleod 5y ago
  Screen recordings don't use ProRes – they're just standard MOV containers with H.264 in them. I recorded one now and ffprobe says: Input #0, mov,mp4,m4a,3gp,3g2,mj2, from './test.mov': ... Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 900x492 [SAR 1:1 DAR 75:41], 1666 kb/s, 58.45 fps, 60 tbr, 6k tbn, 12k tbc (default)
garblegarble 5y ago
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)
mey 5y ago
There are roughly (I am not an expert in this) three things that make up a video file. A container format, then a video and audio encoding. MP4 is a container format. Think of it like a stream optimized zip file. Then inside this container, various video and audio codec actually do the work of compression their respective components. While MP4 is based on the MOV container format, I don't know if they are 1:1. So at minimum, all the contents would need to be unpacked and moved to the MP4 container format if the codecs were staying the same. That doesn't sound like what is happening here as that should be really quick. (If that's even possible). That's why parent was asking about codecs, if the MOV has video in MPEG-1 and Google wants it in H.264, it has to reencode the video stream.

DaiPlusPlus 5y ago

> seems to take 10x longer do encode MOV files vs. raw MP4 > So you are saying there shouldn't be a difference then? There should be no difference if the video coding (codec aka "video format" aka "compression-standard" ) is already one of the standards (e.g. AVC, HEVC, etc). For example, AVC video in a RIFF file[1] should be able to be converted to AVC video in an ISO BMFF (aka QuickTime MOV) file without performing any transcoding at all, so it should take however long it takes for your computer to literally copy bytes from one file into another. The evidence suggests that Apple's screen-recordings are made using the "ProRes 4444" codec, which explains why other programs need it to be transcoded, and why YouTube takes longer: https://support.apple.com/en-us/HT202410 https://support.apple.com/en-us/HT202410 [1] I believe this is theoretically possible, if utterly impractical

matthewmacleod 5y ago
Screen recordings don't use ProRes – they're just standard MOV containers with H.264 in them. I recorded one now and ffprobe says: Input #0, mov,mp4,m4a,3gp,3g2,mj2, from './test.mov': ... Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 900x492 [SAR 1:1 DAR 75:41], 1666 kb/s, 58.45 fps, 60 tbr, 6k tbn, 12k tbc (default)

garblegarble 5y ago

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)

mey 5y ago

There are roughly (I am not an expert in this) three things that make up a video file. A container format, then a video and audio encoding. MP4 is a container format. Think of it like a stream optimized zip file. Then inside this container, various video and audio codec actually do the work of compression their respective components. While MP4 is based on the MOV container format, I don't know if they are 1:1. So at minimum, all the contents would need to be unpacked and moved to the MP4 container format if the codecs were staying the same. That doesn't sound like what is happening here as that should be really quick. (If that's even possible). That's why parent was asking about codecs, if the MOV has video in MPEG-1 and Google wants it in H.264, it has to reencode the video stream.