Command Palette

Search for a command to run...

두 개의 클립을 결합하는 것은 붙여넣기가 아니라 다시 인코딩하는 것입니다.

두 개의 클립을 결합하는 것은 붙여넣기가 아니라 다시 인코딩하는 것입니다.

T
Toolz Team
|Oct 21, 2026|18 최소 읽기
Google 에서 Toolz.dev 를 선호합니다

편집기 컬렉션의 일부입니다

비디오 편집기

여러 클립을 하나의 비디오에 가입하고 각각을 다듬고 순서를 변경하고 해상도,속도 및 오디오를 설정합니다. 모든 것이 브라우저에서 실행되므로 아무 것도 업로드되지 않습니다.

비디오 편집기를 사용하십시오

두 개의 비디오 파일을 끝까지 놓는 것은 세계에서 가장 저렴한 작업처럼 들리며 약 5분 동안 나는 그것을 믿었습니다. 그런 다음 30fps의 1280x720 클립을 25fps의 640x480 클립에 연결하여 스트림을 복사하고 아무것도 다시 쓰지 않는 가장 빠른 방법을 사용하여 사용했습니다. 파일을 생성했습니다. 두 개의 클립이 11개까지 합산되면 길이가 11개인 96초, 컨테이너에는 1280x720이고 스트림의 후반부는 640x480이며 Muxer는 두 번째 클립의 모든 프레임에 대해 다시 작성된 타임스탬프에 대한 경고를 인쇄했습니다. 비디오 가입에 관한 모든 것은 왜 그런 일이 발생하는지에 달려 있습니다.

TL;DR: 저렴한 조인은 두 파일이 이미 코덱, 해상도, 프레임 속도 및 타임베이스에 동의할 때만 작동하며 두 장치의 영상은 절대 그렇지 않습니다. 정직한 경로는 둘 다 디코딩하고 하나의 새 파일을 인코딩합니다. 이 파일은 느리고 재생되는 무언가를 생성합니다. 여기에서 측정: 복사 방법은 11초의 푸티지에 대해 11.996초를 보고하고 잘못된 해상도를 선언했으며, 재인코딩은 0.63초 만에 일관된 1280x720에서 정확히 11.000초를 생성했습니다. 크기가 다른 클립을 먼저 한 프레임에 장착해야 하며 그렇지 않으면 조인이 완전히 거부됩니다. 그만큼 비디오 편집기 최대 8개의 클립과 30분까지 브라우저에서 모든 것을 수행합니다.

두 개의 클립이 서로 붙어 있지 않은 이유는 무엇입니까?

비디오 파일은 헤더가 있는 사진 스트림이 아니기 때문입니다. 인코딩된 스트림을 보유한 컨테이너이며 인코딩 상태가 전달됩니다.

H.264는 대부분의 프레임을 다른 프레임과의 차이로 설명하여 압축합니다. 키프레임은 단독으로 존재하며, 이전의 키프레임까지 이전에 있었던 것과 관련하여 정의된 모든 것입니다. 디코더는 또한 해상도, 색상 형식 및 프로파일을 설명하는 스트림의 매개변수 집합이 필요하며 각 패킷의 숫자를 초로 변환하는 타임베이스를 보유합니다.

두 장치에서 만든 두 개의 파일은 그 어느 것도 동의하지 않습니다. 해상도가 다르다는 것은 다른 매개변수 세트를 의미합니다. 다른 프레임 속도는 일반적으로 다른 시간 기반을 의미합니다. 1년 간격으로 녹화한 같은 전화기의 두 클립도 카메라 앱이 인코더 설정을 변경했기 때문에 다를 수 있습니다.

바이트를 연결하면 디코더가 헤더에 있는 한 가지를 말하고 다른 중간에 전달되는 스트림이 생성됩니다. 때때로 플레이어가 대처합니다. 종종 첫 번째 클립을 표시하고 중지하거나 두 번째 클립을 색상 노이즈로 재생합니다.

빠른 방법은 무엇을 생산합니까?

파일, 경고 더미 및 잘못된 기간.

