Adobe Premiere - MainConcept's H.264 vs x264 open source encoder

[poisondeathray]

I wonder if that interlaced chroma bug affects other file types? Like progressive MPEG2 etc... I'll do some tests later. I suspect it's only progressive h.264 decoding

I already checked if it was container specific and tried .mp4 instead of transport stream, but it still occurred, and I tried other sequence settings as well (including custom desktop settings)

[jagabo]

what about the chroma. what is its range for 601 and 709?

U and V should range from 16 to 240. I don't think it's necessary to clamp them but your conversion matrix should automatically scale to that range.

[jagabo]

I wonder if that interlaced chroma bug affects other file types?

I don't know about PP but VirtualDub doesn't handle interlaced YV12 properly. It treats the interlaced chroma channels as progressive. I spoke to the Avery Lee about this once and his position was that the fourcc YV12 is never interlaced and YV12-like video with interlaced chroma channels should use a different fourcc. Unfortunately, his insistence on being technically correct means you have to convert to interlaced YUY2 before feeding any interlaced YV12 source to VirtualDub.

VirtualDubMod has the opposite problem. Its internal MPEG 2 decdoer treats all YV12 as interlaced. So feeding it progressive MPEG 2 causes problems.

[rallymax]

so it turns out that Adobe has functions to ask what the white and the black are of each format.

edit ...

U and V should range from 16 to 240. I don't think it's necessary to clamp them but your conversion matrix should automatically scale to that range.

very interesting coz that means that Adobe's U|V convert is wrong.

FourCC  PrPixelFormat Bits  Format Additional Details WHITE then BLACK
              / Channel 
bgra  BGRA_4444_8u    8     BGRA Formerly BGRA32 255,255,255 - 0,0,0
vuya  VUYA_4444_8u    8     VUYA Formerly VUYA32  128,128,235 - 128,128,16

yuy2  YUYV_422_8u_601 8   4:2:2 YUY2           235,0,235,0 - 16,128,16,128
yuy3  YUYV_422_8u_709 8   4:2:2 YUY2 Rec. 709  235,0,235,0 - 16,128,16,128

yv12  YUV_420_MPEG2_FRAME_ 
      PICTURE_PLANAR_8u         4:2:0 YUV For MPEG-2 progressive ???????????
yvi2  YUV_420_MPEG2_FIELD_ 
      PICTURE_PLANAR_8u         4:2:0 YUV For MPEG-2 interlaced ???????????

Note that the planar ones return an error so they are not supported for query.
So... it looks like all RGB is 0-255 and all YUV combos are y=16..235 and u|v = 0..128
I which case it's an easy convert if the source is RGB and a passthrough if YUV

[rallymax]

....his insistence on being technically correct means you have to convert to interlaced YUY2 before feeding any interlaced YV12 source to VirtualDub.

According to the Adobe docs I just used interlaced is "yvi2"

[jagabo]

But nothing else seems to support "yvi2".

Everything else I've seen before says U and V range from 16 to 240. But I'm not absolutely sure it's correct.

[rallymax]

from wikipedia http://en.wikipedia.org/wiki/YCbCr
When representing the signals in digital form, the results are scaled and rounded, and offsets are typically added. For example, the scaling and offset applied to the Y' component per specification (e.g. MPEG-2[1]) results in the value of 16 for black and the value of 235 for white when using an 8-bit representation. The standard has 8-bit digitized versions of Cb and Cr scaled to a different range of 16 to 240. Consequently, rescaling by the fraction (235-16)/(240-16) = 219/224 is sometimes required when doing color matrixing or processing in YCbCr space, resulting in quantization distortions when the subsequent processing is not performed using higher bit depths.

[jagabo]

You can look at any YUV video and see there is UV data outside the 0-128 range.
https://forum.videohelp.com/topic378610.html#2043737

[rallymax]

chalk that up to another Adobe bug

[rallymax]

so it turns out that Adobe has functions to ask what the white and the black are of each format.

edit ...

U and V should range from 16 to 240. I don't think it's necessary to clamp them but your conversion matrix should automatically scale to that range.

very interesting coz that means that Adobe's U|V convert is wrong.

