search

getavalon / core

The safe post-production pipeline - https://getavalon.github.io/2.0
MIT License
218 stars 49 forks source link

Internal Review #132

Open mottosso opened 7 years ago

mottosso commented 7 years ago

Goal

Enable internal review of published material.

Motivation

Every change contributes to the greater whole and we currently validate our output such that we can ascertain that the things you published lives up to a certain standard.

But some things are difficult to validate, such as whether it "looks good" or "follows direction" or "is what the director wants". For that we need review. Some mechanism with which to lay eyes on a change and (1) determine whether it moves in the right direction and (2) provide feedback on how to better it.

Options

  1. Shotgun implements Review, an online portal in which to view, make notes and annotate published media.
  2. ftrack implements something similar
  3. There are standalone versions available as well, such as Frame.io and Wipster
  4. On GitHub, there is the pull request. A different approach to reviewing published material in which each change goes through an intermediate step before arriving in the main repository.

A pull request is a unit of change that a user would like to integrate into the main pipeline. It works like this.

  1. The pipeline is "forked", essentially copied in full
  2. A change is made to this copy
  3. A request is made to integrate the changes from this copy into the original.
  4. Others provide feedback on the change, and changes continues to be made as per the feedback
  5. Once everyone is happy, the changes are "merged" into the original, thus progressing the project forward.

This essentially means that, as opposed to Shotgun and ftrack, versions are reviewed before they become public.

Either of these options are a great step forward, which one to pick is up for discussion.

mottosso commented 7 years ago

Here's a mockup for a pull-request like workflow.

workflow3

Technically, what would happen is that before an asset it "integrated" - that is, written into the publish/ folder - it is sent for review. Once the review is "approved", the files get written into the publish/ folder.

Some requirements for this.

  1. A new artist-facing publishing GUI, with comment and annotation capability
  2. An alternative web-based Pyblish validation GUI, possibly based on #99, with commenting and annotation capability.
  3. Running publishing on the server, which would require all relevant software to be available to it, including Maya and Nuke and relevant plug-ins.
  4. Ability to communicate between web-ui and server, distributed online for remote artists, which means some form of login-based security.

Publishing GUI mockup.

 ______________________________________________________
|_____________________________________________________x|
|                                                      |
|  Title                                               |
|  __________________________________________________  |
| |                                                  | |
| |__________________________________________________| |
|                                                      |
|  Body                                                |
|  __________________________________________________  |
| |                                                  | |
| |                                                  | |
| |                                                  | |
| |                                                  | |
| |                                                  | |
| |                                                  | |
| |__________________________________________________| |
|                                                      |
| Annotations                                          |
|  __________________________________________________  |
| |                        |                         | |
| |                        |                         | |
| |                        |                         | |
| |         front          |         right           | |
| |                        |                         | |
| |                        |                         | |
| |                        |                         | |
| |------------------------|-------------------------| |
| |                        |                         | |
| |                        |                         | |
| |                        |                         | |
| |          top           |       perspective       | |
| |                        |                         | |
| |                        |                         | |
| |                        |                         | |
| |________________________|_________________________| |
|                                                      |
|                                    _______________   |
|                                   |               |  |
|                                   |_______________|  |
|______________________________________________________|
mottosso commented 7 years ago

Some more thoughts on this.

At the moment, when the artist hits "File -> Publish" the publishing GUI appears. Once published, the files appear on the server and is accessible by others.

Internally, what happens is three things.

  1. Files are extracted to a temporary storage location, on the local computer, e.g. c:\tmp.
  2. For each extraction, files are transferred into a common location, referred to as the stage. At the moment, the stage is located in the user's working directory.
  3. Once all extractors are finished and it's time to integrate, the files within the stage are lifted out and into a unique version for the given asset currently being published.

In place of (3), we could instead keep the files in the stage and generate a web page like the one shown above.

One this page we present the results of extraction, including any images and video but ideally one central "showpiece" like a playblast that others may comment on (and make annotations on).

Once feedback is complete, the original step (3) could kick in and create a unique version on disk for others to access. This would also be where one could decide whether a publish is "approved" or simply "just a new version".

Hosting

Although we could extract playblasts and turntables onto the server, and use this on the generated web page, there is an associated cost to this which is that whenever anyone watches a playblast online, including clients, our file server takes a performance hit. The same goes for when artists are publishing and working with large caches or renders, the reviewer would be stuck with the buffer symbol.

An alternative is hosting elsewhere, such as on a dedicated file server which would solve the "conflict of interest" in terms of who gets the most performance.

However the cheapest and most performant long-term option might be to host it on something like YouTube.

YouTube offers free unlimited hosting and is guaranteed to have 100% up-time and all the bandwidth we would ever need, no matter how many reviewers are watching in parallel.

I see a couple of problems with this approach.

  1. Our internal videos would become available for anyone to see
  2. Our internal videos would fall under the T&C of using Google (e.g. CC licensed)
  3. We'd be stuck with their native player
  4. Because of (2), we would be unable to "chain" playblasts together to form a sequence of shots
  5. Likewise due to (2) we would be unable "stack" playblasts to enable comparisons to be made
  6. Finally also due (2) we would have trouble implementing annotations, drawing on video.

Points 3-6 could be solved by referencing the video file directly and playing it back ourselves. As it turns out, most videos on YouTube can be referenced like this.

decodeURIComponent(ytplayer.config.args.url_encoded_fmt_stream_map.split(",")[0]);

Point 1 could be solved by either making the video unlisted, which would make it (supposedly) impossible for anyone to find without being given a direct like, or private in which case we could register a "bot"-like account with sole access to the videos.

Point 2 is the potential dealbreaker and the reason we might want to consider hosting the videos ourselves, on a dedicated file server.

mottosso commented 7 years ago

Potential option for creating textual annotations on video.