Asking for BGRA before export is ok only if everything was done properly up to that point
Also there are situations where premiere might not be working in BGRA. e.g. DV-AVI cuts only project with no filters - it can smart render that and works in Y'CbCr
It's usually "safe" to assume HD footage uses Rec.709 , SD uses Rec.601. This applies to 99.9% of the cases. There are a few notable exceptions - some (very few) retail DVD's have metadata that say Rec.709 specifically, and Canon HD DSLR footage uses Rec.601 when you would expect it to use Rec.709I 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?
Code:// 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'),
In CS4, v210 gets treated as Y'CbCr, but RGB conversions get Rec.709 treatment (as they should for HD footage). So YUV filters that are applied before conversion are applied normally, but when the RGB conversion occurs, it gets the correct Rec709 treatment for HD. Once in RGB (I guess BRGA to be precise) , filters are applied normally . Because it's treated as Y'CbCr, you can access superbrights and the full dynamic range with YUV filters such as "fast color corrector" . This is not the case for many other formats which are clipped from the Rec.601 conversionWhat 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?
If you want to downsize to Rec.601 (e.g. for DVD) from v210 , just export normally. Since the import was done correctly (it was converted to RGB correctly), and RGB=>YUV gets Rec601 treatment for everything except exporting v210, the DVD looks fine. (Now whether or not you want to use AME for encoding is a different topic.... ). The problem is HD footage like blu-ray. In the majority of HD cases, you want to use Rec709 matrix for the RGB=>Y'CbCr conversion, not Rec601. Not only that, HD footage is already screwed up at the import stage (converted to RGB with Rec601) . In CS5 most HD imports are done correctly w.r.t Rec.709; I haven't tested it as thoroughly yet
I don't even want to think about it... What a nightmareYou wouldn't believe how many IF statements there are in the exporter to deal with this stuff.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 151 to 160 of 160
Thread
-
-
Hi guys, I just stumbled on this thread doing a bit of research for my in-progress AE plugin.
I asked Zac Lam @ Adobe a while ago if BT709 video was treated correctly, seeing how plugins like mine that request 4:4:4 YUV data always get BT601 (at least last time I checked, which was probably CS4). He assured me that the 709 YUV data is converted to 601 before being handed to plugins (and presumably converted back at the end of the pipe), ie. it's not incorrectly handled.
Now I haven't actually verified this yet, are you sure they don't do that? -
Colorspace is only relavent if you're working in BGR(A). YUV is (/should be) independent of colorspace matrix. So, if you're requesting BGRA_4444_32f you _should_ be fine. Now if any plugin/importer PRIOR to your plugin is BGR(A) then you'll have a problem.
Unfortunately there is no API to find out the purity of the pipeline prior to your plug-in so you can end up getting BT.601 even though the Importer is supplying BT.709. The question for Zac is whether there is the appropriate colorspace translation whenever there is a BGR(A) to YUV(A) and vice versa conversion. My understanding is that it is always a BT.601 translation. So... if you are editing in BT.709 you HAVE to use CS5 and HAVE to use Effects and Transitions that support YUV mode as indicated by the YUV jigsaw piece icon. -
You misunderstood me. My plugin requests YUV 444 formats. As some of my render paths also temporarily convert that to RGB (it's a complex multi-effect plugin), I need to know the assumed colour space of that YUV data.
CS3 assumed that any YUV444 input is in BT601, from the CS3 Premiere docs:
"All pixel formats use the ITU-R Recommendation BT.601 color space unless noted."
I asked Zac what happens when the input footage is in BT709? He confirmed that Premiere will convert BT709 YUV into BT601 YUV _before_ handing it to plugins, so that they always actually get BT601 (like the docs promise). That suggests a conversion to RGB via BT709, and back to YUV via BT601.
So... if you are editing in BT.709 you HAVE to use CS5 and HAVE to use Effects and Transitions that support YUV mode as indicated by the YUV jigsaw piece icon.
(BTW, reading all this just made me implement the 709 YUV444 formats introduced in CS4.1 ). -
Ah, now I see.
You're probably right on all counts.
That explains why formats like PrPixelFormat_VUYA_4444_*_709 where invented - so that pre-your-plugin could be matrixed to YUV 601 or 709 as needed.
It still begs the question - do you ask for PrPixelFormat_VUYA_4444_32f or PrPixelFormat_VUYA_4444_32f_709? You could choose based on height>=720 but that's still only a guess albeit quite accurate. I guess if you ask for PrPixelFormat_BGRA_4444_32f it would be in the native matrix of the pipeline. Now that's definitely a question for Zac to confirm.
btw: you should post stuff like this to the Premiere Pro SDK Forum http://forums.adobe.com/community/premiere/premierepro_current/sdk -
You don't really get to request a format at run-time, you only get to register which ones you handle, and Premiere picks the most suitable/efficient based on the input, and in some way on what each part of the pipe can handle.
For example, I tried supporting both 601 and 709 444 YUV 8bit formats - in that case my effect (as the only one) with AVCHD video gets 601 which surprised me. If I only support 709, I actually get it. I suspect other internal parts of Premiere (on CS4 at least) still prefer 601, so there's less internal conversion involved.
It's all pretty much voodoo, I wouldn't be shocked if there were some bugs, and if behaviour differs in different versions or even point releases. Writing for Adobe apps is fun (well, they are complex). -
Last edited by _gl; 30th Oct 2011 at 17:10.
-
-
hi all....
It's finished!
ok ok it took, what, 2-3 years but it's now product.
have a look at www.x264pro.com -
Double post. You should answer aedipuss's question posted in the 'Latest Video News section' before posting this news again.
Similar Threads
-
How to have Adobe Flash Encoder CS3 accept x264 AVIs
By Gargalash in forum Video ConversionReplies: 10Last Post: 23rd Aug 2010, 22:19 -
Adobe Premiere H.264 Encoding
By Priapism in forum Camcorders (DV/HDV/AVCHD/HD)Replies: 70Last Post: 27th Aug 2009, 02:24 -
Adobe Premiere 1.5: Adobe Media Encoder: Frame size and scaling?
By vid83 in forum EditingReplies: 2Last Post: 30th Nov 2008, 03:17 -
Raw .264 as input for x264-encoder
By e_i_s_t in forum Blu-ray RippingReplies: 0Last Post: 11th Nov 2008, 04:27 -
MainConcept H.264 Encoder Error
By cowboysroy31 in forum Newbie / General discussionsReplies: 0Last Post: 22nd Jun 2007, 19:06