Converting 4:2:0/4:2:2 4k to 4:4:4 1080p

fxhomer248796 Posts: 1
edited May 2020 in General

First a warning that I'm a beginner so there's lots I'm not really clear about yet haha.

I'm just trying to make simple edits on my 4K footage, but I realized my laptop can't handle it so I'm trying to downscale it. But I've also heard if done correctly I can get 4:4:4 color 1080p footage out of the 4K footage. How can I do so in hitfilm express or elsewhere? Anyways, the footage is 24-bit with codec AVC / H.264 and color space 8-bit 4:2:0, and it also says High Profile @ Level 5.1 if that means anything. It wouldn't be as easy as simply throwing the footage in the timeline and scaling it down to 1080p, would it? Or would that be successful in capturing better color than typical 1080p?


  • NormanPCN
    NormanPCN Posts: 4,122 Enthusiast

    "But I've also heard if done correctly I can get 4:4:4 color 1080p footage out of the 4K footage."

    Yes, you can get effective 4:4:4 1080 media from UHD 4:2:0 media, and yes the scaling must be done a certain way to get the 444 result.

    You would have to convert to a format like Cineform RGB or Prores 444. Everything else has chroma subsampling.

    I've only tested this 420 UHD -> 444 HD using ffmpeg for the downscale conversion and I was doing it the "fancy" way. By simply keeping the UV channels/plane intact/untouched (they are already half res), and scaling the Y channel down to HD from UHD. I'm not sure about other tools like VirtualDub. So long as they operate with an internal RGB space then the downscale can give the 444 result from a 420 source. You can output Cineform or Prores from VirtualDub.

    "It wouldn't be as easy as simply throwing the footage in the timeline and scaling it down to 1080p, would it?"

    Realistically this should work. Hitfilm operates in an RGB space internally the result should be about as good as it gets in the downsample. Problem is that you are still decoding UHD media and that may be the source of your performance issue. That said, hardware decode of 8-bit AVC 420 media should have good performance on decode. An in spec machine for Hitfilm should have AVC hardware decode available (assuming reasonably recent GPU drivers).

  • WhiteCranePhoto
    WhiteCranePhoto Posts: 924 Enthusiast

    HitFilm is actually a good tool for doing this sort of conversion -- particularly since it can render to Cineform.

    If disk throughput or horsepower are limitations though, it might be better to render to 10-bit 4:2:2 Cineform.  That's still a popular acquisition format... and if you use that then you can always go back to the originals and export a 4:4:4 version for just clips where you need the extra flexibility, instead of using 4:4:4 for all of them. It will usually be overkill, and since you'll have the originals available, you don't need them all to be 4:4:4 12-bit files.


  • avsynthe
    avsynthe Posts: 4
    edited May 2020

    What is the hands-down best method to achieve 1080p 4:4:4 from 4K 4:2:0 / 4:2:2? I'm producing files in 4K Slog2 S-Gamut DNxHD in a .mov container, from a Sony a7rII into an Atomos Ninja V monitor, and am happy to use Cineform or stay in DNx to achieve this. I'm doing green screen work, so this would be amazing.


    If it's ffmpeg, what is the best string for JUST that? I've seen some example flags but they seem to include YUV, I was under the impression that this only possible in an RGB work space. Ffmpeg would be the most ideal solution for me, as I wouldn't need any additional paid software

    I've seen posts regarding HitFilm, where users are unsure if it's actually properly achieved 4:4:4 as the end result. If it's guaranteed to work, what is the best way to achieve this in HF?

    I'm currently using the Adobe suite for my workflow, so I have access to After Effects also. I know I need to create a project at 16bit before importing footage, but what working space do I select when creating the project? If i'm to keep it at "none", then what do I set the "Assume working Gamma" to?

    I'm happy to use Resolve just for this also if someone can tell me the exact process

    I'd even get into Vegas if that's what I can get the most info on



    I also have no issues real limitations with hardware 

    There is such a GREAT many threads on this since 2014, all with endless discussion and argument, but pretty much nothing with straight forward, step-by-step guides on how to actually achieve this for the layman. Or, there will be a quick mention of this "special process" that will net you 1080 4:4:4 from 4K 4:2:0 / 4:2:2 without any detail. 

    Every now and then a new thread pops up, asking exactly what I'm asking, only to die with nothing, or have other people agree, saying that they've been chasing this myth or legend also for years haha, and then just all referencing the same, 6 year old threads. So help here would REALLY be appreciated!

    Thanks in advance


  • NormanPCN
    NormanPCN Posts: 4,122 Enthusiast

    "What is the hands-down best method to..."

    Let go of the word/concept of "best" an any kind of generally applicable term. It is too instance specific and even then it is prone to being a subjective process.

    "...all with endless discussion and argument..."

    there's your sign...

    "achieve 1080p 4:4:4 from 4K 4:2:0 / 4:2:2?"

    For anything (app) that works in an internal RGB working space, or even a non chroma subsampled YUV working space, then simply just scale the frame down to your result size. This is most editing apps AFAIK these days. After the scale the frame component data should be as good as it will get at HD RGB from a UHD source. AKA 444 like.

    The "after the scale" statement is somewhat critical given any specific apps internal dataflow. In Hitfilm for example you would want to subcomp the scaled result. This because effects operate before the scale in the dataflow on the same layer. If you want an effect like ChromaKey to operate on the 444 like result then it would have to be on a subcomp which does the scale. The scale has to be "baked in" before you can expect to have a 444 like result. There may be other dataflows available in Hitfilm but this basic/common one comes to mind immediately.

    If you want to transcode to a result and then just edit using that result, you can use VirtualDub 2. VirtualDub 2 gives you a selectable working space (decode). You can do RGB or even full YUV. VirtualDub can output Cineform RGB or Prores 444. Both of  which will work natively with Hitfilm to keep the 444 like result. I'm not sure if Prores 444 is RGB or full YUV. This is kinda a technical thing but knowing could help reduce a transformation within VirtualDub during a transcode. Not that such a mathematical "loss" would ever be noticeable especially since we are talking of a dataflow that involves a frame interpolation (UHD -> HD) which is a fair bit of per pixel data manipulation. Mentioned just to be pedantic.


    Here is an example batch file for testing a UHD 420 to HD 444 using ffmpeg. It maintains planar YUV internal dataspace and scales the Y while preserving the UV and merging those places for the result. There is an alternate test dataflow commented out.

    It outputs Prores. ffmpeg does not have Cineform output available. Hitfilm does not have native DNx support.

    @echo off

    call "%~dp0set_path.cmd"

    set filter=-filter_complex "extractplanes=y+u+v[y][u][v]; [y]scale=w=1920:h=1080:flags=print_info+bicubic+bitexact [ys]; [ys][u][v]mergeplanes=0x001020:yuv444p"

    title transcode UHD to HD 444 - %1
    ffmpeg.exe -i %1 %filter% -c:v prores_ks -profile:v 4444 -qscale:v 5 -vendor:v ap10 -pix_fmt yuv444p10le -colorspace bt709 -color_primaries bt709 -color_trc bt709 -c:a pcm_s16le -chunk_size 64K ""
    if errorlevel 1 goto error

    if NOT %1$==$ goto top
    goto :EOF

    echo !!! error encoding !!!

    REM scale only the luma channel. combine into 444.
    REM -filter_complex "extractplanes=y+u+v[y][u][v]; [y]scale=w=1920:h=1080:flags=print_info+bicubic+bitexact [ys]; [ys][u][v]mergeplanes=0x001020:yuv444p"

    REM scale chroma channels up, combine, now 444, then scale down.
    REM -filter_complex "extractplanes=y+u+v[y][u][v]; [u] scale=w=3840:h=2160:flags=print_info+neighbor+bitexact [us]; [v] scale=w=3840:h=2160:flags=print_info+neighbor+bitexact [vs]; [y][us][vs]mergeplanes=0x001020:yuv444p,format=pix_fmts=yuv444p10le,scale=w=1920:h=1080:flags=print_info+bicubic+full_chroma_inp+full_chroma_int"

  • NormanPCN
    NormanPCN Posts: 4,122 Enthusiast
    edited May 2020

    The "special process" is not special but just full RGB/YUV.

    What if a video editor did the following. The editor dataspace was 4:2:0 YUV. You scale to 50%. 4:2:0 UHD has a Y plane of 3840x2160 and UV planes of 1920x1080. The scale results in 1920x1080 for the Y plane and 960x540 for the UV planes. That does not get you the 444 like result does it. 960x540 is just not there.

    Now if the app was RGB or full YUV then all channels are 3840x2160.  In a decode here the 420 UV is getting scaled up to full rez. Effectively each 4 pixel block is all the same color since the source UV was half rez. A path to a 444 like result.

    edit: The special can be as shown in the ffmpeg script above. The Y plane is scaled 50% and the UV planes are preserved as is. They are already at HD rez.

  • avsynthe
    avsynthe Posts: 4

    Awesome! Thanks so much for your response, very helpful and clears a lot up.

    When I mentioned the endless discussion and argument, it wasn't so much regarding the best way to achieve this, but more that I was still finding threads, recent ones at that, where people still deny that it's even possible, and the theory behind it. To me it all makes perfect sense, especially when you break down the way that ffmpeg is used for it.

    Because I'll be using Cineform over ProRes, and that I think it'd be easier on my rig working on a 1080 timeline, I've decided to transcode to a result using VirtualDub 2 as you suggested. For some reason I avoided this earlier as I was coming accross old threads that existed before GoPro open sourced the Cineform codec, and the free version of Cineform was limited to 4:2:2 back then.

    So i'd really just like to clarify some particulars in VD2 if thats all good. When setting the working space (decode), I'd be selecting RGB24 as any RGBA format would just be overkill, and pointlessly tripling export time due to not needing an alpha channel, correct? 

    And I assume the same goes for configuring Cineform, I'd be using RGB 12-bit over RGBA, though is there any benefit to setting the Intermediate Bit depth to 16 over 10? I noticed the pixel format being used for 10 is r210 versus RGBA64 for 16. Will both of these yield me 4:4:4? Or is there one I should be choosing? I'll be going full quality at Filmscan 3 due to doing green screen work

    Lastly, when configuring the resize filter, it's my understanding that Lanczos3 is the best to use. Again, as a lot of what I've been reading spans over the last 6 or so years, I've seen a lot of discussion about Bicubic also. There was talk on Lanczos as well, but particularly when people were discussing upscaling, not downscaling/upsampling, so I just wanted to clarify here. I've changed nothing else here besides 50% Relative Size

    I'm working within Windows, so I'm assuming it'll just be generally better to wrap it in AVI vs MOV


    Thanks again for all your help mate. You've definitely pushed me in the right direction, eager to move beyond this point finally.

  • Triem23
    Triem23 Posts: 20,518 Ambassador

    With @NormanPCN, you're always in good hands. 

    I changed the title of this thread to be a more clear description, if anyone else has constructive input. On this topic, you already have better help than I. ?

  • NormanPCN
    NormanPCN Posts: 4,122 Enthusiast

    Selecting an RGBA internal format for Vdub is not going to triple time. It is basically a memory cost. Since your source has no alpha there is no need for an Alpha internal format. It's a waste. As for output then of course you would selected Cineform RGB verses RGBA.

    In Vdub when you select Cineform RGB(A) under Compression then the auto setting for the decode dataspace should properly select an RGB(A) dataspace, regardless of the source dataspace. The auto setting should select an 8-bit or 16-bit per component depending on your source media per component bit depth. In other words the auto setting should be good to go when you properly select the output compression type. If the source is 8-bit then the auto should select an 8-bit internal bit depth. Since you are doing an interpolation, thus lots of pixel blending, and you seem interested in "best", feel free to use a 16-bit per component internal space. It's not really a waste since the Cineform RGB output is 12-bit. Wheather 16 vs 8-bit with an 8-bit source and interpolation helps is indeterminate.

    Do what you want but Filmscan 3 is probably overkill. It will make files that are larger and may not decode well in Hitfilm. Filmscan 1 and 2 should be fine. No setting means that Hitfilm will handle you media without issues on your machine. Even Medium. Hitfilm needs all the help it can get with performance. Don't make things harder for it.

    I try to avoid any internet "best" discussion on interpolation algorithms. Do what you want. One thing to remember with interp algorithms is that they are typically not a specific thing. Any implementation of Bicubic is likely to be slightly different than others in bias(weighting).

    Wrap it in a MOV file.

    @Triem23 Changing the title to 422 to 444 is not really the best. The OP of this thread was talking about the more common 420 4k to 444 HD.

  • avsynthe
    avsynthe Posts: 4
    edited May 2020

    So I noticed that when I leave the Decode on Autoselect, it remains on YUV422P16-709 even when setting Cineform to RGB(A). This is also reflected in the compression window where it reads "Using conversion: YUV422P16-709 -> RGBA64" and in the pixel format window

    I also noticed that export time did triple from around 3min to 9min for a 1m10s video, when selecting RGBA for the Decode vs RGB. This is also evident even when simply playing back the footage after selecting this decode. Playback framerate slows down significantly when RGBA is selected

    Thanks for the heads up regarding quality! I'll experiment a bit with how well it's handled in different editors like Premiere Pro and After Effects

    Whats the advantage of wrapping it in MOV? Or is this more an advantage for handling by HitFilm? Will MOV +faststart make a difference here considering everything will be on youtube?

    My ONLY issue now is that I can't seem to get VD2 to play back the audio from the video file. It's scratch audio, but it'd be ideal to sync the mic audio to the scratch audio on the new result, vs having to import the original, unlink the audio, delete the video and replace with the result. Just less mucking around.

    Audio plays in VLC and QT, but no audio in VD2, MPC or MPV either. VLC reads the audio codec as “PCM s24 BE (in24)”, QT see’s it as “24-bit Integar (Little Endian), 4 channels” and VD2 sees it as “pcm_s24le”. Perhaps its listening to the wrong channel where there isn’t any audio? Only 2 of them should have any sound and I'm not sure why the Atomos is recording at 4

    I also agree about the title. For SEO purposes, I'd put both as "Converting 4:2:0 / 4:2:2 4k to 4:4:4 1080p"

  • avsynthe
    avsynthe Posts: 4
    edited May 2020

    Sorted out the audio issue with my files. It did turn out to be the fact that the Atomos unit was reserving channels 1 and 2 for analogue audio, and placing the the digital audio channels 1 and 2 on channels 3 and 4. It seems like VLC plays all audio channels but VirtualDub 2 and MPV must only listen on the first one or two, which in this case, were blank.

    Looks like it'll be smooth sailing from here. Thanks so much for your help. I hope that this thread is found by many

    Any word on why it's better to wrap Cineform in MOV vs AVI on Windows? Is it the cross-platform ability? Because I could definitely see that as an advantage if I was ever to send off to Mac for editing

  • NormanPCN
    NormanPCN Posts: 4,122 Enthusiast
    edited May 2020


    "when I leave the Decode on Autoselect, "

    Yes, since you are doing an interpolation and are looking for the 444 like data result you realistically want to do a manual decode override to something appropriate. RGB 8-bit or RGB 16-bit.

    Looking closer, Vdub dataflow maintains the video in source/native format as long as possible. It can do that since it support a ton of data formats. You definitely want to override than and get into RGB space before you do the interpolation. (any full component space)

    "I also noticed that export time did triple "

    Yes, forcing Vdub to change dataspace at the front end takes big hit. I've usually not done this. Well, I've never needed to do what you want so duh. The biggest hit I saw was just switching to RGB space. Even RGB24. Double. RGBA 32 was incremental and RGBA64 was incrementation on 32. Vdub does not have an RGB48 so you are  forced the alpha channel in the intermediate. The export can still be only RGB since the alpha is unused.

    As prev mention for stated reasons you probably want a 16-bit intermediate space.

    Interesting that there is a hit in the front end but no the back end (encoder).

    "Whats the advantage of wrapping it in MOV?"

    What's the advantage in wrapping it in AVI? You seem to be making an assumption here about AVI.

    AVI is defunct and does not support modern codec features. It is okay for Intra codecs and CFR.

    "Will MOV +faststart make a difference here considering everything will be on youtube?"

    Your intermediate file, this transcode being discussed, is in never going to be uploaded to Youtube so nothing about this transcode has anything to do with Youtube.

    "My ONLY issue now is that I can't seem to get VD2 to play back the audio from the video file."

    Can't help you there. I don't know a thing about your file except it's 4k and you can to get 444 1080. Vdub defaults to a direct stream copy. Full processing mode might be necessary. If it is multiple tracks you can select the individual streams.

  • Hug
    Hug Posts: 1 Just Starting Out

    Hi I'm installing FFmpeg as I'm reading this...also trying to decipher all this great info...

    As creating proxies in Resolve takes time and you can't edit while it's doing so, and after struggling a bit with that kind of footage in a client edit, I thought I'd start using FFmpeg for 8 bit 4k 4.2.0 footage transcoding. My initial idea was Prores HQ to save some space in comparison to 444... this thread seems to suggest the FFmpeg way gives 1080p 444...

    The 420 this client gives me needs some heavy primary and secondary color correction, some roto, and fusion work (y'a know replacing blasted overexposed windows shot with an underexposed moving actor in front ) because it's...politely and gun shoots not always well lighted... but it's work anyways...

    "For anything (app) that works in an internal RGB working space, or even a non-chroma subsampled YUV working space, then simply just scale the frame down to your result size. This is most editing apps AFAIK these days. After the scale the frame component data should be as good as it will get at HD RGB from a UHD source. AKA 444 like."

    I am gonna try the FFmpeg way for the time-saving benefits only but...

    NormanPCN mentioned hitfilm...Does this apply to Resolve when we create 1080p proxies from 4k 420 footage automatically? It would be doing 444 like footage already? Or would the Resolve version of this would be to use the media manager to transcode to 444 (if HQ is enough let me know) with or without other tweaks and work from the 1080p to get the benefits.

    And what about projects settings? Even though it's 8 bit leave it at 10 bit, video levels and or ...? Gonna also guess that Input scaling should be set to scale entire image to fit...

  • NormanPCN
    NormanPCN Posts: 4,122 Enthusiast

    "NormanPCN mentioned Hitfilm", Yes this is a Hitfilm forum. As for Resolve, you probably need to ask in a Resolve forum. Not sure the Resolve expertise here.

    As for generating an HD 444 result from UHD 420, you can do that in ffmpeg to a Prores result. Using VirtualDub 2 you can output Cineform RGB or Prores 444. Both are best in a MOV container. Hitfilm can handle both.

    You talk some about proxies. If so then why consider HD 444, which will be much heavier to edit with if the result is intended to be a proxy. An AVC 8-bit 4:2:0 file would be a better performing proxy since GPU hardware decoding is used these days.