Чи має контроль над версіями участь у робочому процесі виробництва відео?

Я розробник програмного забезпечення, а також цікавлюсь фотографією (протягом чотирьох років) та відеовиробництвом (лише на кілька місяців).

■ У розробці програмного забезпечення існує важливе правило, яке дотримується кожен розробник у кожному проекті: все повинно бути під контролем версій : вихідний код, файли конфігурації, схема бази даних, документація - все, що дозволяє будувати проект з нуля. Це має два приємні наслідки:

1. У разі катастрофи, коли ви втрачаєте все, крім сховища контролю версій, ви повинні мати можливість продовжувати так, ніби нічого не сталося.

2. У разі якоїсь дурної зміни, яка негативно впливає на проект, розробник може повернутися до попередньої редакції.

■ У фотографії кожна зміна, яку я вношу до фотографій, назавжди зберігається в каталозі Lightroom , завдяки чому в будь-який момент можна повернутися до попереднього стану. Завдяки функції віртуальних копій Lightroom також дозволяє робити те, що називається гілкою в контролі версій: можливість тестувати щось інше, або зберігати обидва результати, або видаляти один з них пізніше.

У каталозі не зберігаються фотографії RAW, але вони все одно не змінюються.

■ У виробництві відео речі здаються інакшими. Я працюю з Premiere Pro, After Effects та Soundbooth.

• Здається, ніхто не зберігає історію назавжди: якщо я вчиню дію помилково і помічую її лише наступного дня, немає можливості відновити попередню версію.

• Soundbooth також безпосередньо змінює файли WAV, що вимагає додаткових зусиль, щоб зберегти окремі оригінальні записи від модифікованих.

• Контроль версій рідко згадується, і я не знайшов, щоб хтось розповів, як він насправді використовує контроль версій у своєму робочому процесі. Більше того, ніхто не згадує, яку саме керування версіями слід використовувати, і оскільки більшість систем управління версіями оптимізовані для текстових файлів, а не бінарних, це створює додаткову проблему.

• Video.SE не має тегів для контролю версій чи змін .

Таким чином, у мене є два питання:

1. Чи має управління версіями участь у робочому процесі людини, яка працює з відеовиробництвом? Як вона інтегрована?

2. Чи допоможе перехід на Adobe Creative Cloud? Чи є конкретні функції, які дозволяють у Creative Cloud відслідковувати послідовну редакцію проекту Premiere Pro або After Effects?

Зауваження: щоб уникнути відповідей поза темою, я підкреслюю, що моє запитання не пов’язане із резервними копіями , а саме стосується збереження послідовних змін моєї роботи, не маючи резервного копіювання даних на місці / за межами сайту.

Контроль версій у розумінні Git не дуже практичний у світі відео. Вам потрібно створити спеціальний інструмент контролю версій для кожного інструменту аудіо та відео, оскільки всі працюють із власними форматами проектів. Але вміти читати ці формати - це лише одне, тоді вам також потрібна система візуалізації цього інструменту, щоб показати diff.

Хоча всі ці інструменти працюють неруйнівним способом, якщо ви не заздалегідь нанесіть якісь речі (порівняйте їх зі складанням dll / lib фрагмента вашого коду та працюйте з цим відтепер), тож ви зазвичай можете просто повернутися назад до старої редакції, виконуючи ctrl + z або використовуючи інструмент історії в деяких програмах.

Хоча зазвичай зберігається додаткова версія. Як стиб, описаний у його відповіді, або роблячи це вручну.

Щось мені подобається робити і добре працює з кожним програмним забезпеченням, - це розміщення моїх файлів проекту (без вихідних кадрів) у Dropbox. Якщо у вас дещо швидка швидкість завантаження (~ 1 Мбіт / с), а файл вашого проекту не становить 100 Мб +, ви можете завантажити свій проект до наступного збереження. Середній проект Premiere / AE / FCP становить близько 10-20 МБ, тому ваші нещодавно збережені файли будуть завантажені через 1-2 хвилини. Ще швидше, якщо у вас більше пропускної здатності для завантаження.

Тоді, якщо вам доведеться повернутися назад, ви можете отримати доступ до історії своїх файлів Dropbox і завантажити або відновити цю версію. Dropbox назавжди зберігає ревізії файлів * на платному акаунті (* принаймні, коли у них був варіант пацюкової щури, зараз я думаю, що це рік) і протягом 30 днів на безкоштовному рахунку. Я впевнений, що є й інші хмарні хостери, які пропонують подібні функції. Це трохи схоже на використання надто обмеженої версії git, яка дуже добре обробляє бінарні файли і не болить голова. Це має перевагу в тому, що ви не захаращуєте папку тоннами файлів і одночасно маєте резервну копію.

