VideoHelp Forum
+ Reply to Thread
Page 3 of 7
FirstFirst 1 2 3 4 5 ... LastLast
Results 61 to 90 of 200
Thread
  1. Yes, I put the adjustment layer and level with gamma of 4 or 5 and no visible differences. I also tried clearing the Media Cache in PP, deleting everything out of the project, closing, timelines from scratch, no luck, I can still see the differences. So I am going to chalk this up to a CS6 bug that must not be present in CC, since that is what you are using.

    To be certain, I scoped up the UYVY_INPUT and ffmpeg AVIs in two other applications and could see no differences, although I trust the top scopes more than the bottom scopes. The scope on the left is the INPUT and the right is the ffmpeg.

    Click image for larger version

Name:	SxS1.png
Views:	159
Size:	151.1 KB
ID:	35801

    Click image for larger version

Name:	SxS2.png
Views:	236
Size:	71.8 KB
ID:	35802
    Quote Quote  
  2. Do you have the file interpretation setup correctly for ffmpeg.avi ? Sometimes PP will "guess" something wrong. It might "think" it's TFF interlaced for example. Just check to make sure it looks right in the file interpretation dialog , progressive, square pixels etc...

    If you've used UYVY_Input and exported using UYVY, then re-imported that export, does it still match (ie. all Adobe) ? If yes, then there is something different in the ffmpeg UYVY version that your version doesn't "like" . Maybe metadata or something. It doesn't make sense that your AE version "sees" them as the same ; if some codec or something installed was interfering, it should affect both. UYVY is the "special sauce" for all windows NLE's in terms of 8bit 422 - it should get that treatment across the board
    Quote Quote  


  3. I AM IN AWE POISONDEATHRAY!!!!! If this site had upvotes or thanks for profiles, I would overload yours with them.

    I went to bed last night dejected and convinced my install was broke, or worse, CS6 was broke. Woke up this morning, still convinced there was no solution. Then I saw your post. I thought, hmm, doubtful, nothing else has worked. Let me check. I clicked on the file interpretation dialog for the ffmpeg.avi. This is what I saw:

    Click image for larger version

Name:	interp.png
Views:	277
Size:	32.7 KB
ID:	35805

    Guess what happened when I changed field order to progressive? You guessed it! All the problems went away!!! I had to change it back and forth several times just to make sure I wasn't dreaming.

    All Hail Poisondeathray! The King of Video!

    Click image for larger version

