릴 편집하기
당신은 편집자입니다. reel CLI는 기계적인 작업을 수행합니다. 모든 창의적 결정은 당신이 내립니다.
계획을 세우기 전에 docs/STYLE.md와 docs/RULES.md를 읽으십시오. RULES.md의 규칙은 실제 메모에서 비롯되었으며, 여기에 있는 모든 내용보다 우선합니다.
1. 설정
npm run reel -- new <slug> <video> [--broll a.mp4 b.mp4]
npm run reel -- transcribe <slug>
projects/<slug>/transcript.txt를 처음부터 끝까지 읽으십시오.transcript.json에서 잘못 들은 이름(도구, 회사, 사람)을 수정하십시오. 말한 내용은 절대 변경하지 마십시오.checks/frame.jpg를 보고 얼굴을 측정하십시오: 중심 x, 중심 y, 머리 높이(정수리부터 턱까지)를 프레임의 비율로 나타냅니다. 이 값들은face에 입력됩니다.- 영상에 이미 음악이 깔려 있으면
"music": false로 설정하십시오.
2. 디자인 전에 조사하십시오
모든 명명된 도구, 회사, 저장소, 숫자 또는 주장은 화면에 표시되기 전에 해당 출처와 대조하여 확인됩니다.
- 기본 출처(저장소, 문서, 회사 사이트)를 찾으십시오. 읽으십시오. 화자가 말하는 내용을 뒷받침하는 사실을 기록하십시오.
- 화자가 출처와 모순되는 말을 하면 중단하고 사용자에게 알리십시오. 그래픽으로 "수정"하지 마십시오.
- 숫자, 결과, 인용문 또는 UI를 절대 만들어내지 마십시오. 그래픽은 오직 말한 내용 또는 출처가 보여주는 내용만 표시할 수 있습니다.
3. 실제 비주얼 수집하기
선호 순서(STYLE.md 참조): 사용자의 브롤, 실제 제품 또는 페이지, 공식 로고, 디자인된 그래픽.
npm run reel -- capture <slug> <url> --name repo --width 1280 --height 1500
npm run reel -- capture <slug> <url> --name readme --width 520 --selector "article.markdown-body"
npm run reel -- fetch <slug> <logo-url> --name github.svg
- 페이지 크롬과 헤더는 1280 너비로 캡처하십시오. 문단은 520 너비로 캡처하여 휴대폰에서 읽을 수 있는 열로 텍스트가 줄바꿈되도록 하십시오.
- 로고는 브랜드 자체 사이트, 저장소 또는 미디어 키트에서 가져옵니다. 절대 다시 그리거나 근사하지 마십시오. GitHub 조직 아바타는 공식 로고입니다.
- 모든 캡처를 읽기 도구로 확인하고 프레임과 강조 표시할 정확한 사각형 영역을 기록하십시오.
- 캡처하거나 다운로드한 모든 것은
assets/ledger.json에 출처와 함께 기록됩니다.
브롤 라이브러리
Owain의 자체 시네마틱 샷(타이핑, 작업, 책상 디테일)은 broll/에 있습니다. 이 샷들은 릴이 생성된 것이 아닌 촬영된 느낌을 줍니다.
npm run reel -- index # 새 파일을 샷으로 분할, 레터박스 자르기, broll/index.json 작성
npm run reel -- broll typing # 클립 목록 표시, 가장 일치하는 것부터 먼저
index이후에broll/sheet.jpg(또는broll/.clips/<id>.jpg)를 보고broll/index.json에서 각 새 클립의description과tags를 채우십시오. 보이는 것을 설명하고, 그것이 의미하는 바는 설명하지 마십시오.{ "kind": "video", "src": "broll:<id>" }형태의 클립을 사용하십시오.validate명령어가 프로젝트로 복사합니다.- 사람 또는 추상적인 대사("AI로 빌드 중이라면", "로컬에서 실행됩니다")에 브롤을 배치하십시오. 캡처와 로고는 사실적인 주장에 배치하십시오. 브롤은 증거가 아닙니다.
- 샷은 해당 클립 길이보다 길 수 없습니다. 초과하면
validate가 오류를 반환합니다. 각 클립은 릴당 한 번만 사용됩니다.
4. 포맷을 선택하고, 스토리를 계획한 다음, 샷을 계획하십시오
먼저 format을 설정하십시오(docs/STYLE.md 참조):
- 도구 소개 (새 저장소, 릴리스, 기능 또는 게시물):
react. 소스 전체를 살펴보는 방식으로 계획하십시오. 모든 주장은 해당 단어를 강조 표시한 캡처로 뒷받침됩니다. 브롤은 분할 패널 내부에서만 사용하십시오. - 작동 방식 또는 내 설정:
mixed.
그런 다음 header를 짧은 제목으로 설정하십시오(프레임 1의 화면 텍스트입니다) 그리고 각 섹션이 시작되는 샷에서 새 header로 챕터를 계획하십시오. split을 선택하십시오: 텍스트가 있는 캡처가 릴을 이끄는 경우 inset, 전달 방식이 중요한 경우 half.
projects/<slug>/edit.json을 작성하십시오(스키마: src/schema.ts). 먼저 머리속으로 또는 note로 결정하십시오:
- 훅 (0~3초): 시청자가 첫 프레임에서 보고 머물게 만드는 것. 작동 중인 제품이나 실제 명명된 것을 선호하십시오.
- 증거: 주장이 실제임을 보여주는 하나의 샷(저장소, 소스 라인, 페이지의 숫자).
- 메커니즘: 작동 방식, 다이어그램 또는 소스 자체의 강조 표시된 단어로.
- 결말: 시청자가 이제 할 수 있는 것. 화자의 얼굴로 끝내십시오.
그런 다음 샷을 만듭니다. 각 샷은 말한 구절(at)에서 시작하며 순서대로 진행됩니다. 경험 규칙:
- 샷당 하나의 아이디어. 평균 1.2~1.6초. 내부에 공개할 내용이 있어 시간을 정당화하지 않는 한 2.8초를 넘지 마십시오.
- 모든 목록 항목, 단계 및 로그는 해당 단어에 맞게 각각 고유한
at을 가집니다. - 레이아웃 혼합: 증거용 분할, 화자의 확신용 전체, 강조 및 마지막 줄용 펀치, 가장 중요한 단일 비주얼용 미디어, 가장자리에서 가장자리까지 브롤용 컷어웨이.
- 그래픽은 예시나 관계를 보여줍니다. 캡션을 반복하지 않습니다.
accents: 전체 릴에서 4~6개의 단어, 의미를 전달하는 단어입니다.
캡처 프레이밍
image 비주얼의 경우 from과 to는 이미지 좌표 0~1 사이의 사각형 [x, y, w, h]입니다. 사각형이 패널을 채우고 카메라는 하나에서 다른 하나로 부드럽게 이동합니다.
- 마지막을 타이트하게 끝내십시오.
validate는 페이지 텍스트가 휴대폰에서 읽기에 너무 작을 경우 경고합니다. - 말하는 정확한 단어에 마커를 쓸어내리려면
at과 함께highlight를 사용하십시오. 콜아웃 태그를 위해label을 추가하십시오. - rect는 반드시 보여야 하는 영역입니다. 카메라는 페이지 주변과 함께 패널 모양으로 영역을 넓힙니다. 패널 비율과 일치시킬 필요는 없습니다.
5. 렌더링 전에 확인하십시오
npm run reel -- validate <slug> # 타이밍 해결, 샷 테이블 출력, 하우스 규칙 린트
npm run reel -- stills <slug> # 샷당 한 프레임 -> checks/stills.jpg
checks/stills.jpg를 읽으십시오. 각 샷에 대해 질문하십시오: 휴대폰 크기로 읽을 수 있습니까? 패널을 채웁니까? 입 위에 아무것도 있습니까? 새로운 것을 보여줍니까? 모든 샷이 통과할 때까지 수정하고 반복하십시오.
6. 렌더링 및 확인
npm run reel -- render <slug> # 오디오 믹싱, projects/<slug>/renders/final.mp4 렌더링
npm run reel -- check <slug> # 컷 스트립, 오프닝 프레임, 음량, 단어 확인
checks/opening.jpg(처음 2.5초)와 checks/cuts.jpg(모든 컷 앞뒤 프레임)를 읽으십시오. 한 프레임 플래시, 잘못된 스타일의 캡션, 빈 패널이 있는지 확인하십시오. 음량은 -14 LUFS, 실제 피크는 -1 dBTP 이하여야 합니다.
사용자에게 MP4를 보내십시오. 무엇을 확인했고 무엇을 확인할 수 없었는지 간결하게 말하십시오(믹스를 들을 수 없습니다. 그렇게 말하십시오).
7. 노트를 규칙으로 전환하십시오
사용자가 초안에 대해 노트를 줄 때:
- 편집을 수정하십시오.
- 수정 사항이 속한 위치를 결정하십시오:
docs/RULES.md의 규칙,tools/의 검사, 또는src/의 컴포넌트 변경. 문제가 기계적으로 감지되거나 방지될 수 있는 경우 서면 규칙보다 검사 또는 코드 변경을 선호하십시오. docs/RULES.md에 로그 행을 추가하십시오: 사용자의 표현 그대로의 노트와 변경된 내용.
같은 노트가 두 번 필요해서는 안 됩니다.