Більшість хостерів у хмарі також пропонують членство в команді, щоб ви могли працювати з кількома редакторами. Або ви поділитесь папкою проекту з іншими членами команди.

Просто для доповнення до попередніх відповідей: Хоча для відеосвіту немає нічого подібного до Git, є засоби цифрового управління активами / Media Asset Management, які можуть більш-менш робити те саме - контроль над версіями та управління дозволом / користувачем (вони також набагато більше, оскільки вони справді створені як бібліотеки для ваших медіа). Протягом багатьох років я використовував додаток Apple Final Cut Server (тепер застарілий), який інтегрується з програмою Final Cut Suite (Final Cut Pro 7, Soundtrack Pro тощо) в невеликому поштовому закладі.

Ми використовували його для контролю версій та розгалуження файлів проектів, що дозволило декільком редакторам працювати над одним проектом відносно безперебійно. Оскільки це був продукт Apple, він був розроблений для використання з Final Cut Pro, а тому міг легко читати та працювати з файлами проектів FCP. Навіть зважаючи на це, контроль версій Final Cut Server спирався на збереження попередніх версій всього файлу проекту, але він не використовував diff. Я не знаю жодної DAM, яка робить саме з тієї причини, що в попередній відповіді вже вказувалося - існує занадто багато фірмових форматів (хоча, за іронією долі, багато з них зараз покладаються на XML як основу для цих форматів файлів проекту ).

FCS був чудовим, тому що він був відносно доступним. Ніколи не було нічого подібного для Premiere Pro. Сьогодні, на жаль, для отримання подібних можливостей вам потрібно буде подати хороший фрагмент змін - здебільшого тому, що ці інструменти справді розроблені для поштових засобів, а не одного редактора. Вони також потребують потенційно значної інтеграції / налаштування.

Ось кілька варіантів (я не маю стосунків ні з однією з цих компаній, це засновано виключно на моїх дослідженнях, які шукають подібне рішення):

• Cantemo: http://www.cantemo.com/premiereprocs6.html
• CatDV: http://www.squarebox.com/

Контроль версій насправді не займає стільки місця в редагуванні відео, оскільки він за своєю природою не руйнує. В основі будь-якого NLE (нелінійного редактора відео), вихід насправді є чимось, відомим як Список рішень про редагування або EDL. Це надзвичайно аналогічно історії в Lightroom, оскільки ця історія - це запис усіх змін, які були застосовані в порядку.

NLEs працюють із вихідних кліпів. Вони беруть початкові та кінцеві точки цих кліпів, щоб розмістити їх у часовій шкалі, а потім ефекти можуть бути застосовані до цих активів у заданому порядку (на основі розміщення ефектів), однак це всі рішення щодо редагування та застосовуються на ходу ( або можливо виведені у тимчасові файли попереднього перегляду). Остаточний вихідний рендер є результатом застосування всього EDL до вихідних кліпів.

Ви можете зберегти версію проекту, щоб мати можливість повернутися до попередньої версії EDL, якщо хочете, але це, як правило, не потрібно, якщо ви навмисно не розгалужуєтесь, щоб спробувати альтернативний підхід до редагування послідовності ( у такому випадку копія цієї часової шкали часто є кращим вибором.)

Якщо ввімкнути це в налаштуваннях After Effects і Premiere, автоматично зробіть додаткові збереження файлів проекту.

Ці додаткові збереження можуть бути використані для повернення до попередніх версій, що є як дуже базовою реалізацією контролю версій (можливо, ви хочете збільшити кількість версій з 5). FCP має вбудовану функцію "відновлення з попередньої версії", що добре, коли він керує файлами проекту. Після того, як ефекти мають (але у прем’єри немає, зрозумійте) можливість поступового збереження проекту. Я використовую це весь час, коли роблю великі зміни в проекті, і хочу, щоб я могла повернутися до основного ствола, так би мовити.

Для додаткового контролю, ви можете собі уявити, використовуйте програмне забезпечення для управління версіями для управління папками, в яких ви зберігаєте свої файли проекту та автоматично зберігаєте, щоб редактори перевіряли поточний зріз та вносили зміни, доки всі медіа були доступними в центрі або скопійовані на всіх машинах однаковим відносним шляхом. Це не дозволить розщедрити та об'єднати редагування інших людей, як можна, з кодом - це було б цікавою особливістю (я б сказав, що це може бути реалізовано за допомогою сценарію розширеного сценарію Adobe, якщо ваші навички перезаписуються Git або SVN у Javascript).

