Clip/Shot Updating Feature

[Chadt54]

As a user coming from The Foundry's Hiero, Hiero has a feature that allows you to click on clips in the timeline of the "bin" (project available clips window) and change the clip/shot's version up/down to newer and older versions. The versioning function was based on a regex (actually, it is based on a python script that you can custom write that returned a list of all the versions available for each clip) that allowed the software to search and discover what versions of clips are available on the server (at startup, or when you executed a versions re-search-and-discover).

You could also tell the program to iterate through all clips in the project and update to their newest versions.

This feature is useful for animation studios that create multiple iterative improvements to each clip, and instead of reimporting clips every time there's a change, users can just tell the program to find all the newest clips available and update the project automatically.

If you could implement some kind of (flexible) versioning system like Hiero has, then it would most likely end up being one of the biggest features of the application. And you'd have larger production studios starting to use Olive.

• One of the functions as an example, can be executed through the python scripting interface, or the UI https://learn.foundry.com/hiero/developers/1.8/hieropythondevguide/api/api_core.html?highlight=version#hiero.core.BinItem.maxVersion

[frink]

If we add scripting as suggested in #806 we may be able to allow a similar interface...

[sobotka]

I believe this sort of a feature fits in well with logging / review. I wonder if there is a viable schema for using a SHA hash to index revisions?

[Chadt54]

Hmm, if you're suggesting hard coding in the method for indexing/discovering revisions/versions, then I would say this is not a good decision. Ultimately only the end user can decide their project structure and how versions are grouped.

