1. 개요
COder and DECoder음성 또는 영상의 신호를 디지털 신호로 변환하는 코더와 그 반대로 변환시켜 주는 디코더를 통틀어 부르는 용어이다.
2. 상세
고용량의 미디어 파일 크기를 획기적으로 줄일 수 있게 하여, 파일 저장과 스트리밍을 수월하게 했으며, 역으로 보다 고화질의 영상을 즐길 수 있게 하였다. 소프트웨어 코덱과 이를 물리적으로 구현하여 효율을 높인 하드웨어 코덱이 있으며, 알고리즘 발달과 CPU 성능 개선으로 여러 고사양의 코덱이 개발되어 왔다.영상 신호를 디지털 신호로 변환하는 것을 코딩( 인코딩), 디지털 신호를 영상으로 변환하는 것을 디코딩이라고 한다. 일반적으로 0과 1로 부호화-복호화 하는 것을 모두 인코딩-디코딩이라 하지만, 멀티미디어(소리, 정지영상, 동영상) 영역 그중에서도 비디오 영역에서 크고 아름다운 임팩트를 발휘하기에 코덱은 동영상 인코딩 (+디코딩)에서 주로 쓰이는 용어가 되었다.
멀티미디어들은 아날로그 신호들이다. 이것을 디지털로 부호화 하기 위해서는 샘플링을 하는데, 이를 조밀하게 하면 원래 신호와 거의 똑같게 구현할 수 있지만, 용량은 기하급수적으로 늘어나게 된다. 다행히도 아날로그 신호는 Sin 함수 등등으로 계산하여 구현할 수 있고, 사람이 인지하지 못하는 것은 가비지로 처리할 수 있는 등의 특성이 있어, 용량을 줄일 수 있는 여지가 매우 컸다. 이에 따라 다양한 압축 알고리즘들이 개발되었고 코덱이란 이름으로, 자세히는 손실 압축 포맷, 무손실 압축 포맷, 무손실 무압축 포맷 종류로 상황과 필요에 따라 발전되었다.
초창기에는 코덱 춘추전국시대였다. 듣도보도 못한 코덱도 많았고, 모르는 코덱으로 저장된 미디어 파일은 재생을 못하는 경우도 많았다.[1] 그럼에도 인터넷과 파일공유가 발전하면서 해결책이 하나 둘 나오기 시작했다.
- " 통합코덱"은 코덱을 하나하나 설치하는 것이 귀찮은 사람들을 위한 코덱 모음집이다. 당시에는 필수 프로그램이었지만, 불필요한 코덱으로 인한 용량낭비, 중복코덱, 코덱 버전 충돌 및 시스템 크러시, 애드웨어 삽입 등으로 인한 문제로 현재는 추천하지 않게 되었다.
- "내장코덱"은 몇몇 동영상 플레이어가 자주 쓰는 코덱을 안에 포함하고 재생시켜주는 방식이다. 코덱을 설치하지 않아도 동영상이 재생되기 때문에 코덱에 대한 이해가 부족한 유저들로부터 "유능한 플레이어"로 칭송을 받았다. 곰플레이어는 그 선두주자이며 이 덕분에 여전히 많은 사람들이 Windows Media Player 대신 곰플레이어를 설치해서 쓴다. 현재는 이를 따르는 KMPlayer, 다음 팟플레이어등의 다양한 미디어 플레이어들이 있으니 취향에 따라 설치하여 쓰면 된다. 덧붙여 이러한 플레이어들은 내장 코덱에 없는 코덱으로 인코딩된 영상을 재생하려 하면, 영상을 분석하여 필요한 코덱을 찾아서 깔도록 해 주기도 한다.
- " FFmpeg"는 현재 쓸만한 코덱의 통합코덱이다. 상위 미디어 플레이어의 내장코덱 그 자체이며, 사실상 표준코덱이다. LAVFilters는 FFmpeg의 디코딩 기능만 떼온 특허문제에서 자유로운 재생 전용 코덱이다. 이 코덱만으로도 대다수의 영상이 재생되며 퀵타임(.mov)코덱과 리얼 플레이어(.rm) 코덱를 추가로 설치하면 거의 모든 영상을 재생할 수 있다.
코덱의 역사는 MPEG 역사와 궤를 같이 한다. 위에서 언급한 FFmpeg 이름에서 알 수 있다.
- 초창기 코덱의 춘추전국시대에는 다양한 코덱이 존재했다. 그 중 MPEG-1 Audio Layer 3 ( MP3)가 현재까지 이어져 내려오고 있다.
- MPEG-2 Part.2 시대. DVD로 정리되며, 코덱의 대세가 일단락 되었다. WMV가 유명하다.
- MPEG-4 Part.2 시대. 인터넷(스트리밍)에서 급격한 발전이 있었으나, 마이크로소프트의 독점적 행태( ASF, MS MPEG4)에 반기를 들면서 DivX, DivX의 독점에 반기를 들면서 Xvid가 등장하였으며 어둠의 세계에선 "대 P2P 시대"가 열린다.
- MPEG-4 Part.10/ H.264(AVC) 시대. MPEG(미디어)그룹과 ITU(통신)그룹이 연합하여 코덱을 발전시켰다. 그래서 같은 코덱인데 이름이 두개다. iPhone, Blu-ray Disc 이후부터 사람들에게 친숙해졌다. 이어서 MPEG-H Part.2( H.265 HEVC, HEIC, UHD)가 나온다.
이정도를 알면 코덱 역사의 기본 뼈대를 안다고 해도 된다. 조금 더 나아가 MPEG의 대항마 오픈소스 진영 ( FLAC, VP9, AV1) 정도만 더 알면 좋다. 상세한 내용은 별도 목차 참고.
같은 영상이라도 코덱의 차이에 따라 재구성된 화질이 달라진다. 이 때문에 돈 들여서 컴퓨터에 직접 장착하는 하드웨어 디코더를 달거나, 소프트웨어 코덱이라고 하더라도 유료 코덱을 사서 쓰던 시절도 있었다. CPU나 GPU의 성능이 부족하던 1990년대 중반까지는 소프트웨어 디코딩이 거의 불가능하여, 데스크탑 PC에 필수적으로 하드웨어 디코더를 달아야만 동영상을 볼 수 있었다.[2] TV같은 경우는 화질 향상을 위해 다양한 후처리 과정이 이루어지는데, 이를 위해 자체 하드웨어 디코더를 쓴다. TV에서 영상을 직접 재생하면 컴퓨터에서 재생할 때 보다 화질이 좋아보이는 이유.
스마트폰 기준으로 최근 주요 코덱의 하드웨어 디코더가 보급된 시기를 간략히 정리하면 다음과 같다. 상세내용은 각 문서 참고.
- 2014년, H.265 하드웨어 디코더가 갤럭시 S5, 노트4, 갤럭시 알파, LG G3 중심으로 보급되기 시작한다.
- 2015년, VP9(비디오 코덱) 하드웨어 디코더가 갤럭시 S6, 노트5, LG G5, LG V20 중심으로 보급되기 시작한다.
3. 인코딩 설정 옵션
인코더에 따라 다르지만, 코덱을 사용하여 인코딩을 할 때, 보통 다음과 같은 것들을 고려하게 된다. 음원 음질은 상향평준화되어 코덱 옵션에 딱히 선택장애가 일어나지 않는다. 많은 고려사항들이 영상 옵션에 달려있다. 많은 동영상 인코더가 FFmpeg 기반으로 만들어져 있기 때문에, FFmpeg 일반옵션의 명령어를 참고하면 인코더 기능의 존재를 파악하기 좋다. 이쪽은 인코더 기능의 의미를 이해하는데 도움이 되는 서술을 한다.- 파일형식: 컨테이너 선택. mp4, mkv, webM 등의 껍데기를 지정한다. 컨테이너에 따라 지원되는 코덱종류(정확히는 인코딩 된 미디어 포함 가부), 자막이나 메타데이터의 포함여부가 갈린다.
- 코덱: 비디오코덱, 오디오코덱 종류 선택
- 프로파일: 영상 용도에 따라 사용할 기술을 묶어놓은 것. 가령 "고압축 저용량"을 추구할 것인가 "저압축 저지연"을 추구할 것인가 "구형 기기"에서도 돌릴 수 있도록 할 것인가 등등에 따라 설정해야 할 프로파일이 다를 수 있다.
- 크로마 서브샘플링: 4:4:4, 4:2:2, 4:1:1, 4:2:0 등 색차 샘플링 방식으로 용량을 절약하는 설정값이다. 자세한 내용은 YUV문서 참고.
- I 픽처 P 픽처 B 픽처: I 픽처는 소위 키프레임 역할을 하는 이미지이고, P픽처 B 픽처는 움직이는 정보만 이전 이미지(P), 이전 이후 이미지(B)를 참고하여 저장해서 용량을 줄인 이미지이다. I 픽처가 일반 사진 용량임에 비해 P, B는 용량을 훨씬 아낄 수 있다. 다만 B는 용량을 극히 아낄 수 있지만, 높은 연산량을 요구해서 실시간 방송용 프로파일에서는 쓰지 않는 경향이 있다.
- 레벨: 영상이 주는 부담과 이에 따라 요구되는 성능에 대한 인덱스를 제공한다. (따로 설정할 옵션은 아니다.)
- 품질: FFmpeg기준, 퀄리티, 퀀타이저, (평균)비트레이트 등의 설정값으로 조절한다.
- 퀄리티 기준: FFmpeg의 crf 옵션값이며, "가변비트레이트(VBR) 종합적인 화질우선 기준"을 수치화 한다. 0~51(주로 18~27) 범위이고, 손실률 개념과 궤를 같이 하므로 값이 클수록 화질이 떨어진다. 품질 기준을 잡기 무난하지만, 인코딩 후 용량을 가늠하기 아주 어렵다.
- 퀀타이저 기준: "절대적 화질 우선 기준"을 수치화 한다. 일종의 양자화 값이며 crf값과 마찬가지로 0~51(주로 18~27) 범위에서 설정을 할 수 있다.
- 평균 비트레이트 기준: "용량 기준"을 수치화 한다. 비트레이트(후술)에 시간을 곱하면 파일 용량이다. 파일 크기를 예측할 수 있지만, 화질은 예측하기 어렵다. 인코딩시 2pass로 두번 인코딩하면 인코더가 시간에 따라 고화질(움직임 많음) 저화질(정적임)을 어떻게 배분할지 파악할 수 있어서 화질에 좀더 유리하다.
- 샘플레이트(Sample rate): 음원 샘플링 빈도. 높을수록 고주파음을 담을 수 있고, 낮을수록 먹먹해진다. 용량관점에서는 아래 비트레이트와 유사하다.
-
44100(Hz):
가청주파수의 2배, 48kHz: 고음질 음원, 8kHz:
저음질사람 음성 위주 음원(전화, 무전기 등) - PCM(무압축) 음원 기준으로, 샘플레이트에 비트수를 곱하면 비트레이트가 되며, 시간을 곱하면 파일 용량이 된다.
- 비트레이트( BPS, bit per sec): 시간당 처리하는 용량. 비트레이트가 높을수록 화질이 좋아지지만, 파일 용량이 높아지며, CPU에 부하가 걸릴 수 있으며, 네트워크 속도( QoS에 따라 버퍼링이 걸릴 수 있다.
- 미디어 - MP3 128~320kbps, CD 1411kbps, 케이블방송 5Mbps, DVD 10Mbps, 지상파(HD) 20Mbps, 블루레이 40Mbps (근사치)
- 네트워크 - 2G음성: 8kbps, 3G음성: 12.2kbps, 3G데이터: 3Mbps, 데이터 무제한 요금제 QoS: (400kbps, 1,3,5Mbps), LTE: 75Mbps(CAT따라 다름), 일반 인터넷:100Mbps, 기가 인터넷 0.5~1Gbps
- VBR(가변비트레이트, 고용량이 필요한 시간구간에 많은 자원을 몰아줄 수 있어 효율 높음), CBR(고정비트레이트, 뒤로가기 등 탐색에 유리), 그 외 코덱에 따라 혼합형 등등이 있을 수 있다.
- 프레임레이트( FPS): 1초에 보여지는 영상 프레임. 낮으면 화면이 뚝뚝 끊긴다. 30fps 기준으로 움직임이 많으면 60fps, 정적이면 24fps(영화), 10~15fps(CCTV)를 쓴다. 같은 비트레이트(용량)라면 fps가 높을수록 fps에 자원이 더 배분되어 화질은 떨어질 수 있다.
- 키프레임: 일정 시간당 저장되는 일종의 스틸컷 화면. 코덱은 이미지 모두를 저장하지 않고 변화되는 부분만 저장하며, 대략 10초 간격으로(변경가능) 띄엄띄엄 이미지를 저장하기 때문에 용량을 많이 줄일 수 있다. 키프레임 간격이 너무 길면 뒤로가기 할 때 이미지를 계산해 내느라 딜레이가 걸린다. 같은 비트레이트(용량)라면 키프레임이 많을수록 여기에 자원이 더 배분되어 화질은 떨어질 수 있다.
- 영상 사이즈: 영상 해상도. 높을수록 선명한 화면(큰화면)을 보여주지만 적절 비트레이트(용량)를 선택하지 않으면 화질이 떨어질 수 있다. UHD, HD 외에도 타깃 재생기기에 따라 적절히 선택한다.
- 인코딩 시간: 화질을 포기하고 시간을 선택하거나(생방송), 시간을 버리고 화질을 선택하거나(DVD 등), 그 중간 적정선을 선택할 수 있다.
-
일반적으로 최신 코덱이 인코딩 시간이 길다.
최신 컴퓨터 성능을 믿고 CPU를 갈군다. - OpenCL, GPGPU 등의 하드웨어 가속: 일반적으로 인코딩은 CPU(똑똑하다)가 관여한다. 그러나 GPU(머릿수가 많다)의 도움을 받아 시간을 현저하게 줄일 수 있다. 그 결과물은 조별과제 같아서 아직 많은 기술개발이 필요하다(...)
- 1pass, 2pass: 이미지를 분석하여 효율적인 인코딩을 할 수 있으나, 시간이 두배 걸린다.
- Direct Stream: 인코딩을 하지 않고, 그대로 저장하는 옵션. 인코딩을 하지 않고 파일변환을 하기 때문에 아주 빠르다. 미디어를 자르기만 한다던가, (메타데이터 관리를 위해) 컨테이너만 바꾼다던가 할 때 쓴다. "스트림 복사" 등 다른 이름으로 불리기도 한다.
- 녹화: 재생하는 시간만큼 미디어 저장시간이 걸린다(...)
사실, 인코딩을 위해 효율적인 설정을 연구하고, 좋은 하드웨어를 사느니 하드디스크를 하나 더 사는게 싸게 먹힌다는 것이 정설이다.
4. 오디오 코덱
🎵 오디오 코덱 | |||
{{{#!wiki style="margin: 0 -10px -5px; min-height: 26px" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin: -6px -1.5px -13px" |
<colbgcolor=#555>
손실 압축 |
<colbgcolor=#555><colcolor=#fff>일반 | MP1 · MP2 · MP3 · mp3PRO · AAC · Musepack · WMA · Vorbis · Opus · USAC |
음성 특화 | AMR-NB · AMR-WB · AMR-WB+ · WMA Voice · Speex · Opus · Codec 2 · EVS · Lyra | ||
다중채널 특화 | AC-3 · SDDS · DTS · AC-4 | ||
블루투스 | SBC · aptX · AAC · LDAC · SSC( Samsung Seamless Codec · Samsung Scalable Codec) · LC3 | ||
무손실 압축 | FLAC · ALAC · APE · TAK · WMA Lossless · TTA · WavPack | ||
무손실 무압축 | PCM ( WAV · AIFF) | ||
관련 문서: MIDI · DSD | |||
관련 틀: 그래픽 · 오디오 · 비디오 |
- 음성특화: 사람 음성 영역대 외의 소리를 잘라내어 용량을 줄일 수 있다. 음성 용량을 낮추고 빠른 압축이 가능하면 원격회의시 지연율을 낮출 수 있다.
- 다중채널 특화: 5.1채널 영화관 용도. mp3가 스테레오 2채널만 지원해서 발생한 카테고리이다.
- 블루투스 특화: 저전력 저압축 저지연(버퍼링)의 빠른처리가 필요하다.
- AC3 (1991): 돌비의 오디오 코덱. 동영상에서 5.1채널 오디오를 담을 수 있기 때문에 mp3 대신 사용된다.
- MP3 (1993): 손실 압축 포맷 음원의 사실상 표준
-
AAC (1997): MP3의 후신
이지만 mp3가 자리를 비켜주지 않는다. iTunes나 동영상의 오디오 코덱으로 활용되기 시작했다. -
WMA (1999): MS의 오디오 컨테이너/코덱이므로, 스마트폰에서 재생을 보장할 수 없다.
MS의 스마트폰 장사가 망했다 - AMR-WB (1999): 낮은 대역폭에 목소리만 집중한 오디오 코덱.
- Vorbis (2000): 오픈소스. 로열티 없는 mp3라는 강점이 있었는데 오랫동안 큰 관심을 끌지 못했다가, 드디어 2017년 mp3 특허가 만료되어 사람들은 mp3 기술을 로열티 없이 자유롭게 쓸 수 있게 되었다(...)
- FLAC (2001): 오픈소스. 무손실 압축 포맷이기 때문에 mp3 대신 사용된다.
- Opus (2012): 오픈소스. VoIP용 코덱에 두루 쓰이긴 한데, 사실 유튜브 오디오코덱으로 더 널리 사용되고 있다.
- 기타: TwinVQ, QDesign, G.7xx, Wavpack, TTA, OptimFROG
5. 비디오 코덱
🎞️ 비디오 코덱 및 포맷 | |||
{{{#!wiki style="margin: 0 -10px -5px; min-height: 26px" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin: -6px -1.5px -13px" |
<colbgcolor=#555>
코 덱 |
<colbgcolor=#555> | MPEG-1 · MPEG-2 Part 2(H.262) · MPEG-4 Part.2 ( DivX · Xvid) · H.261 · H.262 · H.263 · H.264 · H.265 · H.266 |
기타 | DV · WMV · Theora · VP8 · VP9 · AV1 · Apple ProRes · Bink · GoPro CineForm · Motion JPEG | ||
컨테이너(확장자) | ASF · AVI · BIK · FLV · MKV · MOV · MP4 · MPEG · OGG(OGV) · SKM · TS · WebM · WMV | ||
관련 틀: 그래픽 · 오디오 · 비디오 |
- H.26x: ITU(통신연합)[3]와 MPEG(동영상 전문가 그룹)[4]의 연합. [5]
- H.262 (1995): HDTV, DVD, 캠코더에서 활용. 화질에 강하며 압축률이 낮아 용량이 큰 편이지만, 적은 컴퓨터 리소스로도 편집이 수월하다.
- H.263 (1996): 스트리밍을 강화하였다. 저해상도(영상통화,화상회의)는 h.263으로, 고해상도(MS- ASF, DivX, Xvid)는 MPEG4, 혹은 그 개조버전으로 통용되었다.
- H.264 (2003): 블루레이, iPhone 이후 스마트폰에서 활용. 현재 가장 널리 쓰인다.
- H.265 (2013): UHD에서 널리 쓰일 예정이다.
- 개발중: H.266 (2020), MPEG-5( EVC(2018)[6], LCEVC(2018)[7] )
- WMV (2003): MS 전용 코덱이었다.
- AV1 (2018): 여러 회사에서 연합해 개발한 코덱이다.
- Theora (2004)
- VP8 (2008)
- Daala (2013): Theora의 후속, AV1으로 통합된 오픈소스 자유기술 코덱
- VP9 (2013): Google이 서포트하는 코덱
- 통합코덱 시절의 춘추전국시대 코덱들
- CinePak (1991)
- Intel Indeo (1992)
- Realmedia (1997): 리얼네트워크사(社)의 리얼 플레이어 전용 코덱
- 기타
- Dirac (2008): SMPTE VC-2 표준. BBC R&D의 오픈소스 자유기술 코덱
- 시네폼 (2002/2017): 소위 고프로 코덱, SMPTE VC-5 표준, 2017년 이후 오픈소스가 되었다.
- ProRes (2007): 애플
- DNxHD (2008): AVID, SMPTE VC-3 표준
- NETVC (2015)
- XVC - 2017년 말 발표된 코덱으로, 당시 VP9/HEVC보다 효율이 높았으며 2018년 중반까지는 AV1보다 효율이 높았다. 하지만 AV1 인코더/디코더의 발전으로 속도와 화질 모두 AV1에 뒤처지게 되었으며, 2020년 VVC 발표 이후에는 설 자리를 잃었다.
용량 대비 화질 효율은 일반적으로 MPEG-2 < Theora < WMV 9, Xvid < VP8 < H.264 < VP9 < HEVC < AV1 < VVC 순이다.
최근에 나온 코덱일수록 비트레이트가 부족할 때 깍두기 현상은 줄어드는 대신 디테일은 버리는 경향이 크다. 압축 알고리즘을 개선하더라도 같은 비트레이트에 데이터가 유의미하게 많을 수는 없기 때문이다. 새로운 코덱이 나오더라도 기존영상들의 코덱을 금방 버리지는 않는 이유. 하지만 고 해상도로 갈 수록 디테일 생략이 눈에 덜 띄기 때문에 픽셀 추측 알고리즘을 개선하여 깍두기를 없애는게 대체적으로 효율적이다.
← 깍두기 증가 | 디테일 감소 → | ||||||
MPEG-2 | Theora | Xvid, WMV 9 | VP8 | H.264 | VP9 | HEVC | AV1 |
6. 비교개념: 컨테이너와 확장자
세 줄 요약.- 코덱: 미디어파일 압축방식. 코덱에 따라 용량과 화질이 좌우되며 재생이 불가능할 수 있음.
- 컨테이너: 코덱으로 압축된 미디어와 코덱 이름, 제목, 아티스트, 날짜 등의 메타데이터
- 확장자: 텍스트 꼬리표. 수정해도 파일 본질은 안바뀜. 코덱명의 확장자(aac, opus 등)와 컨테이너명의 확장자(m4a, ogg 등) 같이다양한 확장자가 존재함.
과거에는 코덱으로 압축된 음악파일 그림파일 그 자체로 관리되었기 때문에 컨테이너란 개념이 희박했다. 파일(내부)의 헤더와 파일명의 확장자로 파일을 관리하면 충분했었다. 하지만 음악파일에 앨범명 아티스트명 등의 음악 외 정보를 기록해야 할 필요성 (ID3), 사진파일에 날짜 태그 위치 등의 이미지 외 정보를 기록해야 할 필요성 (EXIF), 동영상 파일에 음성과 자막정보 등의 움직이는 이미지 외 정보를 기록해야 할 필요성이 생기면서 컨테이너란 개념이 필요해졌다.
동영상은 애초에 영상과 소리가 함께 담겨야 하기 때문에 컨테이너 개념으로 파일이 이루어져 있다. 해당 컨테이너가 최신 코덱을 지원하는지 못하는지가 문제될 뿐, 다양한 코덱으로 압축된 미디어 바이너리를 품을 수 있게 구성되어 있다. (= 재생 못하는 코덱을 품을 수도 있다.) 이에 따라 같은 avi 확장자의 파일인데 재생되는 영상과 재생되지 못하는 영상이 나오는 것이다. 자막을 품을 수 없는 구버전의 컨테이너(avi)는 별도의 자막파일을 보유해야 하지만, 자막을 품을 수 있는 신버전의 컨테이너(mkv)는 자막파일이 없어도 자막이 보일 수 있다. 컨테이너가 버전업이 되어 컨테이너가 달라지면 구버전과 차이를 명시하기 위해 확장자를 바꾸기도 한다. (mpg → mp4)[8] 같은 컨테이너라도 파일을 읽어야 하는 앱을 달리 지정하기 위해 굳이 확장자를 바꿔 명시하기도 한다. (영상 mp4, m4v & 음악 m4a) 스트리밍(버퍼링), 비선형탐색(되감기) 등의 기능에 따라 컨테이너 내 영상저장방식이 달라지기도 하므로 이를 구분하기 위해 확장자를 명시하기도 한다. (asf, TS, mTS)
음악은 과거에는 소리만 나면 되기 때문에 소리정보만 담고 적당한 이름의 확장자(wav)를 사용했었다. 이용해야 할 코덱을 지정해야 한다면 코덱명(mp3)을 확장자로 사용하면 되었다. 따라서 컨테이너 개념이 희박했다.
-
mp3가 널리 보급되면서 "음악제목 아티스트명 앨범명 장르" 등을 기록하고자 하는 요구가 발생했는데, 이에 따라 mp3는 컨테이너로
마개조 되었다(...) 어떤 앱은 mp3에 ID3 방식의 메타데이터를 삽입했고, 어떤 앱은 APE 방식의 메타데이터를 삽입했고, 어떤 앱은 메타데이터가 있음에도 읽을 수 없었고, 어떤 파일은 각 메타데이터마다 다른 내용이 들어있는 등
혼파망이 발생했다. 메타데이터를 파일 끝에 삽입하여 파일을 전부 읽은 후에나 노래 제목을 보여주는 상황도 있었고, 이를 개선하기 위해 파일 앞에 노래 제목을 기록하게 되었으나, 옛날에 만든 mp3 플레이어는 노래제목을 소리정보로 이해하고 연주하려 하는 (혹은 에러를 내뿜는) 웃픈 상황도 발생했다. 사람들은 표준화된 컨테이너의 필요성을 깨닫게 되나, mp3는 2019년까지도 음원의
사실상 표준 지위에서 내려오지 않았다(...)
어떤 메타데이터를 읽을지 몰라서 다 집어넣었어 - m4a는 mp4 컨테이너를 사용하여 mp3와 같은 문제를 갖지 않는다. m4a 속 오디오 코덱인 aac로 이루어진 *.aac 파일은 메타데이터를 갖지 않는 거의 순수한 음악 파일로 존재한다.
-
ogg 컨테이너는 vorbis comment라는 메타데이터 방식을 이용하지만, 사람들은 flac 코덱명 확장자의 파일을 주로 쓴다. 무손실음원을 구별할 수 있는 필요성에 의한 현상인데, flac 메타데이터와 ogg 메타데이터 중 선택적으로 하나만 읽을 수 있는 앱이 다수 존재하는 듯 하다(...)
현실은 시궁창
사진은 JPG 이후 큰 발전이 없었다가 디지털카메라가 EXIF를 저장하면서, 아이폰이 HEIF를 사용하면서 분위기 전환이 된다.
- jpg는 단순 이미지 정보만 담은 역사와 전통의 구버전이고, EXIF JPEG는 메타데이터를 포함한 jpg 컨테이너이다. 확장자는 둘다 jpg다.
- bmp, gif, png는 컨테이너라기보다는 순수 이미지파일로 '취급'된다. 메타데이터를 넣은 무손실압축 이미지는 tiff 컨테이너를 쓰는 경향이 있다.
- HEIF는 다름아닌 HEVC의 스틸컷을 담은 이미지 파일(컨테이너)이다. HEVC의 라이센스 문제도 덤으로 따라와 제약이 많다.
[1]
그 당시에는 주로
VHS나
VCD 등의 매체와 전용 플레이어로 영상을 감상했다.
[2]
90년대 중반까지는 GPU를
그래픽 렌더링 이외의 작업에 사용한다는 개념조차 없었고, CPU 성능도 충분하지 않아 MPEG1으로 인코딩된
비디오 CD를 재생하기 위해
ISA 슬롯에 비싼 하드웨어 디코더를 사서 달았다. 이후 MPEG2로 인코딩된
DVD 동영상 재생을 위해
PCI 슬롯에 꽂는 디코더가 출시되었으나 CPU 성능 향상으로 소프트웨어 코덱이 보편화되자 사장되었다.
[3]
저대역 통신망에서 동영상 스트리밍 요구가 강함
[4]
저용량 고화질 요구가 강함
[5]
혹은 같은 기술에 이름을 따로 붙이는 자존심 싸움
[6]
Base + Enhanced 컨셉으로 구성된 코덱. Base 툴은 특허가 만료된 기술로 구성되었고(MPEG4급 기술), Enhanced 툴은 최신(유료)기술들로 구성되어 이 두 조합으로 인코딩의 효율을 높인다. Base는 하드웨어 인코딩으로 빠르게, Enhanced는 소프트웨어로 유연하게 처리할 계획이 있는 듯 하다.
[7]
Base + Enhanced 컨셉으로 구성된 코덱. 기존 코덱(avc, hevc, vp9, av1)을 Base삼고, 이를 Enhanced 시키는 기술들로 구성되어 이 두 조합으로 인코딩의 효율을 높인다. Base는 하드웨어 인코딩으로 빠르게, Enhanced는 소프트웨어로 유연하게 처리할 계획이 있는 듯 하다.
[8]
확장자를 바꾸면 코덱이 바뀌는 줄로 오해하기 좋다.