Changes between Version 4 and Version 5 of Ticket #9132, comment 24


Ignore:
Timestamp:
Jan 15, 2022, 1:24:16 PM (5 years ago)
Author:
Balling

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #9132, comment 24

    v4 v5  
    33I think I did analyse it right, if source file has no BT.709 matrix libx264rgb sets identity still after your patch, if BT.709 matrix is there libx264rgb does not set Identity, unspecified is used after your patch. While '''for ycbcr matrix is not needed''', unspecified can work just as good, for RGB identity is needed and unspecified will lead to defaulting to ycbcr (as happened with "marked as full range4:4:4 YCbCr"). I came to this idea to test back from ycbcr back to rgb today, in the morning. So... I could not have applied patchwork's patch to test this. Sorry.
    44
    5 Anyway, the problem is that I though that your patch while resetting the matrix to unspecified will still in the end apply some matrix to VUI. I was wrong. Sorry about that too. You said so yourself: "Then the color space information could be reset accordingly (since currently the problem is that av_frame_copy_props does indeed copy all properties from the source AVFrame to the output AVFrame, and nothing touches the colorspace value in the structure)."
     5Anyway, the problem is that I thought that your patch while resetting the matrix to unspecified will still in the end apply some matrix to VUI. I was wrong. Sorry about that too. You said so yourself: "Then the color space information could be reset accordingly (since currently the problem is that av_frame_copy_props does indeed copy all properties from the source AVFrame to the output AVFrame, and nothing touches the colorspace value in the structure)."
    66
    77P.S. BTW, I did not suggest that YCbCr --> RGB issue is related to your patch. Will recheck again.