Lossless Workflows using Premiere Pro, VirtualDub, ffmpeg and others

[poisondeathray]

"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

vdub[/url] is LOSSLESS. When I re-export the YUV422 colorbars a second time (no Avisynth script), the scopes overlay perfectly.

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 PP

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.

[poisondeathray]

Seems like only AVI formats are affected for the RGB export, at least in the current CC version. The bars have slightly different values (Not just a chroma subsampling issue, deterioration can be detected right in the middle of a bar) - you can see with a colorpicker or vector scope. For example on the SMPTE HD color bars, 255,0,0 becomes 254,0,0

So instead of having to send to AE, you could export MOV . Works with animation codec, UT video codec, magic YUV. Image sequences work as well . I verified with both internal bars/tone and external RGB test images as the input source. Seems like no AVI love

I am not sure I completely follow. Are you saying there is a lossless pathway through PP? Please see my last post. I doubt the behavior has changed significantly since CS6.

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

[SameSelf]

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

ColorBars(1920,1080,pixel_type="YV24")
ConvertToYV12(chromaresample="point")

2. Save As AVI in vdub with Video Compression set to (Uncompressed RGB/YCbCr)

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.

[SameSelf]

Those tests were specific to RGB formats

Oh I see. I was talking about YUV pathways through PP. That is interesting because my early tests suggested that RGB pathways through PP were lossless. I will try again.

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.

[SameSelf]

Seems like only AVI formats are affected for the RGB export, at least in the current CC version. The bars have slightly different values (Not just a chroma subsampling issue, deterioration can be detected right in the middle of a bar) - you can see with a colorpicker or vector scope. For example on the SMPTE HD color bars, 255,0,0 becomes 254,0,0

So instead of having to send to AE, you could export MOV . Works with animation codec, UT video codec, magic YUV. Image sequences work as well . I verified with both internal bars/tone and external RGB test images as the input source. Seems like no AVI love

OK, after some additional thought, I noticed the same behavior in HD colorbars as well. So for some reason, I don't think the reason is due to no love for AVIs but rather the HD color bars are either more demanding or Adobe just struggles for some bizarre reason. For this reason, I am sticking with the SD bars.

Still, looking for a lossless pathway through PP for YUV video.

[poisondeathray]

^ 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

[SameSelf]

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.

[SameSelf]

This is pretty funny. I googled around for a way to encode video as UYVY and this is what I came up with:

ffmpeg -i ColorBarsYUV444.avi -vcodec copy -pix_fmt uyvy422 -sar 1920x1080 -an ColorBarsUYVY.avi

All it did was flip the video upside down!

[poisondeathray]

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.

[SameSelf]

For some reason, on Windows NLEs, those magical fourcc's unlock the Kingdom. They get special treatment.

This is what my brain did when I read your statement: https://www.youtube.com/watch?v=gz3F-02FwZc

What are dt codecs? Searching the web is fruitless.

[poisondeathray]

sorry, "drastic codecs" ... "DT" is the nickname and the name that shows up in VFW programs like Vdub

[poisondeathray]

for ffmpeg this works , with correct arrangement

ffmpeg -i 8bit422input.ext -pix_fmt uyvy422 -an -c:v rawvideo -vtag "UYVY" output.avi

[SameSelf]

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

[poisondeathray]

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

[SameSelf]

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.

[poisondeathray]

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)

[SameSelf]

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?

ColorBars(1920,1080,pixel_type="YV24")
Trim(0,149)

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%)

As far as converting YUV444 to YUV422, I tried ConvertToYV12(chromaresample="point"), but the borders get messed up and so do the colors. So I decided to just do it PP. I don't know anything about decoding the YUV444 correctly other than the vectorscope images I posted earlier.

[SameSelf]

Well, waddya know. Turns out I was doing it wrong. Didn't have the Color Depth settings in vdub correct. Doh!

[poisondeathray]

As far as converting YUV444 to YUV422, I tried ConvertToYV12(chromaresample="point"), but the borders get messed up and so do the colors. So I decided to just do it PP. I don't know anything about decoding the YUV444 correctly other than the vectorscope images I posted earlier.

YV12 would be 4:2:0 (960x540 for U,V)

You would use ConvertToYV16 for 4:2:2, and specify the matrix

e.g

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

[jagabo]

As far as converting YUV444 to YUV422, I tried ConvertToYV12(chromaresample="point"), but the borders get messed up and so do the colors.

Whether you meant YUY2 or YV12:

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")

and:

ColorBars(1920,1080, pixel_type="YV24")
PointResize(width/2, height/2).PointResize(width,height) # force all transitions to even boundaries
ConvertToYV12(chromaresample="point")

[SameSelf]

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)

Exported this from vdub as an AVI, brought it into PP, and it is the cleanest vectorscope I have seen so far. So that is progress. However, if I export this from PP as UYVY, the borders smear although the colors are stationary. Exporting as V210 is even messier. But here is the strange part, Mediainfo looks identical for the YUV422 source and UYVY export. Are you able to find a lossless path that I am missing?

vdub Export:

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%)

Uncompressed UYVY Export from PP:

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%)

[poisondeathray]

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)

[SameSelf]

ColorBars(1920,1080, pixel_type="YV24")
PointResize(width/2, height/2).PointResize(width,height) # force all transitions to even boundaries
ConvertToYV12(chromaresample="point")

Using ConrtToYV16 now. I tried inserting the PointResize line and compared it to the one without the PointResize line and there is a strange and rather large colorshift.

[SameSelf]

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)

Yes, borders smear. Sadly, as far as I can see, I have everything set properly in my sequence setting and export settings (1920x1080, progressive, square pixel). Here is a screenshot:

[poisondeathray]

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

[SameSelf]

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.

[poisondeathray]

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.

ffmpeg.avi is the same . You can test and verify with the other methods. Maybe something is corrupted with your install ?

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 ?

UYVY_INPUT.avi


ffmpeg.avi

[SameSelf]

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.

[poisondeathray]

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)

[poisondeathray]

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