Journal Archive

: 카메라 디바이스 API를 통해서 Raw 데이터를 받는다. 이때 YUV 데이터를 받는다면 RGBA 형식으로 변환이 필요하다. 화면 Rendering 할 때 OpenGL 라이브러리를 사용하는데, RGBA 형식으로 받아서 처리하기 때문이다.

: 그림 2와 같이 얼굴 특징점을 추출한다. 레퍼런스로 분석하고 있는 기존 시스템에서는 총 96개의 얼굴 특징점을 추출하여 사용하였다.

Fig. 2. 
Face Landmark Position[6]

: 사용자가 원하는 스티커를 다운로드 받는다. 이때 이미지뿐만 아니라, 얼굴 특징점과 매칭되어 화면 랜더링 될 스티커별 좌표 정보도 같이 받아야 된다.

: 얼굴 특징점과 연결되어 스티커가 한 화면으로 구성되어 화면으로 보기 위해서는 좌표간 1:1 매칭이 되어야 한다.

: OpenGL를 사용하여 화면에 자연스럽게 보여준다. 이때 하드웨어 가속을 사용하면 리소스의 부하를 줄 일 수 있다.

: 애니메이션 스티커와 카메라 영상이 하나로 합성이 되어서 구성된 프레임은 Raw 데이터이기 때문에 영상 전송하기 위해서는 Encoding 과정을 진행해야 한다. 비디오 코덱은 H.264 Main Profile Level 3.0으로 하며, Frame rate는 30, 해상도는 480x720, Bitrate는 1Mbps로 인코딩하였다. 오디오 코덱은 AAC를 사용하며, sample rate는 44100Hz, 채널은 2로 인코딩을 하였다.

Fig. 3. 
Live Streaming System Architecture

: 실시간으로 Encoding된 영상은 서비스를 위해 서버로 전송되어 진다. 그림 3은 라이브 스트리밍을 위한 시스템 구성을 보여준다. 서버의 Auto Scaling을 지원하기 위해서 Origin/Edge를 구성하여 서비스한다. 또한 다중채널네트워크 플랫폼에서는 실시간성이 중요한 요소이기 때문에 RTMP(Real Time Messaging Protocol)를 이용하연 Origin Sever로 전송한다.

: Edge Server에서는 2가지 프로토콜을 지원한다. HLS(Http Live Streaming) 및 RTMP를 지원한다. IOS와 Android 자체 플레이어에서는 HLS만 지원하므로 기본 전송 프로토콜로 사용한다. RTMP의 경우 HLS 보다 실시간성을 가질 수 있기 때문에 서비스의 질을 보다 높일 수 있다. 단 전용 플레이어를 설치해야 사용할 수 있다.

데이터 셋 구성은 Kaggle Facial Expression Recognition Challenge[8]로부터 학습된 데이터를 사용하였다. 이 데이터 셋은 48x48 픽셀의 흑백 얼굴이미지로 구성되어 7개의 감정 클래스로 구성된다.

감정 분석을 위해서 다계층(Multi-layered) CNN을 구성하였다. CNN은 Input layer, 여러 개의 Convolution layers, ReLU layers, Pooling layers, Dense layers, Output layer로 구성된다.

1) Input Layer

: 입력된 영상으로부터 OpenCV의 Harr Cascades 알고리즘을 통해서 얼굴 검색을 한다. 검색된 얼굴은 48x48크기의 흑백이미지로 크기조정을 한다. 따라서 네트워크 모델은 48x48x3(RGB)에서 48x48x1(Gray)로 차원을 조정한다.

2) Convolution/Pooling Layer

: 각각의 특징(Feature)들을 추출하기 위해서 커널(Kernel)의 크기를 3x3으로 한다. 원 이미지를 커널과 계속 겹쳐가면서 특징맵(Feature Map)을 구성한다. 설계한 신경망에서는 각각의 Convolution Layer가 256개의 특징맵을 만든다. Convolution 후 Rectified Linear Unit(ReLU) 함수를 사용하여 각각의 특징맵의 차원수를 줄이기 위해 Max Pooling을 사용하여 중요한 정보를 계속 유지하도록 한다. 이때 특징맵에서 2x2 윈도우 안에 있는 가장 큰 픽셀값을 사용하여 재구성 하였다.

3) Dense Layers

: Convolution/Pooling Layer 통해서 나온 결과물은 고차원의 특징정보를 가지고 있다. Dense Layer에서는 입력영상을 다양한 클래스로 구분한다. 제안한 시스템에서 사용한 네트워크모델에서는 2개의 Fully Connected Layer를 사용하였다. 또한 학습한 데이터의 Overfiting을 줄이기 위해서 20%의 Dropout을 하였다.

4) Output Layers