FFmpeg 컴캣 디무크서 스트리밍 복사는 모든 "Just Join them" 방법입니다. Answer Online이 권장하는 방법은 입력이 일치할 때 진정으로 올바른 도구입니다. 일치하지 않는 두 개의 클립을 가리켰습니다. 성공적으로 종료되었으며 다음은 전달하는 것입니다.

측정하다 기대 산물
존속기간 11.000초 11.996초
선언된 결의 하나의 값, 수정 640x480이 되는 스트림의 경우 1280x720
타임스탬프 경고 없음 두 번째 클립의 프레임당 하나

경고는 모두 같은 것을 말합니다.

Non-monotonic DTS; previous: 90981, current: 76133; changing to 90982.
This may result in incorrect timestamps in the output file.

두 번째 클립의 타임스탬프는 자신의 파일 내에서 해야 하는 것처럼 0에서 다시 시작되며, 뮤크는 타임스탬프가 역방향으로 이동하는 스트림을 작성하지 않습니다. 따라서 한 번에 한 프레임씩 새로운 것을 발명하고 실제 타이밍과 발명된 타이밍 사이의 누적된 차이는 추가 초가 나오는 곳입니다.

FFmpeg는 비정상적으로 관대하기 때문에 FFmpeg는 나중에 두 반쪽을 모두 디코딩할 수 있습니다. 브라우저는 그렇지 않습니다. 이것은 컴퓨터에서 잘 재생되고 뷰어에 대한 검은색 사각형을 보여주는 파일입니다.

필터 그래프를 통한 가입 비용은 얼마이며 무엇을 구매합니까?

전체 디코딩 및 인코딩 비용이 듭니다. 올바른 파일을 구입합니다.

스트림을 복사하는 대신 각 입력은 프레임으로 디코딩되고, 프레임은 필터 그래프 내에서 트리밍되고 결합되며, 결과에서 하나의 새 스트림이 인코딩됩니다. 모든 프레임은 실제 작업인 디코더와 인코더를 통과합니다.

그것이 구매하는 것은 출력에 하나의 코덱, 하나의 해상도, 하나의 프레임 속도 및 하나의 연속 타임스탬프가 있다는 것입니다. 왜냐하면 모두 처음부터 인코딩되었기 때문입니다. 동일한 두 개의 클립에서:

측정하다 복사 방법 그래프 필터링
존속기간 11.996초 11.000초
결의안 1280x720 선언, 640x480이 됩니다. 전체에 걸쳐 1280x720
액자 305 305
시간 내보내기 즉석 0.63초
크기 더 작은 2.1MB

ffmpeg를 기본적으로 실행하는 데스크탑에서 11초 출력에 대해 0.63초의 작업. WebAssembly를 통한 브라우저 탭에서는 몇 배 느려집니다. 이것이 정직한 거래이며 클립 수가 제한되는 이유입니다.

각 클립에 타임스탬프를 다시 기반으로 하는 이유는 무엇입니까?

필터 그래프의 연결은 스트림을 연결하고 스트림의 타임스탬프는 절대적이기 때문입니다.

각 클립의 프레임은 자신의 파일 시작부터 측정된 운반 시간에 도착합니다. 클립의 중앙에서 섹션을 다듬고 해당 프레임은 여전히 "이것은 42초에 발생합니다"라고 말합니다. 6초에 끝나는 클립에 연결하면 6에서 42로 점프하는 스트림이 있으며 그 사이에 36초가 아무것도 없습니다.

setpts=PTS-STARTPTS 모든 프레임에서 각 클립의 고유 시작을 빼서 모든 클립이 결합되기 전에 0부터 시작합니다. 오디오에 해당하는 것은 asetpts. 그것들이 없으면 출력은 첫 번째 클립을 재생한 다음 긴 동결을 재생한 다음 두 번째 클립을 재생합니다. 손으로 쓴 ffmpeg join 명령에서 가장 흔한 실수이며 침묵합니다. 파일이 유효하고 지속 시간이 잘못되었습니다.

