08 января, 2021

Функции 'Save to EDL Path' и 'Use Current EDL' в Cinelerra-GG

Как и во многих других видеоредакторах, в Cinelerra вообще, и в Cinelerra GG в частности, имеется возможность пакетного рендеринга (Batch rendering).
Идея пакетного рендеринга заключается в том, что пользователь задаёт в диалоговом окне задание для каждого проекта, и программа последовательно рендерит проекты-задания одно за другим автоматически без необходимости контроля за рендерингом со стороны пользователя.
В Cinelerra пакетный рендеринг работает аналогично прочим редакторам и вопросов обычно не вызывает. Прочитать о нём можно в руководствах по Cin-HV, по Cin-CV, по Cin-GG. Схема работы с пакетным рендерингом в разных версиях Cinelerra одна и та же.
 
В общих чертах: для того, чтобы установить задание пакетного рендеринга в Cinelerra, следует открыть окно пакетного рендеринга 'File -> Batch render', в поле 'EDL Path' следует загрузить проект, затем при помощи кнопки 'New' загруженный проект задать как задание (появится в списке заданий), выбрать 'Output Path' и 'File Format'. И стартовать пакетный рендеринг, нажав на кнопку 'Start'. Только не забудьте включить задание, щёлкнув ЛКМ в поле "Включено" - должен появиться крестик в виде "X". 
 
Однако в Cinelerra GG имеются также две интересных, полезных функции 'Save to EDL Path' ('Сохранить в загруженный EDL') и 'Use Current EDL' ('Использовать текущий EDL'). 
О них и пойдёт речь в этой статье, ибо с одной стороны в интерфейсе все их вроде как и видели, однако, поскольку их применение вызывает ряд вопросов, этими функциями не пользуются, нередко вообще не понимают их назначение, вплоть до настоятельных воплей (1, 2) немедленно удалить их из программы.

 

Итак, приступим и рассмотрим сначала функцию 'Save to EDL Path' (Сохранить в загруженный EDL).

 

Допустим, у нас есть базовый проект base.xml, содержащий некую комбинацию применённых эффектов. Мы намереваемся сделать на его базе несколько (в рассматриваемом примере их будет 3) тест-проектов, содержащих один и тот же материал, но с разными комбинациями применённых эффектов, отрендерить проекты в конечные файлы и оценить результаты. Воспользуемся пакетным рендерингом, чтобы ускорить и облегчить рабочий процесс.
 
Загрузим base.xml на монтажный стол, внесём желаемые изменения и сохраним эти изменения (File ->Save as..) как проект base1.xml. Так как мы сохранили base.xml под новым именем base1.xml, то на монтажном столе теперь base1.xml. А исходный проект base.xml остался в нетронутом состоянии.
 
Открываем окно пакетного рендеринга File->Batch render. Щёлкнув левой кнопкой мыши по значку "Лупа" рядом с полем 'EDL Path'(Путь к EDL), выберите проект (base1.xml). Его название появится в поле 'EDL Path'(Путь к EDL). Щелкаем по кнопке "New" и в списке заданий появляется задание base1.xml. Щёлкнем ещё два раза - в результате получим три установленных одинаковых задания base1.xml
 
Возвращаемся в главное окно программы, снова производим на монтажном столе желаемые изменения (уже в base1.xml или в любой другой загруженный проект), сохраняем его как base2.xml. В окне пакетного рендеринга в поле 'EDL Path'(Путь к EDL) выбираем base2.xml проект. Щелчок по кнопке "New" - base2.xml заменит выделенное синим цветом задание в списке заданий. Обратите внимание: если в списке заданий уже установлено задание, то щелчок по "New" всегда заменяет уже имеющееся выделенное задание новым заданием. Именно поэтому мы установили сразу три одинаковых задания.
Повторяем процедуру на монтажном столе: изменяем проект base2.xml, сохраняем как base3.xml, выбираем и устанавливаем base3.xml-задание пакетного рендеринга.

Возможно более рациональнее было бы сначала сохранить три проекта, а потом уже добавлять их в окно пакетного ренедринга.
 
Флажок с чекбокса "warn if jobs/session mismatched" (предупреждать, если задание не соответствует сессии) в окне пакетного рендеринга следует снять (я ниже объясню почему).
 
