What about chroma in MPEG-2?

I had this nice MPEG encoder comparison planned, but Première pissed me off so much that I don't want to spend too much time anymore. Besides, there is no way to get my footage out of Première without losing supers and screwing up chroma. So, it's not fair to feed other encoders garbage and then blame them for screwing it up. So I'll stick to Première for this part.

One would think this progressive project would be best exported using a progressive MPEG stream. If it even matters. For all I know it's just a bit (or 'flag') being set to interlace or progressive. Even then, it would help other suites such as Avid Xpress to screw things up less. But since we can play the field(s) when exporting MPEG, we'll just check them all out.



It might look like it's not so bad as the RGB still frame output, but it is. It's just that because of chroma subsampling, the lines get smoothed out, leaving even less accurate color data. As you can see, chroma channels are compressed like hell already, but the non-original channels get extra messy.

I really fail to understand what exactly happens (so please, if you can elaborate, leave a message below), but you can clearly see Upper Field First export gives a way better result in chroma than the other two. Isn't Progressive and Upper Field First exactly the same, MPEG-wise, with the only difference being a separation-instruction for the decoder? I guess not.

Always output your progressive HDV project as upper field ANYWAY.

Première MPEG-2 compression guidelines

Multiplexer bitrate type

Since MiniDV bandwidth is 25Mbps, I always use that bitrate for archival purposes. If I want, I
can send those M2T's right back to MiniDV. For your entertainment, I've also compared a 25Mbit CBR
encoded MPEG-2 stream to a VBR one. Not that VBR will work on MiniDV tapes because it
requires an exact bandwidth, but to check which is better. Purely based on guesses, I've decided the
optimal VBR encode settings to mimic 25Mbps CBR bandwidth and final size are Minimal: 6,5 Mbps, Target:
25Mbps, Maximal: 30,5Mbps. My resulting Transport Streams were both approximately 500 MB. Note that for an MPEG Transport Stream (.m2t .ts), it actually does matter that you should tell your multiplexer to be in variable bitrate mode. Otherwise there will be a lot of redundancy in the file. You can test this by compressing (zipping, rarring) the file. If there's enough redundancy, the resulting zip will be notably smaller.

TMPGEnc's cool feature

Then I threw TMPGEnc in the comparison, because TMPGEnc has this nice feature to include supers, and people tell me TMPGEnc is good.

I like to compress my intermediate footage somewhat if I don't have to do compositing, because it makes my life easier. So it's nice that the authoring profile in the Adobe Media Encoder's MainConcept MPEG encoder allows for bitrates up to 100Mbps. With Quality and precision to maximum, I added them to the comparison.



For TMPGEnc, I recreated the same high(est) quality settings I used in Première. Why would TMPGEnc, a very renown encoder, screw this up? Maybe it's because Première outputs RGB with a silent crippled chroma channel? Or is TMPGEnc really not that good? What do you think?

There is no visible difference between the CBR and VBR 25Mbps MPEG. If I cannot see an improvement, I'd stick with CBR because it's more reliable (it works in TS streams on MiniDV). I did a difference match in Photoshop and saw the largest differences are 6 bits off. So the difference mask is clipped between [0 - 6], and really is not as impressive as it looks. But I put it there to show you where to find the main differences.

The high bitrate MPEGs are something else. Zipping them shows a LOT of redundancy. I really think my 25Mbps one is great quality (close to original source) and they are clean of redundancy. Where is that decision made? It makes me want to advise people:

Don't go above 25Mbps unless you figured it out.

Main thoughts

• Always export your HDV project with Upper Field First, even if it's Progressive. Don't use progressive.
  
• You cannot do the dance somewhere else by exporting uncompressed frames; they are tainted in both chroma errors and cropping (but rescaled to [235 - 255]) as well.
  
• Don't write secret messages in the super area; they will get clipped.
  
• In High Bitdepth Mode, it's possible to get your supers back but it's a bitch to work with. For your convenience, I've created a curves preset that does exactly that, tweaked for HV20 footage:
  RED SuperWhite HV20.zip
  
• Remember that even in High Bitdepth mode, 8 bits per channel output (i.e. MPEG) will not utilise values above 235 and you will suffer quality loss, but for an end-product probably mostly unnoticable.

Final thoughts

I haven't tried if, apart from also clipping supers, After Effect outputs MPEGs with the same chroma error, but Première and After Effects both contain the same MainConcept MPEG encoder. Results are prone to be the same. Then again, a single frame export shows the same problem and this bypasses MainConcept's encoder. The problem could be Première internal. Or in the HDV MPEG decoder. Then maybe After Effects uses that same decoder.

As for MPEG, weird things happen a lot with encoding. I wonder why the high bandwidth fail brutally. If you got a thought on that, please leave a comment.

Note that I have exaggerated U and V channels in almost every case. Their bandwith utilisation is so bad, differences are hard to see even in grayscale mode otherwise.

(June 9 2008) bugreport and feature request to Adobe:


Pagina's:
<< Vorige pagina (1) [1][2]