Day 9 ~ 10 : Audio 분석 프로토타입 개발, 성능 이슈

전날은 속이 안좋아서 새벽 4시에 들어갔는데 7시까지 잠을 못잠

15시에 시체처럼 일어나서 병원갔다가 약먹고 밥먹고 18시 출근...

 

수면시간 취침시간이 점점 밀려서 일주일에 잠을 여섯번만 자는것같은데

이러면 일지는 6번을 써야하나 7번을 써야하나 하는 잡생각

 

오늘의 목표 :

오디오 분석 프로토타입 개발

 

 

여기까지 구현하면

서버담당 백엔드 팀원이 list화한 분석 데이터가 프론트에 잘 가는지 체크

잘 가면 프론트는 그 list data를 차트화하여 웹페이지에 view

거기에 클릭한 time에 해당하는 장면 미리보기 등등 구현하면 우리의 최소기능? 프로토타입?은 완성

 

 

비디오와 마찬가지로

FFmpeg으로 오디오만 분리 후 모노타입 PCM으로 디코딩하여 output

아웃풋 파이프를 numpy array화

 

video는 frame diff를 측정하면 유의미할 것 같아서 그렇게 구현했는데,

오디오는 이 array로부터 뭘 해야 성능이 좋을지 떠오르는게 없어서 그냥 일단 이 파형을 직접 보낼 예정

 

44.1kHz의 Sampling Rate를 그대로 던져줄 경우

스트림 1시간당 소요시간 90초, 사용 메모리 0.6GB

 

여기까지로 일단 데이터를 front에서 보여줄 numerical data화 하는 분석엔진 프로토타입은 개발이 끝났는데

해결해야할 성능 이슈가 많다

 

 

토요일

상수값들을 바꿔가며 성능에 어떤 문제가 있는지 이것저것 돌려봄

 

문제점

 

SR 44.1kHz의 음원을 PCM화하면 음원 1시간당 array의 길이가 1.6억

이걸 다루는것도 살짝 딜레이가 있고, 무엇보다 램을 너무 많이 먹는다

3시간 스트림 넣으면 코드가 돌아가는 동안 램 2기가 사용...

 

가장 먼저 떠오르는 아이디어는 비디오때처럼 용량을 줄이는 것

하지만 오디오는 비디오랑 다르게 용량을 줄이면 직접적인 정보 손실이 생긴다

 

소리의 파동을 수치화할때 SR보다 짧은 파장의 부분파는 파형을 제대로 그리지 못하기 때문

SR이 낮아질수록 높은 주파수부터 손실되어 나중가면 동굴소리만 남는다

 

여자 스트리머가 공포게임하면서 비명지른 장면들 모은 유튜브 영상을 분석한 결과

용량 1/20 : 비명 피크가 소실돼서 파형이 달라짐

용량 /100 : 여자 목소리 대부분이 소실돼 아웃트로 음악만 크게 잡힘

 

실시간 스트림의 비디오는 충분히 고화질로 주어짐

화질은 높으면 보는 사람 기분이 좋으니까 높게 제공할수록 좋겠지

 

그래서 붙어있는 픽셀 4개중에 3개 떼서 화질 1/4해도 똑같이 알아볼 수 있는 영상이다

= 육안으로 보기에 분간이 가능한 선까진 줄여도 큰 문제가 없다

그래서 그냥 램이 터지니까 맘놓고 영상 화질을 수십분의 일로 줄였다

10년전 mp4로 영화보던 시절엔 이 화질로도 다 알아봤으니까...

 

하지만 오디오는 이미 극한의 이득을 취한 SR로 송신된다

SR의 절반 주파수의 아날로그 음파까지만 오디오 데이터가 커버 가능하고 사람의 가청주파수가 20kHz 내외인데

실시간 스트림의 일반적인 SR이 44.1kHz로 가청주파수를 건드리지 않는 선에서 이미 최대로 낮춘 퀄리티다.

여기서 더 줄이면 가청주파수에서 데이터가 날아가고, 보여줘야할 파형이 달라진다.

 

 

오디오는 파형만 제공하니까 그냥 추출하고 보내주면 될줄알았는데 이런 문제가 생길줄은 생각도 못했다.

이걸 어째야 하나...