Update client-side video upscaling for multi-pass shader support

[adglkh]

Update client-side video upscaling section for multi-pass shader support in streaming SDK.

[adglkh]

It's targeting for 1.24 release and for now, it's pending until the following canonical/anbox-streaming-sdk#55 is landed.

[keirthana]

LGTM

[adglkh]

@keirthana we need to whitelist the git revision from the image version.
E.g.

The HTML pages are in _build.
. .sphinx/venv/bin/activate ; python3 -m pyspelling -c .sphinx/spellingcheck.yaml -j 4
Misspelled words:
<htmlcontent> _build/reference/component-versions/index.html: html>body>div>div>div>div>article>section>section>section>div>table>tbody>tr>td>p
--------------------------------------------------------------------------------
ba
--------------------------------------------------------------------------------

And the revision number recorded in the table is
| jammy:android13:amd64 | 1.23.0-20240809080136.4a6ba963a |
This revision number changes dynamically with each release. How can we resolve this without hardcoding the revision number in .wordlist.txt?

[keirthana]

@keirthana we need to whitelist the git revision from the image version. E.g.

The HTML pages are in _build.
. .sphinx/venv/bin/activate ; python3 -m pyspelling -c .sphinx/spellingcheck.yaml -j 4
Misspelled words:
<htmlcontent> _build/reference/component-versions/index.html: html>body>div>div>div>div>article>section>section>section>div>table>tbody>tr>td>p
--------------------------------------------------------------------------------
ba
--------------------------------------------------------------------------------

And the revision number recorded in the table is | jammy:android13:amd64 | 1.23.0-20240809080136.4a6ba963a | This revision number changes dynamically with each release. How can we resolve this without hardcoding the revision number in .wordlist.txt?

An easy and dirty hack is to enclose the revision in backticks. If it is fixed as ba, we could include it in the custom_wordlist but if it is a dynamic one, use backticks for now until we have a better solution.

[adglkh]

An easy and dirty hack is to enclose the revision in backticks. If it is fixed as ba, we could include it in the custom_wordlist but if it is a dynamic one, use backticks for now until we have a better solution.

A: I guess you meant to say If it is *NOT* fixed as ba, we could include it in the custom_wordlist...

but if it is a dynamic one, use backticks for now until we have a better solution.

A: As I mentioned above, they're dynamic ones as always, in the next patch release, that would be another new one in the format like 1.23.0-2024080918xxxx.<git-revsion>, hence adding the word to the custom_wordlist is not an option.

Also adding backticks doesn't work for me either when I ran the spellcheck locally.

[keirthana]

An easy and dirty hack is to enclose the revision in backticks. If it is fixed as ba, we could include it in the custom_wordlist but if it is a dynamic one, use backticks for now until we have a better solution.

A: I guess you meant to say If it is *NOT* fixed as ba, we could include it in the custom_wordlist...

No, I meant if it is fixed, meaning if it will always be 'ba', we can include that in the custom_wordlist so that the spellcheck would ignore it. Anyway, I can see that it keeps changing

but if it is a dynamic one, use backticks for now until we have a better solution.

A: As I mentioned above, they're dynamic ones as always, in the next patch release, that would be another new one in the format like 1.23.0-2024080918xxxx.<git-revsion>, hence adding the word to the custom_wordlist is not an option.

Also adding backticks doesn't work for me either when I ran the spellcheck locally.

I have pushed a change with the backticks, if you rebase your branch on top of main, that should do it.

[adglkh]

An easy and dirty hack is to enclose the revision in backticks. If it is fixed as ba, we could include it in the custom_wordlist but if it is a dynamic one, use backticks for now until we have a better solution.

A: I guess you meant to say If it is *NOT* fixed as ba, we could include it in the custom_wordlist...

No, I meant if it is fixed, meaning if it will always be 'ba', we can include that in the custom_wordlist so that the spellcheck would ignore it. Anyway, I can see that it keeps changing
A: Okay, sorry for the misunderstanding.

but if it is a dynamic one, use backticks for now until we have a better solution.

A: As I mentioned above, they're dynamic ones as always, in the next patch release, that would be another new one in the format like 1.23.0-2024080918xxxx.<git-revsion>, hence adding the word to the custom_wordlist is not an option.
Also adding backticks doesn't work for me either when I ran the spellcheck locally.

I have pushed a change with the backticks, if you rebase your branch on top of main, that should do it.
A: thanks for the fixing.

[ajanon]

LGTM