QuickSync H.264 Settings

[pandy]

I forget to add do conversion 444 to 420 yourself properly in first compression. If there is some proper way how to do it. Sorry for misunderstanding. Your english is perfect, my causes many misunderstanding. Sorry again.
Edit: for example 8 bit 444 to 10bit 420 Can't this help a bit?

My English is bad but i'm not native and self learned so if it can be read and understood then IMHO it is OK.

We can't do anything with 444 to 420 conversion - it is lossy and it is visible but acceptable for 99% population so why bother.
10 bit is always beneficial - http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

[jagabo]

Here is difference of two jpeg 100% quality slowest but subsampling 2x2 and 1x1 what I believe is equivalent to 4:2:0 and 4:4:4. The original image has 3 colors and is bellow the difference picture.

[Attachment 43814 - Click to enlarge]

[Attachment 43815 - Click to enlarge]
If you use any resize algorithm then difference will be much bigger. Even with neural network resize difference will be at least similar.
I hope, I did it properly. Any suggestion or what I did wrong is highly appreciated.

Bernix

My guess is the OP has small colored text (or other artwork) with very thin strokes. 4:2:0 subsampling is very obvious with that:

https://forum.videohelp.com/threads/319360-DVD-LAB-PRO-color-map#post1977264

But again, youtube will reduce any 4:4:4 upload to 4:2:0 so it the difference between an 4:4:4 upload and a 4:2:0 upload will be minimal.

[Bernix]

Test of bayer filter pattern. Of course square = pixel. Saves as jpeg, bellow is subsampling using jpeg. 1x1 = 444 2x2 = 420. Most photo camera is using 2x1 probably 411. And of course I know this is the worst possible case. Funny thing is that 444 in this case is smallest filesize but it is also irrelevant.

[Attachment 43830 - Click to enlarge]

[jagabo]

Note that exactly what you get with chroma subsampling will depend on the algorithm used to downscale and upscale the chroma.

And since cameras use bayer pattern sensors they are inherently something 4:2:0 at their best resolution.

[Bernix]

The image is created 8x8pixel resized to be viewable by nearest neigbour. So scaling i think has nothing to do, or I dont understand properly.
here are originals.

[Attachment 43833 - Click to enlarge]
[Attachment 43834 - Click to enlarge]
[Attachment 43835 - Click to enlarge]
[Attachment 43836 - Click to enlarge]
Bernix

[jagabo]

I wasn't talking about your upscaled images. But the algorithm that is used to convert from RGB or YUV 4:4:4 to YUV 4:2:0 and then to convert that YUV 4:2:0 to RGB 4:4:4 for display. Different programs/players use different scaling methods (point, bilinear, bicubuc, something else; MPEG placement, DV placement, etc.). So you'll get slightly different colors from different programs/players.

[Bernix]

I just used this settings

[Attachment 43840 - Click to enlarge]
And now I know that 2x1 is 4:2:2, so 1x2 should be also 4:2:2 with different subsampling"?", or it can be 4:1:1 which I missing in list? It is used for DV ntsc, but it seems to me be more destructive than 4:2:2 of course. And apparently 1x2 and 2x1 seems to me same in term of color "destruction". 4:1:1 should be similar to 4:2:0 of course.
And Bayer filter is based on human color perception, and all the square in its original size doesn't look much different. Because of greenish color.
Bernix

[jagabo]

The term "4:1:1" often refers to NTSC DV chroma subsampling where the luma is 720x480 and the chroma is 180x480. The term "4:2:0" is usually used when the luma is 720x480 and the chroma is 360x240 (or the chrome is half the width and half the height of the luma, whatever the frame size). Both have 4:1:1 ratios of Y:U:V.

I don't know what software you're using but 2:1 vs. 1:2 is likely whether the chroma is subsampled horizontally or vertically.

[Bernix]

Hi Jagabo,
I'm using krita for this, probably gimp should be better, but it has similar functionality. There is also interesting filter, that converts channels of picture to layers. In this example is used channels to layers (HSV). RGB and CMY(k) colorspaces gave predictable result RGB 3 layers CMY(k) four layers, HSV is really interesting. It seems to me it separate color from its bases. When I apply it on picture that I posted earlier, I got this layers (I manually create new image with both in one layer (instead of 2)). Just don't understand, why in bayer pattern (1st on left) almost white space but 2 colors from which one (green) is most probably pure white, i don't understand it well.

[Attachment 43841 - Click to enlarge]
But it works great as I mentioned earlier, for separate chroma, if I understand the thing I get by this operation. Maybe fully saturated colors are displayed as no "luma"
But in bayer pattern there, is in rgb form Red (254,0,0) Green (0,255,1) and Blue (0,0,254) and it was generated by Bayer pattern generator.
If you have some picture, with known subsampling, send it to me (if you want) and I can try "separate color". It is very easy to see in usual photography or real life pictures.
This post is too long for me, so at the end I'm absolutely lost, and not sure about meaning of it, because of several correction....
Bernix

[jagabo]

The images look exactly like what one would expect. https://en.wikipedia.org/wiki/HSL_and_HSV

Keep in mind that HLS and HSV is different from video YUV where R, G, and B are weighted differently in terms of intensity. For example, with rec.601 the intensity (Y) is calculated as:

Y = 0.299 * red + 0.576 * green + 0.114 * blue

So, for example, a full intensity pure blue becomes a fairly dark shade of grey.

https://en.wikipedia.org/wiki/Color_matrix#ITU-R_BT.601_conversion

In AviSynth you can visualize Y, U, and V channels with

Y = ColorYUV(cont_u=-256, cont_v=-256) # or Tweak(sat=0)
U = UtoY()
V = VtoY()

[Bernix]

Hi,
there is only support for YCbCr colorspace but according to Krita settings, there is not opensourced ICC profil, so I can't create picture at least in this color space.
I can actually decompose picture to YUV and even with transparency, but it is all in gray scale. So it is useless. And when create lossless bpg picture, from 8x8 in YCbCr colorspace, it came out really horribly looking (all was too much smoothed) definitely not lossless.
Thank you for info Jagabo.
Bernix

[BartZLederman]

I've been using QSV for close to a year, and on a second system I added a Radeon graphics card with NVENC. My impressons so far is that QSV is indeed better.

But I am very, very frustrated with one aspect of using QSV. I can't find a way to actually produce a VBR video, everything is only CBR.

There is a previous mention of there being a VBR option with h264_qsv but I can't find it. I've been through the entire list of options several times (it is printed here in this topic) and cannot find a combination of options that will produce VBR.

If I do this:

-look_ahead 1 -look_ahead_depth 96 and also have -q:v 30 I get an error:

[h264_qsv @ 00000000001bda40] More than one of: { constant qscale, lookahead, VCM } requested, only one of them can be used at a time.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

which doesn't really help me find the problem

Of I remove the -q:v I get:

[h264_qsv @ 000000000053d800] Selected ratecontrol mode is unsupported
[h264_qsv @ 000000000053d800] some encoding parameters are not supported by the QSV runtime. Please double check the input parameters.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

If there is a way to get variable bit rate encoding using h264_qsv could someone please take pity on me and post a complete ffmpeg command that will encode an MP4 video with variable bit rate? Or point me to documentation that has a COMPLETE command line that actually works? Or, contrarily, could someone point out a statement from Intel that says that in fact VBR is not supported?

Thanks very much.