I recommend there to simply be a generically provided "default" python script that searches for clips just based on (probably) a number appended to files (like 001, that isn't the frame number on sequences), and then the wiki can just provide a tutorial on how to modify this script to suit the user's needs.

And in terms of saving a project file, you can just save the path to the file, and the python script can just use the path string as a starting point to discover all the other versions.

Trust me on this, I wrote scripts that did exactly this for a studio with approximately 300 employees. Each project is different, depending on the director, so there is no possible way for the developers of Olive to predict how versioning shots will work for the end user (even I never knew how the next project would be organized, it was a moving target). It's a futile attempt to try. So just save the clips as normal, but provide access the current clip's path with a method to edit the script that searches and discovers the clips.

Basically though, if Olive has functionality that allows end user's scripts to access the entirety of the UI through Python/PySide, and allows functionality to replace clips in the timeline and in the project bin, then the user can just program the whole versioning system themselves, although having the basic functionality available from the start would provide a stepping stone and make it faster to get up to speed with implementing the functionality they way they would need it (as versus starting from scratch).

(There is a possibility I completely misunderstood your comment though, so correct me if I'm mistaken)

[sobotka]

I’m simply saying that having a hash of a particular media state is useful. Implementing some basic functionality such as revision etc. off of it for logging / revision would also be a pretty decent basic option for logging / revision.

Given right now there is no cache, no project saving, etc., full blown scripting would be a time zone or six away. Baby steps...

[Chadt54]

I'm not rushing anyone, just helping guide the trajectory of development as much as possible.. hehe

The project can move at whatever pace it wants. Just glad it's being developed at all, but hoping it doesn't take a turn for the worst and end up in the other pile of almost useless open-source NLE...

[sobotka]

Basics are hard. A SHA hash though is probably a pretty “in scope” concept for logging / editorial, and would help identify when content has changed.

[Chadt54]

I'm saying though, you don't need to know if the content is changed. A version file itself (usually) wont change (and even if it does, just use the file path and load it in as if it's the first time, replacing the file same same way you will when switching to newer/older versions). Instead, a newer version would get uploaded to the central file server, the software would only need to be able to make the switch to the newer version (after discovering there is a newer version), or making a switch to an older version for use with comparing changes (to know if what has been changed has 'improved' from the last version).

I personally don't see why you'd need to keep such close tabs on a file as much as to need to check hashes of it. This isn't versioning like code version management (like Git). I think you're overthinking it.

The path to the file itself should serve as "hash" enough.

Someone should be able to delete and re-upload a new version of a video file and the program be indifferent to this change, only caring that the file and path are identical to the file+path stored in the project file's data. This change would change the file's SHA hash, but the program should not throw an error due to this change. Which is why you shouldn't be storing hashes of the file itself.

[sobotka]

Paths are fine for relinking and accessing external media, and I would expect even the most broke NLEs have URI / paths, so it was assumed you weren’t suggesting implementing paths as that would go without saying.

I believe hashes have low overhead, and could help with referencing comments or solving collisions on media.

Within your example, the relinking would happen with a changed file, and a new hash would result because the file changed. That doesn’t change anything. It does however also solve the need to iterate through versions, without more complex semantics of evaluating paths and filenames.

Not sure I’m the one here overthinking it. ;)

[Chadt54]

What do you mean by this: "It does however also solve the need to iterate through versions"

I still don't believe I agree.

[sobotka]

A hash is a very quick way to test if the two files are the same. That is, imagine changing a file in a short film or music video and comparing two edits that should be the same but are not. The hash can give an “absolute” insight into the URI / path / file if the file name has remained the same, and changed at a particular date.

A hash can be a nice way to keep order where collisions would result otherwise. They are also so small as to not be a burden in project file serialization. Just seems like a simple little tool that can help bring sanity to a project.

[Chadt54]

"A hash is a very quick way to test if the two files are the same."

I know what a hash is.

"That is, imagine changing a file in a short film or music video and comparing two edits that should be the same but are not. The hash can give an “absolute” insight into the URI / path / file if the file name has remained the same, and changed at a particular date."

A hash only tells you even if a single bit in the file has changed, this flag of difference is practically useless in a production environment. If you have two versions of a shot, you'll either have a version number added to the file, or alternatively you'd have a file with the same name but placed into a folder that is versioned.

If you're replacing a file with another file and you don't know if they are the same or not, you have bigger problems on your hands dealing with basic organizational skills. You should know what files you're dealing with, if for some reason not, you can simply use the command line tool "diff" (or just compare their hashes, of course), it takes 5 seconds, and should practically never be needed in an organized project.

But I digress, what I am proposing in this thread is not a manual file replacement, I'm proposing automatic replacement through a conventions based versioning structure on a file server (or even local computer). Usually through files stored and versioned on a server placed there through other software that manages the versions, usually through custom export tools. (Or, alternatively, very careful naming and organization if no tool exists).

As hash is not useful here.

"where collisions would result otherwise"

What collisions? This makes no sense.

You don't version control media the same way you version control code. They are fundamentally different.

[Chadt54]

Well that deleted comment was pleasant...

Anyways, do whatever you guys want. I don't really care. Not worth the trouble of dealing with people swearing at me over it.

[frink]

is there a way to link the SHA hash with an incremental version? Wouldn't this accomplish everyone's objectives? Or is the issue managing that extra version file?

[Chadt54]

I don't understand why we need a SHA hash at all in the first place. To me, using a SHA hash couples too concretely the file to the project. That's why I was suggesting only keeping track of the file path, and when the application opens to just update anything accordingly if there are any changes to the file located at the path.

What do you foresee will be the issue if we don't use a SHA hash?

[sobotka]

I only suggested a hash as a quick and dirty way to detect if a file has changed.

Linking and relinking media is something that would be dealt with via the interchange component.

[frink]

If we have a historic file that notes hash changes we will have the incremental version that was requested. Otherwise, unless we are importing media from another place it is hard to integrated and move media around if it is changed. Versioning without a workflow is worthless. I think answering questions on workflow could be helpful to understand this issue...

What is the workflow we are trying to empower and shape here?

[Chadt54]

Basically, just look into Hiero, by The Foundry.

Copy that versioning system.

That's all I wanted.

[ghost]

@Chadt54 , are there any resources or media that explains how Hiero's versioning system works? I'm interested to see

[Chadt54]

https://learn.foundry.com/hiero/current/content/timeline_environment/versioning/versions_and_snapshots.html

[Chadt54]

https://learn.foundry.com/hiero/developers/2.0/hieropythondevguide/examples/versioning_example.py

[Chadt54]

https://www.youtube.com/watch?v=_EYQOgRLQJQ

[Chadt54]

She's using an entire Nuke graph for the clips in the video, but it doesn't need to be a Nuke graph-like thing. Just a pointer to a video file or frame sequence.

[frink]

I think this folds into the distributed workflow stuff that I was talking about a couple months ago...

What is the reason for these version? Are these sequence versions or video clip file versions? How are they used in practice?

Thanks for all the great info. Keep it coming. Really interested in distributed teams workflows.

[Chadt54]

Usually when you are creating an animated film, the animators (or compositors, or anything else that needs to iterate) will render out a version they have completed. Usually there's a tool in place that will automatically name the rendered files to append a "_v001" "_v002" every time a new version is rendered. Then, a director can open up the application, and bounce around through the versions to see if what has been submitted is an improvement to the previous submission, a quick A/B comparison, and in context with the previous and post shots to make sure that things are fitting nicely in the overall sequence. If a version has an issue, the director can then send back feedback, a new version can be made, and sent back, the director can click the "Search for new versions" and then update immediately to the newest version without even reopening the project, or navigating through any folders to find a new version.

It can be for either image sequences or video files. Hiero treats image sequences and video files the same, as if they are both basically just video files.

[Chadt54]

Also, when opening a project, all the clips in the bins and on all the timelines can easily be updated to all the newest versions that exist on the server (by right clicking and using some menu, just opening the project shouldn't update everything by default, whatever current versions that are set in the project should remain that way until the user has triggered the project to update everything). The NLE can iterate through each shot/clip in the bins and timelines and find the newest "max" version, and swap the current files out with those automatically. And just like that, everything is up to date.

[Chadt54]

Versioning Up/Down/Min/Max can be done at different levels, at the root of the project which will update everything across the entire project, or just for timelines/sequences, or only for one shot/clip (whether that be one sitting on the timeline, or one sitting in the bin)

[sobotka]

If you can Chad, can you consolidate everything into a single post? It would help to keep everything in a concise summary format, with points. It would also solve notifications going bonkers for the folks who have global notifications.

[Chadt54]

Sorry, I'll be more careful about that next time

[frink]

@Chadt54 There are a few points of clarification that make this process interesting...

Clip length... This particularly affects timelines for editors, composers and foley. As I've noted in other places, ideally the sequence length should be set before adding or updating sound. However, the reality is much more complex. Often sound is reworked along with everything else. This is not only true in animation but for any composited scenes or emotionally complex sequences...

So how do we handle changing clip length with versioning?

Approval... In a complex process like this, things are often sent back for rework multiple times. In these scenarios, there may be several steps waiting on other people. Without tracking approval, extra rework will be done because approval is assumed. This leads to rigidity in the process. Without tracking approval, nobody knows what is safe to work on or what should be avoided.

So how do we track approval throughout this complex process so every party works on stuff in a quasi solidified state?

Communication... Often in this crazy interconnected workflow creative people need to submit ideas of what could be and proof of concept work that is not really fleshed out yet. It becomes important to communicate about how all these clips relate to idea s being discussed. Maintaining this sort of discussion around a team creation is difficult and not unique to video editing. Any distributed team has this problem. (Heh, we are using such a system right now in Github Issues)

So how do we keep commentary relevant to the version work being done?

Transport... In a distributed team there is also the problem of transporting the new versions between one another to keep everyone on the same page. The submitted versions need to be accessed by other members of the team. Often on the other side of the world. Proxy files become a must in this context if you're working on a lengthy 8k feature...

So how can we transport both the originals and the proxies to allow quick updates in edit changes?

---

I guess my point in all of this is that it's not as simple as versioning. There has to be branching, approval and commentary to solve the underlying needs. This is more than versioning files. It has to do with everything that a distributed version control system does. To make this work for our use case, it needs to do all of this with binary files - so stock git isn't an option...

Sadly, I've not seen anyone come up with a good system for all of this yet. In any of the media industries versioning is becoming a bigger and bigger pain. Ardour does one of the best jobs of any media system I have seen with its "snapshots" feature. (Ardour is an audio system.) This could be implemented in Olive at the sequence level and allow multiple snapshots to co-exists for the same project and then replace various subsequence with their more recent snapshot renders... (I do this now in lange audio projects in Ardour)

When we're dealing with a full scale movie we've got everything from print media to video sequences to audio mixes that we have to wrangle. It's tough to keeping any of it straight. The first time I saw someone successfully do this was the LOTR team working on three continents. They have a very good Special Feature section on workflow and file wrangling of their distributed team. Pretty interesting stuff. Really puts things into perspective on what a modern movie workflow can look like...

I don't think Olive should solve the versioning equation by itself... We probably need to tie into a greater ecosystem of a specialized VCS for multimedia files. (I know a few exist but nothing is well adopted and I don't think anything is open source...) If we let that VCS handle the heavy lifting on versioning then all we would need to do is make sure that we had something like "snapshots" to allow different versions to coexist.

Assuming that the VCS works similar to git allowing branching and merging something like GitFlow with it's control structures could be implemented rather easily with a simple interface inside Olive for administering version approval, comments and sidestepping the need for automated adjustment to changes introduced by changes in clip length...

[Chadt54]

I wrote most of the tooling that coupled together Hiero with Shotgun software for a team of ~300 people. So, I understand it can be complex issue. Hiero, by default doesn't solve a lot of issues that exist, but they have designed a good framework to allow customization of the software to fulfill each studio's needs.

The default versioning system in Hiero wasn't even enough for our studio, but I relied on it heavily as a base for my development. And it didn't really take that many changes to suit my company's needs. So, it's not a bad system.

Anyways, in the end, probably with a strong scripting functionality, versioning can be left to end users to decide and implement themselves. But, it's good to at least have a basic default system that suits a majority and can act as a starting example for people who's needs it doesn't fully meet.

[frink]

@Chadt54 After looking at your Github contributions I wonder if Gaffer might be a piece of the puzzle for this whole version/approval/workflow thing using their node system the way Image Engine does. You've commented a few times on Gaffer so there is obviously some experience there...

How do you foresee Gaffer plugging into Olive?

[Chadt54]

Gaffer really has nothing to do with NLEs, besides some very basic image compositing that it's really not meant for, it's a 3d scene assembly and look development application. It also doesn't really have anything to do with versioning or approval.

I don't really foresee it plugging into Olive, besides Olive ingesting the rendered sequence images it produces. But, that data is like any other sequence of images.

Their node system revolves around an alembic style 3d scene hierarchy, and is not really a 'general-purpose' node system. (EDIT: Their front page says the node data is customizable, so it could be useful for something for Olive if you guys wanted, as long as the licenses for both applications agree I assume.)

Usually the pipeline goes 3d-Software >> 3d Alembic Cache >> Gaffer (>> Renderer) >> Natron/Nuke/Fusion >> NLE

So, Gaffer is two (or three, depending on how you look at it) steps away from Olive.

Gaffer is also meant to be embedded into 3d applications like Maya.

[frink]

Some of the Gaffer talks I watched seem to indicate that Gaffer was used as part of their approval process. Seemed odd to me, but I figured you would know better than me since I don't do much in the animation world.

I know that we are talking about redoing things node-wise internally so Gaffer may be worth researching even if we don't use it just to understand internal code structure. The BSD 3 Clause is GPL3 Compatible.

It's obvious that Gaffer is meant to embed in other apps. In theory the node graph could be used to represent an approval workflow. However, That's neither here nor there...

---

So to get back to this feature request...

The real goal is automated or at least simple updatint of shots based on incremental naming. SHAs don't solve this problem for you because the old media still exists. The new stuff just supersedes the old. You need a way to replace the old clips with new clips...

In theory the simplest approach would be a [replace clip] option. If it allowed the possibility of rippling the timeline then most problems are solved. Assuming this could also be done with child sequences, this should also fit most of my proposed use cases as well.

As far as incrementally increasing every clip or showing which ones are stale, that may be more complex than we want to go right now. But replacing clips seems like a pretty reasonable feature. I'll have to try it tomorrow - may already be there. I just don't remember off the top of my head...

[sobotka]

I am going to roll this into interchange under #310, given it is about linking and relinking assets.

[frink]

Thanks.