풀캠정글러

오늘의 목표 (였던것) 페이지에 탑재한 Video Player 컴포넌트의 동기화 문제 해결 영상의 현재 재생시각인 {elapedTime} 값이 context {Pointer} 값을 바꿔 타 컴포넌트에 영향을 주는건 구현됐지만 반대로 다른 컴포넌트가 context값을 바꿨을 때, 그것이 elapedTime을 바꾸지 않는 상황 해결하지 못하면 예를들어 차트 컴포넌트를 완성해서 머지했을 때 차트에서 하이라이트가 될 것 같은 포인트를 더블클릭하는데도 해당 부분 미리보기가 안되는 등의 문제가 생길 것이다. = 프로젝트가 망한다는 뜻 일단 Data Chart 영역을 담당한 팀원이 멋지게 구현을 해둬서 그걸 컴포넌트에 올렸다. 차트 영역을 클릭하면 해당 위치로 context값이 동기화되는 모습 (노란 세로선) 하지만..

불꽃벼락치기로 밀렸던 일지를 겨우 다 정리하고 이제부턴 드디어 현재진행형으로 일지를 쓴다... 팀원이 비디오 플레이어와 채팅 뷰어의 기능을 구현했다 구현된 채팅 뷰어에 채팅이 보여지기 위해서는 추출한 채팅 데이터로부터 시각이랑 메세지만 남겨 {x초 : [x초에 발생한 채팅들의 리스트]}의 dict 구조체를 chatProcess의 return으로 줄 필요가 있다. 채팅을 파싱해서 시각만 추출해 분포도를 만들고 메세지는 버리던 기존 알고리즘 => 메세지도 주워서 dict에 담는 것으로 수정 알고리즘을 서버 담당 팀원에게 보내고, 구현된 컴포넌트를 제 위치에 합친 결과 영상의 재생에 따라 타 컴포넌트들의 time 값도 매 초 잘 바뀌고, Chat Viewer는 그걸 이용해서 해당하는 시각의 채팅을 보여준다. ..

전날 짠 컴포넌트들의 모습 각 컴포넌트의 jsx 파일 안에 유저 이벤트를 의미하는 버튼들을 만들어두었다 비디오 플레이어는 초마다 재생시각을 바꿔야 하니까 버튼에 t+=1, 북마커의 버튼은 누르면 그 장면으로 이동해야 하니까 t={북마크의시간값} 등등 이제 각 컴포넌트의 버튼을 눌렀을때 바뀌는 Time Pointer의 값이 다섯 컴포넌트간에 동기화되는 기능을 구현하면 된다 이걸 구현한다면 결과적으로 하나를 눌러도 나머지 컴포넌트들도 해당 시간에 맞는 모습으로 렌더링될 것 예를 들어 차트에서 눈에 띄는 부분을 클릭했으면 영상 플레이어가 해당 장면으로 넘어가서 보여준다거나 등등 일단 컨텍스트와 그걸 바꿀 함수를 선언 리액트 공식문서에는 한글로 모든게 다 있다 리액트 최고 js에는 () => {} 라는 문법으로..

팀 노션 페이지 중 일부 우리가 바라는 각 기능들이 제대로 동작하려면 function이 어떻게 굴러가야할 지 고민한 결과 이걸 구현하려면 유저 이벤트에 따라 값이 바뀌는 전역변수가 최소 두개는 필요하다. 더 늘어날 수도 있고... 리액트를 간단히 찍먹하며 느낀 것 하위 컴포넌트가 상위 컴포넌트로부터 정보를 받는건 쉽다 그냥 선언할 때 주면 됨 근데 하위 컴포넌트에서 변화가 발생했을 때 위로 정보를 올려서 갱신하는건 조금 귀찮은 우리 프로젝트에선 물론 후자를 구현해야 전체 페이지가 영상의 해당 장면 시간으로 동기화가 가능 프론트 팀원이 알려준 얘기로는 여러 방법이 있다고 한다 context 혹은 redux context를 쓰는 방법도 class 쓰기 vs function 컴포넌트에서 구현하기 등등 사실 뭐..

원래는 분석해서 시각화를 했으니 이제 하이라이트를 감지하는 알고리즘을 탑재할 계획이었다 하이라이트 포인트를 추천해주는 기능인 셈 그런데 중간발표에서 데이터 분석 툴에 가깝고 프론트단에서의 서비스적인 것이 전무하다는 비판을 들었다. 그래서 약간의 진로변경 기존 계획처럼 하이라이트 포인트를 추천하고 다운로드받는 사이트가 되면 프론트에선 아무리 잘해봐야 유튜브 음원추출해주고 영상추출해주는 원페이지 사이트급의 구현밖에 할게 없다 프리미어프로같은 UI로 웹 내에서 다양한 기능을 제공하는 에디터스러운 방향으로 가야 프론트가 뭘 했다는 것이 잘 보일 것 그리고 이걸 가능하게 하려면 팀장인 내가 알고리즘깎기에만 매달려서는 불가능하다 그냥 직전 포인트보다 일정%이상 뛴 부분을 추천하거나, 평균치보다 일정%이상인 포인트를..