Як професіонал довгострокового відео, я можу засвідчити той факт, що потреба у легкій, надійній, прозорій та відкритій формі системи VCS гостро не вистачає у більшості медіапроцесів. Однак проблема є багатогранною і є як культурною, так і технічною.

Традиційно ми працюємо на фабриці ковбасних виробів, коли проект із зеленого світла від сценарію переходить до виробництва, після завершення він переходить у постпродукцію, а потім кінцевий вихід доставляється до розподільної групи, яка потім відкручує виходи пристрою / платформи .

На сьогоднішній день такий заводський підхід є ілюзією, коли розрив між постпродукцією та конкретною дистрибуцією ніколи не зрозумілий. Існує дуже багато вперед і назад, коли скорочення / редагування для різних мов / ринків не мають уваги, повертаючись назад і, наприклад, переробляти для останнього формату, наприклад. Тоді виникає необхідність доступу до остаточних версій для маркетингових цілей ... В результаті ключовою є потреба не лише віддалених сторін, але й людей, які ніколи не зустрінуться, щоб мати каталогізоване, остаточне розуміння, над якою версією потрібно працювати. Це поширюється не тільки на головне кодування, але і на всі версії цього майстра для різних ринків, а також на версії активів, які використовувались для створення кожного ведучого.

Тільки зараз медіатехнологічна спільнота займається тим, що є справді версією, і вона регулярно обговорюється через безліч різних робочих процесів та проблем. Я розбиваю його як робочу версію та версію дистрибутива. Докладаються зусилля, щоб виправити це під час розповсюдження, створивши архівний формат файлу, який відстежує версії всередині себе (для боротьби з тим, що є кілька інструментів, платформ тощо) - це називається Interoperable Master Format (IMF - не плутати з банк) і керується через SMPTE. Хороша річ у тому, що він рухається, щоб забезпечити сумісність між безліччю цифрових систем управління активами (тими, хто хоче його підтримувати), які знаходяться там - у деяких студіях, яких я знаю, є системи управління активами, які налічують у сотні - це було б допомогти їм внутрішньо, не кажучи вже про зовнішні передачі. Звичайно, він не використовувався в виробничому середовищі, але він бачив, як він розроблений як формат архіву (тепер Netflix використовує його). Це також дуже здоровий файл, який не може легко створити його, якщо у вас немає необхідного капіталу для вкладення коштів у інструменти. Netflix випустив набір інструментів з відкритим кодом, який забезпечує приємну здатність до читання. Це також дуже здоровий файл, який не може легко створити його, якщо у вас немає необхідного капіталу для вкладення коштів у інструменти. Netflix випустив набір інструментів з відкритим кодом, який забезпечує приємну здатність до читання. Це також дуже здоровий файл, який не може легко створити його, якщо у вас немає необхідного капіталу для вкладення коштів у інструменти. Netflix випустив набір інструментів з відкритим кодом, який забезпечує приємну здатність до читання.

Робоча версія чи рівень виробництва, я вважаю, що необхідно надати VCS (наприклад, модифіковану форму git), яку кожен може використовувати незалежно від великої чи малої кількості, щоб полегшити віддалену роботу. Зрозуміло, що медіафайли набагато більші за обмін кодом або бібліотеками, але рішення, прийняті за цими файлами, є ключовим компонентом. Я, наприклад, хотів би перевірити роботу віддалено за допомогою git фільмів, щоб лише уникнути конвенцій іменування 'file_Final_FINAL_MASTER_version3.mxf' конвенцій про іменування, які змінюються вперед і назад.

У мене було те саме запитання, також будучи інженером-програмістом у галузі торгівлі, думаючи про роботу в фотошопі.

ми можемо сказати програмі для редагування відео "повернутись до версії 2.5", трохи відредагувати, а потім сказати "повернути до версії 7", і вона здатна це зробити?

Я виявив, що Photoshop дозволяє мені встановити названу версію в історії, і я думаю, що це збережено у файлі ...? Для ревізій (записів у списку історії), які не названі, вузли втрачаються з дисплея, коли редагування робиться на попереднє місце (розгалуження), і рефлог не піддається впливу.

