VideoHelp Forum
+ Reply to Thread
Page 6 of 6
FirstFirst ... 4 5 6
Results 151 to 160 of 160
Thread
  1. Originally Posted by rallymax View Post
    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).
    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


    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?
    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'), 
    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.709

    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?
    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 conversion

    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


    You wouldn't believe how many IF statements there are in the exporter to deal with this stuff.
    I don't even want to think about it... What a nightmare
    Quote Quote  
  2. Member
    Join Date
    Oct 2011
    Location
    UK
    Search PM
    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?
    Quote Quote  
  3. Member
    Join Date
    Sep 2008
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  
  4. Member
    Join Date
    Oct 2011
    Location
    UK
    Search PM
    Originally Posted by rallymax View Post
    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.
    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.
    That's not how he explained it to me, which is why I posted here. Of course he may have been wrong, I'll try to confirm it when I get time.

    (BTW, reading all this just made me implement the 709 YUV444 formats introduced in CS4.1 ).
    Quote Quote  
  5. Member
    Join Date
    Sep 2008
    Location
    United States
    Search Comp PM
    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
    Quote Quote  
  6. Member
    Join Date
    Oct 2011
    Location
    UK
    Search PM
    Originally Posted by rallymax View Post
    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.
    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).
    Quote Quote  
  7. Member
    Join Date
    Oct 2011
    Location
    UK
    Search PM
    Originally Posted by rallymax View Post
    btw: you should post stuff like this to the Premiere Pro SDK Forum http://forums.adobe.com/community/premiere/premierepro_current/sdk
    Right, I only posted here as I wanted to check if I'd missed something on this, and thought it might be helpful.
    Last edited by _gl; 30th Oct 2011 at 18:10.
    Quote Quote  
  8. Member
    Join Date
    Sep 2008
    Location
    United States
    Search Comp PM
    Originally Posted by _gl View Post
    Originally Posted by rallymax View Post
    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.
    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.
    In Exporters you get to choose on a per-instance basis so fortunately for me I can choose PrPixelFormat_* or PrPixelFormat_*_709.
    Quote Quote  
  9. Member
    Join Date
    Sep 2008
    Location
    United States
    Search Comp PM
    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
    Quote Quote  
  10. Double post. You should answer aedipuss's question posted in the 'Latest Video News section' before posting this news again.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!