비디오 제작 워크 플로우에 버전 관리 기능이 있습니까?


20

저는 소프트웨어 개발자이며 사진 (4 년)과 비디오 제작 (몇 달 동안)에 관심이 있습니다.

■ 소프트웨어 개발에는 모든 개발자가 모든 프로젝트에서 따르는 중요한 규칙 이 있습니다 . 모든 것은 소스 코드, 구성 파일, 데이터베이스 스키마, 문서 등 모든 버전 관리 대상이되어야합니다 . 이것은 두 가지 유쾌한 결과를 가져옵니다.

  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 프로젝트의 연속적인 개정을 추적 할 수있는 특정 기능이 있습니까?

비고 : 주제를 벗어난 답변을 피하기 위해 제 질문은 백업과 관련이 없으며 특히 데이터의 온 사이트 / 오프 사이트 백업을하지 않고 내 작업의 연속적인 개정을 저장하는 것에 관한 것임을 강조합니다 .

답변:


10

Git 의미의 버전 제어는 비디오 세계에서 그리 실용적이지 않습니다. 모든 오디오 및 비디오 도구마다 고유 한 프로젝트 형식으로 작업하므로 특정 버전 제어 도구를 모든 오디오 및 비디오 도구에 만들어야합니다. 그러나 이러한 형식을 읽을 수있는 것은 한 가지 일뿐이므로 diff를 표시하려면 해당 도구의 렌더링 엔진도 필요합니다.

이러한 도구는 모두 일부를 사전 렌더링하지 않는 한 비파괴적인 방식으로 작동하지만 (코드의 dll / lib를 컴파일하고 지금부터 작업하는 것과 비교), 일반적으로 되돌아 갈 수 있습니다 ctrl + z를 수행하거나 일부 프로그램에서 히스토리 도구를 사용하여 이전 개정판으로

일반적으로 하위 버전을 저장하는 것이 좋습니다. 그의 답변에 설명되거나 수동으로 수행하여 stib처럼.

내가 좋아하고 모든 소프트웨어에서 잘 작동하는 것은 내 프로젝트 파일 (소스 푸티 지 없음)을 Dropbox에 저장하는 것입니다. 업로드 속도가 다소 빠르며 (~ 1 Mbit / s) 프로젝트 파일이 100MB 이상이 아닌 경우 다음에 저장하기 전에 프로젝트를 업로드 할 수 있습니다. 평균 Premiere / AE / FCP 프로젝트는 약 10-20MB이므로 최근에 저장된 파일이 1-2 분 안에 업로드됩니다. 업로드 대역폭이 많을수록 더 빠릅니다.

그런 다음 되돌아 가야하는 경우 파일의 Dropbox 기록에 액세스하여 해당 버전으로 다운로드하거나 복원 할 수 있습니다. Dropbox는 유료 계정 (* 지금은 1 년 동안 팩 랫 옵션이있을 때 가장 중요)과 무료 계정에 30 일 동안 파일 개정을 영원히 저장합니다. 비슷한 기능을 제공하는 다른 클라우드 호스팅 업체가 있다고 확신합니다. 바이너리 파일을 매우 잘 처리하고 두통이없는 슈퍼 제한 버전의 git을 사용하는 것과 약간 비슷합니다. 이것은 많은 파일로 폴더를 복잡하게 만들지 않고 동시에 백업을 할 수 있다는 이점이 있습니다.

대부분의 클라우드 호스트는 또한 팀 멤버십을 제공하므로 여러 편집자와 작업 할 수 있습니다. 또는 다른 팀 구성원과 프로젝트 폴더를 공유합니다.


Dropbox는 파일 개정을 영원히 저장합니까? 그렇다면 800 개의 개정판이있는 5GB 비디오 파일이 있다면 어떨까요?
Pacerier

나는 대답을 약간 편집했다. 오래된 팩 쥐 옵션을 사용하면 실제로 1 년 동안 영원히 있었고, 당신은 방금 설명 한대로 할 수 있지만 대답에 쓴 것처럼 소스 (예 : 비디오 / 이미지 / 오디오) 파일을 거기에 넣지 마십시오. 프로젝트 파일. 소스 또는 렌더 파일을 변경하는 버전을 유지하는 것은 실용적이지 않은 기가비트 연결이없는 한.
PTS

1
diff가 필요한 경우 형식을 이해하려면 VCS 만 있으면됩니다. 그것은 조금 기대합니다.
Peter Cordes