Проводим рендеринг, открываем результаты в плеере, оцениваем, отбраковываем мусор. На монтажном столе у нас по-прежнему base3.xml.
 
И вот сейчас начинается самое интересное, собственно то, для чего задумывалась эта функция.
Предположим, что после оценки результатов, мы пришли к заключению, что проект base3.xml, находящийся на монтажном столе, содержит данные наиболее близкие к желаемому результату и мы намереваемся продолжить тестирование различных настроек эффектов на его базе.
 
Вносим изменения в base3.xml, выделяем в списке заданий задание (название проекта), которое хотим изменить (мы изменяем base1.xml), жмём 'Save to EDL Path'.
Повторяем процедуру: в тот же base3.xml, что на монтажном столе,  вносим новые изменения, выделяем в списке заданий задание base3.xml), жмём 'Save to EDL Path'.
Разумеется, вы вольны загрузить любой другой проект и переносить оттуда изменения в каждое задание, например, если вы намереваетесь продолжить работу и c проектом base2.xml.
 
Итак, теперь base1.xml и base2.xml переписаны ! Нажимая кнопку
'Save to EDL Path', мы каждый раз вносили в эти проекты изменения, проводившиеся в проекте, находящемся на монтажном столе.
 
Таким образом, изменения в одном проекте, лежащем на монтажном столе, можно вносить в несколько заданий, то-бишь проектов. Очень удобно для тестирования (для этого William Morrow aka GoodGuy её и сделал), оценки результатов применения различных комбинаций эффектов и видеоматериалов, ибо автоматизирует и значительно ускоряет работу, так как использование 'Save to EDL Path' позволяет переносить данные одномоментно, минуя этап выбора проекта в поле 'EDL Path'(Путь к EDL) и добавления при помощи "New".

Однако, перезапись проектов - это очень важный момент, ибо здесь и таится подводный камень, на который может наткнуться пользователь, нечитавший руководство и осваивающий Cinelerra "методом тыка".

В чём же заключается опасность ?

Думаю, что для внимательного читателя ответ уже очевиден, однако давайте ещё раз.
Предположим, что у в окне "Пакетный рендеринг" имеется несколько загруженных заданий, при этом обычно одно из них является выбранным, то-бишь подсвеченным синим цветом (назовём его highlighted.xml).
Предположим, что на монтажном столе находится некий проект (например, something.xml), совершенно отличный от уже установленных заданий, то-бишь проектов. Неосторожное, необдуманное нажатие на кнопку 'Save to EDL Path', приведёт к полной перезаписи выделенного задания (проекта highlighted.xml) содержимым проекта something.xml.
При этом название этого задания останется прежним highlighted.xml, но содержимое этого highlighted.xml (что на диске) будет заменено содержимым проекта something.xml. Пользователь неожиданно для себя может обнаружить, что проект highlighted.xml полностью переписан.
 
Зачем это было сделано ? Когда вы работаете одновременно с рядом проектов, часто возникает некоторое неудобство в управлении  именами проектов. Сочетание специфики этой функции с функцией, описываемой ниже, позволяет работать быстро, легко и эффективно. Я позже рассмотрю это подробнее.
 
Как я уже сказал выше, использование 'Save to EDL Path' значительно ускоряет рабочий процесс. И тут напрашивается вопрос: а есть ли такая функция, которая позволяет не переписывать содержимое, а поностью заменять уже имеющееся задание новым заданием, минуя этапы 'EDL Path'(Путь к EDL) и 'New' ? Ответ утвердительный: да, есть. А подробнее читайте далее.

Рассмотрим функцию 'Use Current EDL' (Использовать текущий EDL)

 
Предположим, что в окне "Пакетный рендеринг" имеется несколько загруженных заданий (одно из них является выбранным, то-бишь подсвеченным синим цветом - назовём его highlighted.xml).
Предположим, что на монтажном столе находится некий проект (например, something.xml), совершенно отличный от уже установленных заданий, то-бишь проектов. Если вы вносите в него изменения, то по окончании сохраните его через File->Save или File->Save as...
При нажатии на кнопку 'Use Current EDL', выделенное задание в списке заданий  (highlighted.xml) будет заменено на something.xml.
 
