ynput
AY-7352_Publish Resolution incorrect in web frontend
Please describe the issue you have encountered?
When rendering from Fusion on a different resolution than e.g. 1920x1080 the web frontend attributes when looking at the reviewable will still display 1920x1080 as attributes, even though the media may very well be a different resolution. Hence the displayed web frontend resolution is incorrect and does not match the video file.
There are two issues here: When rendering from Fusion with Extract Review set to resolution 0x0 (so that it preserves the rendered resolution from Fusion itself) does not work correctly - because it forces it to the "Comp frame format prefs" not to the resolution of the actual rendered media. That is due to it using the instance data here copied from here: . The rendered .mp4 will then incorrectly be forced to the resolutio of the frame format prefs. The second issue is - that it seems the attribute data on web frontend (on the representation) is incorrect, even if the actual rendered mp4 file is say 640x480 the web frontend will still display the resolution as 1920x1080. This may be due to that being the defaults for those attributes and the actual (correct) resolution metadata of the reviewable not being published along to AYON.
How to replicate the issue?
No response
Additional context:
link to discussion on Discord (might be a private channel)
This issue was automatically created from Clickup ticket AY-7352
Moved from ayon-fusion - however the ticket was not Fusion-specific. It happened for all integrations.
The issue is that (in older ayon server releases, e.g. 1.8.1) when playing a reviewable and going to attributes tab right side it would display the Resolution Width/Height.
- One would think that's the currently playing reviewable resolution, but it isn't.
- Then if you learn that those attributes are version attributes, you'd think that's the published version resolution. But we're not publishing along resolution info with versions (the integrator does not). The value you used to see was actually the folder or task resolution. In AYON 1.8.4 server ✅ at least now it shows nothing if the data is not explicitly set, which is much clearer because it wouldn't display invalid information then.
In AYON 1.8.4 it already does not display those values anymore.
I think we should:
- For a reviewable, be able to show the reviewable file's resolution, fps and metadata (likely to be served by backend). Because that'd then always be accurate and would also display for manually uploaded reviewables. This is actually what Random42 was looking for? Basically answering the: What FPS and resolution is this video I'm watching here?
- Separate from that, I think we should still need to make sure we publish along a width,height, etc with a version when we can - which currently the integrator does not submit along at all. Hence, requiring
ayon-corechanges and we should then move this issue there?- This may then also need to be clear in the frontend UX that this attributes you're viewing there are version attributes and technically have nothing to do with the actual reviewable file you're playing.
This may then also need to be clear in the frontend UX that this attributes you're viewing there are version attributes and technically have nothing to do with the actual reviewable file you're playing.
What's the logic here ? I am confused as to why we would display something unrelated to the selected item.
What's the logic here ? I am confused as to why we would display something unrelated to the selected item.
Attributes in AYON are configured in the Attribute settings.
There are some (required?) defaults, like resolution, frame start/end, etc.
Note how those have inherit enabled, which means that if it does not specify e.g. a resolution it inherits from the parent.
So the resolutionHeight for example inherits within the scopes:
- Project
- Folder
- Task
- Version
- Representation
As such, if version specifies no resolutionHeight it inherits it from a parent entity which I think is Task (but may also be Folder actually because I'm not sure how tightly coupled versions really are to tasks. @martastain may be best to answer that.)
The UI, before the recent AYON server releases would display these inherited values on the version attributes tab.. Now it doesn't. Whether that's intentional or a bug, no idea. (@Innders ?) But it does help with the fact that at least it doesn't show the incorrect data.
My proposal was to at least mark which values are explicitly set and which aren't - but in this particular case the attributes just not showing may be even better than "marking" it in a way someone doesn't know what it actually means. Whether it's confusing that it shows no data at all. Maybe?
Does that help?
I understand better now.
- Addons / Publishing
- We should make sure we ALWAYS set these attributes to avoid any confusion.
- I don't think we should attempt any backward-compatible fix given that attrib inheritance is a feature. Our code was just not doing what it should should have done all along.
- Front-end:
- Couldn't we display the inherited values differently (greyed-out or something) to distinguish them from set values ?
Front-end:
- Couldn't we display the inherited values differently (greyed-out or something) to distinguish them from set values ?
We do usually (e.g. see "inherited values" in overview page) - we just didn't here before.. and now they just don't display there currently (which is better than showing the wrong data.)
@Innders may need to clarify why these attributes don't show anymore currently.
We should make sure we ALWAYS set these attributes to avoid any confusion.
Yes - however, my assumption is that the client's biggest issue is that when watching a reviewable they are not seeing the resolution (and metadata) of the reviewable. As such, even if we'd fix host integrations and pass along version resolution. This does NOT necessarily equal the reviewable resolution.
Similarly, a reviewable file can be uploaded without ANY pipeline integration now in AYON 1.9.2 + reviewables can also be uploaded manually to an existing version on the web frontend (which can upload any video file to an existing version as extra reviewable). Those version attributes then having nothing to do with those reviewables.
I'd actually want to recommend that when you're watching a reviewable, you have access to the media's metadata and somehow make it much clearer that Version attributes != reviewable resolution, fps, etc. (there's a high likelihood they are similar). But it may very well be that the version is 1001-1100 but the reviewable contains a slate or other stuff, or that a reviewable may have been uploaded on purpose without handles). Meaning the reviewable can differ, very well, from the version attributes.
I agree @BigRoy. Let's make the reviewable metadata prominently visible in the player. @Innders, I believe the ball is in your court !