클립의 크기가 다르면 어떻게 됩니까?

조인이 거부되었고 최근까지 그 거부가 여기의 전체 이야기였습니다.

X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 10 연결 필터 입력을 비교하며 비디오 치수 또는 샘플 종횡비가 동의하지 않는 경우에는 실행되지 않습니다.

Input link in0:v0 parameters (size 640x480, SAR 1:1) do not match the
corresponding output link in0:v0 parameters (1280x720, SAR 1:1)
Failed to configure output pad on Parsed_concat_8

경고가 아니라 중단입니다. 파일이 생성되지 않습니다. 두 대의 전화기 또는 전화 클립과 화면 녹화가 바로 그것을 유발하는 경우이며 누군가가 클립에 전혀 참여하지 않는 일반적인 이유입니다.

오디오는 그러한 도움이 필요하지 않습니다. 이는 직관적이지 않기 때문에 알아둘 가치가 있습니다. 동일한 그래프가 44.1kHz 모노 트랙을 48kHz 스테레오로 연결하여 불만 없이 연결하고 정확한 11,000초 파일을 생성했습니다. 영상 쪽만 엄격합니다.

수정은 전체 타임라인에 대해 한 프레임을 정하고 결합하기 전에 모든 클립을 프레임에 맞추는 것입니다. 높이는 선택한 출력 해상도 또는 소스 해상도를 유지할 때 첫 번째 클립에서 가져오고 너비는 해당 클립의 종횡비를 따르므로 인물 영상의 타임 라인은 세로로 유지됩니다. 그런 다음 각 클립은 해당 프레임 안에 맞도록 크기가 조정되고 채우도록 패딩됩니다.

scale=1280:720:force_original_aspect_ratio=decrease,
pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1

채우는 것보다 피팅하는 것은 다른 모양의 클립이 늘어나지 않고 레터박스로 표시된다는 것을 의미합니다. 이는 4:3 클립이 16:9 타임라인을 만날 때 두 가지 악 중 작은 것 중 더 작은 것입니다. setsar=1 장식이 아닙니다. 필터는 샘플 종횡비와 픽셀 크기를 비교하므로 두 개의 클립이 동일한 크기로도 여전히 거부될 수 있습니다.

4:2:0의 H.264는 각 방향에서 반 해상도로 색상을 저장하고 홀수 너비 또는 높이를 인코딩할 수 없기 때문에 두 차원 모두 짝수로 반올림됩니다.

왜 8개의 클립과 30분만?

각 클립은 브라우저 탭 내부의 디코드 패스를 사용하고 탭에는 고정된 양의 메모리가 있기 때문입니다.

8개의 입력은 동일한 필터 그래프에 대해 실행되는 8개의 디코더와 인코더, 그리고 스트리밍할 디스크가 없기 때문에 메모리에 보관된 모든 소스 파일을 의미합니다. 30분의 출력은 사람들이 페이지가 중단되었다고 가정할 만큼 충분히 오래 걸리는 시점입니다.

어느 한도가 형식의 법칙이 아닙니다. 둘 다 브라우저 빌드가 즐겁지 않게 하는 과거의 라인이며 탭이 내보내기에 40분 동안 충돌할 때 발견되기 보다는 미리 명시됩니다. 10분의 1초보다 짧은 클립도 거부됩니다. 그 아래에는 경고가 아닌 프레임 및 FFmpeg 오류에 기여하지 않기 때문에 거부됩니다.

더 큰 것은 잘못된 도구이며 데스크탑 편집기가 올바른 도구입니다.

여기 트리밍은 트리머와 어떻게 다릅니까?

조인 내부에서 트리밍은 프레임 정확하며 추가 비용이 들지 않습니다.

헌신적인 비디오 트리머 스트림을 복사하고 키프레임에서만 절단할 수 있는 빠른 모드를 제공하므로 트림 시작이 때때로 최대 10초 일찍 착륙하는 이유입니다. 그것의 가이드 이유를 자세히 다룹니다.