Нові версії Premiere, схоже, мають аналогічний журнал історії, і я здогадуюсь, що розвивається до тієї самої внутрішньої архітектури, де кожна зміна - це ще одна копія проекту, що розділяє більшу частину станів з попередньою. Якщо в історії є контрольно-пропускні пункти, які зберігаються, це дуже схоже на сховище git: кожна версія містить (спільні) посилання на базові елементи, аж до визначення сегмента. Оскільки самого відео немає у файлі, воно добре піддається зростанню все більшої кількості версій з невеликим збільшенням розміру.

Я побачив семінар, де хтось із команди розробників Photoshop пояснював архітектуру. Схоже, записи історії, які ви бачите, аналогічні версіям git, як-от дисплеї gitk. Іменування версії те саме, що і тег git. Ви можете скинути будь-яку видиму редакцію, вказавши на неї, і скинути назад . Але вносити будь-які зміни, які самі вкладаються в історію, - це як зробити повне оновлення (shift або ctrl F5) - ви втрачаєте все, що не прикуте до поточної голови відділення чи названого тегу (але я думаю , такі речі, як посилання на джерело клонування, все ще вкажіть на небачену версію).

Але це не те, про що я пишу. Я встановив об’єм NAS, де мій проект знаходиться, щоб зробити знімок кожні 3 години. У Windows є механізм контрольної точки, але я думаю, що це не налаштовується; Mac Time Machine робить щось подібне.

Загалом, ви можете архівувати всі збережені версії файлу , а в Premiere такий, що не містить усіх імпортованих (постійних) активів, тому розумно зберегти їх усі, навіть не маючи змоги використовувати дельти, щоб зберегти лише те, що змінилося.

Щойно перевчаючи прем'єру та стаючи більш агресивним у спробах речей, я впевнений, що можу повернутись, якщо наступного разу, коли я над цим працюю, пошкодую про те, що зробив, або знайшов кращий спосіб і хочу зробити це ще раз. Це ефективна система версій версій. Роблячи це в NAS, я також захищений від BSOD, який втрачає весь проект при збереженні. :)

оновлення історії невелика, за замовчуванням - 32 записи. Він порожній, коли проект завантажений. Однак автоматичне збереження не просто зберігається над тим самим файлом, як ми бачимо в більшості програм; скоріше він їх нумерує і зберігає. Отже, я можу побачити часові позначки файлів і завантажити старішу копію, яка дає мені історію версій 15-хвилинних контрольних точок. У моєму випадку кожен файл має 44 Кб, що є нічим в порівнянні з розміром активу - це розмір аудіо 76 мілісекунд або 1/7 кадру кадру 10 SD-карти класу 10 .

Якщо у вас є намір зберегти контрольно-пропускний пункт зі значущим іменем, просто збережіть копію як. Але автоматичне збереження, встановлене на високій частоті, може бути використане для повторного перегляду будь-якого стану (до того часу гранульованості) без попереднього планування, з невеликими зусиллями.

Примітка тим інженерам, які не знайомі з контролем версій: Окрім можливості зворотного відстеження вашої роботи очевидним способом, я також часто використовую її для перевірки того, що я щойно змінив, або порівняння зі станом перед початком поточного завдання або порівняти з останньою версією, яку поділили з групою.

Оскільки Premeire тепер підтримує відкриття декількох проектів у робочій області, було б можливо встановити налаштування робочого простору вікон для порівняння двох часових рамок. Тобто, зробити більш ефективне використання має ці версії, а не тільки для резервного копіювання. Я часто розповідаю програмістам, які не використовують git, як це стає інструментом загального призначення, як текстовий редактор.

Цікаво, як професійні режисери справляються з контролем версій, якщо що-небудь більше, ніж спеціальне? Дизайн автоматичного збереження здається цілком корисним, а інтегрований інструмент для створення груп сценаріїв сценаріїв має чітке видиме відстеження редагування.

Отримати контроль над версіями самих відеофайлів недоцільно, оскільки по-перше, вони величезні, по-друге вони рухаються (чи збираєтесь ви зберегти кожен кадр?), По-третє, вони незмінні. Тобто оригінальні файли ніколи не змінюються при редагуванні.

Але контроль версій для файлів проекту має багато сенсу. В даний час після кожної суттєвої зміни я створюю новий файл проекту і даю йому деяку описову назву - що я робив, що додав і що видалив. По суті, я повинен підтримувати історію вручну за допомогою імен файлів. Мати файли проекту під контролем версій - це чудова ідея, чому я раніше про це не думав!