user2022: Has anyone done or seen any tests comparing Apple ProRes 422 with high-bitrate H.264?
We use 422 as a delivery format to go to DCP for theatrical versions of trailers.
The bitrate is around 150mbps.
We are wondering if it is possible to reach adequate quality with H.264. Say, with bitrates of 50-100mbps, and tweaking the GOP size/structure. (E.g., only using "I" frames.)
Assuming H264 is a more "efficient" codec, we are hoping to get smaller file sizes.
Or does H.264 just not have the color depth to compete?
It would be great to see if someone has done some real-world testing.
Update 1: I just did a quick test using 50mbps, GOP size 1, I-frames only ... and "by eye" I see no difference whatsoever. Same level of noise, same colors. The ProRes is 1.92GB, the H264 is 566MB. How would one "test" the difference technically? Or measure the color information?
Update 2: I did some more testing ... with Adobe Media Encoder, using MPEG2, and the "4:2:2" profile, the ProRes file went from 1,920MB to 290MB! And I would say, subjectively, that is is 99% as good. This is remarkable. (With H264 I was down to 500-700MB)

user3295: Well going by the numbers h264 has a lesser bit-depth and color accuracy than ProRes 422. PR422 has 10bit and 4:2:2 chroma sub-sampling, h264 has 8bit and 4:2:0 unless you encode in the Hi422P Intra profile which isn't very well supported in the wild but offers 10bit and 4:2:2.
So in that case I don't think you will have any difference what so ever between the two formats but a better compression ratio than with ProRes.
E: If you want to go real ape shit you can also encode in the 4:4:4 Intra Profile, that supports up to 14 bit of color depth. So technically superior to ProRes4444. Though you probably wont find any commercial application that supports it.
On another note, I don't think content delivery for cinema should be done in h264 nor ProRes 422 especially when you plan to encode to a lossless codec (JPEG2000/DCP) afterwards. It just doesn't make much sense to do so, all you loose is quality even though there is no need to do so, you only save space until you encode your DCP. There are other good lossless codecs, that offer very good compression, to use before encoding the DCP.
You could for example go directly to DCP, the Adobe Media Encoder offers export to 2k DCP since CC 2014, you can skip an encoding step and have a lossless codec with very good compression ratio.
Another great intermediate codec is UtVideo aswell as Schrödinger (an implementation of the Dirac codec from BBC, its available through FFmpeg).
In the end though theory always differs from practice and if you don't deliver for nation wide cinemas with excellent projectors and what not, that quality difference in your delivery chain will be neglectable.
The only thing that could be pitfall is that h264 is very complex an by that always prone for some weird visual defects, so final inspection is always a necessity with h264.

user9105: 
Has anyone done or seen any tests comparing Apple ProRes 422 with high-bitrate H.264?