FourCC  PrPixelFormat Bits  Format Additional Details WHITE then BLACK
              / Channel 
bgra  BGRA_4444_8u    8     BGRA Formerly BGRA32 255,255,255 - 0,0,0
vuya  VUYA_4444_8u    8     VUYA Formerly VUYA32  128,128,235 - 128,128,16
 
yuy2  YUYV_422_8u_601 8   4:2:2 YUY2           235,0,235,0 - 16,128,16,128
yuy3  YUYV_422_8u_709 8   4:2:2 YUY2 Rec. 709  235,0,235,0 - 16,128,16,128
 
yv12  YUV_420_MPEG2_FRAME_ 
      PICTURE_PLANAR_8u         4:2:0 YUV For MPEG-2 progressive ???????????
yvi2  YUV_420_MPEG2_FIELD_ 
      PICTURE_PLANAR_8u         4:2:0 YUV For MPEG-2 interlaced ???????????

Note that the planar ones return an error so they are not supported for query.
So... it looks like all RGB is 0-255 and all YUV combos are y=16..235 and u|v = 0..128
I which case it's an easy convert if the source is RGB and a passthrough if YUV

BTW, The Adobe support engineer confirmed that the returned values for U and V in the functions above is broken so the 0..128 can be ignored.

[rallymax]

OMG it's been a year since I was on this.
I'm at a point now where I really want this working so I'll probably spend a bit of time on it in the coming months.
I have since moved to CS4 so I'll be porting the Custom Compiler (which only works on Premiere Pro CS3 and earlier) to the new Adobe Media Encoder (AME) framework so that it can be used by Premiere, After Effects, Encore and standalone AME. I _should_ be able to recompile for 64bit too so that it works with CS5.

[rallymax]

Hi guys,
can someone explain the difference between yuy3 and yv17?
which of the following FourCC types do I want for feeding into x264 (which is YUV 422 planar)
how about for 10bit support? (do I even want to use 10bit input to make bluray compatible .264 files?)

PrPixelFormat_YUYV_422_8u_601 = MAKE_PIXEL_FORMAT_FOURCC('y', 'u', 'y', '2'), // 8 bit 422 YUY2 601 colorspace
PrPixelFormat_YUYV_422_8u_709 = MAKE_PIXEL_FORMAT_FOURCC('y', 'u', 'y', '3'), // 8 bit 422 YUY2 709 colorspace
PrPixelFormat_UYVY_422_8u_601 = MAKE_PIXEL_FORMAT_FOURCC('u', 'y', 'v', 'y'), // 8 bit 422 UYVY 601 colorspace
PrPixelFormat_UYVY_422_8u_709 = MAKE_PIXEL_FORMAT_FOURCC('u', 'y', 'v', '7'), // 8 bit 422 UYVY 709 colorspace
PrPixelFormat_V210_422_10u_601 = MAKE_PIXEL_FORMAT_FOURCC('v', '2', '1', '0'), // packed uncompressed 10 bit 422 YUV aka V210 601 colorspace
PrPixelFormat_V210_422_10u_709 = MAKE_PIXEL_FORMAT_FOURCC('v', '2', '1', '1'), // packed uncompressed 10 bit 422 YUV aka V210 709 colorspace
// Planar formats
PrPixelFormat_YUV_420_MPEG2_FRAME_PICTURE_PLANAR_8 u_601 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', '1', '2'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2)
PrPixelFormat_YUV_420_MPEG2_FIELD_PICTURE_PLANAR_8 u_601 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', 'i', '2'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2)
PrPixelFormat_YUV_420_MPEG2_FRAME_PICTURE_PLANAR_8 u_709 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', '1', '7'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2) 709 colorspace
PrPixelFormat_YUV_420_MPEG2_FIELD_PICTURE_PLANAR_8 u_709 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', 'i', '7'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2) 709 colorspace

[poisondeathray]

Hi guys,
can someone explain the difference between yuy3 and yv17?
which of the following FourCC types do I want for feeding into x264 (which is YUV 422 planar)
how about for 10bit support? (do I even want to use 10bit input to make bluray compatible .264 files?)