1
따라서 10-20MB의 이진 데이터는 git에 아무런 문제가 없으므로 프로젝트 파일을 쉽게 버전 제어 할 수 있습니다. 저장 파일을 커밋 할 때의 상태를 설명하기 위해 유용한 커밋 메시지를 작성하기 만하면됩니다. 운이 좋으면 작은 편집 변경으로 인해 프로젝트 파일의 대부분의 비트가 변경되지 않는 경우가 많으며 git의 델타 압축은 커밋마다 전체 10MB보다 훨씬 적은 양을 사용합니다. 그리고 백업은 git push백업 서버 만큼 쉽습니다 . (어떤 비디오 마스터가 어떤 프로젝트와 함께 진행하는지 추적 할 수있는 다른 방법, 소스 파일의 md5sum일까요?)
Peter Cordes

프로젝트가 더 큰 프로젝트 파일로 끝나는 경우 연결에 따라 자주 개정을 업로드 할 수 없습니다. 클라우드 스토리지 소프트웨어는 완벽하게 확장되며 git은 결국 문제를 일으 킵니다. 커밋 메시지는 분명히 git의 장점입니다.
PTS

6

이전 응답에 추가하기 위해 : 비디오 세계에는 Git과 비슷한 것은 없지만 버전 관리 및 권한 / 사용자 관리 (동일한 작업)와 거의 동일한 작업을 수행 할 수있는 Digital Asset Management / Media Asset Management 도구가 있습니다. 미디어를위한 라이브러리로 만들어 졌기 때문에 훨씬 더). 몇 년 동안 저는 소규모 포스트 시설에서 Final Cut Suite (Final Cut Pro 7, Soundtrack Pro 등)와 통합 된 Apple의 Final Cut Server 앱 (현재는 사용되지 않음)을 사용했습니다.

프로젝트 파일의 버전 제어 및 분기에이 도구를 사용하여 여러 편집자가 단일 프로젝트에서 비교적 원활하게 작업 할 수있었습니다. 이 제품은 Apple 제품이므로 Final Cut Pro와 함께 사용하도록 설계되었으므로 FCP 프로젝트 파일을 매우 쉽게 읽고 사용할 수 있습니다. 이 경우에도 Final Cut Server의 버전 제어는 전체 프로젝트 파일의 이전 버전을 저장하는 데 의존했지만 diff를 사용하지 않았습니다. 이전 답변이 이미 지적한 바로 그 이유 때문에 DAM을 알지 못합니다. 너무 많은 독점 형식이 있습니다 (심지어 아이러니하게도 많은 사람들은 이제 해당 프로젝트 파일 형식의 백본으로 XML에 의존합니다) ).

FCS는 비교적 저렴했기 때문에 훌륭했습니다. Premiere Pro와 유사한 것은 없었습니다. 오늘날 유감스럽게도 비슷한 기능을 얻기 위해 멋진 변경 사항을 전달해야합니다. 대부분 이러한 도구는 단일 편집기가 아닌 포스트 기능을 위해 설계 되었기 때문입니다. 또한 잠재적으로 상당한 통합 / 설정이 필요합니다.

몇 가지 옵션이 있습니다 (이 회사들과 아무런 관계가 없습니다. 이것은 순수한 솔루션을 찾는 연구에 기초합니다).


5

버전 제어는 본질적으로 비파괴 적이기 때문에 비디오 편집에서 실제로 많은 부분을 차지하지 않습니다. NLE (비선형 비디오 편집기)의 핵심에서 출력은 실제로 편집 결정 목록 또는 EDL이라고합니다. 이 기록은 순서대로 적용된 모든 변경 사항의 기록이므로 Lightroom의 기록과 매우 유사합니다.

NLE는 소스 클립에서 작동합니다. 클립의 시작점과 끝점을 사용하여 타임 라인에 배치 한 다음 효과의 배치에 따라 주어진 순서대로 해당 자산에 효과를 적용 할 수 있지만, 이러한 사항은 모두 편집 결정이며 즉시 적용됩니다 ( 또는 임시 미리보기 파일로 렌더링 될 수 있습니다. 최종 출력 렌더는 전체 EDL을 소스 클립에 적용한 결과입니다.

원하는 경우 이전 버전의 EDL로 되돌아 갈 수 있도록 프로젝트 버전을 저장할 수 있지만 시퀀스 편집에 대한 대체 접근 방식을 시도하기 위해 의도적으로 분기하지 않는 한 일반적으로 필요하지 않습니다. 이 경우 해당 타임 라인의 사본이 종종 더 나은 선택입니다.)


여기서 "비파괴"와 NLE의 의미는 무엇입니까?
Pacerier