수요일은 하루종일 발표 자료 제작 시연부터의 파트는 우리가 무엇을 구현했는지에 따라 달라지지만 시연 이전의 프로덕트 소개, 니즈 이해, 구현 방향 등은 최종발표때와 거의 같게 fix될 내용이니 최종발표 자료 만들듯이 각잡고 만들었다 시연 이후의 슬라이드는 개발 과정에 따라 바뀔 내용이니 적당히 힘빼고... 목요일, 발표날 슬라이드의 디자인적인 부분을 좀 다듬고, 팀원 앞에서 발표 연습 완전히 체화돼서 버퍼링 없이 머리에서 나오는 것에 대해선 발표를 유창하게 할 수 있는데 조금이라도 머리속에서 정리가 안된 부분은 바로 말문이 막힌다 학부장님 말씀대로 나라는사람이 원래 그런거라(ㅠㅠ) 고치긴 힘든 문제고, 항상 가능한한 머리속에 때려넣어서 해결해왔는데 정글에선 그러기엔 늘 시간이 부족해서 아쉽다 오후 15시..

프론트 좀 돕느라 예정에 없던 풀스택으로의 전환(?)을 하고 돌아온 사람 불꽃벼락치기때문에 일지가 일주일이나 밀렸다... 아무튼 다시 12일차로 돌아와서, 속도에 조금 문제가 있지만 아무튼 분석이 유의미한 결과를 내는 알고리즘이 완성 return값을 프론트가 요구하는 포맷으로 바꾸는 몇번의 조정을 거치고 나니 프론트도 데이터를 차트로 보여주고 해당 위치를 미리보기하는 기능까진 구현 완성 서버, DB는 나머지 한명의 백엔드가 내가 알고리즘 짜는동안 진작에 다 완성 localhost 리액트 클라이언트, 내 노트북 서버, 다른 팀원 노트북 DB로 이루어진 프로토타입이 완성됐다 느려터졌지만 완성은 완성이다... 그런데 화요일, 중간발표가 다가오자 떠오르는 이슈 : 시연에서 무엇을 보여줄 것인가 = 발표장에서 어..

오늘할일(이었던것) Chat flow 분석 프로토타입 고치기 chat flow는 오디오나 비디오랑 다르게 그냥 텍스트 형태의 JSON이라 다루기는 쉽다 그래서 주제 고르는 단계에서 대충 구현은 해둔 상태 진짜 대충... 의도와 다른 상황이 나올때마다 하드코딩으로 예외적 스루 처리를 해두고 에러 없이 돌아가는 영상들만 샘플로 쓰던 상태인데 이걸 케이스별로 제대로 분기하여 처리해서 어떤 스트림이 들어와도 에러없이 돌아가게 하는 것이 오늘의 목표(였다) 하지만 프론트에서 큰일 발생 현재 audio data는 차트가 waveform의 모양을 유지하기 위해 pcm audio를 던져준다 뭔가 메모리를 잔뜩 먹지만 그래도 추출은 되니까 프론트에 던져줘봤다 하지만 차트 라이브러리가 무거워서 차트를 그릴 수가 없다.....

전날은 속이 안좋아서 새벽 4시에 들어갔는데 7시까지 잠을 못잠 15시에 시체처럼 일어나서 병원갔다가 약먹고 밥먹고 18시 출근... 수면시간 취침시간이 점점 밀려서 일주일에 잠을 여섯번만 자는것같은데 이러면 일지는 6번을 써야하나 7번을 써야하나 하는 잡생각 오늘의 목표 : 오디오 분석 프로토타입 개발 여기까지 구현하면 서버담당 백엔드 팀원이 list화한 분석 데이터가 프론트에 잘 가는지 체크 잘 가면 프론트는 그 list data를 차트화하여 웹페이지에 view 거기에 클릭한 time에 해당하는 장면 미리보기 등등 구현하면 우리의 최소기능? 프로토타입?은 완성 비디오와 마찬가지로 FFmpeg으로 오디오만 분리 후 모노타입 PCM으로 디코딩하여 output 아웃풋 파이프를 numpy array화 vid..

7시에 들어간 업보로 15시가 돼서야 출근... 뭐 한것도 없는데 코드 몇번 실행하다보니 19시가 됐다 무거운걸 다루니 한번한번 실행이 기본 10분단위 대기라 시간 쓰는게 비효율적이게 되는듯 저녁에는 네이버 협력사 발표회가 있었다 요즘 학교에 코로나가 퍼져서 줌 화상미팅으로 대체됨 토크는 프론트 위주로 진행되어서 UI같은 창업쪽에 중요한 뷰에 도움이 됐다 발표 후 대화시간이 없어서 채용에 관련된 디테일은 못 얻은게 아쉽긴 하다 아무튼 오늘도 밤이 다 되어서야 개발 시작... 오늘의 할일 1. 프레임 분석이 쓸모가 있긴 한가 2. 어디까지 줄여도 쓸모가 있는가 모든 정보를 다 갖고있지만 분석하면 컴퓨터가 터져버리는 영상덩어리와 금방 뚝딱 나오지만 분석해봤자 아무 의미없는 모자이크 덩어리 이 사이의 어딘가에..