한 번은 인터뷰에서 40초 답변을 잘라내어 덱에 떨어뜨리고 내가 원하는 비트보다 7초 전에 연사가 문장 중간에 시작하는 것을 보았습니다. 나는 시작을 조심스럽게 설정했다. 트리머는 나를 무시했거나 그렇게 보였다. 그것은 없었습니다. 그것은 빠른 컷이 할 수 있는 유일한 일을 했습니다. 이것은 내가 요청한 지점보다 가장 가까운 키프레임에서 시작하는 것입니다. 일단 당신이 그것을 알면, 행동은 버그가 되는 것을 멈추고 두 가지 옵션으로 선택이 되며, 올바른 것을 선택하는 데 두 번째가 걸립니다.
TL;DR: 빠른 트림은 기존 비디오 스트림을 다시 인코딩하지 않고 복사하며 복사는 키프레임에서만 시작할 수 있습니다. 키프레임이 10초 간격이고 컷이 0:00부터 시작되는 파일에서 0:07에 시작하도록 요청하십시오. 디코더가 시작할 수 있는 마지막 지점이기 때문입니다. 끝은 당신이 요청한 곳이고, 시작만 드리워지고, 그것은 뒤로 표류합니다. 정확한 프레임이 필요할 때 수정하는 것은 느리고 약간의 비용이 드는 재인코딩입니다. 그만큼 비디오 트리머 모두 제공하고 기본값은 빠른 것입니다.
컷이 요청한 것보다 일찍 시작되는 이유는 무엇입니까?
비디오에 거의 프레임이 없기 때문에 완전한 그림이 아닙니다.
비디오 압축은 하나의 전체 프레임을 저장한 다음 변경 사항을 설명하여 작동합니다. 키프레임, IDR 프레임 H.264, 전체 이미지를 보유하고 아무 것도 의존하지 않습니다. 차이를 유지한 후의 프레임: 이 블록은 4개의 픽셀을 왼쪽으로 이동했으며 이 영역은 변경되지 않았으며 이 픽셀은 약간 더 어둡습니다. 그 시퀀스의 중간에 있는 프레임은 그 자체로 의미가 없습니다. 적용되는 파일이 없으면 diff가 의미가 없습니다.
따라서 0:07에서 시작하도록 요청하고 도구가 스트림을 디코딩하지 않고 복사할 때 0:07에 복사할 것이 없습니다. 0:07이 이전과 어떻게 다른지에 대한 설명이 있습니다. 플레이어가 시작할 수 있는 유일한 장소는 키프레임이며, 유일한 안전한 것은 시작점 또는 시작 지점 이전의 마지막 키프레임입니다.
대안은 비디오를 0:07까지 디코딩하고 이전에 있었던 것을 버리고 남아 있는 것을 새 키프레임으로 시작하는 새 파일로 압축하는 것입니다. 그것은 정확하고, 그것은 바이트를 복사하는 것이 아니라 모든 프레임에서 실제 작업을 수행하기 때문에 느린 경로입니다.
키프레임은 실제로 얼마나 떨어져 있습니까?
대부분의 사람들이 생각하는 것보다 더 멀리, 그리고 격차가 빠른 컷이 얼마나 잘못된지 결정하는 것입니다.
추측보다는 측정을 했네요. 기본값으로 x264로 30초의 테스트 푸티지를 인코딩한 다음 키프레임을 나열합니다.
ffmpeg -f lavfi -i "testsrc=duration=30:size=640x360:rate=25" -c:v libx264 clip.mp4
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4 \
| awk -F, '$2 ~ /K/ {print $1}'
# 0.000000
# 10.000000
# 20.000000
10초마다 하나의 키프레임. 이는 x264의 기본값인 키프레임 사이의 기본 250 프레임(초당 25프레임)입니다. 이러한 기본값으로 인코딩된 파일에서 빠른 트림은 선택한 지점보다 최대 10초 전에 시작할 수 있습니다.
대부분의 영상은 스트리밍을 위해 제작되었기 때문에 더 친숙하게 사용됩니다. 플레이어는 품질을 전환하기 위해 자주 진입 지점이 필요한 스트리밍을 위해 만들어졌습니다. 다음은 알 가치가 있는 범위입니다.
| 소스 | 일반적인 키프레임 간격 | 빠른 컷에서 최악의 드리프트 |
|---|---|---|
| 전화 녹음 | 1~2초 | 거의 눈에 띄지 않는 |
| 스트리밍 비디오, HLS 또는 대시 | 2~6초 | 짧은 클립에서 눈에 띄는 |
| x264 또는 ffmpeg 기본값 | 25fps에서 10초 | 지름길을 망친다 |
| 스크린 레코더, 저모션 | 10초 이상 | 지름길을 망친다 |
패턴: 플레이어에 대해 인코딩된 모든 것은 닫기 키프레임이 있고 저장용으로 한 번 인코딩된 것은 없습니다.
드리프트는 파일에 무엇을 합니까?
시작을 움직이고 끝을 그대로 둡니다. 전체 창이 미끄러진다고 가정하기 쉽기 때문에 정확할 가치가 있습니다.
0:07 ~ 0:15에 같은 클립을 묻는 8초의 창을 스트림 복사본이 있습니다.
| 의문의 | 소스의 키프레임 | 결과 | 무슨 일이 있었는지 |
|---|---|---|---|
| 7초 ~ 15초 | 0, 10, 20 | 0~15.08초 | 0에서 키프레임으로 다시 떨어졌습니다. |
| 12~20대 | 0, 10, 20 | 10~20.08초 | 10시에 키프레임으로 다시 시작 |
| 7초 ~ 15초 | 매 2초 | 6~15.08초 | 시작은 하나의 키프레임으로 되돌아갔다. |
세 가지 모두에서 끝이 맞습니다. 나는 지속 시간을 신뢰하는 것이 아니라 해싱 프레임을 통해 확인했습니다. 출력의 마지막 프레임은 15.04초의 소스 프레임에 바이트 동일합니다. 이것은 내가 요청한 프레임의 프레임과 중지할 올바른 위치를 나타냅니다. 변화된 것은 그것이 시작되는 곳입니다.
이 때문에 선택한 창보다 파일이 더 길어집니다. 8초라고 생각했던 컷이 15로 도착했습니다. 과도하게 흘러서가 아니라 7초의 리드인이 등장했기 때문입니다. 키프레임이 2초 간격인 클립에서 동일한 컷이 9초로 도착하고 아무도 눈치채지 못합니다.
대신 언제 다시 인코딩해야 합니까?
세 가지 경우가 있으며, 그 밖에 빠른 경로가 더 나은 도구입니다.
특정 프레임이 필요합니다. 공이 방망이를 때리는 순간, 몸짓으로 말을 자르십시오. 키프레임 정확도가 충분하지 않으며 슬라이더에 대한 신경을 많이 쓰지 않아도 도움이 됩니다. 제한이 인터페이스가 아닌 파일에 있기 때문입니다.
클립이 짧습니다. 30초 컷에서 7초 리드인은 성가신 일입니다. 4초 컷에서는 그것이 전부입니다.
희소 키프레임이 있는 파일을 잘라내고 있습니다. 위의 측정값과 같이 화면 기록 및 아카이브를 위해 한 번 내보낸 모든 항목.
비용은 실재하지만 사람들이 두려워하는 것보다 적습니다. 재인코딩은 창의 모든 프레임을 디코딩하고 다시 압축하므로 파일 크기보다 컷 길이에 비례하는 시간이 걸리고 품질 생성이 손실됩니다. 트리머가 정확한 모드에 사용하는 23의 일정한 비율 계수에서 그 손실은 한 패스에서 보이지 않는 것에 가깝습니다. 이미 한 번 압축된 영상을 두 번째로 전달한 것입니다. 압축을 지배하는 세대 손실 일반적으로.
자신의 파일에서 키프레임을 어떻게 찾습니까?
하나의 명령이며 빠른 경로가 수행할지 여부를 미리 알려줍니다.
# the first ten keyframe timestamps, in seconds
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.mp4 \
| awk -F, '$2 ~ /K/ {print $1}' | head -10
틈이 1~2초라면 빠르게 다듬고 생각을 멈춰라. 10개이고 컷이 중요하면 다시 인코딩하십시오.
이를 위해 두 번째 용도가 있습니다. 다른 사람들이 잘라낼 영상을 제작하는 경우 키프레임 간격이 더 짧아 인코딩을 하면 파일 크기가 적은 비용으로 훨씬 더 쉽게 수명이 다해집니다. 키프레임은 전체 그림이므로 더 많은 바이트를 의미하므로 아무도 다른 것을 요구하지 않을 때 인코더가 공간을 확보하는 이유가 바로 여기에 있습니다.
트리밍은 품질을 잃습니까?
엄밀한 의미에서 빠른 길은 그렇지 않습니다. 디코딩된 것은 없으므로 다시 압축된 것은 없습니다. 출력의 프레임은 새 컨테이너에 있는 입력(바이트용 바이트)에 있던 것과 동일한 압축 프레임입니다. 파일을 이런 식으로 10번 자르면 10번째가 첫 번째와 품질이 동일합니다.
정확한 경로는 한 번입니다. 창은 디코딩되고 다시 압축되므로 한 세대의 손실을 포착합니다. 합리적인 품질의 목표에서 잘 인코딩된 소스에서 이것은 보기 어렵고, 합리적인 규칙은 트림의 트리밍을 다듬는 것보다 원본에서 필요한 컷을 한 번에 만드는 것입니다.
어떤 경로도 무엇이든 업스케일하거나 선명하게 하거나 개선하지 않습니다. 트리머는 전체 작업인 시간을 제거합니다.
트리밍된 클립이 즉시 재생되기 시작하지 않는 이유는 무엇입니까?
인덱스가 어디에 있는지 때문에 압축할 때 중요한 플래그입니다.
MP4는 모든 프레임이 시작되는 위치를 설명하는 테이블을 보유합니다. 명백한 순서로 작성된 테이블은 파일의 끝에 끝납니다. 인코더는 완료되면 내용만 알기 때문입니다. 디스크에서 재생, 괜찮습니다. HTTP를 통해 제공되는 경우 전체 파일이 도착할 때까지 플레이어를 시작할 수 없습니다.
트리머가 통과 -movflags +faststart, 빠른 두 번째 패스를 수행하고 해당 테이블을 앞으로 이동합니다. 그런 다음 파일이 채팅 앱, CMS 또는 URL에서 파일을 가져오는 슬라이드로 이동할 때 원하는 대로 컷이 다운로드되는 동안 재생되기 시작합니다.
오디오는 어떻게 됩니까?
오디오는 자체 프레임 경계에서 절단되며 비디오 키프레임 간격보다 훨씬 짧기 때문에 오디오가 사진보다 마크에 더 가깝게 시작할 수 있습니다.
그 불일치는 다른 고전적인 트리밍 결함의 원인입니다. 소리가 그림보다 약간 앞서 있거나 단어의 조각으로 시작하는 클립입니다. 수정은 편집이 아닌 인수에 있으며 트리머는 그것을 전달합니다. -avoid_negative_ts make_zero 두 스트림의 타임스탬프를 리베이스하여 출력이 0에서 시작되도록 스트림이 서로에 대해 정렬된 상태에서 시작됩니다. 그것 없이는 스트림 복사본이 키프레임과 컷 포인트 사이의 프레임에 대해 부정적인 타임스탬프를 내보낼 수 있으며, 플레이어는 이를 어떻게 처리해야 하는지에 대해 동의하지 않습니다. 일부는 건너뛰고, 일부는 실속하고, 일부는 오디오를 일찍 재생합니다.
소리만 원하면 먼저 영상을 자른 다음 오디오 추출 잘못된 순서입니다. 오디오 컷이 프레임에 정확하고 저렴하기 때문에 먼저 추출하고 오디오를 자릅니다.
전화기의 사진 앱에서 손질하는 것이 더 낫습니까?
빠른 개인 클립을 위해 괜찮고 바로 거기에 있습니다. 당신이 출판할 모든 것에 대해, 아니요, 그리고 그 이유는 분명하지 않습니다.
전화 편집기는 일반적으로 내보내기에 다시 인코딩하며 충실도가 아닌 속도와 예측 가능한 파일 크기에 대해 선택한 설정으로 수행합니다. 당신은 모든 트림에 대해 한 세대의 손실을 지불합니다. 설상가상으로, 그들 중 일부는 비파괴적으로 트림하여 원본 옆에 메타데이터로 입력 및 종료 지점을 저장합니다. 이는 전화기의 트림처럼 보이며 파일이 떠나면 전혀 트림이 아닙니다. 받는 사람이 전체 클립을 얻거나 플레이어가 무시하는 편집 목록을 얻습니다.
복사 모드 트림은 두 가지 문제를 모두 피합니다. 당신이 얻는 파일은 모든 사람이 얻는 파일이며, 그 안에 있는 프레임은 결코 디코딩되지 않았습니다.
비디오가 내 기계를 떠나나요?
...이 아닌 . 컷이 통과합니다. WebAssembly로 컴파일된 FFmpeg 브라우저 탭 내부: 파일을 디스크에서 페이지 메모리로 읽고, 트리밍하고, 다운로드로 다시 전달합니다. DevTools의 네트워크 패널은 이 일이 발생하는 동안 비디오를 비워 둡니다.
영상의 경우 대부분의 파일 형식보다 더 중요합니다. 클립은 일반적으로 누구나 편집하는 가장 크고 가장 개인적인 것입니다. 무료 온라인 트리머의 일반적인 배열은 낯선 사람에게 영상을 업로드하고 읽지 않은 페이지에서 보존 정책을 신뢰하는 것입니다. 여기에 보관할 사본이 없습니다.
한계는 계획이 아니라 탭의 것입니다. 단일 컷은 30분으로 제한되며 전체 소스는 브라우저 메모리에 맞아야 합니다. 그 이후에는 데스크탑 도구가 더 빠르고 안정적이며, 9분에 메모리가 부족한 탭을 건네주는 것보다 낫다고 말하는 것이 좋습니다.
데스크탑 편집기가 올바른 도구는 언제입니까?
시간을 제거하는 것 이상을 할 때. 여러 클립을 연결하거나, 제목, 색상, 음악을 추가하거나, 샘플 수준에서 볼 수 있는 파형을 자르기. 그것은 트리머가 아니라 편집 타임라인이며 정답은 실제 편집기입니다.
브라우저 내에서 분할 라인은 거의 똑같이 깨끗합니다. 한 클립에서 하나의 스트레칭을 제거하는 것은 트림입니다. 조각을 함께 결합하는 것은 비디오 편집기. 결과를 작게 만드는 것은 압축기, 컨테이너 또는 코덱을 변경하는 것은 변환기, 어느 압축과 다른 작동 두 사람이 끊임없이 혼란스러워도.
미리보기와 내보낸 파일이 동의하지 않는 이유는 무엇입니까?
트림 인터페이스는 숫자가 무엇인지에 동의하지 않는 세 곳에서 동일한 숫자를 수집하고 하나의 값으로 가져오는 것이 트리머의 대부분의 작업이기 때문입니다.
텍스트 필드는 누군가가 입력한 모든 것을 제공합니다. 7, 0:07, 00:00:07 또는 7.25. 슬라이더는 누구보다 정밀하게 플로트를 제공합니다. 동영상 요소 currentTime 프레임의 타임스탬프가 아닌 다른 float를 제공합니다. 브라우저는 프레임 사이의 위치를 보고할 수 있으며 그렇게 합니다.
이 세 가지가 약간 다른 초에 착륙하면 미리보기에 한 가지가 표시되고 내보내기가 다른 항목을 생성합니다. 이는 컷이 정확하더라도 트리머가 부서지는 느낌을 주는 특정 버그입니다. 여기에서 파서는 세 가지 타임코드 모양을 모두 허용하고 오른쪽 정렬을 통해 마지막 부분이 길이에 관계없이 항상 초가 되도록 하고 미리보기와 내보내기 모두에 단일 값을 전달합니다. 반입된 필드는 던지는 것보다 아무것도 반환하지 않으므로 입력하는 동안 입력이 모든 키 입력에서 폭발하지 않습니다. 0:0.
실용적인 조언: 정확한 두 번째가 중요한 때 드래그하지 않고 타임코드를 입력하십시오. 슬라이더는 순간을 찾기 위한 것이고 필드는 이름을 지정하기 위한 것입니다.
중간 부분을 어떻게 잘라내나요?
두 개의 컷과 조인, 그리고 No Trimmer는 한 단계로 그것을 수행하므로 사람들을 합리적으로 자주 놀라게 합니다.
클립의 중간을 제거하는 것은 선택 전 부품을 유지하고 두 개의 개별 창인 부품을 뒤에 두었다가 다시 결합하는 것을 의미합니다. 여기에서 트리머는 실행당 하나의 창을 생성하므로 시퀀스는 다음과 같습니다. 비디오 편집기.
할 때 두 가지를 볼 수 있습니다. 조인은 두 조각이 코덱, 해상도 및 프레임 속도를 공유할 때 깔끔하게 작동하며, 둘 다 복사 모드 트림을 통해 동일한 소스 파일에서 가져온 경우 그렇게 됩니다. 그리고 솔기는 양쪽의 키프레임 경계에 착륙하므로 두 번째 조각은 위에서 설명한 대로 정확히 표시된 것보다 약간 일찍 시작됩니다. 컷 포인트가 중요한 경우 두 번째 조각에 대해 정확한 모드를 사용하십시오.
다른 옵션은 시작하기 전에 중지하는 것입니다. 원하는 것이 수정이 아닌 하이라이트인 경우 두 개의 개별 클립이 간격이 꿰매어진 하나의 클립보다 더 유용합니다.
