3 ms·

2021 is the year .mov finally breaks out

by pluc 5y ago

DaiPlusPlus 5y ago
The *.mov file format is the same as MPEG-4's container format (in fact, MPEG-4's container is intentionally based on QuickTime's *.mov) and is even standardized as an ISO spec: "ISO/IEC base media file format": https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format + https://en.wikipedia.org/wiki/QuickTime_File_Format https://en.wikipedia.org/wiki/QuickTime_File_Format ...and Apple has been using MPEG-4 AVC and HEVC for at least a decade now, so I don't understand what the OP is complaining about: QuickTime *.mov files are MPEG-4 container files, which usually contain MPEG-4 AVC or MPEG-4 HEVC streams. Other people are reporting the same problem: the other media software can't read Apple's screen-recording files, so I'm assuming this actually means that Apple's screen-recordings are saved using a codec other than MPEG-4 AVC or HEVC, but still in an MPEG-4 container. So for this conversation to continue, we need to know what codec/video-stream-format is actually being used (I don't have a Mac ready to experiment right now, sorry). ----- UPDATE: After some research, I think that macOS screen-recordings are made using Apple's ProRes video coding, and then saved inside a QuickTime (aka MPEG-4) Container. ProRes is very different to AVC, HEVC, etc, which explains why you need to transcode it to do anything useful with it. ------- UPDATE 2: So screen recordings don't use ProRes by default, they use AVC (but what profile?), so I'm unsure why so many other programs and websites reject those files because, theoretically, there should be no problem in processing them, unless the site was written by someone who doesn't understand how video files work...
- reimertz 5y ago
  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.
- traviswt 5y ago
  I don't know much about codecs, but I just did a screen recording and checked it out with VLC: H264 - MPEG-4 AVC (part 10) (avc1)
  - DaiPlusPlus 5y ago
    What software did you use to make it?
    - jagged-chisel 5y ago
      QuickTime does screen recording. This is my default assumption when someone makes a screen recording on a Mac.
- crazygringo 5y ago
  Just tried making a screen recording with QuickTime on my Mac and investigating it with the "mediainfo" command-line tool (available on Homebrew). It's absolutely h.264, not ProRes. It's similarly h.264 when you record from the built-in webcam in QuickTime using the default "high" quality, but switches to ProRes if you select "maximum" quality for recording. (ProRes files are enormous, BTW.) A lot of people report that simply renaming a "mov" file to "mp4" works when the data is h.264 such as in this case. Unfortunately every tool I have which takes .mp4 as input also accepts .mov, so I can't actually verify this since for all I know my tools might be ignoring the extension and autodetecting mov. But if anyone knows any websites that accept mp4 but not mov I'd be happy to test an upload and see if it works. Edit, for anyone interested, here's the relevant output from mediainfo: General Format : MPEG-4 Format profile : QuickTime Codec ID : qt 0000.00 (qt ) ... Overall bit rate mode : Variable Overall bit rate : 4 014 kb/s ... Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : Main@L5.1 Format settings : CABAC / 2 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 2 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding ... Bit rate mode : Variable ... Frame rate mode : Variable ... Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive ... Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 Codec configuration box : avcC
- snowwrestler 5y ago
  I made a QT screen recording earlier this week, exported to 1080p, and uploaded it to Microsoft Streams, which worked fine. So either the QT export was a standard h.264 file, or Microsoft Streams is set up to recognize whatever weirdness comes out of QT (which seems unlikely to me).

2021 is the year .mov finally breaks out

by pluc 5y ago

2021 is the year .mov finally breaks out

The *.mov file format is the same as MPEG-4's container format (in fact, MPEG-4's container is intentionally based on QuickTime's *.mov) and is even standardized as an ISO spec: "ISO/IEC base media file format": https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format + https://en.wikipedia.org/wiki/QuickTime_File_Format https://en.wikipedia.org/wiki/QuickTime_File_Format ...and Apple has been using MPEG-4 AVC and HEVC for at least a decade now, so I don't understand what the OP is complaining about: QuickTime *.mov files are MPEG-4 container files, which usually contain MPEG-4 AVC or MPEG-4 HEVC streams. Other people are reporting the same problem: the other media software can't read Apple's screen-recording files, so I'm assuming this actually means that Apple's screen-recordings are saved using a codec other than MPEG-4 AVC or HEVC, but still in an MPEG-4 container. So for this conversation to continue, we need to know what codec/video-stream-format is actually being used (I don't have a Mac ready to experiment right now, sorry). ----- UPDATE: After some research, I think that macOS screen-recordings are made using Apple's ProRes video coding, and then saved inside a QuickTime (aka MPEG-4) Container. ProRes is very different to AVC, HEVC, etc, which explains why you need to transcode it to do anything useful with it. ------- UPDATE 2: So screen recordings don't use ProRes by default, they use AVC (but what profile?), so I'm unsure why so many other programs and websites reject those files because, theoretically, there should be no problem in processing them, unless the site was written by someone who doesn't understand how video files work...

reimertz 5y ago
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.
traviswt 5y ago
I don't know much about codecs, but I just did a screen recording and checked it out with VLC: H264 - MPEG-4 AVC (part 10) (avc1)
- DaiPlusPlus 5y ago
  What software did you use to make it?
  - jagged-chisel 5y ago
    QuickTime does screen recording. This is my default assumption when someone makes a screen recording on a Mac.
crazygringo 5y ago
Just tried making a screen recording with QuickTime on my Mac and investigating it with the "mediainfo" command-line tool (available on Homebrew). It's absolutely h.264, not ProRes. It's similarly h.264 when you record from the built-in webcam in QuickTime using the default "high" quality, but switches to ProRes if you select "maximum" quality for recording. (ProRes files are enormous, BTW.) A lot of people report that simply renaming a "mov" file to "mp4" works when the data is h.264 such as in this case. Unfortunately every tool I have which takes .mp4 as input also accepts .mov, so I can't actually verify this since for all I know my tools might be ignoring the extension and autodetecting mov. But if anyone knows any websites that accept mp4 but not mov I'd be happy to test an upload and see if it works. Edit, for anyone interested, here's the relevant output from mediainfo: General Format : MPEG-4 Format profile : QuickTime Codec ID : qt 0000.00 (qt ) ... Overall bit rate mode : Variable Overall bit rate : 4 014 kb/s ... Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : Main@L5.1 Format settings : CABAC / 2 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 2 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding ... Bit rate mode : Variable ... Frame rate mode : Variable ... Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive ... Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 Codec configuration box : avcC
snowwrestler 5y ago
I made a QT screen recording earlier this week, exported to 1080p, and uploaded it to Microsoft Streams, which worked fine. So either the QT export was a standard h.264 file, or Microsoft Streams is set up to recognize whatever weirdness comes out of QT (which seems unlikely to me).