Answers.Body: <p>If the pixelation wasn't in the sources you had, then it was probably introduced by the video encoder you used to export.  (Presumably Apple's h.264 encoder, creating a .mov with an h.264 video stream, as opposed to one of the many other video codecs that the mov container can hold.)</p>
  
  <p>Video encoding always trades off CPU time vs. bitrate vs. quality.  Using more CPU time can get better quality at the same file size.  Different encoders (x264 vs. mainconcept vs. apple vs. IDK what else) will have worse or better achievable tradeoffs.  <a href="http://www.videolan.org/developers/x264.html" rel="nofollow">x264</a> is the best H.264 encoder for pretty much everything, esp. if you care most about final quality per file size.  It's free and open source, so there's no reason not to use it.</p>
  
  <p>Look for a slider to turn up the CPU usage and/or bitrate until the resulting encode is high enough quality.  I'm not going to go into any more detail, just google for video encoding guides to find out more.</p>
  
  <p><strong>edit:</strong> As stib points out, you might well be in a situation where your output file is going to be transcoded before broadcast, in which case you should just turn up the bitrate as high as is reasonable, to minimize generation loss.  Prores has no advantage over h.264 for this purpose, though.  Your file will be decoded once, at full rez, in order.  Prores is intra-only, and can decode faster at reduced rez, but gives up quality per bitrate in order to gain those features.  h.264 and prores both support bit depths higher than 8bit per component (subject to encoder/decoder support), which may be relevant if the TV station that will broadcast it wants to mess with the colors during transcode.  If they won't, then the small compression advantage of 10bit h.264 is of low value, given how much slower x264 is when encoding at higher than 8bit.</p>
  
  <p>prores is (slightly) lossy, but as far as I know, h.264 at the same very high bitrate will be even less lossy.  You can even use x264 to produce lossless h.264, if the people you're sending it to can decode it.</p>
  
  <p>If you were sending it to people that were going to do something and save that as prores themselves, then using prores yourself might make sense.  I <em>think</em> I read that prores is designed to stop losing quality for multiple generations of transcoding.</p>
  
  <p>If you're going to permanently archive the output file, spending some more CPU time (and using x264) to get good quality per bitrate might still be useful.  But if you're instead archiving the FCP project and sources, then that doesn't matter.</p>
  
  <p><strong>end of edit</strong></p>
  
  <p>If you don't want to set up x264 for Final Cut Pro, or export lossless and feed that to x264, then similar controls for the h.264 encoder that comes with FCP probably exist.  I don't use FCP, but this is really a video-encode-quality question, so I'm answering anyway.  An answer from a FCP user would probably still be useful.</p>
  
  <p>BTW, one case where x264 isn't the best choice is encoding a movie for your mobile device or something where you're only going to watch it once, and large filesize doesn't matter.  Then a GPU encoder like Intel quicksync can throw enough bitrate at the video for it to look good enough on a tablet or phone, but be smaller than the dvd or blu-ray source.</p>
  
  <p>If you're doing "encode once -> watch many", like for broadcast, it makes sense to use as much CPU time as you can, to get the best quality for your target filesize (2pass mode).  Or to get the smallest filesize for your target quality (CRF mode).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T05:58:05.457Z
