루프 이미지 시퀀스를위한 무손실 압축 코덱

15fps에서 2 분 루프에 넣고 싶은 14 개의 PNG 이미지 ( 여기서는 중요하지는 않음)가 있습니다.

Photoshop CS3는이를위한 최고의 도구로 보였으므로 이미지 시퀀스 *로 열어 파일-> 내보내기-> 비디오 렌더링을 수행하고 AVI로 내보냈습니다.

그러나 나는 14 개의 이미지 만 가지고 있었으므로 스크립트 ( 여기서는 중요하지는 않음)를 사용하여 1805 이미지 (약 2 분의 비디오)로 복제했습니다.

Photoshop 단계를 반복했을 때 파일 크기는 원래 429KB와 반대로 55MB였습니다.

실제로 필요한 모든 비디오는 처음 14 개 파일이 링크 된 후 반복됩니다 (무손실).

어떤 코덱을 사용할 수 있습니까? 해당 코덱을 어떻게 사용합니까? (저는 OS X Lion을 사용하고 있습니다).

GIF가 아닌 비디오로 필요합니다.

_{* (열기-> 첫 번째 파일-> 틱 이미지 시퀀스)}

무손실 압축은 이미지 / 비디오 / 데이터가 압축 될 때 손실이 없음을 의미합니다 ( http://en.wikipedia.org/wiki/Lossless_compression) . 예 : zip / gzip 파일을 반복한다는 의미는 아닙니다. ffmpeg를 사용하여 이미지에서 비디오를 만들려면이 링크의 명령을 따르십시오. https://ffmpeg.org/trac/ffmpeg/wiki/Create%20a%20video%20slideshow%20from%20images

Mac OS X에서는 다음 단계에 따라 ffmpeg를 설치할 수 있습니다. http://www.markszulc.com/blog/2012/09/03/installing-ffmpeg-with-h264-support-on-mac-os-x-mountain -사자/

웹에 비디오를 넣는 경우 HTML5의 비디오 루프 속성을 사용할 수 있습니다. http://www.w3schools.com/tags/att_video_loop.asp

예를 들어 http://cordes.ca/Working/clip.html 은 뮤지컬 Working에서 짧은 x264 인코딩 된 slo-mo 클립을 반복합니다.

또한 참조 APNG / PNG로 비디오를 변환?

AFAICT에서 ffmpeg가 지원하는 비디오 컨테이너 형식 (예 : mp4, mkv, avi, nut, ogm)은 컨테이너 메타 데이터에 루프 카운트가 없습니다. 맞습니다. 반복되는 입력 프레임 시퀀스를 비디오 코덱에 공급해야하며 인코더가 막대한 중복성을 찾을 수 있기를 바랍니다.

프레임 시퀀스를 저장할 수 있으므로 gif, mng 및 webp 비디오 형식을 호출 할 수 있습니다. 그러나 이러한 컨테이너 형식 중 하나는 자신이 설계된 단일 스틸 이미지 코덱을 제외하고는 아무것도 지원하지 않습니다. 그들은 모두 루핑이있는 애니메이션을 지원하며, 아마도 무한한 루프 수를 사용하여 원하는 2 분을 줄 것입니다.

ffmpeg -framerate 15 -loop 1 -i src/b93-'%d.png' -frames 1805 -preset veryslow -crf 23 -movflags +faststart party.mp4
2.5M    party.mp4  # see [1] for the encode log

ffmpeg -framerate 15 -i src/b93-'%d.png' -loop 128 containerloop.gif
684K    containerloop.gif
...
172K    containerloop.webp

ffplay는 애니메이션 된 webp를 재생할 수 없으므로 vwebp 또는 google chrome을 사용하십시오.

왜 당신이 이것을 원할지 모르겠습니다. 애니메이션 GIF가있는 경우 재생하십시오. ffplay -ignore_loop 0 containerloop.gif유한 루프 수로 gif를 만들었으므로 2 분 동안 반복됩니다.

비디오 편집 프로젝트 용 클립을 만드는 경우에는 그 말이 맞는 것 같습니다.

[1] 16 개의 ref 프레임이있는 x264, 최대 8b 프레임, yuv444 버전의 입력 신호.

frame= 1805 fps=7.2 q=-1.0 Lsize=    2540kB time=00:02:00.20 bitrate= 173.1kbits/s    
video:2518kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.872666%
[libx264 @ 0x1a787e0] frame I:8     Avg QP:21.35  size: 18650
[libx264 @ 0x1a787e0] frame P:515   Avg QP:16.45  size:  1044
[libx264 @ 0x1a787e0] frame B:1282  Avg QP:25.79  size:  1475
[libx264 @ 0x1a787e0] consecutive B-frames:  0.7% 13.9%  0.8% 84.2%  0.0%  0.0%  0.0%  0.4%  0.0%
[libx264 @ 0x1a787e0] mb I  I16..4:  3.4% 64.4% 32.2%
[libx264 @ 0x1a787e0] mb P  I16..4:  0.9% 15.9%  0.9%  P16..4: 80.9%  0.3%  0.6%  0.0%  0.0%    skip: 0.5%
[libx264 @ 0x1a787e0] mb B  I16..4:  0.3%  2.8%  0.5%  B16..8:  4.8%  3.3%  1.9%  direct: 1.2%  skip:85.2%  L0:35.1% L1:64.0% BI: 0.9%
[libx264 @ 0x1a787e0] Weighted P-Frames: Y:75.0% UV:75.0%
[libx264 @ 0x1a787e0] ref P L0:  1.3%  0.1%  0.7%  0.1%  0.3%  0.0% 24.1% 41.7% 27.4%  0.1%  0.0%  0.0%  0.0%  0.4%  3.5%  0.4%
[libx264 @ 0x1a787e0] ref B L0:  8.7%  1.6%  0.8%  0.1%  0.7%  1.2% 74.6%  2.1%  0.0%  0.1%  0.0%  0.0%  0.4%  9.5%
[libx264 @ 0x1a787e0] ref B L1: 99.5%  0.5%
[libx264 @ 0x1a787e0] kb/s:171.40

평균 P 프레임 크기는 평균 B 프레임보다 작습니다.

무손실 모드 인 rgb 또는 yuv의 x264는 16 개의 참조 프레임을 다시 인코딩하지 않고 계속 참조 할 수있는 방식으로 정렬하지 않았습니다. 디코더 그림 순서와 그 이유를 이해하기 위해 참조로 유지되는 프레임에 대해 충분한 IDK.