: 활성화함수(Activation function)로 SoftMax를 사용하였다. 따라서, 결과물에서는 7개의 감정 요소의 확률분포를 나타낸다. 결과적으로 9개의 Convolution Layer와 3개의 Max Pooling Layer 과 2개의 Dense Layer를 통해서 얼굴이 가지는 감정을 확률적으로 분석하게 된다.

그림 6에서는 얼굴 감정 스티커를 송출하기위한 단말단의 처리 순서도를 나타낸다.

Fig. 6. 
Face Emotion Sticker Transfer Flow Chart

카메라로부터 얻은 입력 데이터의 감정을 분석하고 얼굴의 특징점과 스티커 좌표점을 매칭하여 화면에 표출한다. 화면 데이터를 H.264 코덱으로 Encoding 하기 위하여 YUV로 포맷 변환을 하고, 마이크 입력의 데이터를 AAC로 인코딩하여 Muxer를 통해 비디오/오디오 압축 데이터를 RTMP로 전송하게 된다.

기존 서비스보다 좀 더 진화된 서비스를 제공하기 위하여 3-2의 딥러닝을 통한 감정 분석 부분을 추가하여 흥미요소들을 더욱 증가 시킬 수 있다.

그림 7에서는 다중채널네트워크 라이브 플랫폼 구성도를 나타낸다. 서버 단에서는 3가지(Streaming Server, Common Management, Live Management) 구성요소를 가진다.

Fig. 7. 
MCN Live Platform Configuration[1]

1) Streaming Server

- RTMP Server

: Encoder User로부터 실시간으로 스트리밍 데이터를 Push 입력 받는다. 이때 지연시간을 최소화하기 위해서 RTMP로 입력 받는다. 입력 받은 Stream은 RTMP 형태로 Broadcasting한다. 사용자는 3초 안에 시청 가능해야 한다.

- HLS(Http Live Streaming) Server

: RTMP Server로부터 실시간으로 스트리밍 데이터를 Push입력 받는다. 입력 받은 Stream은 HLS 형태로 Broadcasting한다. HLS의 경우 Segmentation 속성에 따라 사용자가 시청할 때 지연정도가 결정 나기 때문에 Segmentation 속성을 조절할 수 있어야 한다.

2) Common Management

- Front Server

: 현재 입출력 URL 정보에 대한 관리자를 구성한다. 방송을 송출할 때마다 새로운 채널이 생기므로 URL정보는 동적으로 생성되어야 한다. 따라서 Encoder 단에서 Streaming 하겠다는 요청이 오면 Edge URL(RTMP, HLS), Thumbnail URL 정보를 전달해야 한다.

- Monitoring/Management Server

:모든 서버로부터 Physical&Connection 정보를 주기적으로 가져온다. 각 서버의 상태를 보고 Active 서버를 결정하여 Front Server에 전달한다. 이를 위해 모든 서버에 대한 정보 관리자를 구성하고 운영한다. 그리고 Edge Server들 중에 Fail Over 여부를 판단하여 서버를 교체하고, Streaming의 Auto Scaling을 결정한다.

- Admin Application

: 등록된 서버 Pool을 관리한다. Monitoring/Management Server로부터 모든 서버의 Physical&Connection 정보를 가시화 한다. 이때 Physical&Connection 정보를 통해 기준 초과/미달 시 서버의 Auto Scaling을 한다.

- Thumbnail Server

: Origin Server로부터 RTMP 입력을 받는다. Thumbnail 추출시 Live Stream에 대한 추출 주기 및 해상도를 지정할 수 있어야 한다. 또한 HTTP 서버를 구축하여 URL을 통해서 Thumbnail을 가져 올 수 있다.

- Host Server

: 서비스 사용자가 로그인 했을 때 인증 관리를 한다. 서비스의 용도에 따라서 사용자별 기간 설정이나 사용회수 설정도 가능하다.

3) Live Management

- Origin Server

: Encoder User로부터 RTMP 입력을 받는다. 또한 Edge/Filtering Proxy Server에 영상을 전달한다.

- Edge Server

: Origin Server로부터 RTMP 입력을 받는다. 이 입력 Stream에 대해서 HLS를 지원하기 위해서 HTTP 서버의 Publish 폴더 내에 HLS 서비스 파일(ts, m3u8)로 변환한다. 그리고 Encoder User가 Streaming을 종료한 경우에는 Publish 폴더를 삭제한다.

- Filtering Proxy Server

: Origin Server로부터 RTMP 입력을 받는다. 이 입력은 Encoder User로부터 들어온 Stream인지 타당성 검사를 해야 한다. 비정상 User에 의해서 의도적으로 Streaming Server가 점유 당할 수 있기 때문에 이에 대한 타당성 검사는 필수이다. 검사절차는 아래와 같다.

A. Origin 입력 관리자와 실제로 Origin으로 Push된 입력을 주기적으로 체크한다.

B. 관리자를 통해서 비정상 입력 id 또는 URL에 대해서 Kickoff시킨다.