NLE는 비선형 편집기 (대부분의 비디오 편집 소프트웨어의 기술적 이름)입니다. 비파괴는 변경으로 인해 자산이 파괴되지 않음을 의미합니다. 버전 컨트롤과 기본적으로 동일한 변경 사항 목록을 구성하고 있습니다. 코드를 변경하면 새로운 변경 사항이 기존 코드를 파괴하기 때문에 파괴적입니다. NLE를 사용하면 자산이 모두 변경되지 않고 사용할 섹션 목록과 적용 할 필터 만 수정하면됩니다.
AJ Henderson

비디오 편집 프로그램에 "버전 2.5로 돌아 가기", ​​비트 편집 후 "버전 7로 되돌리기"라고 말할 수 있습니까?
Pacerier

1
아니요, 그는 항상 마스터 비디오를 가지고 있음을 의미합니다. 이전에 효과 / 컷을 재현하는 것이 어렵지 않거나 VCS를 사용하여 프로젝트 파일을 저장하는 것이 편집 결정을 다시 입력하는 것보다 더 효과적이라고 가정합니다. 그렇지 않은 경우 프로젝트 파일을 버전 관리하십시오. 서로 다른 브랜치의 변경 사항을 병합 할 수는 없지만 컷을위한 적절한 장소 나 다른 곳을 찾는 데 오랜 시간이 걸린 정확한 프레임 번호를 적어 두는 것이 더 유용 할 것입니다.
Peter Cordes

3

환경 설정에서 활성화하면 After Effects 및 Premiere에서 자동으로 프로젝트 파일을 증분 저장합니다. 자동 저장 환경 설정

이러한 증분 저장을 사용하면 이전 버전으로 되돌릴 수 있습니다. 이는 버전 제어의 매우 기본적인 구현과 같습니다 (버전 수를 5에서 늘릴 수 있습니다). FCP에는 "이전 버전에서 복원"기능이 내장되어있어 프로젝트 파일을 관리 할 때 유용합니다. After Effects에는 프로젝트를 증분 저장하는 기능이 있지만 Premiere에는 없습니다. 나는 프로젝트를 크게 변경할 때 항상 이것을 사용하고 메인 트렁크로 되돌릴 수 있기를 원합니다.

추가 제어를 위해 버전 제어 소프트웨어를 사용하여 프로젝트 파일과 자동 저장을 보관할 폴더를 관리하므로 모든 미디어가 중앙에서 액세스 가능하거나 복사 된 경우 편집자가 현재 잘라 내기 및 커밋 변경 사항을 확인합니다. 같은 상대 경로에서 모든 사람의 기계에. 코드를 사용하는 것처럼 다른 사람의 편집 내용을 포크하고 병합 할 수는 없습니다. 흥미로운 기능입니다 (기술이 다시 쓰이는 한 Adobe 확장 스크립트 스크립팅으로 구현할 수 있다고 말하고 싶습니다) Javascript의 Git 또는 SVN).


