안녕Ȣ16;세요.
1109;편 영화 한 편1032; MOV(422HQ) 파1068;1008; 대략 170mbps1032; 비트/112;1060;트를 갖습니다. 애플 프/196;/112;스가 1060; ǥ16;야에서lj16; 업계 표1456;1004;/196; 사용.104;고 1080;습니다. ǹ17;축률 대비 품1656;1060; ƻ16;찮아서,192;1648;요.
H.264lj16; 가ǣ16;운 상영용 스크리너 용도/196; Ǹ16;1077;니다. 3Gb~20Gb까1648; 다양한 품1656;/196; 1061;스포트를 합니다. 블루/112;1060; 1228;1089; 시에lj16; 20Gb~25Gb 까1648;... H264치고lj16; 꽤나 고용량1032; 데1060;터/196; 나오lj16;데요.
Ƽ17;금한 ,163;1008;, 1) H.264 코덱1060; 가1656; 수 1080;lj16; 최대1032; 비트/112;1060;트(데1060;터 1204;송률, 1452;/196; Mb per sec)lj16; ኧ1;1064;1648;... 편1665;Ț12;에서 최대1032; Ꮢ1;션1012; ,152;고 뽑아 봐도... 소스 영상(위에 말한 422HQ1032; 파1068;)에 따라 들ᑔ1;DŽ16;ᑔ1; 합니다. Ǻ12;떤 녀석1008; 최대/196; 뽑아도 20mbps가 한계1060;고... Ǻ12;떤 녀석1008; 60mbps까1648; 올라갑니다.
그리고 2) ᇼ1;영상 파1068;1032; 비트/112;1060;트를 결1221;Ȣ16;lj16; 요소들에lj16; 뭐가 1080;lj16;1648; 1077;니다. 1228; 추측1004;/196;lj16;... 영상 소스 내에 움1649;1076;1060;나 컬러 1221;보가 많다면 비트/112;1060;트도 높,172; 뽑7176;lj16; ,163; 같1008;데 1060;,148; 그냥 추론1077;니다.1221;1201;1064; 영화라고 해서 꼭 가ǣ16;운 파1068;/196; 나오lj16; ,163; 같1648;도 않구요... 
ᕬ1;시... 1064;코딩 Ȣ16;lj16; PC1032; 사양에 따라 결과물1060; 달라1656; 수도 1080;lj16; ,148; 아닌1648;... 1060;,148; 아니,192;1424;... 같1008; Ꮢ1;션1064; 앉1008; 1088;리마다 다른 파1068;1012; 만들Ǻ12; 낸다면...
같1008; .160; 시간 1676;리 영상1064;데... 왜 Ǻ12;떤 영화lj16; 최대가 20Gb1060;고... Ǻ12;떤 영화lj16; 60Gb 용량1004;/196; 나오lj16; ,163;1068;까요...
ᕬ1;시나 해서... 영상1032; 화면비(상Ȣ16;/196; 들Ǻ12;가lj16; ,160;1008; /112;터0149;스1032; 비율)에 따라 달라1648;lj16; ,163;1064;가도 생각해봤습니다.생각해보면 2.35:11032; 영화lj16; 1.85:11032; 화면비를 가1652; 영화보다 Ȧ16;씬 더 1201;1008; 양1032; 색1221;보/0157;기 1221;보를 포함Ȣ16;,192;1648;요... 그런데.. 그/111;다고 해서 1.85:1 화면비를 가1652; 영화들1060; 꼭 고용량1004;/196; 뽑7176;lj16; ,163;도 아니더랍니다...
230828 댓글/196; 1312;Ǻ16;1452;신 ǥ16;들 감사드립니다. 말씀Ȣ16;신 사항들 체크해가며 테스트한 결과를 기/197;합니다. 테스트lj16; 다ǧ12;치 리1320;브 스ț16;디오/196; 했습니다.
H264 코덱1032; 비트/112;1060;트에 영향1012; 1452;lj16; 요1064;
- 해상도
- 프/112;1076; /112;1060;트
- 품1656; Ꮢ1;션 ( 크/196;마 비율, 패스 횟수, QP, 엔트/196;피)
- 영상 속 피사체 (물, 불, DZ14; መ1;… Particle 처/100; 보1060;lj16;,172; 많1004;면 ǹ17;축해도 용량1060; 커1652;다)
- 코덱1032; 버1204; (1452;/196; 편1665;기에 내1109;.108;)
- Ȣ16;드웨Ǻ12; 1064;코딩(GPU 사양) 여ǥ12;
가1109; 영향1012; 많1060; -180;치lj16; 순1004;/196; 1221;/148;해보면 위와 같습니다. 해상도나 프/112;1076;/112;1060;트 መ1;1008; 대ǥ12;ǥ16; 업계에서 표1456;1201;1004;/196; Ǹ16;1060;lj16; ,163;들1060; 1080;다보니 큰 변수lj16; 아닙니다. 1228; 생각에 가1109; 1032;0120; 1080;lj16; 요1064;1008; 영상 속 Ǻ12;떤 피사체가 나타나lj12;냐 1077;니다. 아래 메모lj16; 최대 품1656; Ꮢ1;션1004;/196; 5ǥ16;1012; 테스트 /116;더링한 결과별/196; 비트/112;1060;트를 기/197;한 ,163;1077;니다.
Black Solid Layer - 101kbps (아무 움1649;1076;1060; 없lj16; 솔리드 /112;1060;Ǻ12;를 5ǥ16; 1064;코딩)
엔딩 크/112;딧 - 7000kbps (ProRes 422HQ 소스/196; Ȟ17;범한 상업영화1032; 엔딩 크/112;딧1012; 5ǥ16; 1064;코딩)
/196;맨티 코0120;디 영화1032; 1068;상1201;1064; 화면 - 29.6mbps (마찬가1648;/196; ProRes 422HQ 소스)
물, 폭0156;1060; 많1008; 액션 1109;면1012; Ȣ16;드웨Ǻ12; 1064;코딩 - 92mpbs (마찬가1648;/196; ProRes 422HQ 소스)
물, 폭0156;1060; 많1008; 액션 1109;면1012; 소프트웨Ǻ12; 1064;코딩 - 185mbps (마찬가1648;/196; ProRes 422HQ 소스)
액션 1109;면1012; 가1648;고 세ǥ12;1201;1004;/196; 테스트해본 결과, Entropy Mode(CABAC, CAVLC)lj16; 비트/112;1060;트 상에 유1032;0120;한 차1060;를 0156;생Ȣ16;1648; 않았습니다. 
1032;외1032; 0156;견1008; Ȣ16;드웨Ǻ12; 가속 시 bit rate 모드가 가변(variable)/196; 사용.108;다lj16; ,163;1060;고. bit ratelj16; Ȣ16;드웨Ǻ12; 1064;코딩1012; 사용Ȣ16;1648; 않1008; ᅆ1;우가 월መ1;7176; 높,172; 나Ꮢ1;니다. 1204;1088;1032; ᅆ1;우lj16; 다ǧ12;치 리1320;브1032; 특성1068;1648; 모르,192;습니다.
정적인 화면이면 프레임당 처리해야 하는 비트수가 적고, 동적이면 비트수가 많을 수 밖에 없습니다.
영상의 상대적인 용량은 정보 엔트로피가 영향을 끼치지요. 정보량 (화면의 복잡도와 변화량 등)과 목표하는 재현 정확도가 높으면 높을 수록 용량이 크다고 볼 수 있는데.. 단, 인코더의 설계는 복잡한 부분이 많아서 저도 현실적인 최대 비트레이트 수치는 잘 모르겠습니다.
아마 1Gbps인듯합니다 (이런 비트레이트로 만들면 분당 7.5기가라는 끔찍한 수치가 나옵니다)
6.1의 Base/Mainline의 최대치가 800M인데, High Profile은 그 1.25배라고 하니 저런 수치일듯합니다
프로파일이 버전업 되면 늘어나므로 더 오를 가능성도 있습니다
2. mpeg 이후 키프레임 개념이 도입되었으므로 키 프레임의 개수와 키/다른 프레임의 변경되는 정보량, 영상 자체의 복잡도, 해상도, 컬러, 손실 압축이므로 얼마나 원본에 가깝게 처리할지(Q)라던가 많은 요인이 엃힙니다
위에도 적혀있지만, 같은 소스에 동일 설정 줘도 스팩에 따라 바뀔 수 있습니다 (GPU 제조사나 하드웨어 세대는 물른이고, 심지어는 인코더의 버전에 따라서도 차이날 수 있습니다)
1. 모든 손실 영상압축은 DCT 이산 코사인 변환 이라는 방법에 베이스를 두고 있습니다. DCT를 간단히 설명하자면, 화면의 특정 부분을 네모난 블럭으로 때우는 기술입니다. 네모의 각 꼭지점 4개는 독자적 컬러 정보를 가지고 있고요, 그 사이에는 코사인 보간을 한 색 그라데이션이 입혀지게 됩니다.
2. 아니 그런 허접 방법으로 영상 압축이 된다굽쇼! 네 됩니다 ;;;;; 생각보다 영상이란 건 초점이 안 맞아 흐릿한 부분이 많고, 이런 흐릿한 부분은 꽤 큰 DCT블럭으로 때울 수 있거든요. 사실 이건 개략적인 설명이고, 자세한 이해를 위해서는 이산푸리에 변환에 대한 지식이 좀 필요합니다만... 몰라도 이해에는 큰 문제 없습니다!
3. 추가적으로 빌딩한 DCT블록들은 허프만 코딩이나 Lempel-Ziv(LZW)알고리즘을 통해 용량을 더 줄일 수도 있습니다.
4. 거기에다가 영상으로 가면 프레임 간에 바뀌는 부분과 바뀌지 않는 부분도 있기 때문에 안 바뀌는 부분은 전부 퉁쳐서 압축할 수 있습니다. 소위 I프레임 P프레임 B프레임이라고 부르는 건데 자세한 설명은 https://tell-mia.tistory.com/46 참조하세요
5. 그리고 우리가 흔히 쓰이는 초당 비트 레이트 Bit Rate per Second 그냥 요즘은 비트레이트라고 쓰는데, 얘는 뭐냐면 이 영상 1초를 저장하기 위해서 데이터가 얼마나 필요하냐는 겁니다. 100 kbps 라고 하면 1초 저장하는데 1k비트(는 대충 128킬로바이트)정도가 필요하다는 거겠죠.
6. 아니 그런데 왜 딱 128킬로가 아니라 그 정도라는 어중간한 표현을 쓰냐고요... 그건 웃기는 얘긴데 영상 데이터 압축은 해 봐야 정확한 압축값을 알 수 있기 때문입니다. 이미 압축된 데이터는 정확한 비트레이트를 계산할 수 있지만, 무손실 영상을 압축할 때 예상 비트레이트를 100kbps라고 정해도 정확하게 100kbps로 압축 되지는 않습니다. 영상이 동적이거나 고주파 영상(=디테일이 높은 영상)은 압축이 잘 안 되기 때문이고 그 반대의 경우는 압축이 훨씬 잘 되기 때문입니다. 영상을 인코딩 할 때 비트레이트를 정하는 건 DCT블럭의 스레스홀드 값이나 기타 파라미터를 이 정도로 하면 이 정도 영상에서 대충 이 정도 비트레이트가 나오겠지 하는 값에 불과합니다.
7. 그렇다고 해서 동일하게 압축한다고 해도 어떤건 20G, 어떤 건 60G가 나오고 이러긴 어렵습니다. 비슷한 퀄리티로 압축할 경우 오차가 배로 나고 이러진 않아요 :) 그 정도로 차이난다면 애초에 압축할 때 압축 파라미터 특히 DCT블럭의 문턱값이라든가 초당 허용 가능한 I프레임의 개수 등등 이런 파라미터 자체가 차이 나는 겁니다. 당연히 고품질일수록 영상이 손실이 덜 하겠지요.
대충 이해가 되셨을라나요?
2)는 다른분이 답변했으니 생략
위 문서에 보시면 레벨별 최대 비트레이트와 해상도, FPS정보가 있습니다.
그리고 사람눈에는 정적으로 보이는 것도 기계가 해석하기에는 매우 복잡한 부분들이
잔디, 구름, 파도, 나무, 숲 같은 것들입니다.
어쨋든 컴퓨터가 해석하기에 복잡하면 용량이 커지는 구조입니다.
그리고 인코딩 결과물의 사이즈는 컴퓨터 성능보다는 코덱의 버전에 따라 용량이 달라집니다.
코덱의 버전에 따라 용량이 달라지는게 맞지만 최신 pc는 복잡한 명령어 셋을 많이 지원하고
예전 PC나 휴대폰 같은 경우 복잡한 명령셋이 없거나 지원해보 배터리 효율로 인해 선택을 안함으로 인해서 간단히 인코딩 할 수 있는 알고리즘을 선택해서
압축률이 떨어질 수 있습니다.
동적인 화면에서는 높게 정적인 화면에서는 낮게 수동으로 결정합니다.