아직도 Google WebRTC 코드와 시간을 보내고 있다. AV1 인코더는 요새 부쩍 빨라진 libaom 2.0을 써도 넷플릭스가 만든 svt-av1을 써도 어셈블리 반 러스트 반인 rav1e를 써도 라이브에 적용하기에는 성능이 별로라 접고 만만한 VP9을 썼다.
Google WebRTC에서 안 쓰는 기능들 샥샥 날려 압축한 바이너리 크기도 아키텍처당 3MB 미만으로 줄였다. 뭐 하나 고칠 때마다 iOS arm64 x86_64, macOS x86_64 프레임워크 빌드하고, Android 빌드 환경은 리눅스만 지원하니 VirtualBox 속 우분투에서 arm arm64 x64 빌드해 나오느라 조금 지치는 구석이 있다.
앱은 플러터로 만들지만 화상채팅은 다 WebRTC 바이너리가 하고 플러터에서는 픽셀 버퍼 뿌리기만 해서 성능 이슈는 아직 없다. iPhone XS에서는 프레임당 인코딩 6ms 디코딩 2ms 정도인데, 저가형 안드로이드 Moto G에서는 프레임당 인코딩이 25ms 정도로 느린 편이나 나중에 문제되면 안드 인코더만 H264로 바꾸면 되고, 5분 통화해도 폰이 막 뜨거워지는 건 아니니 넘어가기로 했다.
이제 방화벽 환경 만들어 STUN, TURN 서버 테스트만 하면 다시 일상으로 돌아갈 수 있다. 세븐틴 13명이 한 자리에 모여 각자 아이패드 앞에서 팬미팅 한다 치면 인바운드 아웃바운드 합쳐 3MB/s 정도 쓴다. 부담되는 트래픽은 아니지만 팬미팅 장소를 내가 통제할 수 없기 때문에 가능한 한 방탄 투바투 엔하이픈 정도 스케일만 했으면 좋겠다. 13명은 부담스럽다.
번아웃 방지 차원에서 중간중간 Daygram macOS 버전을 만들어 런칭했다. Mac Catalyst로 날로 먹긴 했지만 일단 폰이랑 데스크탑 iCloud 싱크가 되니 일기를 더 자주 쓰게 된다. 500원으로 할인 중입니다..?
Continue Reading
Discover more thoughts and insights
우선순위 측정
우선순위를 측정할 수 없다면 초심을 잃거나 기회를 놓치게 될 것이다. 지키고자 하는 초심이 그럴만한 가치가 있는지, 주어진 기회가 자신에게 좋은 것인지 나쁜 것인지 판단할 수 없다면, 정체성을 찾지 못한 것이며
ActionScript 3 삼매경
처음에 Flash 란 녀석을 접했을 때는 '디자이너만 쓰는 건가보다' 였다. 그때가 99년 00년 시절이던가. 사내 디자이너 누님들이 쓰는 것을 보고 마냥 신기해하기만 했다. 그러다가 다시 흥미를 가지게 된 것은
인간관계 향상에 방해가 되는 요소
확대해석 여기서부터 시작해서 의심도 하고, 별별 자기만의 정보로 결정을 내리기 시작하며 문제는 시작되었다. 자기 방어와 자기 합리화가 무의식적인 수준에서 초스피드로 이루어지는 시스템을 가진 내겐 큰 적. 물론