1
예, diff와 merge를하려면 VCS가 NLE의 저장 파일을 이해해야하거나 NLE가 diff / merge를 제공해야합니다. (예를 들어 공통 조상이 주어지면 프로젝트 파일의 변경 사항을 병합 할 수있는 프로그램이 주어지면 git mergetool수정 된 프로젝트 파일이 포함 된 트리의 커밋을 병합 할 수 있도록 git을 사용할 수 있다고 생각 합니다.
Peter Cordes

extendscript를 사용하여 모든 프로젝트 항목의 모든 속성을 가져오고 데이터를 파일로 저장하여 현재 프로젝트를 '저장'할 수 있습니다. 그러나 시간이 오래 걸리는 중간 규모의 프로젝트조차도. 그렇게하면 버전 관리 시스템을 구축 할 수 있습니다.
stib

3

장기적인 비디오 전문가로서 가볍고 강력하며 투명하며 개방적인 VCS 형식의 필요성이 대부분의 미디어 워크 플로에서 부족하다는 사실을 증명할 수 있습니다. 그러나 문제는 다면적이며 기술적 문제 일뿐만 아니라 문화적 문제이기도합니다.

전통적으로 우리는 프로젝트가 스크립트에서 초록빛으로 바뀌고 생산으로 이동하고 일단 랩핑 된 후 포스트 프로덕션으로 이동 한 다음 최종 출력이 분배 암으로 전달 된 다음 장치 / 플랫폼 출력을 스핀 오프하는 방식과 같은 소시지 공장에서 일해 왔습니다. .

요즘 공장과 같은 접근 방식은 포스트 프로덕션과 배포 사이의 핸드 오프가 명확하지 않은 환상입니다. 서로 다른 언어 / 시장에 대한 편집 / 편집 기능이 많이 있으며, 예를 들어 최신 형식으로 돌아가서 다시 마스터 링하지 않아도됩니다. 마케팅 목적으로 최종 버전에 액세스 할 필요가 있습니다. 결과적으로 원격 당사자뿐만 아니라 만날 수없는 사람들도 자신이 어떤 버전으로 작업해야하는지 카탈로그 화되고 결정적인 이해를하는 것이 중요합니다. 이는 마스터 인코딩뿐만 아니라 각기 다른 시장에 대한 해당 마스터의 모든 버전과 각 마스터를 만드는 데 사용 된 자산의 버전으로 확장됩니다.

미디어 테크놀로지 커뮤니티는 현재 버전에 관한 내용을 다루고 있으며, 수많은 다른 워크 플로우와 우려로 인해 정기적으로 논의되고 있습니다. 작업 버전과 배포 버전으로 분류합니다. 여러 툴, 플랫폼 등이 있다는 사실을 방지하기 위해 자체 버전을 추적하는 아카이브 파일 형식을 만들어 배포 내에서이를 해결하려는 노력이 있습니다.이를 상호 운용 가능한 마스터 형식 (IMF)이라고합니다. 은행) 및 SMPTE를 통해 조정 중입니다. 이것에 대한 좋은 점은 무수히 많은 디지털 자산 관리 시스템 (지원하고자하는) 사이에 상호 운용성을 제공하기 위해 움직이고 있다는 것입니다. 내가 알고있는 일부 스튜디오는 수백에 이르는 자산 관리 시스템을 가지고 있습니다. 외부 핸드 오프를 위해 내부적으로 혼자 도울 수 있습니다. 물론 프로덕션 환경에서는 아직 사용되지 않았지만 아카이브 수준 형식으로 설계되었으므로 Netflix가이를 활용합니다. 또한 도구에 투자 할 자본이없는 한 쉽게 만들 수있는 매우 무거운 파일입니다. Netflix는 읽기 기능을 제공하는 오픈 소스 도구 세트를 출시했습니다. 또한 도구에 투자 할 자본이없는 한 쉽게 만들 수있는 매우 무거운 파일입니다. Netflix는 읽기 기능을 제공하는 오픈 소스 도구 세트를 출시했습니다. 또한 도구에 투자 할 자본이없는 한 쉽게 만들 수있는 매우 무거운 파일입니다. Netflix는 읽기 기능을 제공하는 오픈 소스 도구 세트를 출시했습니다.

작업 버전 또는 프로덕션 수준의 현명한 나는 원격 작업을 용이하게하기 위해 아무리 크든 작든 누구나 사용할 수있는 VCS (예 : 수정 된 형태의 git)를 제공해야한다고 생각합니다. 미디어 파일은 물론 코드 나 라이브러리를 바꾸는 것보다 훨씬 크지 만 이러한 파일에 대한 결정은 핵심 구성 요소입니다. 나는 git commits를 통해 원격으로 작업을 테스트하고 싶을뿐입니다.


2

나는 같은 질문을했고, 포토샵 작업을 생각하면서 무역에 의한 소프트웨어 엔지니어이기도했다.

비디오 편집 프로그램에 "버전 2.5로 되돌리기", 비트 편집 후 "버전 7로 되돌리기"라고하면 그렇게 할 수 있습니까?

Photoshop에서 히스토리에 이름이 지정된 버전을 설정할 수 있다는 것을 알았으며 파일에 저장되었다고 생각합니까? 이름이 지정되지 않은 수정본 (히스토리 목록의 항목)의 경우 이전 위치를 편집 (분기)하고 Reflog가 노출되지 않으면 노드가 표시에서 유실됩니다.

새 버전의 Premiere에는 비슷한 기록이있는 것 같습니다. 동일한 변경 사항이 동일한 내부 아키텍처로 발전하고 있다고 생각합니다. 여기서 각 변경 사항은 이전 버전과 대부분의 상태를 공유하는 프로젝트의 또 다른 복사본입니다. 히스토리에 저장된 체크 포인트가있는 경우 git store와 매우 유사합니다. 각 버전에는 세그먼트 정의까지 기본 요소에 대한 (공유) 참조가 포함됩니다. 비디오 자체는 파일에 없기 때문에 크기가 거의 증가하지 않고 점점 더 많은 버전을 성장시키는 데 적합합니다.