수출이 어쨌든 모든 것을 다시 인코딩하기 때문에 그 무역은 여기에 존재하지 않습니다. 트림은 디코딩된 프레임에서 필터 그래프 내부에서 발생하므로 4.3초의 컷은 4.3초로 절단됩니다. 이미 지불하고 있는 비용의 부작용으로 프레임 정확도를 무료로 받을 수 있습니다.

따라서 클립 하나를 다듬고 다른 것이 없으면 트리머의 빠른 모드가 훨씬 빠릅니다. 가입하고 계시다면 여기에서 손질하세요.

속도 변경은 오디오에 어떤 영향을 줍니까?

따로 처리해야 하며 산술은 비디오와 동일하지 않습니다.

비디오 속도는 타임스탬프 작업입니다. setpts=PTS/2 모든 프레임의 프레젠테이션 시간을 절반으로 설정하고 프레임 자체는 그대로입니다. 샘플을 두 배 빠르게 재생하면 피치가 옥타브를 올리기 때문에 오디오가 그런 식으로 작동할 수 없습니다. 그만큼 atempo 대신 리샘플링을 필터링하여 피치를 유지하고 지속 시간을 변경합니다.

atempo 대부분의 수명 동안 단일 패스에서 0.5~2.0만 허용되므로 4배 변경은 2개의 2x 패스와 0.25x 변경으로 2개의 0.5x 패스로 구축됩니다. 현재 빌드는 상한선을 높였으며 FFMPEG 8.1은 0.5에서 100까지의 범위를 보고합니다. 하나의 클립으로 측정된 atempo=4 그리고 사슬로 묶인 atempo=2,atempo=2 11밀리초 간격으로 착륙했습니다.

WebAssembly 코어는 버전에 고정되지 않고 런타임에 가져오기 때문에 체인은 여전히 구축되고 있으며 필터를 배송한 모든 빌드에서 패스 곱셈이 정확하기 때문입니다. 제공되는 속도 범위인 0.25배에서 4배까지는 결과가 여전히 참신함이 아니라 편집된 곳입니다.

MP4 또는 WebM?

MP4 특별한 이유가 없는 한, 그 이유는 거의 항상 품질 논거가 아니라 라이선스입니다.

MP4 웨브엠
비디오 코덱 H.264 VP9
오디오 코덱 일류 작
에서 재생 무엇이든지 브라우저, 대부분의 현대 플레이어
탭에서 속도 인코딩 더 빠르게 상당히 느림
비슷한 품질의 크기 더 큰 더 작은

VP9는 동일한 품질에 대해 더 작은 파일을 생성하며 로열티가 없으며 일부 프로젝트에서는 중요하지만 다른 프로젝트에는 전혀 중요하지 않습니다. FFmpeg의 자체 VP9 인코딩 가이드 속도 비용에 대해 무뚝뚝합니다. 그것이 아닌 것은 빠릅니다. 여기에서 WebM 경로는 실시간 마감일과 함께 더 높은 CRF에서 실행됩니다. cpu-used 5, 데스크탑 인코딩은 부주의한 것으로 간주할 수 있습니다. 탭이 없으면 탭의 VP9 인코딩이 깨진 느낌이 들기에 충분히 오래 걸리기 때문입니다.

MP4 경로는 -preset veryfast CRF 23에서 yuv420p, 플러스 -movflags +faststart, 파일의 앞쪽으로 인덱스를 이동하여 다운로드 후가 아닌 다운로드하는 동안 재생됩니다.

수출은 얼마나 되고, 얼마나 걸릴까요?

크기는 해상도에서 예측할 수 있습니다. 시간은 어떤 것에서도 예측할 수 없습니다.

내보내기는 항상 다시 인코딩되기 때문에 소스 파일의 크기는 결과에 대해 거의 알려 주지 않습니다. 표시된 추정치는 대신 출력 높이에서 나온 것입니다. 1080p에서 대략 5Mbps, 720p에서 2.5, 그보다 1.2, WebM이 MP4 수치의 약 70%를 착륙시키고 음소거를 하지 않는 한 오디오가 128kbps를 추가하는 경우입니다.

내용은 어떤 공식보다 중요하기 때문에 추정치이며 하나로 분류됩니다. CRF는 품질 수준을 목표로 하고 필요한 비트 전송률을 사용하기 때문에 동일한 해상도와 동일한 CRF에서 나무를 통한 정적 인터뷰 샷과 휴대용 팬이 여러 번 다릅니다.

시간은 컴퓨터, 해상도, 클립 수 및 탭에 다른 작업이 있는지 여부에 따라 다릅니다. 0.63초 만에 11초의 출력을 관리하는 기본 FFmpeg 실행이 있으며, 브라우저가 그보다 몇 배 느릴 것으로 예상되며, WebM이 다시 느려질 것으로 예상됩니다.

이것이하지 않는 것

결합, 자르기, 순서 변경, 스케일 변경, 속도 변경 및 오디오 드롭. 이것이 전체 기능 세트이며 비디오 편집기와 비디오 편집기 간의 격차는 명확하게 볼 가치가 있습니다.

전환, 제목, 음악 트랙, 색상 수정, 자르기, 클립별 볼륨, 키프레임 없음, 완성된 타임라인 미리보기가 없습니다. 각 클립은 트리밍되고 배치되며, 하나의 출력 설정 세트가 모든 클립에 적용되며 결과가 인코딩됩니다.

여기에는 실제적이고 일반적인 작업이 포함됩니다. 하나의 파일이 되어야 하는 여러 녹음이 유용한 부분으로 잘려져 있고 올바른 순서로 무언가가 받아들일 수 있는 크기로. 창의적인 결정과 관련된 모든 것은 편집기를 사용하십시오.

클립은 어떤 순서로 들어가며 변경할 수 있습니까?

추가한 순서와 예, 각 클립의 위쪽 및 아래쪽 버튼이 있습니다.

재정렬은 비디오가 아닌 목록 작업입니다. 필터 그래프에서 차지하는 입력 인덱스를 변경하고 내보내기가 실행될 때까지 아무것도 다시 읽거나 다시 디코딩되지 않습니다. 따라서 이동은 파일이 아무리 크더라도 즉각적이며 원하는 만큼 타임라인을 무료로 재정렬할 수 있습니다.

드래그 앤 드롭이 아닌 버튼은 최대 8개 항목의 목록에 대한 의도적인 선택입니다. 각각은 클립이라는 이름의 레이블을 가지고 있으므로 키보드로 주문을 변경할 수 있고 스크린 리더로 읽을 수 있습니다.

내보내기 전에 확인할 가치가 있는 것은 시퀀스의 방향입니다. 동일한 이벤트의 여러 녹음은 일반적으로 알파벳 순서로 파일 선택기에서 도착합니다. 이는 카메라의 파일 이름이 생성되는 순서이며 항상 녹음된 순서가 아닌 순서입니다.

이것이 브라우저에서 실행되는 이유는 무엇입니까?

영상은 일반적으로 업로드하지 않는 종류이고 작업에는 서버가 필요하지 않기 때문입니다.

여기에서 모든 작업은 ffmpeg 및 ffmpeg입니다. WebAssembly로 컴파일. 파일은 디스크에서 탭으로 읽고, 거기에서 디코딩되고, 거기에 결합되고, 거기에서 인코딩되고, 다운로드로 다시 전달됩니다. 업로드된 항목이 없고, 영상이 저장되어 있지 않으며, 제어하지 않는 컴퓨터에는 복사본이 없습니다.

사람들이 참여하는 클립은 인터뷰, 상담, 가족 녹음, 내부 소프트웨어의 화면 캡처, 금수 조치 아래의 초안입니다. 일반적인 대안은 수백 메가바이트를 무료 서비스에 업로드하고, 당신이 전혀 알지 못하는 하드웨어로 변환하고, 아무도 읽지 않는 용어로 유지합니다.

비용은 8개의 클립과 30분의 천장이며 데스크탑보다 느린 인코딩입니다. 둘 다 시작하기 전에 명시되어 있으며, 이는 거래 가치가 있습니다.

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!