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.
+ Reply to Thread
Results 61 to 90 of 200
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
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:
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!
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
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.
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)
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
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
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 .
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.
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
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.
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.
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
ffmpeg and PP. IOW, the ffmpeg script:
ffmpeg -i UYVY.avi -pix_fmt uyvy422 -c:v rawvideo -an -vtag "UYVY" out.avi
ffmpeg -i UYVY.avi -c:v copy -an out.avi
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
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.
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)
ffmpeg32 -i lsmash.avs -c:v rawvideo -pix_fmt uyvy422 -an -vtag "UYVY" lsmash.avi
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
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!
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 -> RGB24Code:
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 -> RGB24Code:
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 -> RGB24Code:
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.
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