No, but I can tell you that x264 can get as close to lossless as you want (or even mathematically lossless, with -qp 0).  x264 can produce h.264 streams in 4:2:0, 4:2:2, or 4:4:4 YUV colorspaces, at 8 or 10 bits per component.  (It can also do RGB, but unless you're doing lossless, you'll probably get better quality per bitrate from YUV.)
Decoder support for anything other than 4:2:0 8bit isn't as widespread.  (e.g. video cards have hardware decoders that can only accelerate 4:2:0 8bit).
Note that x264 has to be compiled for either 8 or 10bit output.  You need a separate build of libx264 (or a whole separate static build of ffmpeg) for 8bit and 10bit.  Either can handle any input bit depth you want to throw at it, but will always output the bit depth it was compiled for.
The Hi444PP h.264 profile supports up to 14bit depth for lossy or lossless operation, but x264 still only supports 8 or 10bit.  (Also 9bit, if you compile it with bit depth = 9, but there's really no point in doing that.  The speed hit comes as soon as you go beyond 8)
BTW, even if your input is 8bit and your final display is 8bit RGB, 10bit h.264 looks better for the same bitrate.  8bit h.264 is a speed vs. quality tradeoff.  (and obviously decoder compat.)  Google should find some threads on doom9, and a PDF from ateme, to back up this assertion.
To understand it, remember that lossy codecs aren't trying to reproduce all the input bits, just something that looks similar.  10bit allows more internal precision for motion prediction, and lets the encoder tweak the least-significant bits for better CABAC efficiency (trellis) without producing a visible difference.  So you get less banding of gradients.

We are wondering if it is possible to reach adequate quality with
  H.264. Say, with bitrates of 50-100mbps, and tweaking the GOP
  size/structure. (E.g., only using "I" frames.)

Forcing more I frames, or I frames only, does NOT increase quality.  h.264 encoders "know" how their output differs from their input, and will use I macroblocks where they're a better choice.
Short GOPs are useful for seeking, or error recovery in realtime streaming use cases.  For video production, a short GOP lets you frame step backwards without having to decode very many frames from the previous keyframe.  So you can scrub with more precision.
If seeking isn't a concern at all, you could set keyint=1000, and then x264 could use almost as long a GOP as it wanted.  (Scenecut detection is on in every preset except ultrafast, so x264 will use an IDR (key frame) every time a scene cut makes an I frame a good idea anyway.)

Update 2: I did some more testing ... with Adobe Media Encoder, using
  MPEG2, and the "4:2:2" profile, the ProRes file went from 1,920MB to
  290MB! And I would say, subjectively, that is is 99% as good. This is
  remarkable. (With H264 I was down to 500-700MB)

If you got results that good with MPEG2, you should easily get even smaller files with a decent h.264 encoder.  Your content probably compresses pretty well (low grain, some areas with lots of similarity).
If you have your input in a file that ffmpeg can read (i.e. almost any format),
ffmpeg -i in.mp4 -c:a copy -c:v libx264 -preset medium -tune film -crf 10 -movflags +faststart out.mp4

CRF 10 is way beyond visually lossless.  ffmpeg defaults to the same colorspace as the input, if the output codec supports it.  If your input is 4:4:4, but you want to subsample your chroma, use something like:
ffmpeg -i in ... -sws-flags lanczos+print_info -pix_fmt yuv422p  out
...
[swscaler @ 0x33be0c0] Lanczos scaler, from rgb24 to yuv422p using MMXEXT


Update 1: How would one "test" the difference technically? Or measure
  the color information?

Measure the output color depth?  maybe with mediainfo.
To compare quality of different encodes of the same source, measure the SSIM or PSNR of each encode relative to the source.  x264 can measure both those metrics during the encode process.  There are other tools for comparing two already-made video files, to measure those quality metrics, but I haven't used them.
For ffmpeg, use -ssim 1  -psnr -tune ssim.  (Don't use -tune ssim except when benchmarking that metric.  It defaults to enabling psychovisual optimizations that produce output that looks better to humans, but is mathematically less similar according to that metric.)
SSIM and PSNR are about the only thing you can use when you're working with bitrates that go way beyond visually transparent.  Google on these for more info.
To test losslessness, you can use ffmpeg's -f framemd5 codec to make sure the h.264 decodes bit-identically to the input.  (see this question for an example.  Make sure you use the same -pix_fmt for all tests, because different decoders might pack the same data differently.)
Oh, just read Prof Sparkles' answer.  Didn't realize that you were eventually outputting to lossless.  You're just shooting yourself in the foot if you use any lossy codecs along the way.  The lossless codec will have to encode all the invisible blocking / ringing artifacts left by the lossy codecs, so you'll typically get bigger files from your lossless codec if you feed it input that's been through a lossy codec, instead of the original source.
So if you want to use h.264, use lossless.  (ffmpeg -i in -preset ultrafast -qp 0 out).  (slower presets give only a tiny compression improvement for lossless.  Never use ultrafast for anything except lossless, though.)

2022: <p>Has anyone done or seen any tests comparing Apple ProRes 422 with high-bitrate H.264?</p>

<p>We use 422 as a delivery format to go to DCP for theatrical versions of trailers.
The bitrate is around 150mbps.</p>

<p>We are wondering if it is possible to reach adequate quality with H.264. Say, with bitrates of 50-100mbps, and tweaking the GOP size/structure. (E.g., only using "I" frames.)</p>

<p>Assuming H264 is a more "efficient" codec, we are hoping to get smaller file sizes.</p>

<p>Or does H.264 just not have the color depth to compete?</p>

<p>It would be great to see if someone has done some real-world testing.</p>

<p><strong>Update 1:</strong> I just did a quick test using 50mbps, GOP size 1, I-frames only ... and "by eye" I see no difference whatsoever. Same level of noise, same colors. The ProRes is 1.92GB, the H264 is 566MB. How would one "test" the difference technically? Or measure the color information?</p>

<p><strong>Update 2:</strong> I did some more testing ... with Adobe Media Encoder, using MPEG2, and the "4:2:2" profile, the ProRes file went from <strong>1,920MB to 290MB</strong>! And I would say, subjectively, that is is 99% as good. This is remarkable. (With H264 I was down to 500-700MB)</p>
 3295: <p>Well going by the numbers h264 has a lesser bit-depth and color accuracy than ProRes 422. PR422 has 10bit and 4:2:2 chroma sub-sampling, h264 has 8bit and 4:2:0 unless you encode in the Hi422P Intra profile which isn't very well supported in the wild but offers 10bit and 4:2:2.
So in that case I don't think you will have any difference what so ever between the two formats but a better compression ratio than with ProRes.</p>

<p>E: If you want to go real ape shit you can also encode in the 4:4:4 Intra Profile, that supports up to 14 bit of color depth. So technically superior to ProRes4444. Though you probably wont find any commercial application that supports it.</p>

<p>On another note, I don't think content delivery for cinema should be done in h264 nor ProRes 422 especially when you plan to encode to a lossless codec (JPEG2000/DCP) afterwards. It just doesn't make much sense to do so, all you loose is quality even though there is no need to do so, you only save space until you encode your DCP. There are other good lossless codecs, that offer very good compression, to use before encoding the DCP.</p>

<p>You could for example go directly to DCP, the Adobe Media Encoder offers export to 2k DCP since CC 2014, you can skip an encoding step and have a lossless codec with very good compression ratio.</p>

<p>Another great intermediate codec is <a href="http://www.videohelp.com/tools/Ut-Video-Codec-Suite" rel="nofollow">UtVideo</a> aswell as <a href="http://diracvideo.org/schrodinger-faq/" rel="nofollow">Schrödinger</a> (an implementation of the Dirac codec from BBC, its available through <a href="https://www.ffmpeg.org/download.html" rel="nofollow">FFmpeg</a>).</p>

<p>In the end though theory always differs from practice and if you don't deliver for nation wide cinemas with excellent projectors and what not, that quality difference in your delivery chain will be neglectable.
The only thing that could be pitfall is that h264 is very complex an by that always prone for some weird visual defects, so final inspection is always a necessity with h264.</p>
 9105: <blockquote>
  <p>Has anyone done or seen any tests comparing Apple ProRes 422 with high-bitrate H.264?</p>
</blockquote>

<p>No, but I can tell you that x264 can get as close to lossless as you want (or even mathematically lossless, with <code>-qp 0</code>).  x264 can produce h.264 streams in 4:2:0, 4:2:2, or 4:4:4 YUV colorspaces, at 8 or 10 bits per component.  (It can also do RGB, but unless you're doing lossless, you'll probably get better quality per bitrate from YUV.)</p>

<p>Decoder support for anything other than 4:2:0 8bit isn't as widespread.  (e.g. video cards have hardware decoders that can only accelerate 4:2:0 8bit).</p>

<p>Note that x264 has to be compiled for either 8 or 10bit output.  You need a separate build of libx264 (or a whole separate static build of ffmpeg) for 8bit and 10bit.  Either can handle any input bit depth you want to throw at it, but will always output the bit depth it was compiled for.</p>

<p>The <a href="https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles" rel="nofollow noreferrer">Hi444PP</a> h.264 profile supports up to 14bit depth for lossy or lossless operation, but x264 still only supports 8 or 10bit.  (Also 9bit, if you compile it with bit depth = 9, but there's really no point in doing that.  The speed hit comes as soon as you go beyond 8)</p>

<p>BTW, even if your input is 8bit and your final display is 8bit RGB, 10bit h.264 looks better for the same bitrate.  8bit h.264 is a speed vs. quality tradeoff.  (and obviously decoder compat.)  Google should find some threads on doom9, and a PDF from ateme, to back up this assertion.</p>

<p>To understand it, remember that lossy codecs aren't trying to reproduce all the input bits, just something that looks similar.  10bit allows more internal precision for motion prediction, and lets the encoder tweak the least-significant bits for better CABAC efficiency (trellis) without producing a visible difference.  So you get less banding of gradients.</p>

<blockquote>
  <p>We are wondering if it is possible to reach adequate quality with
  H.264. Say, with bitrates of 50-100mbps, and tweaking the GOP
  size/structure. (E.g., only using "I" frames.)</p>
</blockquote>

<p>Forcing more I frames, or I frames only, does NOT increase quality.  h.264 encoders "know" how their output differs from their input, and will use I macroblocks where they're a better choice.</p>

<p>Short GOPs are useful for seeking, or error recovery in realtime streaming use cases.  For video production, a short GOP lets you frame step backwards without having to decode very many frames from the previous keyframe.  So you can scrub with more precision.</p>

<p>If seeking isn't a concern at all, you could set keyint=1000, and then x264 could use almost as long a GOP as it wanted.  (Scenecut detection is on in every preset except ultrafast, so x264 will use an IDR (key frame) every time a scene cut makes an I frame a good idea anyway.)</p>

<blockquote>
  <p>Update 2: I did some more testing ... with Adobe Media Encoder, using
  MPEG2, and the "4:2:2" profile, the ProRes file went from 1,920MB to
  290MB! And I would say, subjectively, that is is 99% as good. This is
  remarkable. (With H264 I was down to 500-700MB)</p>
</blockquote>

<p>If you got results that good with MPEG2, you should easily get even smaller files with a decent h.264 encoder.  Your content probably compresses pretty well (low grain, some areas with lots of similarity).</p>

<p>If you have your input in a file that ffmpeg can read (i.e. almost any format),</p>

<pre><code>ffmpeg -i in.mp4 -c:a copy -c:v libx264 -preset medium -tune film -crf 10 -movflags +faststart out.mp4
</code></pre>

<p>CRF 10 is way beyond visually lossless.  ffmpeg defaults to the same colorspace as the input, if the output codec supports it.  If your input is 4:4:4, but you want to subsample your chroma, use something like:</p>

<pre><code>ffmpeg -i in ... -sws-flags lanczos+print_info -pix_fmt yuv422p  out
...
[swscaler @ 0x33be0c0] Lanczos scaler, from rgb24 to yuv422p using MMXEXT
</code></pre>

<blockquote>
  <p>Update 1: How would one "test" the difference technically? Or measure
  the color information?</p>
</blockquote>

<p>Measure the output color depth?  maybe with <a href="https://mediaarea.net/en/MediaInfo" rel="nofollow noreferrer">mediainfo</a>.</p>

<p>To compare quality of different encodes of the same source, measure the SSIM or PSNR of each encode relative to the source.  x264 can measure both those metrics during the encode process.  There are other tools for comparing two already-made video files, to measure those quality metrics, but I haven't used them.</p>

<p>For ffmpeg, use <code>-ssim 1  -psnr -tune ssim</code>.  (Don't use <code>-tune ssim</code> except when benchmarking that metric.  It defaults to enabling psychovisual optimizations that produce output that looks better to humans, but is mathematically less similar according to that metric.)</p>

<p>SSIM and PSNR are about the only thing you can use when you're working with bitrates that go way beyond visually transparent.  Google on these for more info.</p>

<p>To test losslessness, you can use ffmpeg's <code>-f framemd5</code> codec to make sure the h.264 decodes bit-identically to the input.  (see <a href="https://video.stackexchange.com/questions/7903/how-to-losslessly-encode-a-jpg-image-sequence-to-a-video-in-ffmpeg">this question</a> for an example.  Make sure you use the same -pix_fmt for all tests, because different decoders might pack the same data differently.)</p>

<p>Oh, just read Prof Sparkles' answer.  Didn't realize that you were eventually outputting to lossless.  You're just shooting yourself in the foot if you use any lossy codecs along the way.  The lossless codec will have to encode all the invisible blocking / ringing artifacts left by the lossy codecs, so you'll typically get bigger files from your lossless codec if you feed it input that's been through a lossy codec, instead of the original source.</p>

<p>So if you want to use h.264, use lossless.  (<code>ffmpeg -i in -preset ultrafast -qp 0 out</code>).  (slower presets give only a tiny compression improvement for lossless.  Never use ultrafast for anything except lossless, though.)</p>
