뚱2's Story

Android 동영상 플레이어를 왜 만들어야 하는가?

Android는 오픈 플랫폼이어서 다양한 제조사가 다양한 기기를 만들고 있다. 이러한 다양성은 소비자에게는 기기 선택의 폭을 넓혀 줄 수 있지만, NHN 같은 서비스 제공자 입장에서는 다양한 종류의 단말기에서 동일한 사용자 경험을 제공하려면 추가적인 노력을 들여야 한다. Android 단말기에서 기본으로 제공하는 동영상 플레이어마다 기능이 다르고, 지원하는 동영상 포맷도 다르기 때문이다.

그래서 Android 동영상 서비스를 위해서는 독자적인 동영상 플레이어를 갖추고 있는 것이 좋다. 이를 위해 오픈 소스인 FFmpeg(http://www.ffmpeg.org/)을 이용해 Android 동영상 플레이어를 만들었다. 

동영상 플레이어에 대한 배경 지식

코덱, 컨테이너 그리고 플레이어

일반적인 사용자 입장에서 생각한다면 동영상(비디오)에는 오디오가 포함되어 있지만, 전문적인 개발자 입장에서는 동영상과 오디오는 서로 다른 영역이다. MP3나 Vorbis와 같은 오디오 압축 코덱이 소리를 담당하고, 동영상을 담당하는 동영상 압축 코덱은 MPEG, MPEG-4 AVC(H.264), WMV9 등이다. 동영상 압축 코덱은 동영상 정보를 압축하는 알고리즘 종류를 지칭하는 것으로 이해하는 것이 좋다. 동영상이란 정지 영상(동영상 프레임)을 초당 수 개에서 수십 개까지 빠르게 보여 주는 것을 말하는 것이고, 압축 동영상이란 최소한의 정지 영상 정보만으로 완전한 동영상 정보를 만들어 내어 이를 재생해낼 수 있도록 하는 것이다.

우리가 알고 있는 .mp4, .wmv, .asf, .3gpp 등의 파일은 Digital Container Format이라고 부르는 것이다. 엄밀히 말해 이들은 코덱이 아니다. Digital Container Format은 동영상/오디오 코덱을 이용하여 데이터를 저장하는 방식과 재생 동기화 정보 등의 부가 정보를 담고 있는 파일 형식을 말한다. 그리고 동영상 플레이어는 이 Digital Container Format을 읽어 동영상/오디오를 재생하는 프로그램이다.

원본 영상 데이터로부터 특정 동영상 코덱으로 변환하는 것을 인코딩이라 하고, 변환한 데이터를 파일에 담는 것을 먹싱(muxing)이라고 한다. 동영상을 재생하려면 역순으로 해야 한다. 이때 동영상 파일로부터 비트스트림(bit-stream) 데이터를 추출하는 과정을 디먹싱(demuxing)이라고 한다. 이렇게 디먹싱하면 어떤 코덱으로 인코딩되었는지 알 수 있게 된다. 그리하여 적합한 코덱으로 디코딩하면 원본 데이터 영상을 얻을 수 있다.

FFmpeg

FFmpeg은 크로스 플랫폼을 지원하는 오픈소스 멀티미디어 프레임워크이다. FFmpeg을 이용해 인코딩/디코딩, 트랜스코딩(transcode), 먹싱/디먹싱, 스트림(stream)은 물론 '재생'까지 멀티미디어와 관련한 거의 모든 기능을 다 갖추고 있다.

FFmpeg의 라이선스는 GPL과 LGPL이다. FFmpeg에는 다음과 같은 여러 세부 라이브러리가 있다. 

Android NDK

Android NDK(Native Development Kit)는 C/C++와 같은 네이티브 언어로 개발한 라이브러리를 Android 앱에서 사용할 수 있게 하는 개발 도구이다. Android NDK의 구성 사항은 다음과 같다.

FFmpeg 포팅

FFmpeg은 C로 작성되었기 때문에 Android에서 동작시키려면 NDK를 이용해야 한다. 동영상 플레이어를 개발할 때에는 FFmpeg의 모든 library가 다 필요한 것은 아니기 때문에 필요한 libavformat과 libavcodec, libswscale만 NDK에서 빌드했다. NDK를 이용한 FFmpeg의 빌드 과정은 다음과 같다.

Android 동영상 플레이어

Android용으로 빌드한 FFmpeg 라이브러리로 동영상 플레이어를 개발하는 방법에는 크게 두 가지가 있다.

첫 번째로 플레이어에 필요한 기능을 직접 개발하는 방법이다. 관련 지식을 쌓을 수 있고, 필요한 기능을 요구에 맞게 개발할 수 있는 장점이 있지만 데이터 큐(data queue), 스트림 싱크(stream sync) 등 많은 기능을 직접 모두 구현해야 하기 때문에 오랜 개발 기간이 필요하다는 단점이 있다.

두 번째는 FFmpeg에서 레퍼런스로 제공하는 FFPlay를 Android용으로 포팅하는 방법이다. FFPlay는 FFMpeg 프로젝트의 일부로, SDL(Simple DirectMedia Layer)을 이용한 동영상 플레이어이다. SDL은 여러 그래픽, 사운드, 입력 디바이스에 대한 레이어 인터페이스를 제공하는 크로스 플랫폼 중 하나이다. Android용 SDL이 없기 때문에 동영상(비디오)/오디오 렌더링을 위해 FFPlay에서 SDL을 사용하는 부분을 수정해서 개발해야 하는 문제가 있다. 하지만 FFPlay에는 필요한 기능들이 이미 상당수가 있기 때문에 FFPlay의 Android 포팅 버전을 개발하는 것이 전체적으로 개발 시간을 줄일 수 있는 방법이다. 또한 FFPlay가 FFmpeg의 레퍼런스 프로젝트이기 때문에 FFmpeg 사용법을 잘 습득할 수 있는 기회가 될 수 있다.

그래서 FFPlay를 Android 용으로 포팅하는 방식을 선택했다.

그림 2 FFPlay의 구조

Android에서 오디오 재생

Android에서 PCM 데이터를 재생하기 위해 AudioTrack 클래스를 이용했다.

AudioTrack 클래스는 PCM 데이터를 전달하면 JNI를 통해 AudioFlinger에 접근하여 오디오 디바이스로 소리를 출력해 준다. SDL에서는 오디오 재생(Audio rendering)에 콜백 인터페이스를 사용한다. 즉 오디오 디바이스에 출력할 데이터가 필요하면 콜백 함수가 호출되고, 필요한 만큼의 데이터를 디코딩하여 전달하는 방식이다. 하지만 AudioTrack은 콜백 인터페이스 기반이 아니기 때문에 지속적으로 데이터를 전달해 주어야 한다. 이를 위해 FFPlay에서 Audio Decoder 부분을 별도의 스레드로 동작시키고 지속적으로 PCM 데이터를 AudioTrack에 넘겨주도록 수정했다.

그림 3 Audio Rendering

Android에서 동영상(비디오) 렌더링

Android에서 픽셀 데이터를 화면에 출력하기 위해 OpenGL을 이용했다.

Android에서는 OpenGL을 이용하여 화면에 출력하려면 GLSurfaceView 클래스를 이용해야 한다. SDL에서는 화면을 그려야 할 때에 SDL에 픽셀 데이터를 넘겨 주도록 되어 있다. 그리고 Android에서 OpenGL을 이용할 때는 꼭 OpenGL 스레드에서 GLSurfaceView.Renderer.onDraw() 함수가 호출되어 화면을 출력하도록 해야 한다. 이를 위하여 기존의 Video Refresher가 스레드로 수행되면서 필요한 시점에 화면을 그렸던 방식에서, Video Refresher가 스레드로 수행되면서 필요한 시점에 GLSurfaceView 클래스에 요청(GLSurfaceView.requestRender() 함수 호출)을 보내어 GLSurfaceView.Renderer.onDraw() 함수를 호출하고 함수 내에서 픽셀 데이터를 가져와 화면에 그리는 방식으로 구조를 변경했다.

그림 4 Video Rendering

OpenGL ES를 이용하여 화면을 그리는 과정은 다음 그림과 같다. 동영상 프레임(Video frame)을 디코딩하여 나온 결과인 픽셀 데이터는 원본 동영상 프레임보다 더 넓다(이것은 처리 성능을 향상시키기 위한 방법이고, 이렇게 넓어진 너비를 line-size라고 한다). 이렇게 나온 픽셀 데이터의 크기를 기준으로 해당 크기보다 큰 텍스처(texture)를 준비한다. 그 다음 텍스처에 픽셀 데이터를 그대로 복사하고, 원래의 동영상 프레임 크기만큼의 텍스처만 화면(screen)에 입힌다.

그림 5 OpenGL ES를 이용한 동영상 프레임 렌더링

Android 동영상 플레이어 최종 모습

Android 동영상 플레이어의 개략적인 구조는 다음 그리과 같다.

그림 6 Android 동영상 플레이어의 구조

FFPlay와 기본적인 구조는 동일하지만 앞서 설명한 대로 오디오와 비디오의 렌더링은 SDL을 이용하는 방식에서 AudioTrack과 OpenGL을 이용하는 방식으로 바꾼 것이 가장 큰 차이다.

또 하나의 차이는 스레드 사용이다. 원래의 FFPlay는 SDL 스레드를 사용하는데, 이는 내부적으로 pthread를 사용하는 것이다. Android에서도 pthread를 이용할 수는 있지만 네이티브 코드에서 생성한 pthread의 존재를 JavaVM이 모르고 있기 때문에 여러 가지 예상치 못한 오류가 발생할 수 있고 JNI를 호출할(call) 수 없다.

참조

JNI와 pthread에 대한 자세한 내용은 "JNI Tips" 문서를 참조한다.

이러한 문제점을 피하고 NDK에서 스레드를 사용하기 위해서는 생성된 pthread를 AttachCurrentThread() 함수를 사용하여 JavaVM에게 알려주거나, Java 스레드를 생성한 후 해당 스레드에서 수행하려하는 함수를 JNI를 이용하여 실행하도록 하는 방법이 있다. Android 동영상 플레이어는 개발 과정의 디버깅 편의성 등을 고려하여 Java 스레드를 이용하여 개발했다.

성능 개선

FFmpeg을 이용해 디코딩하여 나온 픽셀 데이터는 YUV 픽셀 데이터이다. 하지만 OpenGL을 이용해 렌더링을 하려면 RGB 픽셀 데이터가 필요하다. FFmpeg에서는 다음 그림과 같이 libswscale을 이용해 YUV 픽셀 데이터를 RGB 픽셀 데이터로 변환하는 색공간 변환 작업을 할 수 있다.

그림 7 libswscale을 이용한 픽셀 데이터 변환

하지만 libswscale은 CPU를 이용하여 변환 작업을 진행하기 때문에, 비록 변환 계산은 단순해도 변환해야 할 데이터의 양이 많아 수행 성능이 좋지 않다. 이를 개선하기 위하여 Shader를 사용했다. Shader는 CPU가 아닌 GPU를 사용한다. Shader에는 vertex를 변환하는 vertex shader와 픽셀을 변환하는 fragment shader가 있다. 색 공간의 변환은 픽셀 단위로 이루어지기 때문에 fragment shader를 이용했다. 관련 코드는 다음과 같다.

Shader를 이용하여 색 공간을 변환하면 다음 그림과 같은 구조가 된다. GPU는 CPU와 달리 단순 반복 연산에서 더욱 좋은 성능을 내기 때문에 좀 더 빠른 변환이 가능하다. 또한 변환 과정 중 CPU는 다른 작업을 수행하도록 할 수 있는 장점이 있다. 그 결과 동영상 플레이어 재생 능력이 libswscale을 썼을 때보다 더 향상되었다.

그림 8 OpenGL ES의 shader를 이용한 pixel data 변환

마치며

더 나은 동영상 서비스를 준비하기 위하여 모바일 동영상 플레이어를 자체 개발할 필요가 있다고 판단했고, FFmpeg을 이용해 Android 동영상 플레이어를 개발했다. 동영상 플레이어를 개발하는 과정에서는 FFmpeg을 비롯한 많은 오픈 소스의 도움을 받았기 때문에 개발 과정을 공개하는 것이 좋다고 생각했다. 비록 이 글을 읽는 독자 분들이 하는 일이 동영상이나 모바일과는 크게 관계가 없어도, 사용한 기술과 의사 결정 과정 등이 다른 분야의 업무에도 도움이 될 수 있을 것이라 생각한다.

앞으로도 개발 경험이나 새로운 기술에 대한 내용을 공유할 수 있는 기회가 더 있으면 한다. 궁금한 내용은 언제든 문의해 주기를 바란다.