Skip to content
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

va: limit to VAProfileAV1Profile2_420 #832

Closed
wants to merge 1 commit into from

Conversation

davidwuAMD
Copy link
Contributor

Some hardwares do not support a full set of AV1 profile2, in this case use a subset instead. At the moment, VAProfileAV1Profile2_420 is for supporting 12-bit 4:2:0.

@davidwuAMD davidwuAMD mentioned this pull request Aug 12, 2024
@davidwuAMD
Copy link
Contributor Author

this is to address the issue in #828

@davidwuAMD
Copy link
Contributor Author

@XinfengZhang, any concern about this patch? please let me know I can take a look.

@davidwuAMD
Copy link
Contributor Author

wondering if this change can be merged? Am I missing something?

@XinfengZhang
Copy link
Contributor

I am ok to merge it , but still not understand why profile + vaSurfaceAttrib could not report the restriction, such as 12bit 422only could use profile2+P010 format. of course, it will be more complex than current solution.

@davidwuAMD
Copy link
Contributor Author

OK - I will see if I can find something with profile + vaSurfaceAttrib. I think there could be a reporting issue (vainfo) as it cannot show 420only if we did not define a profile for it. (but I need to look into more details to be sure).
When will be the next libva release? I'd like to see if we need to apply this merge or not before that.

@XinfengZhang
Copy link
Contributor

suppose next release will happened by end of this year.
I am ok to merge current change, because it is simpler than profile+vaSurfaceAttrib. application just need to query the profile list. of course, from other hand, if backend driver want to support both. they have to report both profile.

I am thinking whether there are similar problem with other codec, and whether we need to use "profile + surfaceAttrib" to keep behavior consistent.

just like AV1 profile0, how to clarify driver support monochrome or not? ho to differentiate driver support 444 8bit or 444 10bit for AV1 profile1? and suppose there are also some problem with VP9.

so, both solution is ok to me, feel free to ping me to merge current PR.

Some hardwares do not support a full set of AV1 profile2, in this case
use a subset instead. At the moment, VAProfileAV1Profile2_420 is for
supporting 12-bit 4:2:0.

Signed-off-by: David (Ming Qiang) Wu <[email protected]>
@XinfengZhang XinfengZhang force-pushed the subset_AV1Profile2_420 branch from ac3349f to 20a8be5 Compare November 27, 2024 12:49
@davidwuAMD
Copy link
Contributor Author

Hi @XinfengZhang - either VAProfileAV1Profile2_420 or VAProfileAV1Profile2 should be OK for mesa or libva. The real issue is in ffmpeg which uses the best match profile/format to decode video. Once ffmpeg enables full set profile2 support then ffmpeg will use p012 to decode a YUV444 video clip even though it is not supported in mesa (only 12bit YUV420 is supported).

@davidwuAMD
Copy link
Contributor Author

we have a solution for ffmpeg so it won't do unexpected fallback. in this case - we can keep VAProfileAV1Profile2 - I can drop this MR -

@davidwuAMD
Copy link
Contributor Author

let me drop this PR as there is a solution in ffmpeg to check the RT format so it won't use an unexpected format to decode

@davidwuAMD davidwuAMD closed this Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants