-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wrong color-space metadata after encode from RGB #281
Comments
Thanks for catching this issue, and I'll look into it. |
Hi @xhaihao Any update on this issue? Thanks. |
For example:
The output is bgra(pc, gbr/unknown/unknown, progressive)
The output is bgra(pc, bt709/unknown/unknown, progressive)
The output is bgra(tv, bt709/unknown/unknown, progressive) The color properties are different in the above examples, however out.0.rgb, out.1.rgb and out.2.rgb are same.
|
You may use |
thank you much for looking into this
I am aware of the fact that it just sets input metadata. Anyways, if I deduced it correctly, so QSV does unconditional conversion from (full-range) RGB to limited-range BT.601 YCbCr (please correct me, if I am wrong). In this case, I believe that in the HEVC metadata there should be limited-range YCbCr, not full-range (optionally also BT.601). (The conversion will be correct only for input RGB pc/bt601, of course.) Currently even though the input RGB using pc/bt601 is converted to limited-range YCbCr, while in codestream metadata remains PC/full range (seems to be just copied from the |
Hi @xhaihao, Any thoughts on Martin's latest information? Thanks, |
@alatteri Yes the driver does an internal conversion, however the default range (full range) is set by FFmpeg, not QSV. Note the two commands below have different color ranges, it is full range in
@XinfengZhang Any thought about this issue ? Is it possible to expose the capability in VA-API level so that user may control the conversion ? |
plan to add a new interfaces to report the color space support for a given config + format TBH, because no requirement previously , I defer it. |
When do you think you'll be able to get this merged? I see it has been pending for a very long time. Thanks,
@MartinPulec Do you think this is the fix we need? ->
|
this refers to CESNET/UltraGrid#341
hi, when QSV is compressing from a RGB format (BGRA for now; but applies also to X2RGB), it converts unconditionally to limited-range YUV BT.601, but sets stream metadata according to AVCodecContext::color_primaries and AVCodecContext::color_range. If those are not set explicitly, it sets full-range to metadata, anyways.
Please see following test case:
input
ffmpeg -y -f lavfi -i color=#ff0000 -t 1 -pix_fmt bgra [params] -c:v hevc_qsv out.h265
output evaluation
input RGB=[0xff,0x00,0x00] corresponds¹ to full-range YCbCr BT.601 [76,85,255]=[0x4c,0x55,0xff], limited range [65,91,237]=[0x51,0x5b,0xed] ²
¹ computed using this coefficient; Cb,Cr coefficients are offset by 128
² or Y=67=0x53 if using Y range 16-240, which I think is correct
evaluation:
-colorspace bt709
- [0x51,0x5b,0xef], mediainfo: "BT.709,Full"-colorspace bt709 -color_range tv
- (ditto), mediainfo: "BT.709,Limited"-color_range tv
- (ditto), mediainfo: ",Limited"-colorspace smpte170m -color_range tv
- (ditto), mediainfo: "BT.601,Limited"So, in all cases, the output is in limitted-range YCbCr 601, but metadata are correct only in case 5 (and also 4, assuming that implicit value is OK).
PS:
-vf lavfi -i color=#ff0000 -t 1 -pix_fmt bgra
seems to convert to [0x00,0x00,0xfd,0xff] - the swscale conversion is not entirely accurate but I don't know how to produce single-color RGB directly, without conversion from YUV (-vf lavfi -i color
produces YUV)The text was updated successfully, but these errors were encountered: