FFMPEG를 사용하여 일련의 1000 년대 PNG 이미지에서 비 압축 AVI를 만들려면 어떻게해야합니까?
이 명령을 사용하여 input.avi파일을 일련의 PNG 프레임 으로 변환했습니다 .
ffmpeg -y -i input.avi -an -vcodec png -s 1024x768 pic%d.png`
이제 모든 PNG 프레임에서 압축되지 않은 AVI 비디오를 만드는 방법을 알아야합니다. 나는 이것을 시도했다 :
ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi
그러나 결과 비디오는 원래 AVI에 비해 많은 품질을 잃습니다.
답변:
"압축되지 않은"AVI를 얻는 방법에는 여러 가지가 ffmpeg있지만 실제로 "무손실"을 의미하는 것 같습니다. 두 용어 모두 정의에 따라 약간의 흔들림이 있습니다.
720p HD 버전의 Big Buck Bunny 와 함께이 토론을 시작하겠습니다. 무료로 이용할 수있는 비디오이기 때문에 모두 테스트하고 비교할 수있는 결과를 얻을 수 있습니다. 24fps에서 1280 × 720p 비디오의 원시 데이터 속도는 29.97fps 목표에서 명시된 1024 × 768의 데이터 속도와 거의 동일하므로 내 결과는 영상에서 기대할 수있는 데이터 속도에 대한 훌륭한 가이드가되어야합니다.
다음 POSIX 명령 ¹은 아래에서 논의한 내용과 대부분 일치하는 목록을 제공합니다.
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
FFmpeg 빌드가 지원하는 것을 확인하기 위해 자신의 컴퓨터에서 해당 명령을 실행할 수 있습니다. FFmpeg는 가능한 모든 엔코더가 활성화 된 경우가 거의 없습니다.
이제 이러한 옵션에 대해 설명하겠습니다.
"압축"당신의 정의는이 디지털 디스플레이에 의해 광자로 전환되기 전에 비디오가 우측에있는 양식, 나는에서 볼 수있는 가장 가까운 경우 ffmpeg -codecs입니다 목록 -c:v r210, r10k, v410, v308, ayuv와 v408. 이것들은 색 깊이 , 색 공간 및 알파 채널 지원 만 다른 점에서 모두 실질적으로 동일 합니다.
R210 및 R10K 는 구성 요소 당 10 비트 (bpc)에서 4 : 4 : 4 RGB이므로테스트시 720p에약 708Mbit / s가 필요합니다. (시간당 약 ⅓TB 정도입니다.)
이 코덱은 픽셀 당 3 × 10 비트 색상 구성 요소를 32 비트 값으로 압축하여 2의 거듭 제곱과 같은 컴퓨터에서 쉽게 조작 할 수 있습니다. 이 코덱들 간의 유일한 차이점은 사용하지 않는 두 비트가있는 32 비트 워드의 끝입니다. 이 사소한 차이는 의심 할 여지가 없습니다. 경쟁 회사 인 Blackmagic Design 과 AJA Video Systems 에서 각각 나왔기 때문 입니다.
간단한 코덱이지만 컴퓨터에서 파일을 사용하려면 Blackmagic 및 / 또는 AJA 코덱을 다운로드해야합니다. 두 회사는 당신이 고객에 의해 생성 된 파일을 처리 할 수있다 알고 있기 때문에 당신이 먼저 하드웨어를 구입하지 않고 자신의 코덱을 다운로드하게됩니다 할 하드웨어의 일부를 가지고있다.
V410 은 기본적으로 Y210 버전의 R210 / R10K입니다. 그들의 데이터 속도는 동일합니다. 그럼에도 불구하고이 코덱은 ffmpeg입력 프레임의 색 공간과이 색 공간 사이에 색 공간 변환 경로가 가속화 될 가능성이 높기 때문에 더 빠르게 인코딩 할 수 있습니다 .
그러나 AJA 및 Blackmagic 코덱이 설치되어 있어도 시도한 소프트웨어에서 결과 파일을 재생할 수 없으므로이 코덱을 권장 할 수 없습니다.
V308 은 V410 의 8bpc 변형이므로테스트에서518Mbit / s 입니다. V410과 마찬가지로 일반 비디오 플레이어 소프트웨어에서 이러한 파일을 재생할 수 없었습니다.
AYUV 및 V408 은 알파 채널이 필요하든 없든 상관없이 V308 과 본질적으로 동일합니다! 비디오가 투명도를 사용하지 않는 경우, 더 깊은 색 공간의 이점을 얻지 않고 위의 10bpc R210 / R10K 코덱의 크기에 따라 비용을 지불해야합니다.
AYUV의 장점은 Windows Media의 "네이티브"코덱이므로 특별한 소프트웨어가 필요하지 않습니다.
V408은 같은 방식으로 QuickTime에 기본으로 설정되어 있지만 V408 파일은 Mac의 QuickTime 7 또는 10에서 재생되지 않습니다.
따라서 PNG의 이름이 지정된 경우이 모든 것을 하나로 모으십시오 frame0001.png.
$ ffmpeg -i frame%04d.png -c:v r10k output.mov
...or... -c:v r210 output.mov
...or... -c:v v410 output.mov
...or... -c:v v408 output.mov
...or... -c:v v308 output.mov
...or... -c:v ayuv output.avi
AYUV의 경우 AVI를 지정했습니다. Windows 전용 코덱이기 때문입니다. 다른 코덱은 컴퓨터에있는 코덱에 따라 QuickTime 또는 AVI로 작동 할 수 있습니다. 한 컨테이너 형식이 작동하지 않으면 다른 컨테이너 형식을 시도하십시오.
위의 명령과 아래의 명령도 입력 프레임이 이미 출력 비디오에 대해 원하는 크기와 같다고 가정합니다. 그렇지 않은 경우 -s 1280x720출력 파일 이름 앞에 명령 과 같은 것을 추가하십시오 .
내가 생각하기에 실제로 "비 압축"대신 "무손실"을 의미한다면, 위의 어떤 것보다 훨씬 더 나은 선택은 Apple QuickTime Animation입니다 .-c:v qtrle
AVI를 원한다고 말했지만 사실 여기에 언급 된 AVI 기반 파일 형식을 읽으려면 Windows 시스템에 코덱을 설치해야 할 것입니다. 선택한 응용 프로그램은 이미 QuickTime 애니메이션 파일을 여는 방법을 알고 있습니다. (위의 AYUV 코덱은 내가 알고있는 유일한 예외이지만 데이터 속도는 AVI의 이점을 얻기 위해 엄청나게 높습니다.)
ffmpeg물건을 것입니다 qtrle당신을 위해 AVI 컨테이너에,하지만 결과는 매우 광범위하게 호환되지 않을 수 있습니다. 필자의 테스트에서 QuickTime Player는 이러한 파일에 대해 약간 이해하지만 재생합니다. 그러나 이상하게도 VLC 는 부분적으로에 기반하더라도 재생되지 않습니다 ffmpeg. 이 코덱의 QT 컨테이너를 고수했습니다.
QuickTime 애니메이션 코덱은 간단한 RLE 체계를 사용하므로 간단한 애니메이션의 경우 아래의 Huffyuv와 마찬가지로 수행해야합니다. 각 프레임의 색상이 많을수록 위의 완전 압축되지 않은 옵션의 비트 전송률에 더 근접하게됩니다. Big Buck Bunny로 테스트 할 때 RGB 4 : 4 : 4 모드로 165Mbit / s 파일 ffmpeg을 제공 할 수있었습니다 .-pix_fmt rgb24
이 형식은 압축되어 있지만 PNG의 무손실 압축 이 픽셀 값에 영향을 미치지 않는 것과 같은 이유로 PNG 입력 파일에 동일한 출력 픽셀 값을 제공 합니다.
ffmpeg도 지원 퀵타임 애니메이션 구현 -pix_fmt argb당신에게 4를 얻는다 : 4 : 4 : 4 RGB, 그 의미는 알파 채널을 가지고 있습니다. 매우 거친 방식으로 -c:v ayuv위에서 언급 한 QuickTime과 같습니다 . 그러나 무손실 압축으로 인해 품질이나 기능 손실이 전혀없는 AYUV의 데이터 속도보다 적은 214 Mbit / s 에 불과합니다.
픽셀 당 24 비트 미만 의 QuickTime 애니메이션 변형이 있지만 점진적으로 단순한 애니메이션 스타일에 가장 적합합니다. ffmpeg는 사양에 의해 정의 된 다른 형식 중 하나만 지원하는 것으로 보입니다 ( -pix_fmt rgb555be15 bpp 빅 엔디안 RGB). 일부 비디오에는 허용되며 대부분의 스크린 캐스트 캡처 및 간단한 애니메이션에 적합합니다. 색 공간 데시 메이션을 수락 할 수 있으면 122Mbit / s의 데이터 속도가 매력적일 수 있습니다.
이 모든 것을 종합하면 :
$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24 output.mov
...or... -pix_fmt argb output.mov
...or... -pix_fmt rgb555be output.mov
RGB 및 4 : 4 : 4 YUV 에 대한 것은 컴퓨터에서 처리하기가 매우 쉽지만 인간의 시각에 대한 사실을 무시한다는 것입니다. 즉, 우리의 눈은 색상 차이보다 흑백 차이에 더 민감합니다. .
따라서 비디오 저장 및 전달 시스템은 휘도 정보보다 컬러 정보에 대해 거의 항상 픽셀 당 더 적은 비트를 사용합니다. 이것을 크로마 서브 샘플링 이라고 합니다. 가장 일반적인 방식은 4 : 2 : 0 및 4 : 2 : 2입니다.
4 : 2 : 0 YUV의 데이터 속도는 흑백 (Y 만) 비 압축 비디오의 경우보다 50 % 더 높고 4 : 4 : 4 RGB 또는 YUV의 데이터 속도의 1/2입니다.
4 : 2 : 2는 4 : 2 : 0과 4 : 4 : 4 사이의 중간 지점입니다. Y 전용 비디오의 데이터 속도의 두 배이며 4 : 4 : 4 : 4의 데이터 속도입니다.
구형 DV 카메라 표준 에서와 같이 4 : 1 : 1이 표시되는 경우도 있습니다 . 4 : 1 : 1은 4 : 2 : 0과 동일한 압축되지 않은 데이터 속도를 갖지만 색상 정보는 다르게 배열됩니다.
이 점의 핵심은 4 : 2 : 0 H.264 파일로 시작하는 경우 압축되지 않은 RGB를 4 : 4 : 4로 다시 인코딩하면 손실없이 압축 된 YUV를 4 : 2 : 0보다 크게 구매할 수 없다는 것입니다. 워크 플로가 4 : 4 : 4 RGB 인 경우에도 사소한 변환이므로 이는 사실입니다. 비디오 하드웨어 및 소프트웨어는 일상적으로 그러한 변환을 수행합니다.
픽셀 엿보기 또는 비디오에서 픽셀 수준의 색상 변경을 수행 할 때는 4 : 4 : 4 만 있으면되며 정확한 픽셀 값을 유지해야합니다. 예를 들어 4 : 4 : 4 픽셀 형식으로 시각 효과 (VFX) 작업을 수행하기가 더 쉬우므로 고급 VFX 하우스는 종종 필요한 높은 데이터 속도를 허용 할 수 있습니다.
색상 데시 메이션을 사용하여 YUV 코덱을 열면 옵션도 열립니다. ffmpeg많은 효과적인 무손실 코덱이 있습니다.
가장 널리 호환되는 옵션은 Huffyuv 입니다. 당신은 이것을 통해 얻을 수 -c:v huffyuv있습니다.
원래 Windows Huffyuv 코덱은 RGB24 및 YUV 4 : 2 : 2의 두 가지 픽셀 형식 만 지원합니다. (실제로 YUV 4 : 2 : 2의 두 가지 버전을 지원하며 디스크의 바이트 순서 만 다릅니다.)
FFmpeg Huffyuv 코덱의 이전 버전에는 RGB24 지원이 포함되어 있지 않으므로 시도하고 FFmpeg에서 yuv422p픽셀 형식 을 사용하겠다고하면 업그레이드해야합니다.
FFmpeg에는 또한 YUV 4 : 2 : 0을 지원하는 FFVHuff라는 Huffyuv 변형 코덱이 있습니다. 이 변형은 Windows DirectShow Huffyuv 코덱과 호환되지 않지만 libavcodecVLC와 같은에 기반한 모든 소프트웨어에서 열어야 합니다.
RGB24 — RGB 4 : 4 : 4는 본질적으로 QuickTime Animation의 RGB24 색상 공간 옵션과 동일합니다. 두 코덱은 주어진 파일에 대해 압축률이 약간 다르지만 일반적으로 가깝습니다.
또한 V308 옵션에서 사용하는 YUV 4 : 4 : 4 모드와 본질적으로 동일합니다. 색 공간 변환은 실시간으로 수행하기 쉽기 때문에 색 공간 차이는 실질적인 차이가 없습니다.
Huffyuv의 무손실 압축으로 인해 RGB24 모드에서 약 251Mbit / s 로 압축하는 테스트 비디오를 V308 또는 AYUV에서 얻을 수있는 것과 동일한 시각적 품질로 얻을 수있었습니다. AVI가 절대적으로 필요한 경우 Huffyuv 코덱을 설치하는 것이 AYUV의 3 배 데이터 속도 비용을 지불하는 것보다 덜 고통 스럽습니다.
YUV 4 : 2 : 2 —이 모드는 RGB24보다 비디오에 훨씬 더 실용적입니다. ffmpeg개발자가 왜 먼저 비디오 를 구현하기로 선택 했는지는 의심의 여지가 없습니다. 위에서 논의한 이론적 인 ⅔ 감소에서 기대할 수 있듯이, 테스트 파일은 173 Mbit / s로 인코딩되었습니다 . 이 두 테스트에서 오디오 트랙이 변경되지 않았다는 사실을 고려하면 거의 정확히 ⅔입니다.
YUV 4 : 2 : 0 —이 옵션은 4 : 2 : 2 이상의 색상 정보를 제거하여 테스트에서 데이터 속도를 133Mbit / s 로 떨어 뜨립니다 .
이 모든 것을 종합하면 :
$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24 output.avi
...or... -pix_fmt yuv422p output.avi
...or... -c:v ffvhuff -pix_fmt yuv420p output.avi
비록 ffvhuff2 : 4 코덱을 기본값 0 내가 이것을 쓰고, 참으로 단지 내가 사용 릴리스 버전에서 픽셀 형식은 지원 이 변화 할 경우에 대비하여이 기본 변경 플래그를 포함해야한다, 그래서.
Huffyuv 및 FFVHuff와 같은 정신에서 가장 최근의 옵션은 Ut Video 입니다. Huffyuv와 마찬가지로 Windows 비디오 코덱도 있습니다 . 즉, 영화를 재생할 수있는 모든 Windows 프로그램에서 코덱이 설치된 상태에서이 코덱을 사용하여 비디오를 재생할 수 있습니다. Huffyuv와 달리 Mac 비디오 코덱도 있으므로 FFmpeg 기반 소프트웨어로 제한되거나 libavcodecMac에서 이러한 파일을 읽을 수 없습니다.
이 코덱은 색 공간 측면에서 매우 유연하므로 일반적인 색 공간의 예를 몇 가지만 소개하겠습니다.
4 : 4 : 4 RGB 비아 -f avi -c:v utvideo -pix_fmt rgb24범 178 메가 비트 / 초 출력
4 : 4 : 4 YUV 통해 -f avi -c:v utvideo -pix_fmt yuv444p제공 153 메가 비트 / 초 출력
4 : 2 : 2 YUV 통해 -f avi -c:v utvideo -pix_fmt yuv422p제공 123 메가 비트 / 초 출력
4 : 2 : 0 YUV 통해 -f avi -c:v utvideo -pix_fmt yuv420p제공 100 메가 비트 / 초 출력
소스 비디오가 4 : 2 : 0 YUV이기 때문에 기술적으로 동등한 두 가지에도 불구 하고이 테스트에서 4 : 4 : 4 YUV가 4 : 4 : 4 RGB보다 우수하다고 생각합니다 .YUV 형식으로 데이터를 정렬하면 무손실 압축이 더 좋습니다. 파일에서 부분 중복 U 및 V 채널을 그룹화하여
이 공간에서 또 다른 흥미로운 옵션은 FFmpeg의 자체 FFV1코덱 입니다. 이것은 대부분 재생 또는 편집 코덱이 아닌 보관 코덱으로 사용되지만, 많은 소프트웨어는 libavcodecFFmpeg를 기반으로하는 라이브러리를 기반으로하거나 , libavcodec같은 도구 를 통해 래핑 ffdshow될 수 있기 때문에 어쨌든 유용 할 수 있습니다.
기본적으로 ffmpegFFV1과 같은 유연한 코덱을 사용할 때 입력 파일의 색 공간을 유지하므로 4 : 2 : 0 YUV를 사용하는 공식 Big Buck Bunny MP4 파일 중 하나를 공급하면 얻을 수있는 것입니다. 당신이 포기하지 않는 한 밖으로 -pix_fmt에 플래그 ffmpeg. 결과적으로 63Mbit / s 출력 파일이 생성됩니다.
FFV1이와 함께 4 : 4 : 4 YUV 색상 공간을 사용하도록 강제 -pix_fmt yuv444p하면 파일 크기는 최대 86Mbit / sec 까지 증가하지만 4 : 2 : 0 원본에서 인코딩하기 때문에이 경우 아무것도 사지 않습니다. . 그러나 원래 질문에서와 같이 대신 PNG 세트를 공급하는 경우 출력 파일은 위에 표시된 및 색 공간의 재 배열 인 bgra또는 bgr0색 공간 을 사용합니다 .argbrgb24
또 다른 흥미로운 대안은 Lossless H.264 입니다. 이것은 이 글을 쓰는 시점에서 x264 전용 일이지만 인코딩 측에서 FFmpeg를 사용하는 사람들 은 VLC와 같은 디코딩 측에도 포함 libx264된 다른 소프트웨어를 사용하고있을 것 입니다.
이러한 파일을 얻는 가장 간단한 방법은 다음과 같습니다.
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
-qp 0플래그가 핵심이다 : 높은 값은 손실 압축을 제공합니다. ( -crf 0같은 효과를 줄 수도 있습니다 .)
FFV1과 마찬가지로 ffmpeg입력 색상 공간이 주어지면 최상의 출력 색상 공간을 추측하려고 시도하므로 위의 결과와 비교하기 위해 Big Buck Bunny 소스 파일에서 여러 색상 공간으로 여러 인코딩 패스를 실행했습니다.
yuv444p : ffmpeg원본 질문에서와 같이 RGB PNG 스트림을 제공 할 때 선택하는 것으로 테스트 파일과 함께 44Mbit / sec 파일이 생성됩니다.
yuv422p : Huffyuv의 기본 색 공간과 비슷하지만이 경우 34Mbit / sec 파일을 얻습니다 .
yuv420p : 테스트중인 Big Buck Bunny 공식 MP4의 기본값이며 29Mbit / sec 파일이 생성됩니다.
작은 파일 크기를 얻으려면 많은 호환성을 유지해야합니다. 그렇기 때문에 AVI 또는 MOV 컨테이너에 넣지 않아도됩니다. x264와 매우 밀접하게 연결되어 있으므로 표준 컨테이너 유형 (MP4)을 대신 사용할 수도 있습니다. Matroska 와 같은 것을 사용할 수도 있습니다 .
를 추가하여 비트 전송률 중 일부를 더 빠른 인코딩 시간으로 교환 할 수 있습니다 -preset ultrafast. 이로 인해 YUV 4 : 2 : 2 모드에서 테스트 파일의 비트 전송률이 44Mbit / s 로 증가 했지만 약속 한대로 훨씬 빠르게 인코딩되었습니다. 문서 -preset veryslow는 또한 가치가 있다고 주장 하지만, 약간의 공간을 절약하면서 인코딩 시간 이 훨씬 길어졌습니다. 나는 그것을 추천 할 수 없다.
ffmpegLagarith의 디코딩 전용 모드와 Lossless JPEG의 인코딩 전용 모드도 지원합니다 . 이 두 코덱은 실제로 다소 비슷하며 파일이 같은 품질의 Huffyuv보다 약간 작습니다. ffmpeg개발자가 Lagarith 인코딩을 추가 한 경우 Huffyuv를 대체 할 수 있습니다. 그러나 Lossless JPEG는 광범위한 디코딩 지원을 즐기지 않기 때문에 권장하지 않습니다.
그런 다음 지각 적으로 무손실 코덱이 있습니다 . 픽셀 엿보기가 아니라면 이전 두 그룹과 다른 시각적 결과를 제공한다고 말할 수는 없습니다. 비디오 캡처 센서와 디스플레이 장치 사이의 절대적인 변화가 없다는 아이디어를 포기함으로써 상당한 절감 효과를 얻을 수 있습니다.
Apple ProRes :-c:v prores또는-c:v prores_ks— ProRes는 프로파일 기반 코덱으로, 품질과 공간의 균형이 서로 다른 여러 변형이 있습니다.
ProRes 4444 는 114Mbit / s 만 사용하여 테스트 비디오를 인코딩하지만 VFX 품질 입니다. 현재prores*FFmpeg에는세 가지코덱이 있지만옵션을prores_ks통해이 코드를 작성할 때 ProRes 4444만지원합니다-profile:v 4444.
Lossless H.264를 통해 ProRes 4444를 사용하는 이유가 궁금하다면 호환성, 디코딩 속도, 예측 가능성 및 알파 채널이 필요합니다.
ProRes 422 는픽셀 엿보기만으로 ProRes 4444에서 알 수있는 결과를 제공하기 위해 84 Mbit / s 만 있으면 더 많은 공간을 절약합니다. ProRes 4444가 제공하는 알파 채널이 필요하지 않으면 ProRes 4444를 주장 할 이유가 없습니다.
알파 채널을 지원하지 않기 때문에 ProRes 422는 위의 Lossless H.264 옵션과 더 가까운 경쟁 업체입니다. Apple pro 비디오 앱과의 호환성, 인코딩 및 디코딩을위한 CPU 오버 헤드 감소 또는 예측 가능한 비트 전송률이 필요한 경우 더 높은 비트 전송률의 ProRes를 허용해야합니다. 후자는 예를 들어 하드웨어 인코더에서 중요합니다. 반면에 Lossless H.264의 호환성 문제에 대처할 수 있다면 4 : 2 : 0 색 공간을 사용할 수있는 옵션이 있습니다. 이는 ProRes 프로파일의 옵션이 아닙니다.
FFmpeg의 3 가지 ProRes 인코더는 모두 ProRes 422 프로파일을 지원하므로 가장 간단한 옵션은을 사용하는 -c:v prores것이 아니라 -c:v prores_ks -profile hq자동 프로파일 기능에 의존하거나 prores_ks올바른 작업을 수행하는 것입니다.
더 포용적인 ProRes 프로파일이 있지만 SD 비디오 용 또는 고해상도 파일 용 프록시 용입니다.
ProRes의 주요 문제점은 Apple 및 Pro 비디오 세계 이외의 지역에서는 아직 광범위하게 지원되지 않는다는 것입니다.
Avid의 DNxHD 는 ProRes와 유사한 코덱이지만 Apple Pro 비디오 세계와는 관련이 없습니다. Avid는Windows 및 Macintosh 모두에 대해 무료로 다운로드 가능한 코덱 을 제공하며 FFmpeg는 이제를 통해이를 지원합니다-c:v dnxhd.
DNxHD는 ProRes와 같은 프로파일 기반 코덱이므로 사전 정의 된 세트 에서 프로파일을 선택하면 사용할 프레임 크기, 프레임 속도 및 비트 전송률을 코덱에 알려줍니다. Big Buck Bunny 테스트 파일의 경우 -b:v 60M프로파일이 가장 적합합니다. 당연히 결과 파일은 약 59 Mbit / s 입니다.
저손실 MJPEG :-vcodec mjpeg -qscale:v 1— 무손실 JPEG보다 훨씬 일반적입니다. 사실, 이것은 한때 매우 일반적인 비디오 편집 코덱이었으며 여전히 네트워크 스트리밍 비디오 카메라와 같은 것들에서 자주 사용됩니다. 모든 역사는 그것을 지원하는 소프트웨어를 쉽게 찾을 수 있음을 의미합니다.
이 코덱의 데이터 속도는 매우 다양합니다. 방금 만든 테스트 로 720p 비디오에 25Mbit / s가 제공 되었습니다. 그것은 손실에 대해 긴장하게 만들기에 충분한 압축률이지만, 나에게는 꽤 좋아 보였다. 데이터 속도만으로 볼 때 아마도 12 Mbit / s MPEG-2 또는 6 Mbit / s H.264 수준의 품질 수준이라고 생각합니다 .
이 모든 것을 종합하면 :
$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
...or... -c:v prores_ks -profile:v hq output.mov
...or... -c:v prores output.mov
...or... -c:v dnxhd -b:v 60M output.mov
...or... -c:v mjpeg -qscale:v 1 output.avi
이 방법의 결론은 매우 까다로운 작업을 수행하지 않으면 "충분히 좋은"것만으로도 충분하다는 것입니다.
각주 및 오류
이 명령은 Linux, macOS, BSD 및 Unix에서 제공된대로 작동해야합니다. Windows를 사용하는 경우 Cygwin 또는 WSL을 통해 POSIX 명령 줄을 얻을 수 있습니다 .
해당 명령으로 생성 된 목록이 위에서 설명한 코덱 세트와 완벽하게 일치하지 않는 데는 몇 가지 이유가 있습니다.
두 번째 grep는 이 목록 bmp에 태그가 붙어 있음에도 불구하고 "비디오"코덱이 아닌 부적절한 인코더를 필터링하는 것 입니다 V. 기술적으로 단일 파일 비디오를 얻기 위해 AVI, MP4 또는 MKV와 같은 컨테이너에 많은 것들을 넣을 수는 있지만 ffmpeg또는에 기반을 둔 프로그램 이외의 다른 파일은 해당 파일을 읽을 수 없습니다 libavcodec.
-f avi -c:v ljpeg"무손실 MJPEG"라고 부를 수있는 것과 같은 몇 가지 예외가 있지만, 일반적으로 영화를 만들기 위해 많은 스틸 이미지 파일을 A / V 컨테이너에 채워 넣는 것에 관심이 없습니다. 시맨틱 속임수가 아닌 널리 인식되는 비디오 코덱이 필요합니다.
이 명령은 현재 ffmpeg -codecs출력 bitmap또는 image파일 형식 으로 설명되어 있지 않기 때문에 GIF와 같은 일부 부적절한 인코더를 필터링하지 못합니다 .
GIF는 흥미로운 경우입니다. 모션 재생을위한 타이밍 정보가있는 단일 GIF 파일에서 여러 이미지 프레임을 지원하지만 여러 가지 이유로 여기서 논의하는 것은 전적으로 부적절합니다.
표시되는 옵션 중 일부는 다음과 같은, 정말 많은 견인을 가지고 폐기 또는 않습니다 flashsv, dirac그리고 snow그 이상을 논의 가치가 없어, 그래서.
이 목록에있는 옵션 중 일부는 단지 사이의 파이프 라인에서 사용하기 위해 의미 ffmpeg인스턴스 또는 간 ffmpeg등의 다른 프로그램, rawvideo및 wrapped_avframe, 그래서 여기에 우리의 목적에 부적합하다.
위의 논의가 끝날 무렵, 나는 신중하게 선택된 손실 옵션을 포함하도록 질문의 범위를 약간 확장 grep하여 위의 명령에서 첫 번째 필터를 통과시키지 않습니다 .
그래서 나는 내 자신의 대답을 너무 길게 만들었습니다.
TL; DR 요약 : 무손실 이미지의 사용 순서 기억 libx264또는 libx264rgb함께이 -preset ultrafast -qp 0. 비트 전송률이 훨씬 낮고 디코딩 속도가 더 빠르며 ffvhuff만큼 빠릅니다. huffyuv는 ffmpeg 외부에서 훨씬 더 광범위하게 지원되지만만큼 많은 픽셀 형식을 지원하지 않습니다 ffvhuff. 따라서 다른 도구 High 4:4:4 Predictive가 x264가 무손실 모드에서 사용 하는 h.264 프로필을 처리 할 수 있다고 가정하면 h.264를 사용해야하는 또 다른 이유 입니다. 임의의 프레임에 빠른 임의 액세스가 필요한 경우 x264는 인트라 전용을 수행 할 수 있습니다.
이미지 디렉토리에서 읽을 때 libx264rgb에 영향을주는 ffmpeg 버그 에 주의하십시오 . (그리고 다른 경우를 아는 사람) 사용하기 전에 설정에서 손실이 없는지 테스트하십시오. ( ffmpeg -i in -pix_fmt rgb24 -f framemd5소스에서 쉽고 무손실 압축)
편집 : utvideo상당히 빠르게 인코딩 및 디코딩하며 h.264보다 훨씬 간단한 코덱입니다. 기본적으로 huffyuv더 유용한 색상 공간을 지원 하는 현대적 입니다. h.264에 문제가있는 경우 임시 파일을 위해 utvideo를 시도하십시오.
edit2 : RGB 코덱으로 PNG가 적어도 Sintel 트레일러에서 잘 작동하는 것으로 보입니다.
비슷한 질문에 대한 비슷한 답변을 참조하십시오 : https://superuser.com/a/860335/20798
Warren Young의 답변에는 다양한 원시 형식 및 코덱에 대한 많은 정보가 있습니다. 답변이 더 짧으면 더 유용 할 것 같아서 새로운 답변을 만들고 있습니다. 무손실 x264 또는 ffvhuff를 지원하지 않는 소프트웨어를 사용하는 경우 해당 정보 중 일부가 여전히 유용 할 수 있습니다.
이 문맥에서 "무손실"의 가장 유용한 정의는 비트 단위로 입력을 복구 할 수 있다는 것입니다. 무엇을하든 비디오 인코딩의 품질 저하에 대해 걱정할 필요가 없습니다.
http://en.wikipedia.org/wiki/Chroma_subsampling
이상적으로는 여러 색 공간 변환을 피하십시오. 반올림 오류가 발생할 수 있습니다. RGB 색상 공간에서 작동하는 필터를 사용하여 비디오를 작업하려는 경우 높은 비트 전송률이 문제가되지 않는 한 RGB를 유지하는 것이 좋습니다. 궁극적으로 yuv 4:2:0비디오를 제작할 가능성이 있지만 적용 할 필터에 따라 추가 크로마 해상도를 유지하는 것이 유용 할 수 있습니다.
어느 쪽이든, 무손실 x264 및 지원 RGB와 YUV 모두 ffvhuff 4:4:4, 4:2:2하고 4:2:0. 디코딩이 빠르기 때문에 x264를 제안합니다. RGB HD 비디오를 실시간으로 재생하려는 경우 xv 대신 opengl을 시도하십시오. 시스템의 xv는 yuv 입력 만 허용하기 때문입니다. mplayer는 색상 공간 변환을 수행하는 데 추가 CPU 시간이 필요했습니다.
https://media.xiph.org/ 인코더 테스트 소스 . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz 그들은 sintel 트레일러 용 y4m 파일을 압축하는 것을 잊었으므로 png tarball은 실제로 훨씬 작습니다.
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv
예 :
peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.100 / 56. 18.100
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 7.100 / 5. 7.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
Metadata:
encoder : Lavf56.18.100
Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
Metadata:
encoder : Lavc56.20.100 libx264rgb
Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize= 834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6 Avg QP: 0.00 size:612470
[libx264rgb @ 0x2770760] frame P:1247 Avg QP: 0.00 size:678787
[libx264rgb @ 0x2770760] mb I I16..4: 100.0% 0.0% 0.0%
[libx264rgb @ 0x2770760] mb P I16..4: 50.3% 0.0% 0.0% P16..4: 12.0% 0.0% 0.0% 0.0% 0.0% skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48% 1% 1%
[libx264rgb @ 0x2770760] kb/s:135693.94
-r 24fps 를 지정하는 것을 잊었 으므로 오디오와의 av 동기화를 유지하지 않습니다. (및 파일 크기가 아닌) 비트 전송률도 해제됩니다. ffmpeg의 기본값은 25fps입니다. 이 머신의 CPU는 1 세대 (콘로) 코어 2 듀오 2.4GHz (E6600)입니다.
결과 :
4.5M sintel_trailer-audio.flac # this is muxed in to every mkv
948M 1080 # the directory of PNGs
940M /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M sintel.y4m # yuv444, uncompressed. mplayer gets the colors wrong?
2342M qtrle.mkv # encode went at 16fps, so qtrle is slower and worse filesize
2105M sintel.huff.mkv # ffvhuff with default options, rgb pix fmt
1228M sintel.utvideo.mkv # muxed without audio, I should update the others this way
946M png-copy.mkv # -codec copy makes a MPNG stream. Use -codec png for non-png sources, but it won't make PNGs as small. Decodes very fast
824M lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M frompng.sintel.264rgb.mkv
735M sintel.x264rgb.medium.nocabac.mkv # encode went at 3.3 fps instead of 18. Better gain than for live-action, though
626M sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps. With CABAC, 16 ref frames, etc. etc.
512M lossy.prores.mov # yuv422p10le, 12fps
341M sintel.yuv420.x264.lossless.mkv
21M lossy.rgb.crf26.preset=medium.mkv
13M lossy.yuv420.crf26.preset=medium.mkv # remember this is WITH 4.5MB audio
참고 mediainfoRGB H.264에 대해 알고하지 않습니다, 그것은 여전히 파일 YUV를 것을 말한다.
실제로 손실이 없는지 확인하십시오.
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24 -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical
따라서 원본 PNG 입력을 복구 할 수 있습니다. 즉, 동일한 이미지 데이터가있는 PNG를 만들 수 있습니다.
-pix_fmt rgb24x264 테스트에 유의하십시오 . ffmpeg의 h.264 디코더는 gbrp (평면, 패킹되지 않은) 출력을 출력하므로 비트는 동일하지만 순서가 다릅니다. framemd5 "컨테이너"는 어떤 종류의 형식 제한도 부과하지 않지만 비트가 동일한 방식으로 배열 된 경우 동일한 md5 만 얻게됩니다. 나는 ffmpeg가 PNG를 공급할 때 pix fmt에 사용하고 있다고 말한 것을 보았고 그것을 -pix_fmt디코딩 을 위한 인수로 사용했습니다 . 또한 vlc가 RGB h.264 파일을 재생하지 않는 이유 (다음 릴리스 또는 현재 야간 빌드까지) : gbrp 픽셀 형식을 지원하지 않습니다.
yuv 사용을 위해 libx264, 아닙니다 libx264rgb. RGB 버전의 x264를 설치할 필요가 없으며 실제 라이브러리는 두 가지를 모두 지원합니다. 두 개의 다른 이름의 인코더로 구현 한 것은 단지 ffmpeg입니다. 그들이 그렇게하지 않았다면 기본 동작은 rgb 입력을 rgb로 남겨두고 동일한 품질에 대해 훨씬 높은 비트 레이트 출력을 생성하면서 실제로 느리게 실행하는 것입니다. ( h.264 출력 대신 -pix_fmt yuv420p원하는 경우 여전히 사용해야 합니다 .420444
장기 저장 용 파일을 만들지 않는 한 항상 -preset ultrafast무손실 x264에 사용하십시오. 더 많은 참조 프레임과 모션 검색은 노이즈가없는 애니메이션이 적용되지 않은 재질의 경우 손실없는 차이를 거의 만들지 않습니다. CABAC는 무손실 비트 전송률로 막대한 양의 CPU를 사용하며 심지어 디코딩에도 사용됩니다. 파일을 스크래치하지 않고 보관 목적으로 만 사용하십시오. CABAC를 사용하지 않도록 설정합니다. CABAC는 10-15 %의 비트 전송률 절감 효과를 제공합니다.
모든 프레임이 키 프레임이어야하는 경우을 설정하십시오 -keyint 1. 그런 다음 키 프레임 또는 w / e 만 잘라내려는 비디오 편집 소프트웨어는 사용자를 제한하지 않습니다.
원래 질문에 대답하려면 다음 단계를 수행하는 동안 임시 파일을 던지기 위해 수행 해야하는 작업입니다 (예 : 느린 디인터레이스, 다른 작업을 시도하기 전에 손실없는 출력 저장).
ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv
스틸 이미지 도구로 수정할 수있는 이미지 파일의 출력이 실제로 필요한 경우 png로 디코딩하십시오. 각 픽셀의 Y, Cb 및 Cr 값 각각에 대해 8 비트 중 가장 중요하지 않은 것을 잃지 않을 것입니다.
x264는 약간의 텍스트, 페이드 인 및 페이드 아웃 및 많은 프레임의 큰 영역간에 완벽한 유사성이있는 많은 검은 색 프레임이 있기 때문에 실제로 잘 나타납니다 -preset ultrafast. 라이브 액션에서 ffvhuff (yuv420) 파일 크기의 절반에 x264가 계속 표시됩니다.
궁금한 사람은 다음과 같습니다. 높은 CPU 시간 무손실 RGB 인코딩에는 (x264 코어 144 r2525)가 있습니다.
[libx264rgb @ 0x35b97a0] frame I:27 Avg QP: 0.00 size:604367
[libx264rgb @ 0x35b97a0] frame P:1226 Avg QP: 0.00 size:517512
[libx264rgb @ 0x35b97a0] mb I I16..4..PCM: 46.3% 38.1% 15.7% 0.0%
[libx264rgb @ 0x35b97a0] mb P I16..4..PCM: 24.3% 5.4% 4.5% 0.0% P16..4: 10.5% 3.3% 5.7% 0.0% 0.0% skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64% 1% 0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13% 2% 1% 1% 1% 1% 1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37% 5% 5% 6% 5% 5% 4% 3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5% 4.2% 9.1% 4.1% 2.1% 1.7% 1.2% 0.8% 0.6% 0.5% 0.3% 0.2% 0.2% 0.2% 0.2% 0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66
가중 된 p 프레임의 매우 높은 비율과 건너 뛰기 매크로 블록의 매우 높은 비율에 주목하십시오. 모든 장면 전환은 잘릴 수있는 페이드가 아니며 x264는 CPU 시간을 알려 주면 활용 방법을 알 수 있습니다.
클립을 통해 앞으로 / 뒤로 문지르는 경우 일반적으로 인트라 코덱 만 선호됩니다 (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). 짧은 GOP (1/2 ~ 1 초)가있는 일반 AVC도 소프트웨어가 무엇을하고 있는지 알고있는 한 잘 닦을 것이라고 생각합니다 (빠르게 문지르면 가장 가까운 I 프레임을 디코딩하고 GOP 내에서 디코딩하여 필요한 경우 타임 라인에서 충분히 확대 한 경우 인터 프레임).
나는 이것과 https://video.stackexchange.com/ 에 "손실이없는 코덱보다 느리고 더 나쁜 압축이라면 요점은 무엇입니까?"와 같은 전문가에 대해 부정적인 것을 게시 했지만 흥미로운 기능이 있습니다. 애플은 풀 레즈 디코딩의 CPU 시간의 1/3 정도만 사용하면 절반 해상도로 디코딩 할 수 있다고 말했다 .
ffmpeg의 prores 구현은 아마도 Apple만큼 속도에 최적화되지 않았을 것입니다. ffmpeg를 사용한 테스트로 인해 느리게 보입니다. ffmpeg 기반 도구를 사용한 무료 소프트웨어 워크 플로우가있는 경우에는 사용할 가치가 없지만 상용 소프트웨어를 사용하는 경우 시도해 보는 것이 좋습니다.
나는 비디오 편집을 많이하지 않고 주로 인코딩 만 수행하므로 prores와 같은 코덱에 어떤 테스트가 적합한 지 잘 모릅니다. short-GOP x264가 제대로 작동하지 않으면 mjpeg가 좋은 빠른 대안 일 것입니다. Linux 배포판에는 jpeg의 asm-accelerated 구현이 있으며 매우 간단한 코덱입니다. 품질 대 파일 크기 + 인코딩 / 디코딩 속도를 절충하기 위해 필요에 따라 품질을 높이거나 낮출 수 있습니다. 그것은 고대이지만, 정말 빠른 인트라 전용 코덱을 원한다면 x264를 능가 할 것입니다.
x264의 경우 x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (내부 전용, --avcintra-class설정 하는 다른 항목없이) 시도해보십시오 . 참고 superfast(CABAC 없음) 또는 faster, ultrafast아마도 손실 된 작업 에는 적합하지 않습니다 . 나는 초고속이 훨씬 빠르지 않으면 많은 품질을 잃어 버린다고 생각합니다. 사용하는 품질이 낮을수록 (높은 crf) 더 나은 인코딩을 찾는 데 더 많은 CPU 시간을 소비 할 가치가 있습니다. 그러나이 중 많은 부분이 GOP 크기 = 1과 관련이 없을 수 있습니다.
GOP 크기가 1보다 큰 경우, 인코딩에서 너무 많은 비트를 던지면 잔차를 인코딩 할 때 더 나은 인터 예측이 많은 비트를 절약하지 못합니다 (프레임 간의 노이즈 / 그레인 / 미묘한 변화가 매우 정확하게 유지되기 때문에) 그냥 초고속 일 것입니다. 그렇지 않으면, --keyint=30또는 무엇인가, 아마도 --preset veryfast --crf 12흥미로울 것 입니다.
이론적으로 주어진 CRF 설정의 품질은 사전 설정에서 일정해야합니다. 더 작은 파일 (더 빠른 디코드)을 찾고 있다면 일부 품질과 일부 인코딩 시간을 사용하는 것이 좋습니다.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov.