| |
| ▲ | tatersolid 5 days ago | parent [-] | | The overwhelming majority of large assets (images, audio, video) will receive near-zero benefit from using the rsync algorithm. The formats generally have massive byte-level differences even after small “tweaks” to a file. | | |
| ▲ | TZubiri 5 days ago | parent | next [-] | | Video might be strictly out of scope for git, consider that not even youtube allows 'updating' a video. This will sound absolutely insane, but maybe the source code for the video should be a script? Then the process of building produces a video which is a release artifact? | | |
| ▲ | qubidt 5 days ago | parent | next [-] | | This is relatively niche, but that's a thing for anime fan-encodes. Some groups publish their vapoursynth scripts, allow you to produce the same re-encoding (given you have the same source video). e.g.: * https://github.com/LightArrowsEXE/Encoding-Projects * https://github.com/Beatrice-Raws/encode-scripts | | |
| ▲ | TZubiri 3 days ago | parent [-] | | Hm, the video itself would probably be referenced by an indexable identifier like "Anime X Season 1 Chapter 5", and provisioning of the actual video would be up to the builder to get (probably from some torrent network or from DVD although no one will do that) |
| |
| ▲ | yencabulator 4 days ago | parent | prev | next [-] | | > This will sound absolutely insane, but maybe the source code for the video should be a script? Then the process of building produces a video which is a release artifact? It already kinda is, but that just means you now need access to all the raw footage, and rendering a video file in high quality & good compression takes a long time. https://en.wikipedia.org/wiki/Edit_decision_list | | |
| ▲ | TZubiri 3 days ago | parent | next [-] | | I see, I think in that case the raw video format would still be the source code along with the EDL. What I'm suggesting is that the raw footage would still be an output from the source code that would be the script and the filming plans. Silly idea, but it's worth thinking about this stuff in an era where the line between source code and target code is being blurred with prompts. | |
| ▲ | TZubiri 3 days ago | parent | prev [-] | | Which is the problem only if you see of "building" as something that should be instantaneous or take a couple of hours tops. This is similar to replicability in science, there's some experiments that are inmensely expensive to replicate, like LHC, but it still IS replicable technically. |
| |
| ▲ | izacus 5 days ago | parent | prev [-] | | That is nowhere near practical for even basic use cases like a website or a mobile app. | | |
| ▲ | TZubiri 3 days ago | parent [-] | | Isn't it? In practice it means that the "video" should live outside of the git repo, you could just download it from an external repo, and you always have the script to recreate it if it ever goes down. For example: PromotionalDemo.mp4.script "Make a video 10 seconds long showcasing the video, a voice in off should say 'We can click here if we want to do this, or click there if we want to go there'. 1024*768 resolution. Male voice. Perky attitude" |
|
| |
| ▲ | cyberax 5 days ago | parent | prev [-] | | A lot of video editing includes splicing/deleting some footage, rather than full video rework. rsync, with its rolling hash approach, can work wonders for this use-case. |
|
|