Name:	celebrate.gif
Views:	259
Size:	2.35 MB
ID:	35806

    Quote Quote  
  4. Maybe something about the metadata written to the AVI is confusing some versions of premiere and vegas in current versions of ffmpeg. Someone had the same problem in vegas the other day with fraps videos. And why wouldn't AE from the same Adobe versions be "fooled" as well?

    The only thing that is obviously different is ODML AVI 2.0 vs. AVI 1.0 (e.g if you look in gspot) , but sometimes software will use AVI 2.0 automatically if the file is >2GB. ffmpeg has -use_odml switch, but it's "on" by default and using it makes no difference to what gspot says . I don't see any other relevant AVI muxer options in ffmpeg --fullhelp

    Can you try this one and see if it's automatically detected as progressive ? This one uses -vf setfield=prog
    Image Attached Files
    Quote Quote  
  5. I don't know why PP doesn't interpret ffmpeg UYVY avi's correctly. Possibly something is embedded in the code on how to handle what might be considered a "legacy" format for video. IOW, the defaults were never updated to include progressive video. The 2 GB file size should not have been an issue because none of my files were ever that large.

    I downloaded v3 above and tried it and the same result: PP interprets the footage as Upper Field First for field order. So setfield=prog doesn't do the trick.

    What I find interesting is that PP CC interprets footage correctly. That leads me to believe it is a bug on Adobe's end. I need to also check that I have the latest update to CS6.
    Quote Quote  
  6. What I meant was Adobe used AVI 2.0 , even for the 1 frame test. So if you tried ffmpeg to generate a >2GB file, it should switch over to AVI 2.0 (not sure if it does, but some software does). Or you can direct stream copy in vdub and it will re-wrap it to AVI 2.0 . Just to test if that is the culprit


    Also maybe try uninstalling Drastic codecs , in case that is interfering somehow (do 1 thing at time, test AVI 2.0 first)
    Quote Quote  
  7. OK, I think I am starting to catch up to what you are saying. Every post you write is loaded with expertise that takes me a while to decipher .

    Here is what I have done so far:

    1. Checked my version of CS6: 6.0.5 (looks like the latest)
    2. Uninstalled Drastic and reran dxdiag per their instructions, everything is OK
    3. Uninstalled a couple of other codecs that I was testing (GV, Dirac). FWIW, I only have QT and Utvideo installed (this is a fresh rebuild that I recently did to get rid of stuff like K-Lite). And the only players I have installed are WMP, QT, and VLC.
    4. ffmpegv3 in gspot says AVI v1.0

    At this point still defaulting to Upper Field First.

    5. Direct stream copy of v3 in vdub (oops, I did it in the wrong order you suggested, sorry)
    6. gspot says it is now AVI v2.0 (didn't know that little trick existed, thanks btw )

    PP still defaulting to Upper Field First
    Quote Quote  
  8. In CC, the ffmpeg generated AVI's actually say "fields (unknown dominance)" , but the Adobe one says "progressive" . But it doesn't automatically deinterlace and degrade the ffmpeg version in CC. There is something in the Adobe generated one that automatically signals progressive. Not sure what it is, I looked with a riff chunk editor but don't see anything that stands out. Maybe jagabo knows

    You can still interpret as a workaround, or just use AME ; but it would be nice to know what is causing the difference
    Quote Quote  
  9. That is very interesting. I was under the impression CC was interpreting it as progressive.

    Yes, maybe jagabo can provide some insight.

    Also, is this a doom9 worthy question?
    Quote Quote  
  10. It's been asked before both here and there before: There is no way to signal interlace/progressive in the AVI container or specs itself. That information must be contained elsewhere. Jagabo is probably the most knowledgable about AVI structure , RIFF, hex editor stuff IMO .
    Quote Quote  
  11. OK, then let's wait on a response from jagabo. Until then, I am fine with double-checking the interpret footage dialog.

    One final question though. Now that we have defined lossless pathways for UYVY footage through both PP and ffmpeg, do you know one for vdub? I have been fiddling with it this morning with no luck. But I am far from a vdub ninja.
    Quote Quote  
  12. For vdub ? direct stream copy

    But it depends what you do in PP or vdub . The operations you do might cause them to do other manipulations

    The big take home message about UYVY, v210, I420 in Windows NLE's is they are the ones that are actually treated as uncompressed YUV. The other "uncompressed" variants have other bad things happen to them upon import. The biggest one is clipping superbrights/darks. You export something like YUY2 from vdub expecting it to be uncompressed YUV422 , but it gets converted to RGB in most NLE's upon import
    Quote Quote  
  13. vdub direct stream copy is all well and good, but that is no different than just a copy/paste in explorer imho (although using that to rewrap AVI 1.0 in AVI 2.0 is a pretty neat trick). What I was hoping for was a lossless pathway via Avisource() and then finding a color depth/compression or whatever that would produce a lossless result.

    EDIT: I should add that if I load the AVI through AVISource(), no other filters, and do a direct stream copy, it switches the codec to YV12. So I guess AVISource converts UYVY to YV12?
    Last edited by SameSelf; 21st Feb 2016 at 20:22.
    Quote Quote  
  14. The ODML extensions to AVI support an interlace flag but I've never seen a program use it. Some codecs have an internal interlace flag but programs have to parse the codecs internal data to get at it. The only common codec for which editors do that is DV. So basically AVI doesn't support an interlace flag and editors will make whatever assumptions they want.
    Quote Quote  
  15. Originally Posted by SameSelf View Post
    vdub direct stream copy is all well and good, but that is no different than just a copy/paste in explorer imho (although using that to rewrap AVI 1.0 in AVI 2.0 is a pretty neat trick). What I was hoping for was a lossless pathway via Avisource() and then finding a color depth/compression or whatever that would produce a lossless result.

    I don't understand the background context. I have to ask "why" - if all you are doing is AVISource(), why even use vdub? Why even use avisynth ? What is the source video and what are you doing ?

    AVISource should output whatever colorspace the source is, but you might have to "force" it with pixel_type argument. It depends on the video and decoder. AVISource depends on the VFW decoder you have installed on your system for the file type

    Unlike NLE's avisynth and vdub can handle all types of uncompressed video and arrangements, but some avisynth filters might require a special planar version (YV16, instead of packed YUY2). But there is no "magical" byte order or planar arrangement for them that get special treatment. Also FFMpeg can re-arrange them losslessly if you need a specific one. YUY2 is 8bit422 , YV16 is 8bit422, UYVY is 8bit422 (there are several other variants, you can read about them here http://www.fourcc.org/yuv.php) . It's just re-arranging the byte order. It's like 1+2=3 , but 2+1=3 as well
    Quote Quote  
  16. Originally Posted by jagabo View Post
    The ODML extensions to AVI support an interlace flag but I've never seen a program use it. Some codecs have an internal interlace flag but programs have to parse the codecs internal data to get at it. The only common codec for which editors do that is DV. So basically AVI doesn't support an interlace flag and editors will make whatever assumptions they want.
    Yes, I asked you about that for DV in the past

    But there is definitely something here, both are uncompressed YUV422 , no codec - yet the Adobe version somehow signals progressive, at least to Adobe software. I'll check with others but I'm just curious
    Quote Quote  
  17. Originally Posted by poisondeathray View Post
    But there is definitely something here, both are uncompressed YUV422 , no codec - yet the Adobe version somehow signals progressive, at least to Adobe software. I'll check with others but I'm just curious
    This probably just comes down to something stupid: the programmer that added support for YUY2 had an interlaced sample and decided to treat incoming YUY2 as interlaced. The programmer that added support for UYVY had a progressive sample and decided to treat incoming UYVY as progressive.
    Quote Quote  
  18. Originally Posted by poisondeathray View Post
    I don't understand the background context. I have to ask "why" - if all you are doing is AVISource(), why even use vdub? Why even use avisynth ? What is the source video and what are you doing ?

    AVISource should output whatever colorspace the source is, but you might have to "force" it with pixel_type argument. It depends on the video and decoder. AVISource depends on the VFW decoder you have installed on your system for the file type

    Unlike NLE's avisynth and vdub can handle all types of uncompressed video and arrangements, but some avisynth filters might require a special planar version (YV16, instead of packed YUY2). But there is no "magical" byte order or planar arrangement for them that get special treatment. Also FFMpeg can re-arrange them losslessly if you need a specific one. YUY2 is 8bit422 , YV16 is 8bit422, UYVY is 8bit422 (there are several other variants, you can read about them here http://www.fourcc.org/yuv.php) . It's just re-arranging the byte order. It's like 1+2=3 , but 2+1=3 as well
    Well, maybe I am being a little too ambitious in my thinking. But I was under the impression that vdub could transcode losslessly UYVY input to UYVY output similarly to ffmpeg and PP. IOW, the ffmpeg script:

    Code:
    ffmpeg -i UYVY.avi -pix_fmt uyvy422 -c:v rawvideo -an -vtag "UYVY" out.avi
    is fundamentally different than using:

    Code:
    ffmpeg -i UYVY.avi -c:v copy -an out.avi
    I just haven't found a way to squeeze a UYVY encode out of vdub.
    Quote Quote  
  19. OK, I guess I see the source of the problem now. AVISource() does not support UYVY according to these links:

    http://avisynth.nl/index.php/AviSource
    http://forum.doom9.org/showthread.php?t=140820
    Quote Quote  
  20. AVISource supports it if you can decode it. Drastic is mentioned there too. Internally, avisynth only supports YUY2 and YV16. But UYVY is functionally 4:2:2 . YUY2 is functionally 4:2:2. YV16 is functionally 4:2:2 . For all intents they should be the same, they are just "stored" differently. It's only because some software prefer certain arrangements that they get treated differently. In an ideal world, 1+2=3, 2+1=3

    I think newer versions of vdub support UYVY natively. It can be set for input and output without a 3rd party codec. It's under video=>color depth
    Quote Quote  
  21. Yes, if I select the UYVY option for both in the Decompression and Output format under color depth, then when opening the UYVY AVI directly in vdub and Save As AVI with Full Processing Mode produces a lossless file.

    Just haven't found a lossless method loading the video through AVISource() or RawSource() yet. May not be possible.
    Quote Quote  
  22. Yes, internally the data is YUY2 or YV16 in avisynth. It's all the same thing to avisynth (with the exception of some filters that require maybe YV16 instead of YUY2 or vice versa), but 422 is 422 to avisynth. Avisynth really doesn't export anything. Send it to ffmpeg or vdub etc.. and export it there. If you need UYVY change it there

    You can force a pixel_type with AVISource(), eg. pixel_type="YUY2" . Or use FFMS2 or L-Smash . I double check and verify the results at each step, because sometimes "forcing" a pixel type might mean upsampling if the decoder is really outputting YV12 or something else. You have no way of knowing which VFW decoder is being used with avisource, but you can "infer" with programs such as vcswap . You can use info() or look at the status bar in avspmod at each stage in your avs script

    For example, using the ffmpeg.avi UYVY as input into avisynth using l-smash (FYI, internally, that status bar says "YUY2" at this point)

    Code:
    LWLibavVideoSource("ffmpeg.avi", format="YUV422P8")
    Using ffmpeg to output UYVY from the avs script

    Code:
    ffmpeg32 -i lsmash.avs -c:v rawvideo -pix_fmt uyvy422 -an -vtag "UYVY" lsmash.avi
    If you check in AE with the amplified differences or PP with the vectorscope (but don't forget to interpret the file ) , you will see lsmash.avi and ffmpeg.avi are the same
    Quote Quote  
  23. And in vegas, all of the UYVY variants played with above are read as "progressive" when imported, no need to interpret

    And the lsmash avs script into vdub (with the AVI driver specifically chosen in the open dialog, because the ffms2 driver can sometimes cause problems with avs scripts), with input set to auto , output set to UYVY, full processing, the output AVI is also the same in PP and AE. File=>file information in vdub with the avs script loaded reported YV16 (despite avspmod reporting YUY2)

    MS has a better description of the differences between YUY2 and UYVY with pictures
    https://msdn.microsoft.com/en-us/library/windows/desktop/dd206750%28v=vs.85%29.aspx#uyvy
    Quote Quote  
  24. I found the progressive signalling metadata with a hex editor. Adobe uses XMP. No easy way to implement that in ffmpeg or vdub

    Click image for larger version

Name:	prog.png
Views:	282
Size:	34.6 KB
ID:	35818
    Quote Quote  
  25. Good stuf, pdr, as always, You are the king. I hadn't forgotten about this thread. I just got busy trying to get L-SMASH to work and decided to rebuild my system from scratch. I finally got things working again, and I can report that loading the ffmpeg.avi UYVY into Avisynth using LWLibavVideoSource("ffmpeg.avi", format="YUV422P8") vs AVISource() or RAWSource(), then opening that in vdub and saving as an AVI with the Color Depth output set to UYVY, is INDEED lossless and Adobe interprets the file correctly.

    So now may next step (wow, will he ever stop???), is frameserving out of PP. It is tricky as DMFS only offers YUY2, not UYVY, but that would be pretty sweet!

    PP -> DMFS -> Avisynth -> ffmpeg -> PP: Completely Lossless Chain!
    Quote Quote  
  26. 10-bit vs 8-bit

    We know that RGB -> YUV -> RGB is lossy due to 8-bit rounding in the YUV space. For example, in BT.709 space, RGB[0,0,191] transforms to YCbCr[28,212,120], but recovering the original RGB values is impossible. The round trip results in RGB[0,0,192]. So one question is: how many bits does YUV space need to recover the original RGB values? 9 bits? 10 bits? more? Some authors on the web have said 9 bits is enough. To answer this question though, we need a better example than the one given.

    Let's use the triad RGB[9,63,106], RGB[10,63,106], and RGB[11,63,106]. This is a worse case scenario:
    RGB24 -> YCbCr24 -> RGB24
    Code:
    Orig       Conv     Recover
    R   9 ->   Y  63 ->  R  10
    G  63 ->  Cb 152 ->  G  63
    B 106 ->  Cr 103 ->  B 106
    
    R  10 ->   Y  63 ->  R  10
    G  63 ->  Cb 152 ->  G  63
    B 106 ->  Cr 103 ->  B 106
    
    R  11 ->   Y  63 ->  R  10
    G  63 ->  Cb 152 ->  G  63
    B 106 ->  Cr 103 ->  B 106
    As can be seen, the triad transforms to the exact same YCbCr values and only one member of the original triad is returned from the round trip. But what if we move up to 9-bit values?
    RGB24 -> YCbCr27 -> RGB24
    Code:
    Orig       Conv     Recover
    R   9 ->   Y 126 ->  R   9
    G  63 ->  Cb 305 ->  G  63
    B 106 ->  Cr 205 ->  B 107
    
    R  10 ->   Y 126 ->  R  10
    G  63 ->  Cb 304 ->  G  63
    B 106 ->  Cr 206 ->  B 106
    
    R  11 ->   Y 127 ->  R  11
    G  63 ->  Cb 304 ->  G  63
    B 106 ->  Cr 207 ->  B 106
    This is an improvement as we get three distinct YCbCr values. However, recovering the original RGB values is still problematic. So moving up to 10 bit:
    RGB24 -> YCbCr30 -> RGB24
    Code:
    Orig       Conv     Recover
    R   9 ->   Y 252 ->  R   9
    G  63 ->  Cb 609 ->  G  63
    B 106 ->  Cr 410 ->  B 106
    
    R  10 ->   Y 252 ->  R  10
    G  63 ->  Cb 609 ->  G  63
    B 106 ->  Cr 412 ->  B 106
    
    R  11 ->   Y 253 ->  R  11
    G  63 ->  Cb 608 ->  G  63
    B 106 ->  Cr 414 ->  B 106
    We still have three distinct YCbCr value BUT NOW we recover the the original 8-bit RGB values for all three members of the triad as well. So 10-bits in YUV space is needed when moving between RGB24.


    Adobe PP Color Picker
    On another note, it took me a while to figure out, but the color picker dialog for Adobe PP CS6 uses the BT.601 coefficients with the following offsets for YUV [16,0,0]. This is different from anything else I have seen on the web. Additionally, even though it uses the BT.601 matrix coefficients, it appears that the YUV values can be full range versus clamped. Bottomline, picking colors using YUV values is just weird and the YUV values should be ignored as they are useless imo. This is disappointing.
    Quote Quote  
  27. Originally Posted by poisondeathray View Post
    What I meant was Adobe used AVI 2.0 , even for the 1 frame test. So if you tried ffmpeg to generate a >2GB file, it should switch over to AVI 2.0 (not sure if it does, but some software does). Or you can direct stream copy in vdub and it will re-wrap it to AVI 2.0.
    I have some DV AVI v2.0 video files I was working with over the weekend and did a quick test using ffmpeg (-c:v copy). According to Gspot, the ffmpeg AVI was v1.0. These files were smaller than 2 GB (i.e. I didn't test your >2 GB theory). Nevertheless I find it odd that ffmpeg outputs v1.0 even when the input is v2.0.

    I wonder if ffmbc has the same behavior?
    Quote Quote  
  28. I have figured out a lossless workflow when frameserving out of PP (works in CS5 and up):

    1. Download and install Advanced Frameserver
    2. Frameserve out of PP using AFS and choose UYVY from the Colorspace options
    3. Download and install into the Avisynth plug-ins folder the QTSource.dll
    4. Load the signpost in Avisynth using QTInput("signpost.avi",mode=1,raw="uyvy")
    5. Encode ffmpeg -i in.avs -c:v rawvideo -pix_fmt uyvy422 -vtag "UYVY" -an out.avi

    Woohoo!
    Quote Quote  
  29. Originally Posted by SameSelf View Post
    We still have three distinct YCbCr value BUT NOW we recover the the original 8-bit RGB values for all three members of the triad as well. So 10-bits in YUV space is needed when moving between RGB24.
    Yes, that worked for those particular values. But I bet if you do that with all valid 8-bit YUV triplets you will still have some that aren't returned to their original values. Much fewer than with 8 bit precision, of course.
    Quote Quote  
  30. Originally Posted by jagabo View Post
    Yes, that worked for those particular values. But I bet if you do that with all valid 8-bit YUV triplets you will still have some that aren't returned to their original values. Much fewer than with 8 bit precision, of course.
    I wasn't interested in a YUV -> RGB -> YUV round trip involving all possible YUV values because I was focused on how to transform the colorbars from known RGB values. That is the gist of the above post since all the colorbar generators I have tested start from RGB versus YUV values. IOW, I challenge you to find a set of RGB24 values that cannot be recovered when using YUV 10-bit.
    Quote Quote  



Similar Threads

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