Answers.Text: If he's sending it off for broadcast (and here I'm assuming DVB terrestrial broadcast, as in "on the telly") it will probably be transcoded before the end user watches it anyway. So it's not really an encode once → watch many situation. Better to find out what codecs / formats are accepted by the broadcaster and do the highest quality transcode that fits. For example, the TV stations here in Australia accept ProRes (HQ) encoded quicktime mov media which is great, because there's no guesswork about bitrates or h.264 settings, and it's a damn good codec.
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T06:16:29.333Z
Answers.Text: I was thinking Danielle was maybe at a TV station, making broadcast encodes, but your interpretation of the question makes more sense.  Updated.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T06:18:13.013Z
Answers.Text: I probably have a worse impression of prores than you, since I've only ever seen the slow implementation in ffmpeg, not Apple's.  I get that it's fast and convenient for a lot of things due to software support in commercial stuff.  I'd be curious to see how x264 did in quality per bitrate, with settings that make it encode as fast as prores.  As I understand it, prores only really shines as a codec for scratch files that you want to be able to scrub / frame-accurate-seek / fast-decode-at-low-rez, and to avoid generation loss if I'm remembering that part correctly.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T07:01:11.137Z
Answers.Text: Well the big advantage Prores (and dnxHD and even v210) has over h.264 for mastering is that it's 10-bit 4:2:2, rather than 8-bit 4:2:0 (I realise you can do higher bit-rates and lower subsampling if you use the newer features of x264, but good luck getting a TV station to recognise the files). And that's another advantage: because there are no settings to change you don't have to worry about whether your ChromaQPOffset, WeightedBPrediction or VBVInitialBuffer (etc etc) settings are compatible. If you can afford the bandwidth and the processing time it saves a lot of headaches.
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T15:12:08.947Z
Answers.Text: Do people really still use h.264 decoders that can't handle all of High profile?  (weightb is the only option you mentioned that does anything requiring decoder support, but I know what you mean.)  I'll grant you that it's inconvenient to get 10bit x264 set up, and decoder support for anything but 8-bit 4:2:0 is limited.  However, if that's what you ARE doing, then just set x264 preset=medium crf=14 and don't touch anything else.  You'll get a h.264 High profile encode, which any compliant decoder will handle.  h.264 High profile hasn't changed for a decade.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-13T15:17:09.993Z
Answers.Text: Broadcast TV streams invariably go out as 8bit 4:2:0 h.264, right?  Is there any reason you'd encode at a higher bit depth or chroma rez (e.g. 4:2:2)?  (asking because I don't know, since I don't work in professional video.  I just mess around with ffmpeg for my own use, and I find compression interesting. :)  Would that be to make a master that you might use in the future for some higher-quality purpose than HDTV broadcast?
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-14T00:13:20.790Z
Answers.Text: Where I live the TV stations multiplex several channels onto one signal, at different data rates and resolutions. So they'll be re-encoding for each stream. I'd guess the pictures go out through a hardware encoder, so everything would get decoded and then re-encoded anyway. My thinking is that it's better to give them a higher quality master to re-encode, rather than something that's already lost a lot already.
Answers.UserDisplayName: stib
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-14T02:23:15.743Z
Answers.Text: I've come across posts on the ffmpeg mailing list archives from a guy at a TV station (CTV.ca, I think, which is a major network with digital broadcast antennas in many cities, as well as cable) saying he uses ffmpeg / x264 to encode files for final broadcast.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-14T02:31:07.700Z
Answers.Text: But I completely agree, unless the people you're sending it to request that you make an encode at a bitrate low enough for final use as-is, or can avoid xcoding if you make one, then use LOTS of bitrate, well beyond visually transparent.  (even invisible ringing artifacts look like detail to the next encoder in the chain, so it will spend bits preserving artifacts.)  If you're going to archive this master, though, then size has some relevance, so h.264 is probably worth it.  (assuming decoder compat and similar factors doesn't tip the balance to prores or dnxhd)
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-11T10:42:54.840Z
Answers.LastActivityDate: 2015-04-13T06:12:52.053Z
Answers.LastEditDate: 2015-04-13T06:12:52.053Z
Answers.UserDisplayName: Peter Cordes
Body: <p>I took over the editing for a project recently and I wasn't given the raw files. All I was given was the partially completed MP4 file. I used Final Cut Pro 7 to complete the project edits. When I exported the file, I exported using Quicktime Conversion to create a .mov file. </p>
  
  <p>The issue is that this file must be broadcast quality and it just failed QC because parts of it are pixilated. </p>
  
  <p>I'm wondering, is there a way to export the file - which looks perfect on my end - so that it isn't pixilated and it passes QC?</p>
  
Tags: <final-cut-pro><quicktime>
Title: How to get the highest possible quality out of a MP4 file
UserDisplayName: Danielle
ThreadText: # How to get the highest possible quality out of a MP4 file
  
  (Asked by: username_0 on 2015-04-11)
  
  I took over the editing for a project recently and I wasn't given the raw files. All I was given was the partially completed MP4 file. I used Final Cut Pro 7 to complete the project edits. When I exported the file, I exported using Quicktime Conversion to create a .mov file.
  
  The issue is that this file must be broadcast quality and it just failed QC because parts of it are pixilated.
  
  I'm wondering, is there a way to export the file - which looks perfect on my end - so that it isn't pixilated and it passes QC?
  
  **Tags:** final-cut-pro, quicktime
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-04-11. Score: 1
  
  If the pixelation wasn't in the sources you had, then it was probably introduced by the video encoder you used to export. (Presumably Apple's h.264 encoder, creating a .mov with an h.264 video stream, as opposed to one of the many other video codecs that the mov container can hold.)
  
  Video encoding always trades off CPU time vs. bitrate vs. quality. Using more CPU time can get better quality at the same file size. Different encoders (x264 vs. mainconcept vs. apple vs. IDK what else) will have worse or better achievable tradeoffs. [x264](http://www.videolan.org/developers/x264.html) is the best H.264 encoder for pretty much everything, esp. if you care most about final quality per file size. It's free and open source, so there's no reason not to use it.
  
  Look for a slider to turn up the CPU usage and/or bitrate until the resulting encode is high enough quality. I'm not going to go into any more detail, just google for video encoding guides to find out more.
  
  **edit:** As username_2 points out, you might well be in a situation where your output file is going to be transcoded before broadcast, in which case you should just turn up the bitrate as high as is reasonable, to minimize generation loss. Prores has no advantage over h.264 for this purpose, though. Your file will be decoded once, at full rez, in order. Prores is intra-only, and can decode faster at reduced rez, but gives up quality per bitrate in order to gain those features. h.264 and prores both support bit depths higher than 8bit per component (subject to encoder/decoder support), which may be relevant if the TV station that will broadcast it wants to mess with the colors during transcode. If they won't, then the small compression advantage of 10bit h.264 is of low value, given how much slower x264 is when encoding at higher than 8bit.
  
  prores is (slightly) lossy, but as far as I know, h.264 at the same very high bitrate will be even less lossy. You can even use x264 to produce lossless h.264, if the people you're sending it to can decode it.
  
  If you were sending it to people that were going to do something and save that as prores themselves, then using prores yourself might make sense. I *think* I read that prores is designed to stop losing quality for multiple generations of transcoding.
  
  If you're going to permanently archive the output file, spending some more CPU time (and using x264) to get good quality per bitrate might still be useful. But if you're instead archiving the FCP project and sources, then that doesn't matter.
  
  **end of edit**
  
  If you don't want to set up x264 for Final Cut Pro, or export lossless and feed that to x264, then similar controls for the h.264 encoder that comes with FCP probably exist. I don't use FCP, but this is really a video-encode-quality question, so I'm answering anyway. An answer from a FCP user would probably still be useful.
  
  BTW, one case where x264 isn't the best choice is encoding a movie for your mobile device or something where you're only going to watch it once, and large filesize doesn't matter. Then a GPU encoder like Intel quicksync can throw enough bitrate at the video for it to look good enough on a tablet or phone, but be smaller than the dvd or blu-ray source.
  
  If you're doing "encode once -> watch many", like for broadcast, it makes sense to use as much CPU time as you can, to get the best quality for your target filesize (2pass mode). Or to get the smallest filesize for your target quality (CRF mode).
  
  > **Comments:**
  > **username_2**: If he's sending it off for broadcast (and here I'm assuming DVB terrestrial broadcast, as in "on the telly") it will probably be transcoded before the end user watches it anyway. So it's not really an encode once → watch many situation. Better to find out what codecs / formats are accepted by the broadcaster and do the highest quality transcode that fits. For example, the TV stations here in Australia accept ProRes (HQ) encoded quicktime mov media which is great, because there's no guesswork about bitrates or h.264 settings, and it's a damn good codec.  
  > **username_1**: I was thinking username_0 was maybe at a TV station, making broadcast encodes, but your interpretation of the question makes more sense.  Updated.  
  > **username_1**: I probably have a worse impression of prores than you, since I've only ever seen the slow implementation in ffmpeg, not Apple's.  I get that it's fast and convenient for a lot of things due to software support in commercial stuff.  I'd be curious to see how x264 did in quality per bitrate, with settings that make it encode as fast as prores.  As I understand it, prores only really shines as a codec for scratch files that you want to be able to scrub / frame-accurate-seek / fast-decode-at-low-rez, and to avoid generation loss if I'm remembering that part correctly.  
  > **username_2**: Well the big advantage Prores (and dnxHD and even v210) has over h.264 for mastering is that it's 10-bit 4:2:2, rather than 8-bit 4:2:0 (I realise you can do higher bit-rates and lower subsampling if you use the newer features of x264, but good luck getting a TV station to recognise the files). And that's another advantage: because there are no settings to change you don't have to worry about whether your ChromaQPOffset, WeightedBPrediction or VBVInitialBuffer (etc etc) settings are compatible. If you can afford the bandwidth and the processing time it saves a lot of headaches.  
  > **username_1**: Do people really still use h.264 decoders that can't handle all of High profile?  (weightb is the only option you mentioned that does anything requiring decoder support, but I know what you mean.)  I'll grant you that it's inconvenient to get 10bit x264 set up, and decoder support for anything but 8-bit 4:2:0 is limited.  However, if that's what you ARE doing, then just set x264 preset=medium crf=14 and don't touch anything else.  You'll get a h.264 High profile encode, which any compliant decoder will handle.  h.264 High profile hasn't changed for a decade.  
  > **username_1**: Broadcast TV streams invariably go out as 8bit 4:2:0 h.264, right?  Is there any reason you'd encode at a higher bit depth or chroma rez (e.g. 4:2:2)?  (asking because I don't know, since I don't work in professional video.  I just mess around with ffmpeg for my own use, and I find compression interesting. :)  Would that be to make a master that you might use in the future for some higher-quality purpose than HDTV broadcast?  
  > **username_2**: Where I live the TV stations multiplex several channels onto one signal, at different data rates and resolutions. So they'll be re-encoding for each stream. I'd guess the pictures go out through a hardware encoder, so everything would get decoded and then re-encoded anyway. My thinking is that it's better to give them a higher quality master to re-encode, rather than something that's already lost a lot already.  
  > **username_1**: I've come across posts on the ffmpeg mailing list archives from a guy at a TV station (CTV.ca, I think, which is a major network with digital broadcast antennas in many cities, as well as cable) saying he uses ffmpeg / x264 to encode files for final broadcast.  
  > **username_1**: But I completely agree, unless the people you're sending it to request that you make an encode at a bitrate low enough for final use as-is, or can avoid xcoding if you make one, then use LOTS of bitrate, well beyond visually transparent.  (even invisible ringing artifacts look like detail to the next encoder in the chain, so it will spend bits preserving artifacts.)  If you're going to archive this master, though, then size has some relevance, so h.264 is probably worth it.  (assuming decoder compat and similar factors doesn't tip the balance to prores or dnxhd)  
  
  ---
  
  