Но, в отличие от 'Save to EDL Path', в случае 'Use Current EDL' в списке заданий изменится и имя, и содержимое. То есть задание highlighted.xml будет удалено, а его место займёт something.xml. При этом содержимое файла highlighted.xml (что на диске) останется прежним, в отличие от применения функции 'Save to EDL Path', где оно будет перезаписано содержимым something.xml. Иными словами, 'Use Current EDL' просто производит замену одного задания на другое.

Теперь, познакомив вас с функционалом, давайте я ещё более углублю ваши знания.

Как вы помните, в самом начале мы создавали три одинаковых задания, а потом переносили
в эти задания данные с созданных на монтажном столе трех разных проектов. Сейчас, когда вы уже знаете, как работает функция 'Save to EDL Path', я покажу вам еще один вариант её использования. Вариант похож на ранее описанный, но это более рациональный способ.
 
Открываем программу, монтажный стол у нас пустой. Переходим в окно пакетного рендеринга и поле 'EDL Path' пишем адрес и имя пока что несуществующего проекта, например /home/user/base1.xml. Если вы нажмете сейчас кнопку 'New', в списке заданий появляется задание base1.xml для несуществующего пока проекта (будущего проекта). Повторяем процедуру и задаем несколько заданий base2.xml, base3.xml для несуществующих пока проектов. Теперь переходим в 'File'->'Load files', загружаем на монтажный стол base.xml, добавляем медиаматериал, вносим изменения, и при помощи 'Save to EDL Path' переносим изменения в задание base2.xml. В том же base.xml вносим изменения, но уже другого характера и переносим их при помощи функции 'Save to EDL Path' в задание base3.xml.

Таким образом мы не создаем три отдельных проекта как я описывал ранее, а работаем на базе одного и того же проекта base.xml. Использование функции 'Use Current EDL' в данном случае было бы неэффективным и неудобным, поскольку она просто заменяла бы три разных задания заданием под одним и тем же именем и нужно было бы дополнительно заниматься переименованием проектов.

И еще один интересный момент. Только что мы, прописав в поле 'EDL Path' адрес и имя несуществующего (будущего) проекта, нажимали кнопку 'New' и устанавливали тем самым новое задание baseX.xml для несуществующего (будущего) проекта baseX.xml. Если бы мы вместо кнопки 'New' нажали кнопку 'Save to EDL Path', то, помимо задания, на диске одновременно появился бы новый пустой проект baseX.xml, который бы можно было бы загрузить на монтажный стол, добавить медиаданные и приступить к редактированию, а после перенести его в любое задание.

Таким образом, используя все эти приёмы, можно работать быстро, гибко, эффективно и рационально.

Приведу еще один, более наглядный пример. Представим, что мы размахнулись на очень масштабный проект, очень долго с ним работали, отрендерили множество вариантов, используя пакетный рендеринг, отобрали наиболее близкие к желаемому результату и вот наконец начинаем собирать его разрозненные части воедино, объединяя на монтажном столе по-несколько проектов. Допустим, у нас есть вводная часть (base1.xml+base2.xml), основная часть (base3.xml+base4.xml) и заключительная часть (base5.xml+base6.xml).

Теперь мы планируем сделать титры для каждой из его частей, причем титры будут очень разными: в начале это появляющиеся и исчезающие, в основной - бегающие змейкой, а в финальной - движущиеся снизу вверх.
 
Создадим задание пакетного рендера intro.xml, main-part.xml, final-part.xml для несуществующих пока одноименных проектов и перенесем в эти задания содержимое пар проектов на монтажном столе при помощи 'Save to EDL Path'. При этом на диске у нас появятся intro.xml, main-part.xml, final-part.xml, содержащие контент пар проектов, лежащих на монтажном столе. 
Удобно ? Конечно же удобно, эффективно и рационально ! Именно для этого разработчик и создал эту функцию. Кстати, в этом случае 'Use Current EDL' не сохраняло бы содержимое проектов в отличие от 'Save to EDL Path'. 
 
Да, мы могли бы сохранить эти пары проектов под новыми именами и загрузить их в окно пакетного рендеринга, но мы использовали более рациональный метод.
 
А теперь начнём пакетный рендеринг, оценим результаты, снова внесём изменения на монтажном столе, возможно даже добавим в имеющиеся пары проектов новые другие, ранее сохранённые проекты, и опять перенесем их при помощи 'Save to EDL Path' в задания intro.xml, main-part.xml, final-part.xml. При этом названия этих трех частей не изменяются ! Удобно ? Конечно удобно. А вот 'Use Current EDL' не позволит нам такие манипуляции.