PrPixelFormat_YUYV_422_8u_601 = MAKE_PIXEL_FORMAT_FOURCC('y', 'u', 'y', '2'), // 8 bit 422 YUY2 601 colorspace
PrPixelFormat_YUYV_422_8u_709 = MAKE_PIXEL_FORMAT_FOURCC('y', 'u', 'y', '3'), // 8 bit 422 YUY2 709 colorspace
PrPixelFormat_UYVY_422_8u_601 = MAKE_PIXEL_FORMAT_FOURCC('u', 'y', 'v', 'y'), // 8 bit 422 UYVY 601 colorspace
PrPixelFormat_UYVY_422_8u_709 = MAKE_PIXEL_FORMAT_FOURCC('u', 'y', 'v', '7'), // 8 bit 422 UYVY 709 colorspace
PrPixelFormat_V210_422_10u_601 = MAKE_PIXEL_FORMAT_FOURCC('v', '2', '1', '0'), // packed uncompressed 10 bit 422 YUV aka V210 601 colorspace
PrPixelFormat_V210_422_10u_709 = MAKE_PIXEL_FORMAT_FOURCC('v', '2', '1', '1'), // packed uncompressed 10 bit 422 YUV aka V210 709 colorspace
// Planar formats
PrPixelFormat_YUV_420_MPEG2_FRAME_PICTURE_PLANAR_8 u_601 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', '1', '2'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2)
PrPixelFormat_YUV_420_MPEG2_FIELD_PICTURE_PLANAR_8 u_601 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', 'i', '2'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2)
PrPixelFormat_YUV_420_MPEG2_FRAME_PICTURE_PLANAR_8 u_709 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', '1', '7'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2) 709 colorspace
PrPixelFormat_YUV_420_MPEG2_FIELD_PICTURE_PLANAR_8 u_709 = MAKE_PIXEL_FORMAT_FOURCC('y', 'v', 'i', '7'), // YUV with 2x2 chroma subsampling. Planar. (for MPEG-2) 709 colorspace

The difference is the chroma subsampling 4:2:2 vs. 4:2:0

If by "YUY3", you mean the 2nd entry ? this is 8bit 4:2:2 , not compatible with blu-ray

"YV17" the 2nd last entry? this is 8bit 4:2:0, this is the one you want for progressive, the last one is the one for interlaced. => these are the ones to use

In 4:2:0 subsampling, it's very important to distingush between interlaced and progressive sampling, because chroma is stretched across two luma lines in the same field with interlaced.




10-bit isn't compatible with blu-ray either.

HD uses BT.709 for the matrix coefficients so the two last entries are the ones you want , SD usually uses BT.601

[rallymax]

thx.
(can't believe I didn't see the 422 vs 420 - blinded by looking at it too long I guess)
x264 AME output is close!

[rallymax]

HD uses BT.709 for the matrix coefficients so the two last entries are the ones you want , SD usually uses BT.601

I found a table somewhere (i think in a thread here actually) that has all the sd and hd resolutions and fps and thier 601 or 709 types. I'm hoping to make a lookup table based on that info.

[poisondeathray]

Adobe CS4 has a bug according to my tests - all RGB<=>Y'CbCr conversions (including HD) are done using BT.601 . So HD content isn't handled properly