Photoshop 개발 팀의 누군가가 아키텍처를 설명하는 세미나를 보았습니다. 보이는 기록 항목은 gitk 디스플레이와 같은 git 버전과 유사합니다. 버전 이름은 git 태그와 동일합니다. 당신은 그것을 가리켜 보이는 버전으로 재설정하고 재설정 할 수 있습니다 다시 너무. 그러나 그 자체가 역사에 넣어 어떤 변화를 만드는 것은 완전 새로 고침 (Shift 또는 Ctrl F5)을 수행 같다 - 현재 브랜치 머리에서 아래로 체인 또는 태그 이름 (하지만하지 않는 어떤 잃을 생각 여전히 복제 소스 참조 같은 것들을 보이지 않는 버전을 가리 킵니다).

그러나 그것은 내가 제안하기 위해 쓰는 것이 아닙니다. 3 시간마다 스냅 샷을 만들도록 프로젝트가있는 NAS 볼륨을 설정했습니다. Windows에는 검사 점 메커니즘이 있지만 구성 할 수 없다고 생각합니다. Mac Time Machine은 비슷한 기능을 수행합니다.

일반적으로, 저장된 모든 버전의 파일 과 Premiere에서 가져온 (일관된) 애셋이 모두 포함되지 않은 상태에서 보관할 수 있으므로 델타를 사용하여 변경된 내용 만 저장할 수없는 경우에도 모두 저장하는 것이 합리적입니다.

프리미어를 다시 배우고 일을 시도하는 것에 더 적극적으로 접근하기 만하면 다음에 작업 할 때 되돌릴 수 있다고 확신합니다. 효과적인 버전 관리 시스템입니다. NAS에서이 작업을 수행하면 저장시 전체 프로젝트를 휴지통에 버리는 BSOD로부터 보호됩니다. :)

히스토리 업데이트 는 짧은 길이이며 기본값은 32 개 항목입니다. 프로젝트가로드 될 때 비어 있습니다. 그러나 자동 저장은 대부분의 프로그램에서 볼 수있는 것과 동일한 파일을 저장하지 않습니다. 오히려 그것들을 번호를 매기고 유지합니다. 따라서 파일 타임 스탬프를 볼 수 있고 이전 사본을로드 할 수 있으므로 15 분 검사 점의 버전 기록이 제공됩니다. 필자의 경우, 각 파일은 44K로 자산 크기와 비교할 수 없습니다. 오디오 크기는 76 밀리 초 또는 클래스 10 SD 카드 푸티 지 프레임의 1/7입니다 .

의미있는 이름으로 검사 점을 유지해야 할 경우 사본을 다른 이름으로 저장하십시오. 그러나 높은 빈도로 설정된 자동 저장을 사용하면 사전 계획없이 모든 노력을 (그 당시의 세분성까지) 다시 방문하는 데 거의 노력을 들이지 않아도됩니다.

버전 제어에 익숙하지 않은 사람이 아닌 엔지니어들에게주의 사항 : 명백한 방법으로 작업을 역 추적 할 수있는 능력, 나는 종종 내가 무엇을 확인하는 데 사용할 게다가 단지 변경 또는 현재 작업을 시작하기 전에의 상태와 비교 또는 그룹과 공유 된 마지막 버전과 비교하십시오.

Premeire는 이제 작업 영역에서 여러 프로젝트를 열 수 있도록 지원하므로 두 개의 타임 라인을 비교하기위한 창 배열 작업 영역 설정을 갖는 것이 가능합니다. 즉,보다 효율적으로 사용하게 가지고 뿐만 아니라 백업을 위해 해당 버전을. 나는 종종 git을 사용하지 않는 프로그래머에게 텍스트 편집기와 같은 범용 도구가되는 방법을 알려줍니다.

전문 영화 제작자가 임시 버전 이상을 다루는 경우 어떻게 버전 제어를 처리하는지 궁금합니다. 자동 저장 설계는 매우 유용한 것으로 보이며 통합 된 스크립트 작성 그룹웨어 도구에는 명백한 수정본 추적 기능이 있습니다.


0

비디오 파일 자체에 대한 버전 제어 기능은 처음에는 크기가 크고, 두 번째로 이동하고 (모든 프레임을 보존 할 예정입니까?), 세 번째로, 변경 불가능하기 때문에 비현실적입니다. 즉, 원본 파일은 편집시 변경되지 않습니다.

그러나 프로젝트 파일의 버전 관리는 의미가 있습니다. 현재, 중대한 변화가있을 때마다 새 프로젝트 파일을 작성하고 설명이 포함 된 이름을 지정합니다. 본질적으로 파일 이름을 사용하여 기록을 수동으로 유지해야합니다. 프로젝트 파일을 버전 관리하에 두는 것이 좋은 생각입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.