Day 11 : front에 보낼 Audio 데이터 경량화

오늘할일(이었던것)

Chat flow 분석 프로토타입 고치기

 

chat flow는 오디오나 비디오랑 다르게 그냥 텍스트 형태의 JSON이라 다루기는 쉽다

그래서 주제 고르는 단계에서 대충 구현은 해둔 상태

 

진짜 대충...

 

의도와 다른 상황이 나올때마다 하드코딩으로 예외적 스루 처리를 해두고

에러 없이 돌아가는 영상들만 샘플로 쓰던 상태인데

 

이걸 케이스별로 제대로 분기하여 처리해서

어떤 스트림이 들어와도 에러없이 돌아가게 하는 것이 오늘의 목표(였다)

 

 

하지만 프론트에서 큰일 발생

현재 audio data는 차트가 waveform의 모양을 유지하기 위해 pcm audio를 던져준다

뭔가 메모리를 잔뜩 먹지만 그래도 추출은 되니까 프론트에 던져줘봤다

 

하지만 차트 라이브러리가 무거워서 차트를 그릴 수가 없다...

많아야 Video처럼 시간당 몇천개 정도의 포인트 정도의 규모로만 만들 수 있다고 한다

 

트레이딩이나 믹싱 할때 보던 차트들을 생각해서 가능하지 않을까 싶었는데 안되나보다ㅋㅋ

내가 써온건 분명 대단한 개발자들이 힘을 합쳐 개발한 거였겠지

 

아무튼 SR을 줄이면 데이터가 날아가는데 안줄이면 프론트가 터지는 이 상황을 개선하려 고민

 

문제 : 

초당 {SR}개의 점이 있다

{newSR}개로 줄이면(=0 mod newSR에 해당하는 점만 남기면) 고주파의 손실이 일어나고 파형이 달라진다

사라진 {SR - newSR}개의 점 중에 피크가 있을 가능성이 높기 때문

 

해결방법 :

SR개의 점을 전수조사하여 max값을 탐색 후 딱 두개만 그 second의 대표값으로 남기고 나머진 버린다

-> 처리에 시간은 좀 걸리지만 audio pick의 소실 없이 초당 데이터량을 줄일 수 있음

 

이렇게 wave form의 형태는 SR 44.1kHz의 형태를 유지하지만

 

 

확대하면 이런 느낌

매 초 음양 1개씩의 pick만 남기고 나머지 중간 point들을 날린 것

 

억단위의 array를 index 0부터 끝까지 탐색해야하니 시간은 좀 빡세게 걸린다

소요시간 스트림 1시간당 90초

코드 실행중 RAM 사용량은 시간당 0.6GB

 

그래도 비디오보단 덜걸리니 병렬로 처리하면 시간단축이 될거라 믿는다.

그리고 이건 피크값만 남기는거니까 뭔가 GPU도 할수있을법한 계산같은데, 시간이 되면 한번 시도해보자

 

 

이미 새벽3시반

이제와서 오늘안에 chat flow 알고리즘을 뜯어고칠 수는 없을 거라 생각해서

비디오 쪽이나 자잘하게 수정하기로 했다

 

무식하게 구현한다고 영상 전체 frame 크기만한 numpy array를 2개나 썼는데,

어떻게 머리를 잘 써서 하나의 for문 안에서 잘 돌리는 것으로 array 하나로 해결

코드 실행중 RAM 사용량 반토막

 

굿

 

근데 줄인게 시간당 1GB

소요시간은 시간당 100초

 

어지럽네...

 

오디오도 비디오도 근본적인 해결이 필요

 

평소에 쓰던 프리미어프로같은 프로그램들은 아웃풋 누르는 순간 파일 path가 딱 생겨서

그때그때 완성된 부분은 디스크에 파일화해두니 아무리 큰 파일을 다뤄도 RAM이 터지는 일은 없었는데

이게 RAM이 안터지고도 분석이 가능한 방법이 분명 어떻게든 있다는 것을 의미할텐데

이걸 어떻게 하는건지 알아볼 필요가 있다