The only workaround is to use v210 (uncompressed Y'CbCr 10-bit 4:2:2)

Even if your plugin handles the RGB=> YV12 conversion as BT.709 properly , the error is upstream - when imported the video gets converted from YV12=>RGB using BT.601

[rallymax]

...or take responsibility for the RGB to Y'CbCr. Since FFmpeg (libavscale) has that already I might as well continue to ask for RGB like I did with my project when it was CS3 (and a premiere exporter only) - I'm in the process of moving it to the CS4 sdk (which now has these planar types and much more 709) and moving it to the new AME "Exporter" plugin type since, a: Compilers are now deprecated and b: AME Exporters work for Premiere, AE, Soundbooth and Encore.
I think I'll start by trusting Adobe and change the request to RGB if it's wrong (as we both suspect it is based thread discussions we had about a year ago).

[poisondeathray]

...or take responsibility for the RGB to Y'CbCr. Since FFmpeg (libavscale) has that already I might as well continue to ask for RGB like I did with my project when it was CS3 (and a premiere exporter only) - I'm in the process of moving it to the CS4 sdk (which now has these planar types and much more 709) and moving it to the new AME "Exporter" plugin type since, a: Compilers are now deprecated and b: AME Exporters work for Premiere, AE, Soundbooth and Encore.
I think I'll start by trusting Adobe and change the request to RGB if it's wrong (as we both suspect it is based thread discussions we had about a year ago).

If you import a RGB format separately & properly converted , then you're safe, but if you did ffmpeg conversion to another Y'CbCr format for import (except v210) then you're out of luck

[rallymax]

Hi all,
much has progressed in the last 7 or so months.
A quick question to poisondeathray.
If I get RGB 4:4:4 from Adobe and then force the colorspace setting of x264 will it be correct?
As you mentioned many months ago Premiere's RGB to YUV conversions are "questionable" so I'm thinking of backing out my code back to RGBA 4:4:4:4 and letting lavf do the conversion with the approriate colorspace flag set.
Will it screw up the 709?
thx.

[poisondeathray]

If I get RGB 4:4:4 from Adobe and then force the colorspace setting of x264 will it be correct?
As you mentioned many months ago Premiere's RGB to YUV conversions are "questionable" so I'm thinking of backing out my code back to RGBA 4:4:4:4 and letting lavf do the conversion with the approriate colorspace flag set.
Will it screw up the 709?

what do you mean by "colorspace setting" ? how are you piping to x264 ?

if you mean --colormatrix flag in x264 , this is only VUI information, it doesn't change the actual data or affect RGB=>YUV conversions . I think RGB=>YUV will use Rec601 by default if you feed it directly into x264

I use avisynth to do the conversion RGB=>YUV, specifying Rec709 , so it pipes the correct YUV data into x264

[BigPines]

What is the current status of this project? I am very interested in it.

Mike

[rallymax]

It's really close to release.
I'm hoping to have it out before end of the year.

I have worked out workarounds of all the Adobe bugs with respect to Premiere screwing up colorspace handling.
It's technically finished (except a couple of little bugs with the GUI) - it's just not a "product" at the moment.
After fixing those little querks I'll finish the Installer program.
One of the bigs things that is holding us release is the creation of an eCommerce system.
If anyone here is interested in trialing it without downloading it and registering it automatically drop me a private message and I'll get you an early release as soon as I have the installer finished.

v1.0 will have
- Support for CS4 (32bit) & CS5 (64bit) Premiere Pro
- x264 with bluray legal output (only).
- Future 1.x updates will include other forms of H.264 - ie advanced manuipulation of settings will be turned on (it's turned off in code right now)
- mono,stereo& 5.1 PCM (.wav) file output
- if I get any interest I'll break the channels out into individual files (eg filename-L.wav, filename-C.wav, filename-R.wav, filename-RL.wav, etc...)
- Encore has an AC3 conversion licensed into it so you can get your AC3 from the WAV that way.
- if there is interest in Dolby AC3, DolbyHD, DTS or DTS-HD drop me a note and I'll look into that too.

- Future 1.x updates will include some tweaks so that Encore (CS5 only) can use it as a transcoder too.

Another product is slated behind this one to make an AVC Intra 4:4:4 digital intermediate/long term storage solution as well if people are interested. I am for archiving my own stuff.

[BigPines]

Will this work for OS X? I would be willing to test for you if you need it.

Mike

[rallymax]

it is possible that I could do it for OS-X. No plans yet unless I hear interest from at least 20 people.

[BigPines]

Thanks for your response.

I'm assuming this would just be a standard plug-in right? I think you can just drop the Windows version in the correct OS X directory -
/Library/Application Support/Adobe/Common/Plug-ins/<version>/MediaCore - and you are in business. I have done it in the past but I don't know if the developer had to do anything special to make the plug-in OS X compatible.

Again, I can test for you if you like. I am also a .net developer but have limited experience with OS X development so I may be able to contribute if you don't feel like doing it yourself.

Mike

[rallymax]

Adobe CS4 has a bug according to my tests - all RGB<=>Y'CbCr conversions (including HD) are done using BT.601 . So HD content isn't handled properly

The only workaround is to use v210 (uncompressed Y'CbCr 10-bit 4:2:2)

You mean as source footage or as the output format? If src is that because they got it right for Y'CbCr 10bit 4:2:2? I have a question into Adobe at the moment about the workflow. - for example, what happens if an effect or transition is BGRA only and the incoming src is YUV? - my guess is that it always uses BT.601 colorspace conversion and hoses it.

Even if your plugin handles the RGB=> YV12 conversion as BT.709 properly , the error is upstream - when imported the video gets converted from YV12=>RGB using BT.601

yup - I confirmed this a couple of days ago. I dropped an RGB png file of the Belle Nuit test in as a sequence and exported it with the colorspace set as BT.709. I asked Premiere for the footage as BGRA (it theoretically was RGB all the way through so no colorspace conversions) and did my own RGB->YUV BT.709 conversion. Importing the .264 stream back in showed that the .264 decoded i420 stream was converted as BT.601 and thus all blown out. (YCrCb Reference Monitor confirmed the bad convert too)

I'm starting to think that I need to make an AVC Importer so that I can override Premiere's shipped Main Concept .264 Importer and handle it properly myself.

[poisondeathray]

Adobe CS4 has a bug according to my tests - all RGB<=>Y'CbCr conversions (including HD) are done using BT.601 . So HD content isn't handled properly

The only workaround is to use v210 (uncompressed Y'CbCr 10-bit 4:2:2)

You mean as source footage or as the output format? If src is that because they got it right for Y'CbCr 10bit 4:2:2? I have a question into Adobe at the moment about the workflow. - for example, what happens if an effect or transition is BGRA only and the incoming src is YUV? - my guess is that it always uses BT.601 colorspace conversion and hoses it.

For CS4, usually both ways, except for v210. v210 gets special treatment as Rec.709, but exporting anything but v210 out gets Rec.601 treatment for RGB back to Y'CbCr

This only occurs where there a colorspace conversion . For example a DV-AVI cuts only project will work in Y'CbCr space internally until you add a filter. Some filters can work in Y'CbCr, like fast color corrector. In CS5 there are "YUV" labelled filters

Even if your plugin handles the RGB=> YV12 conversion as BT.709 properly , the error is upstream - when imported the video gets converted from YV12=>RGB using BT.601

yup - I confirmed this a couple of days ago. I dropped an RGB png file of the Belle Nuit test in as a sequence and exported it with the colorspave set as BT.709. I asked Premiere for the footage as BGRA (it theoretically was RGB all the way through so no colorspace conversions) and did my own RGB->YUV BT.709 conversion. Importing the .264 stream back in showed that the .264 decoded i420 stream was converted as BT.601 and thus all blown out. (YCrCb Reference Monitor confirmed the bad convert too)

When using the belle nuit chart, you should do the converstion to Full range 709 . So RGB 0-255 => YUV 0-255 insetad of RGB 0-255 => YUV 16-235. Otherwise YOUR conversion will clip the data, not premiere's fault

If you import a full range Y'CbCr video into premiere , and it TREATS it as Y'CbCr - then you can tell if it's clipping or not, and if you have access to superbrights and superdarks Y' 0-15 and 235-255

This is where the "YUV" filters come into play. They are applied BEFORE the RGB conversion. So you can salvage that data before premiere converts to RGB. In CS4, "fast color corrector" can do this, ONLY IF premiere "treats" that format as Y'CbCr. Many formats are NOT treated as Y'CbCr by premiere. For example, lagarith, huffyuv, ut video codec, even cineform. So even from a Y'CbCr "lossless" format, they are not lossless in premiere because of the colorspace conversion. The only truly lossless intermediate is v210 , and 8-bit UYVY . Other Y'CbCr uncompressed and "lossless" formats are not treated by premiere as Y'CbCr and thus incur the conversion.

Most native camera formats are treated as Y'CbCr. So HDV, DV-AVI, AVCHD, etc...

I'm starting to think that I need to make an AVC Importer so that I can override Premiere's shipped Main Concept .264 Importer and handle it properly myself.

It's improved in CS5 and 5.5. Only CS4 has it botched that badly. There is still chroma upsampling issues, however (though not as bad)

[rallymax]

Thanks for your response.

I'm assuming this would just be a standard plug-in right? I think you can just drop the Windows version in the correct OS X directory -
/Library/Application Support/Adobe/Common/Plug-ins/<version>/MediaCore - and you are in business. I have done it in the past but I don't know if the developer had to do anything special to make the plug-in OS X compatible.

Again, I can test for you if you like. I am also a .net developer but have limited experience with OS X development so I may be able to contribute if you don't feel like doing it yourself.

Mike

It doesn't work like that. A Premiere Plugin from Windows won't work on Mac. A Windows PRM is a PECOFF DLL, a Mac PRM is a ELF Shared Object ".so". If a plugin did work then the developer did some secret source to pull it off. Codewise the Premiere API is the same but the OS APIs are not. I would have to get a Mac, get Premiere CS4 and CS5 for Mac, and then go through and mimic all the non c-runtime Windows calls I made with the equivalent OS-X call. The Windows version has taken 2+ yrs on and off so far so unless there is some serious interest I'm not going to start on Mac. It hasn't been anywhere near as easy as I expected - If I'd known I probably wouldn't have started. It's reasonably easy to get frames out of Premiere but getting the colorspace conversions right and a stack of other Adobe bug workarounds so that it works on pre CS5.5 versions has been A LOT of code. I don't know if those Adobe bugs are exactly the same on the Mac version so it could potentially be dozens of new problems.
Right now I'd rather work on AVC Intra 4:4:4 digital intermediate support to be able to archive all my video.

[rallymax]

Adobe CS4 has a bug according to my tests - all RGB<=>Y'CbCr conversions (including HD) are done using BT.601 . So HD content isn't handled properly

The only workaround is to use v210 (uncompressed Y'CbCr 10-bit 4:2:2)

You mean as source footage or as the output format? If src is that because they got it right for Y'CbCr 10bit 4:2:2? I have a question into Adobe at the moment about the workflow. - for example, what happens if an effect or transition is BGRA only and the incoming src is YUV? - my guess is that it always uses BT.601 colorspace conversion and hoses it.

For CS4, usually both ways, except for v210. v210 gets special treatment as Rec.709, but exporting anything but v210 out gets Rec.601 treatment for RGB back to Y'CbCr

That's why I was staying away from asking for YUV frames - I was hoping that BGRA was dumb all the way through. I was wrong though because I didn't count the scenario of there being a YUV to BGRA conversion somewhere along the pipeline (Importer or Filter).

This only occurs where there a colorspace conversion . For example a DV-AVI cuts only project will work in Y'CbCr space internally until you add a filter. Some filters can work in Y'CbCr, like fast color corrector. In CS5 there are "YUV" labelled filters

I guess that means that you have to provide a GUI button to ask whether to treat the sequence as BT.601 or BT.709 since there is no way to know programmatically. It begs the question - what does it really mean to the pipeline workflow when you get your frames as v210 as BT.601 or BT.709? Is it only in the last export step or does it change YUV->RGB and RGB->YUV matrix lookups in and out of non-YUV filters?

// packed uncompressed 10 bit 422 YUV aka V210 601 colorspace
PrPixelFormat_V210_422_10u_601 =
                     MAKE_PIXEL_FORMAT_FOURCC('v', '2', '1', '0'), 
// packed uncompressed 10 bit 422 YUV aka V210 709 colorspace
PrPixelFormat_V210_422_10u_709 =
                     MAKE_PIXEL_FORMAT_FOURCC('v', '2', '1', '1'), 

What happens with v210 source when BGRA filters are used? What happens if the source is HD BT.709 but you want to downsize it to Standard Def BT.601? What if it has no filters other than scaling (ie YUV pipeline only)? What about if you use a non YUV filter?

I don't know if I can trust those fetch modes. I guess tests will tell. Granted knowledge of the use of YUV filters in CS5 is easier because of the YUV labels but you don't know in CS4. (Much more of this frustration and I'll make the Exporter CS5 only).
You wouldn't believe how many IF statements there are in the exporter to deal with this stuff.

[rallymax]

It's improved in CS5 and 5.5. Only CS4 has it botched that badly. There is still chroma upsampling issues, however (though not as bad)

Is that the failure to handle interlaced properly? I seem to recall from a post years ago that there is a problem there.