Что каcается чекбокса "warn if jobs/session mismatched" (предупреждать, если задание не соответствует сессии), имеющегося в окне 'Batch render' Cinelerra-GG, то, после того, как были заданы настройки рендеринга и нажата кнопка 'Start', Cin-GG проверяет соответствует ли текущая EDL-сессия (что на монтажном столе) заданию пакетного рендеринга. Если с того времени, как в окне пакетного рендеринга было установлено задание, в EDL были внесены изменения, программа предупреждает, что задание не соответствует EDL-файлу сессии.
 
Загрузим в Cinelerra-GG проект test.xml, откроем окно 'Batch render' (Пакетный рендеринг) и создадим задание пакетный рендеринга test.xml.  Теперь вырежем часть материала из проекта; изменения не сохраняем. В окне пакетного рендеринга 'Batch render' нажмём на кнопку 'Start'. Тут же появится окно, в котором программа сообщит, что задание пакетного рендеринга test.xml не соответствует данным текущей EDL-сессии, то-бишь данным проекта, лежащего на монтажном столе. Следует нажать кнопку "Save to EDL path", чтобы перенести данные сессии в проект (можно также произвести сохранение через File->Save).
Если вы, вырезав часть материала, сохранили изменения как новый проект new_test.xml и нажали кнопку 'Start', то в этом случаем программа тоже сообщит о несоответствии данных. Можно заменить задание, нажав на кнопку 'Use Current EDL'. Можно применить и 'Save to EDL path', но помните о чём я говорил, описывая её работу.
Тем, кто начал читать эту статью с конца, настоятельно рекомендую прочитать её с начала.

Вы можете отключить это предупреждение, тем более, что на настоящий момент эта функция не работает должным образом и, очевидно, частично поломана.

Дело в том, что если в окне задано только одно задание пакетного ренедринга, то предупреждение работает как положено. Однако если задано несколько заданий и вы выполняете манипуляции, описанные в предыдущих абзацах, то программа настойчиво требует перенести данные сессии во все задания, заданные в окне пакетного рендеринга, что конечно же бессмысленно. Похоже, что исправление "Tweak asset equivalent for batch render warn which was causing false alarms", сделанное в октябре 2020, проблему решило только частично.

Вот и всё.
Как видите, ничего страшного, при условии, что пользователь внимателен и понимает как работает используемая функция. Собственно, проблема у пользователя (по ссылкам, приведенным во втором абзаце в начале статьи) возникла потому, что он, осваивая функцию "методом тыка" решил, что 'Save to EDL Path' - это кнопка для добавления проекта в окно пакетного рендеринга (т.е. создания задания), тогда как проект добавляется при помощи кнопки "New".
 
Потому читайте руководства и, создавая тестовые мини-проекты, проверяйте и закрепляйте полученные знания на практике. 

P.S.

Однако, как я уже говорил выше, неграмотное использование функции может привести к проблеме. Потому мне представляется необходимым кнопки 'Save to EDL Path' и 'Use Current EDL' перенести вниз и спрятать в раскрывающееся меню  "Advanced usage" (надо сделать такое меню). А на виду оставить привычные и понятные 'New' и 'Delete', не вызывающие ни у кого вопросов и проблем.

Можно ещё сделать предупреждающее окно (после нажатия на кнопку 'Save to EDL Path') с текстом и кнопкой подтверждения. Ну и "желтые подсказки" для каждой кнопки с текстом из мануала. И/или изменить названия этих кнопок. Например 'Save to EDL Path' поменять на 'Save to loaded EDL (highlighted)' как я сделал в своё время в русской локализации.
'New'  переименовать (и/или сделать всплыв. подсказки) 'Create a new batch', 'Delete' - в 'Delete loaded (highlighted) batch'. А работу чекбокса с предупреждением надо исправлять - он явно поломан.
 
P.P.S.
 
Несмотря на некоторую опасность, таящуюся в использовании этих функций, их удаление, как предлагают некоторые пользователи, было бы неправильным, тем более, что окно подтверждения выполнения операции с предупреждением полностью сняло бы вероятность неконтролируемого изменения данных. Упрощение, примитивизация программы, попытки оправдать удаление сравнением с другими видеоредактораами - этот верный способ превратить Cinelerra в безликую программу, неотличающуюся от прочих видеоредакторов, это верный способ остаться в результате ни с чем.
 
