"Losslessness" is just a relative state. You can define anything to be the starting point.
Other ways to test for "losslessness" are difference testing , SSIM, PSNR etc... You have to be careful that you're testing in the same manner. If you compare in RGB, you have to be certain that you upsample the same way (e.g. if you use spline on one but bicubic on another it's going to "say" not lossless). So it's usually better to test in the native color model and sampling and bit depth
Did you mean uncompressed ? Because only certain YUV422 fourcc's (YUY2 isn't, UYVY is) are truly lossless in PP. Your source test probably didn't contain extended range values. Lossless YUV codecs are not lossless in PPOriginally Posted by SameSelf;2433653
The good news is that [url=https://www.videohelp.com/software/Virtualdub
I can see why people complain about Adobe now. If you bring a YUV422 video into a timeline and export as lossless, that is not a lossless pipeline. Maybe I am missing something about PP?
If you're using prores , it's trickier to test because that's 10bit 422 . How 8<=>10bit conversions are done will impact whether or not something is mathematcially lossless. ie. Dithering, and the algorithm used . You would need use 10bit 422 export format to be lossless. If you mean 8bit 422 footage, yes it can lossless depending on how it's used - and you can verify using those tests
Important to note that PP doesn't treat commonly used lossless YUV codecs as YUV (not just a PP issue, most NLE's don't handle lossless YUV codecs as YUV). If you bring in full range video with ut video 422, superbrights/darks will be clipped.
+ Reply to Thread
Results 31 to 60 of 200
Those tests were specific to RGB formats, RGB exports (no effect of YUV intermediate, or chroma subsampling). Yes it's lossless - just an alternative to the AE workaround
Unlike commonly used "lossless" YUV codecs, RGB lossless codecs usually fewer issues in host applications, but it seems to be an issue with AVI in PP
Good questions. I was getting a little sloppy towards the end of that long post. Here is my "verified" LOSSLESS workflow:
1. Generate YUV422 colorbars in Avisynth
3. Open the AVI in vdub and repeat #2
4. Scope up the AVI's in step 2 and 3 in PP and see if they overlay perfectly. This process seems to be rigorous enough that any differences will show no matter how small e.g. a Red value changing from 191 to 190.
Hopefully this makes more sense.
EDIT: When I export my RGB32 AE colorbars from PP as Utvideo RGB, the AVI scopes up exactly over the AE RGB bars implying lossless even though the file is about 10% the size of the AE RGB file.
Still, looking for a lossless pathway through PP for YUV video.
^ Yes that's not surprising, it's bit for bit the same video if you do it that way. You could copy & paste and do the same thing
To do the same thing in PP, an 8bit 4:2:2 format would have to use "UYVY" as uncompressed, or "IYUV" as 8bit 4:2:0 , or "v210" as 10bit 4:2:2. Those are the "magical" fourcc's that get pass through in PP.
If you take a full range test video and did the same test but using full range. Y' 0-255 , did the same thing in vdub; imported both into PP, both would show the same, but both would clip <16, >235. i.e both would be wrong. Because vdub uses "YV12" for the fourcc for uncompressed 8bit 4:2:0
Technically, it wasn't bit for bit the same like a copy/paste, but I am guessing that was due to metadata and not the actual video. It is the closest thing I have seen to a lossless pathway for YUV thus far.
So UYVY or IYUV uncompressed is the special sauce for lossless 8-bit 4:2:2/4:2:0 PP pathways. How does one generate that sort of video? Thanks as always.
In ffmpeg sar is used with -vf setsar . The -pix_fmt should be yuv422p and -vtag "UYVY". But I'm not sure if this is valid planar arrangement, it might just "tag" the metadata
Easier way is there is a free version of "dt codecs" that can be used in vdub. AME/PP can also export with UYVY, or V210, but I don't think IYUV (4:2:0 is frowned upon I guess)
PP will pass through in/out when one of those magical uncompressed plane arrangements is used. The only difference between various fourcc's of the same category is the byte and plane arrangement. For example UYVY is functionally the same thing as YUY2 and YV16 (all are 8bit 4:2:2), but they are just "packaged" or arranged slightly differently. For some reason, on Windows NLEs, those magical fourcc's unlock the Kingdom. They get special treatment.
Thanks as always for all the help. Unfortunately, neither of those pathways appear lossless. See below:
#1. Starting with my YUV444 colorbars, Save As AVI in vdub with video compression set to DT 8 bit Y'CbCr 4:2:2 AVI/WMV [UYVY]. When I bring the resulting AVI into PP, the colors actually shift a little. For example, the Red RGB[191,0,1] becomes RGB[190,0,4]. Very disturbing.
#2. The ffmpeg pathway shifts even more with Red RGB[209,18,0].
But, not to be 100% discouraged. I tried exporting the DT encode from PP as Uncompressed UYVY 422 8bit to see if I unlocked the keys. But, after reimporting no luck. While the colors don't shift, the borders get messed up again. But, if I re-export this version again, there was no additional degradation of the borders and no color shifts. The scopes looks identical.
So in order to get to a lossless 422 colorbar, I need to transcode it at least twice? This is a strange world we live in.
So to recap:
Start: YUV444: Red RGB[191,0,1] (I am a little bothered this is not RGB[191,0,0])
Pathway 1.1: DT UYVY 422 from vdub: Red RGB[190,0,4] (that's a big shift)
Pathway 1.2.1: PP Export as Uncompressed UYVY 422: Red RGB[190,0,4] (Phew, but borders are smeared.)
Pathway 1.2.2: PP Export of 2.2.1 as Uncompressed UYVY 422: Scope of 2.2.1 and 2.2.2 are identical. Finally.
Pathway 2: ffmpeg UYVY 422: Red RGB[209,18,0] (whoa! what happened here?)
What do you mean by lossess 422 colorbar ? What is your point of reference ?
"Lossless" is always in reference to something. If you start with UYVY, export UYVY, it's bit for bit lossless by any test (and I mean any test, including SSIM,PSNR, difference testing etc...within PP , with AE, within avisynth etc.. every test), even re-importing/exporting 100x. Your starting point and reference point is the input UYVY video. If you made bars that were converted to 191,0,1 instead of 191,0,0 as a starting point it's from the loss in precision when converting to 8bit RGB and/or how you converted in YUV444 to YUV422. If 191,0,1 is what you had to start with in RGB converted values, that's what you get as output 191,0,1 - by definition that is lossless. If you had 32,34,234 you should get 32,34,234 in 8bit RGB values. That's what I'm getting: input = output it's been the same every since at least CS4 . ffmpeg UYVY as posted above works too
If the borders were "smeared" that's from chroma subsampling. It was there to begin with. If your "source" was UYVY that's 422 - there is no way to get "sharp" borders with 422. You can't "spread" 960x1080 to "fit" 1920x1080 without losing something. There is no additional loss when you import/export UYVY
I may be a little sloppy in my use of the term lossless, but I think you will understand why in a minute. I am trying to find a qualifier for how much color shifts on conversion from 4:4:4 to 4:2:2. We already determined that the RGB --> YUV pathway is not lossless due to the rounding to 8 bits. Exact colors can't be recovered when going back to RGB from YUV. But that is a separate issue from chroma subsampling.
I am trying to get my head around the 4:4:4 --> 4:2:2 pathway when no colorspace conversion is taking place. It should be theoretically possible, I would think, to recover a 4:4:4 color from a 4:2:2 conversion if that color is in the interior of a colorbar. Admittedly, that is not what I am trying to do here. Rather I am just interested in how stationary color is, similar to the RGB --> YUV pathway.
Rec. ITU-R BT.801-1 (Reference) Red is RGB[191,0,0]. PP reports Red for my YUV444 bars as RGB[191,0,1]. Close enough since we know the YCbCr --> RGB conversion is not lossless. This can serve as my point of reference. I would think a lossless(?) color pathway from YUV444 to UYVY 422 would produce the same color as my YUV444 Red, RGB[191,0,1], since no colorspace conversion is taking place.
Starting with the YUV444 AVI, Pathway 1 through vdub produced Red RGB[190,0,4]. So Red has moved away from my point of reference of RGB[191,0,1].
Starting again with the YUV444 AVI, Pathway 2 through ffmpeg shifted Red to RGB[209,18,0]. Now, that is just unacceptable, imo.
I guess we need to add that any 4:4:4 to 4:2:2 conversion is never lossless in the color domain even if the colorspace remains the same. It's a level of minutia that I needed to get my head around. So,
RGB --> YUV lossy (color will shift)
YUV --> RGB lossy (color will shift)
YUV 4:4:4 --> UYVY 4:2:2 lossy (color will shift)
This is very surprising to me. My apologies if this is obvious to you. However, this is my first rodeo, and I feel like I keep getting bucked off.
In addition to this, I have determined:
PP Export of YUV444 as Utvideo YUV 422 --> Re-export the Utvideo from PP as Utvideo YUV 422 again --> Lossy
PP Export of YUV444 as Uncompressed UYVY 422 8 bit --> Re-export from PP as Uncompressed UYVY 422 8 bit again --> Lossless
PP Export of YUV444 as Uncompressed UYVY 422 8 bit --> Export from vdub as DT UYVY 422 from vdub --> Very Lossy (big color shifts)
PP Export of YUV444 as Uncompressed UYVY 422 8 bit --> Transcode in ffmpeg as UYVY --> Nearly lossless, only border smearing
vdub Export as DT UYVY 422 --> Re-export from vdub as DT UYVY 422 again --> Lossy (color shifting and borders smearing, very stange)
ffmpeg transcode as UYVY --> transcode again --> lossless
So, bottomline, lossless pathways seem to be like hunting for unicorns.
Last edited by SameSelf; 20th Feb 2016 at 17:28.
You're probably messing up the YUV444 to YUV422 conversion, or not decoding the YUV444 video correctly. How are you doing that conversion ? What format is your YUV444 video ?
Start with a KNOWN 8bit 422 video, unless your goal is to test the method of converting 444 to 422. In that case verify the 422 first before converting to UYVY. If using avisynth, use avspmod, there is a built in color picker and you can check YUV and RGB values. If using vdub, beware of RGB intermediates if not using "fast recompress"
To re-iterate, it's lossless when INPUT and OUTPUT videos have one of those magical fourcc's . There is no magical fourcc for YUV444 that I know of. UYVY means 8bit422 uncompressed (there are different types of 8bit422 uncompressed, UYVY is a specific byte order and plane arrangement)
I have no doubts that I screwing lots of things up
I can't post my YUV444 video as it is nearly 1 GB. But here is the mediainfo. I generated it in vdub by saving as (Uncompressed RGB/YCbCr) using the following Avisynth script. Maybe I am confused, and it is really RGB? Perhaps you can test my workflow?
General Complete name : E:\ColorBarsYUV444.avi Format : AVI Format/Info : Audio Video Interleave File size : 891 MiB Duration : 5s 5ms Overall bit rate : 1 493 Mbps Video ID : 0 Format : RGB Codec ID : 0x00000000 Codec ID/Info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples Duration : 5s 5ms Bit rate : 1 491 Mbps Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 29.970 fps Bit depth : 8 bits Bits/(Pixel*Frame) : 24.000 Stream size : 890 MiB (100%)
You would use ConvertToYV16 for 4:2:2, and specify the matrix
ColorBarsHD(1920,1080,pixel_type="YV24") ConvertToYV16(matrix="rec709", chromaresample="point")
So did you get it all sorted out ? There is a lossless In/Out workflow for PP, but only for 8bit422 and 10bit422 for YUV formats, and they must be UYVY or v210 respectively. There are other lossless YUV workflows for other formats, but only with those specific formats that it smart renders
Be careful about the width and height of the individual color bars. If they are an odd width/height then the subsampled chroma can't line up perfectly with the luma. Compare:
ColorBars(1920,1080, pixel_type="YV24") ConvertToYV12(chromaresample="point")
ColorBars(1920,1080, pixel_type="YV24") PointResize(width/2, height/2).PointResize(width,height) # force all transitions to even boundaries ConvertToYV12(chromaresample="point")
Thanks, yes, I think I have it sorted out now. For the video color depth, I chose 4:2:2 YCbCr (UYVY) for both Decompression and Output and ran the following code:
ColorBars(1920,1080,pixel_type="YV24") ConvertToYV16(chromaresample="point") Trim(0,149)
General Complete name : E:\ColorBarsYUV422.avi Format : AVI Format/Info : Audio Video Interleave File size : 594 MiB Duration : 5s 5ms Overall bit rate : 996 Mbps Video ID : 0 Format : YUV Codec ID : UYVY Codec ID/Info : Uncompressed 16bpp. YUV 4:2:2 (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line). A macropixel contains 2 pixels in 1 u_int32. Duration : 5s 5ms Bit rate : 994 Mbps Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 29.970 fps Color space : YUV Chroma subsampling : 4:2:2 Compression mode : Lossless Bits/(Pixel*Frame) : 16.000 Stream size : 593 MiB (100%)
General Complete name : E:\ColorBarsUYVY.avi Format : AVI Format/Info : Audio Video Interleave File size : 593 MiB Duration : 5s 5ms Overall bit rate : 994 Mbps Recorded date : 2016-02-20T17:21:48-06:00 Writing application : Adobe Premiere Pro CS6 (Windows) Video ID : 0 Format : YUV Codec ID : UYVY Codec ID/Info : Uncompressed 16bpp. YUV 4:2:2 (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line). A macropixel contains 2 pixels in 1 u_int32. Duration : 5s 5ms Bit rate : 994 Mbps Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 29.970 fps Color space : YUV Chroma subsampling : 4:2:2 Compression mode : Lossless Bits/(Pixel*Frame) : 16.000 Time code of first frame : 00;00;00;00 / 00;00;00;00 Time code source : Adobe tc_A / Adobe tc_O Stream size : 593 MiB (100%)
borders smear? make sure you setup the sequence settings and export settings properly (1920x1080, progressive , square pixel etc...)
BTW You only need 1 frame to test ( trim(0,-1) would have sufficed)
Also check your sequence settings. I don't have CS6 installed right now but there are several places where UYVY can be found. It shouldn't matter but check under "uncompressed AVI", there should be another UYVY version.
Just so we are on the same page, here are 3 videos
UYVY_INPUT.avi was generated from internal PP colorbars, UYVY as output. This is the "source video" now. You could have used the avs script to generate the UYVY source, but it's unclear from me what pathway you used in vdub, so I'll take vdub out of the equation for now . I want you to use this as your input video
ffmpeg.avi was generated from UYVY_INPUT.avi with
ffmpeg -i UYVY_input.avi -pix_fmt uyvy422 -c:v rawvideo -an -vtag "UYVY" ffmpeg.avi
UYVY_OUTPUT.avi was generated from either re-importing UYVY_INPUT.avi or ffmpeg.avi and exporting UYVY again .
You can do this a million times and get the same thing . It's not a version issue, because UYVY pass through worked since at least CS4 - I've posted about this many years ago
Thanks for those. OK, I switch over to AVI (Uncompressed) and chose UYVY from there. Not sure if it makes any difference though. And yes, I am able to find lossless pathways through UYVY exports from PP. In fact I can generate the exact same vectorscope as your included files. However, you do realize that the ffmpeg.avi file that you included is not exactly the same as the UYVY_INPUT and UYVY_OUTPUT right? In fact, I was able to replicate all your videos precisely. According to my vectorscope, the ffmpeg pathway is not lossless. It is close, no color shifting, but the boundaries shift. Now, if I take the ffmpeg video and push it through ffmpeg again, that is a lossless path. But starting with either UYVY_INPUT or UYVY_OUTPUT is not.
If you put both videos in after effects, set the top layer to "difference". Add an adjustment layer, add levels effect, set the gamma to 2 or something high, what do you see ?
Hmm, well now I am even more baffled. You are correct. When I bring the footage into AE and do as you said, I see pure black. But in PP the borders clearly move. I don't even need the vectorscope to tell me something changed. This is baffling beyond comprehension.
Did you do the adjustment layer, with levels in AE ? Because tiny differences won't be seen with just plain differences. You need to amplify the differences.
Try clearing the media cache and do the comparison again in PP, starting from re-importing (sometimes when "weirdness" happens, Adobe can mix up cached versions of files)
But you said the Adobe exported UYVY version worked ? Ie. you can import/export with Adobe all day long no problems and get the same vectorscope result? Sometimes there are incompatibility versions with ffmpeg/ffmbc with some software - sometimes it's the header or AVI container differences. For example Resolve is very picky about those types of things