Пользователь, берущий в руки сложную программу, должен осознавать что, если он взял в руки сложную программу, он должен пройти некоторую подготовку. Попытки оправдать удаление функций подсчетом числа их пользователей просто смешны: не пользуются потому, что не умеют и не понимают, не умеют и не понимают, потому, что не хотят читать. Кроме того, если текущий состав участников ими не пользуется, это еще не означает, что новоприбывшие не будут пользоваться в будущем. Кроме того, большое количество участников их сообщества читает рассылку от случаю к случаю, появляясь только при возникновении каких-либо вопросов или проблем.
 
В общем, мне будет интересно посмотреть на итоги дебатов в их рассылке - в настоящее время ничего кроме смеха они у меня не вызывают, ибо эти деятели похоже что таки решили удалить эти функции из программы. Что тут можно сказать: их дебаты - это прорва эмоций и нулевая аргументация.Удаление этих функций, войдёт, наверное, в историю этого форка как позорное пятно. И ведь это не какое-то случайное массовое умопомрачение - это, похоже, станет тенденцией. Думаю, что такое будет повторяться ещё не раз - там уже предложили удалить пункт меню для функции 'Save backup', потому что кто-то промахнулся указателем мыши и вместо 'Load backup' ткнул 'Save backup' при пустом монтажном столе. И ведь вполне могут продавить решение - достаточно всего лишь громко и настойчиво покричать, размазывая сопли и эмоции по почтовой рассылке. Мне искренне жаль покойного разработчика - он наверное и представить не мог, что такое произойдёт с его программой. Какой стыд и позорище ! И эти люди позиционируют свой видеоредактор как профессиональный ... Это посмешище !

Кстати, Phyllis, супруга и помощница ныне покойного разработчика поддержала это удаление. Думаю, что с её стороны это было "политическое" решение - очевидно она испугалась критики и потери пользователя-инициатора удаления, создающего скринкасты и статьи, ведь ещё совсем недавно она говорила о полезности и эффективности этих функций.
 
C 2019г. я не участвую, не желал и не желаю участвовать в работе сообщества Cin-GG, а уровень этих их "дебатов" и методы принятия решений ещё более укрепили меня в этом нежелании.
Рекомендации выше следует рассматривать просто как советы постороннего. Мне всегда было интересно выводить на поверхность малоизвестные функции - поэтому я написал эту статью - просто для развлечения. Кроме того меня иногда раздражают крикливые, эгоцентричные новички, не дающие себе труд вникнуть в функционал, но громко требующие удалить его только потому, что они его не осилили или испугались, или не нашли свои "привычные тапочки в привычном месте".

Проблема пользователей, не читавших руководство пользователя в том, что, приходя в новую для них программу, они не могут видеть функцию, как часть единого целого, во всех её взаимосвязях с другими функциями. Поэтому их мнения и суждения сродни суждениям персонажей из известной притчи, которые ощупывали слона и делали выводы о целом на основе локальных данных.

Вообще, очень важно, когда в проекте есть кто-то, кто готов, низвергая на себя вопли недовольных, волевым решением отказывать в удовлетворении просьб, несущих примитивизацию и регрессию в функционал. Когда же такового не находится или когда вожди руководствуются какими-то другими соображениями, происходит то, что сейчас происходит.
 
В этом плане интересна позиция разработчика видеоредактора Olive: "Don't ask to be like XXX. Olive is struggling to work right now, and worrying about what someone else looks like in the class is not relevant. If FCPX, iMovie, KDEnlive, Premiere, or any thing makes you really happy, use it. Olive won't bring you joy if you find those tools meeting your needs.". 
 
Конечно, был бы жив разработчик GoodGuy - он не допустил бы такой позорной регрессии. Ну а нынче - шабаш невежества и торопыг, ультиматумами прогибающих под себя руководство.

Вовсе не стыдно быть новичком стыдно быть таким как те, которых я описал. Со своей стороны я всегда помогал новичкам всем, чем мог, при условии, что они не поливали грязью разработчиков и не считали, что им априори все должны. Но это уже совсем другая история.