Android 2.3 GingerBread Multimedia Framework 분석 - 1

http://www.aesop.or.kr/?document_srl=417850&mid=Board_Documents_AndroidPlatform

-----------------------------------
8. Android Multimedia

Android의 멀티미디어는 어느 OS 혹은 platform에서와 마찬가지로 가장 어려운 부분에 속한다. 일반 리눅스의 경우에서는 mplayer, ffmpeg, VLC player, xine 등과 같은 자기 자신만의 구조를 갖는 멀티미디어 엔진의 경우와 GStreamer와 같은 멀티미디어 프레임워크 구조를 갖는 엔진으로 나뉠 수 있다. 

윈도우즈 계열에서도 이와 비슷하게 Direct show filter 등을 이용한 멀티미디어 엔진과 독자적인 멀티미디어 엔진을 갖는 플레이어들이 존재 한다. 

안드로이드 멀티미디어 엔진은 기존의 OS등에서 사용되는 멀티미디어 엔진과는 다른 구조를 보여준다. 

기본적인 구조는 멀티미디어 프레임워크 구조가 이미 구성되어 있고, 이 기본적인 구조에 독자적인 멀티미디어 엔진을 만들어서 붙일 수 있는 구조이다. 즉, 표준 인터페이스가 존재하고, 멀티미디어 엔진은 표준 인터페이스만 맞춘다면 어떤 것을 장착해도 상관이 없도록 되어 있다. 

이러한 멀티미디어 엔진에 대한 구글의 해답은 2.1 버전까지는 OpenCORE에 있었으며 2.2까지는 OpenCORE와 Stagefright를 선택해서 쓸 수 있는 구조였고, 2.3에서부터는 Stagefright 가 기본적인 안드로이드 멀티미디어 엔진으로 사용되고 있다. 

위에서 설명하였듯이 Android에서의 멀티미디어는 일반적인 PC에서의 멀티미디어 처리와는 약간의 거리가 있게 구성되어 있다. 

안드로이드의 초기 버전의 경우 2.1 버전까지 주로 통신용인 Qualcomm 사의 칩만을 타겟으로 제작한 부분이 많이 보인다. 이는 멀티미디어 엔진을 기존의 통신용 멀티미디어 업체인 PacketVideo사의 OpenCORE를 채용한 것만 보더라도 안드로이드 멀티미디어의 구조는 그 방향이 정해졌다고 볼 수 있다.

하지만, 다행스러운 일은 안드로이드 멀티미디어 프레임워크의 하부 구조인 멀티미디어 엔진은 고정된 엔진을 쓰도록 강요하지지 않고 독자적인 멀티미디어 엔진을 구성할 수 있도록 개방된 구조로 되어 있다. 

이러한 부분들을 보면 안드로이드의 초기 설계에 있어서 얼마나 향후의 발전에 신경을 썼는지, 소프트웨어 개발사들의 독자 솔루션 개발에 대해 개방적인 구조를 갖을 수 있도록 새로운 멀티미디어 엔진에 대한 가능성을 열어 두었는지 알 수 있는 부분이다.

안드로이드 멀티미디어 엔진은 기본적으로 릴리즈 될 때서부터 OpenCORE를 기반으로 하고 있다. 하지만 2.0 elcair 버전서부터는 OpenCORE의 대안으로 stagefright를 같이 안드로이드 소스에 탑재하기 시작했으며, 2.2 froyo 버전에서도 OpenCORE와 stagefright를 선택해서 사용할 수 있도록 제공을 하였으나, 현재(2011년 03월)의 시점에서의 안드로이드 버전인 Gingerbread(Android 2.3)에서는 기본적으로는 stagefright를 사용할 수 있도록 한 상태이다. 

OpenCORE의 경우 소스에 포함되어 있지 않지만, Froyo 버전의 엔진을 그대로 사용할 수는 있다(이는 개발사의 능력에 따라서이다).

안드로이드 멀티미디어의 기본적인 구현은 안드로이드를 지원하는 대부분의 SoC 회사가 Linux BSP와 OpenMAX IL형식의 Hardware Codec을 지원한다. 

특정 SoC회사의 경우에는 커스터마이징 된 OpenCORE까지도 제공하거나 별도의 멀티미디어 엔진을 제공한다(nVidia Tegra2의 경우). 칩 벤더에서 제공하는 대부분의 상용 멀티미디어 엔진은 많은 종류의 demuxer/composer를 지원할 뿐 아니라, Media Scanner, DRM Support까지도 지원할 수 있도록 구성을 해 놓았지만, 상용화에는 부족함이 있는 경우가 있기 때문에 실제로 상용화까지 가기 위해서는 전문적인 솔루션 회사의 제품을 이용하는 것도 하나의 길이 될 수 있다.

OpenCORE는 Android를 확장하려는 구글의 전략에 가장 치명적인 약점이었고 여러 SoC 제조사와 단말 제조사들이 이러한 부분을 인력과 시간을 투입해서 Android 2.2 버전까지 해결해 왔지만 2.3 Gingerbread버전서부터는 stagefright에 그 자리를 내 주었다. 

하지만, 이는 또한 여러 SoC 제조사와 여러 제품 제조사들, 그리고 OpenCORE solution 제공회사들에게 괴로운 숙제를 다시 던져준 것이 되었고, OpenCORE 보다는 간단한 구조로 되어 있기는 하지만, stagefright 그 자체도 그다지 쉬운 구조는 아니어서 아주 난감한 일이 아닐 수 없다(필자 개인적으로도 닭 쫓던 개 지붕 쳐다보는 격이라고 생각한다).

※ Galaxy-S2의 경우도 OpenCORE를 사용한 것으로 보여지며, 구글에서는 따로 멀티미디어를 Qualcomm 칩 전용으로 파는 듯 하다 (구글의 경우는 예상하고 있었지만, 참 치사하네요.....잉 ㅎㅎ)

안드로이드 멀티미디어 엔진의 경우 실제 적용에서는 두 방향의 적용 방식을 볼 수 있는데 하나는 통신을 위주로 하는 제품에의 적용이고(기본적으로 Qualcomm chip을 기반으로한 제품), 나머지 하나는 멀티미디어 Application Processor(Samsung System LSI의 S5PC110/V210)를 탑재한 제품으로 나눌 수 있다.

Qualcomm chip을 기반으로 한 제품은 Qualcomm 칩의 원래의 한계로 인하여 제한적인 멀티미디어 기능만을 사용하는 경우가 많다(이는 필자의 경험상 DualCore의 경우도 비슷하다고 보여진다). 

하지만, 멀티미디어 Application Processor(ex> S5PC110/V210)를 기반으로 하는 제품의 경우 통신은 기본적으로 지원하고, 통신 이외에도 PC급의 멀티미디어를 지원할 수 있는 성능을 보여주고 있다. 

멀티미디어에 그 비중을 많이 둔 제품의 개발에서는 상대적으로 멀티미디어의 PC레벨의 호환성을 요구하게 되므로 많은 노력과 비용이 들게 된다. 하지만, 이러한 제품이 이미 출시되었고 점점 이러한 기능이 기본적으로 요구되고 있기 때문에 앞으로 나오게 되는 안드로이드 제품은 강력한 멀티미디어 기능을 탑재해야할 시장에서 이미 출시되어 있는 제품과 경쟁할 수 있다. 

이러한 기능을 갖추지 못한 제품은 상대적으로 통신위주의 저가형 시장을 공략할 수 밖에 없는 상황이 될 것이다.

8.1 안드로이드 멀티미디어에서 구조와 지원사양

안드로이드에서의 멀티미디어 프레임워크 구조는 크게 네 개의 기본 구성요소로 나눌 수 있다.

- client

- Server

- Multimedia Engine

- Codec interface

여기서 Codec Interface는 다시 2가지 계층으로 나눌 수 있다.

- OpenMAX IL

- Hardware 혹은 Software codec 

 

안드로이드 구조 그림에서 Libraries(Native Framework이라고 한다) 쪽에 있는 Media Framework는 위에서 설명한 네 개의 부분에서 server, media engine, codec interface 세 부분을 하나로 통틀어 표현하는 것이다.

  

안드로이드 멀티미디어 프레임워크 구조 부분을 조금 자세하게 그린다면 다음과 같은 그림이 될 수 있다. 

여기서 Packet video engine이라고 되어 있는 부분은 stagefright 혹은 독자적인 멀티미디어 엔진으로 교체될 수 있는 부분이다. 멀티미디어 프레임워크 부분을 구성하는 가장 중요한 멀티미디어 엔진 부분에 대한 부분은 뒤쪽에서 다시 자세하게 설명한다. 여기서는 멀티미디어 엔진의 기본적인 구성요소만을 나타내도록 그림을 구성하였다.

 

안드로이드는 멀티미디어 프레임워크의 구조와 멀티미디어 엔진의 기본적인 뼈대만을 제공한다. 멀티미디어 엔진의 많은 부분들은 칩 벤더, 제품 제조사 혹은 멀티미디어 솔루션 제작사 등이 직접 작성하도록 구성되어 있다. 

안드로이드에서 기본적으로 지원하는 파일의 형식과 포맷은 다음과 같다. 

 

위의 리스트를 보면 대부분 통신용에 가깝게 포맷과 형식이 지원되고 있는 것을 볼 수 있다. 여기서 특이한 점은 Ogg Vorbis의 지원이다. 안드로이드 내부에서 사용되는 대부분의 음원은 mp3의 형태가 아니라 ogg file의 형태를 갖고 있다.

위의 지원형태에도 볼 수 있듯이 대부분의 동영상 엔진의 지원은 software codec을 위주로 지원하도록 되어 있다. 

Gingerbread 소스의 경우는 레퍼런스 폰인 Nexus-S에 사용된 Samsung S.LSI의 S5PC110(POP type) 혹은 이와 동일한 칩인 S5PV210(Single type)의 멀티미디어 하드웨어 코덱인 MFC(Multi-Fuction Codec)을 OpenMAX IL을 통해서 지원할 수 있도록 하고 있다. 

하지만, Audio/Video codec부분은 여전히 제한적으로 지원하고 있으며 이와 마찬가지로, 동영상을 갖고 있는 container(demuxer 혹은 parser)와 composer(muxer)등도 제한적으로 지원하고 있다. 이와 같은 점은 PC등에서 사용하는 멀티미디어 포맷의 많은 부분을 지원하지 않는 것으로 볼 수 있다. 

상용화에는 많은 걸림돌이 존재하며 소프트웨어 솔루션 회사 입장에서는 이와 같은 점을 이용해서 틈새시장을 창출할 수 있는 기회가 될 수도 있다.

현존하는 PC용의 파일 포맷들과 코덱들을 지원하고자 한다면 Hardware 혹은 많이 최적화 된 Software codec을 이용한 video codec을 지원하여야 하며, 많은 parser들이 Android 멀티미디어 엔진으로 포팅되어 있어야 한다

.

밑의 표는 안드로이드에서 확장으로 지원해야할 리스트를 보여준다(멀티미디어 기기로 적용하기 위한).

8.2 Android Multimedia Application의 call flow

 

Android 멀티미디어 어플리케이션의 함수 호출 흐름은 그림에서 보는 것과 같다. 위에서 언급한 안드로이드 멀티미디어 구조의 네 부분에 맞춰서 설명하면 다음과 같다.

1> client 부분

- Multimedia Application

- Multimedia JAVA API: Application Framework

- Mutimedia JNI interface(libmedia_jni.so)

- Multimedia Native client library(libmedia.so)

2> server 부분

- Multimedia Native server library(libmediaplayerservice.so)

- Multimedia engine(MidiFile, libstagefrighplayer.so)

Multimedia Engine의 경우 미디어 파일 혹은 URL에 따라 Multimedia Engine은 MidiFile, 

Stagefright(libstagefrightplayer.so)등으로 구분될 수 있는데, 

이는 2.3 Gingerbread 버전의 경우이며, 2.2 froyo의 경우는 MidiFile, Vorbis player, OpenCORE (libopencoreplayer.so)로 나누어 볼 수 있다.

이러한 부분을 Class를 기반으로 그 구조를 그려보면 다음과 같다.

 

이 그림은 위에서 설명한 멀티미디어 응용 프로그램에서의 함수 흐름을 Class별로 구성을 바꾼 것이다. 여기서 눈 여겨 봐야 할 부분은 MediaPlayer, MediaPlayerService, StagefrightPlayer 표현된 안드로이드 멀티미디어의 기본 구성요소들이다. 그리고, 이와 더불어 유심히 봐야할 부분은 MediaPlayer class와 MediaPlayerService class 사이의 통신 구조인 Binder연결이다. 

MediaPlayer class는 libmedia.so 소속으로 안드로이드 멀티미디어 클라이언트 부분의 최종단 부분을 담당한다. 여기서부터 Binder통신을 이용하여 MediaPlayerService에 멀티미디어의 기능을 사용할 수 있도록 요청하는 역할을 담당한다.

MediaPlayerService class는 libmediaplayerservice.so를 구성하는 기본 클래스로 안드로이드 멀티미디어 서버 부분의 기본구조를 담당하는 클래스이다. 실제 이 클래스가 안드로이드 멀티미디어 프레임워크라고 불리는 부분이다. 

멀티미디어 서비스의 전체 뼈대를 구성하는 클래스로 이 하부구조가 각 멀티미디어 엔진들이다. 

위의 그림에서는 그 멀티미디어 엔진의 하나로 StagefrightPlayer class를 표시하고 있으며, 이와 같은 엔진으로는 MidiFile class, 2.2 froyo의 경우는 PVPlayer class와 VorbisPlayer class등이 존재한다. 물론 이 멀티미디어 엔진은 제조사에 따라 독자적인 엔진으로 구성할 수도 있다.

안드로이드 멀티미디어 프레임워크를 이해하기 위해서는 기본적으로 안드로이드 멀티미디어 응용 프로그램이 이벤트 구동방식으로 동작한다는 것을 이해해야 하며, 각 이벤트에 따른 상태의 움직임을 명확하게 알고 있어야 한다. 이 상태에 따라 멀티미디어 서비스와 그 밑의 멀티미디어 엔진의 함수 호출과 그 함수의 내용을 어떻게 구성하는지가 결정된다.

다음의 그림은 멀티미디어 응용 프로그램의 상태 다이어그램을 보여준다. 여기서는 Application Framework에서의 함수 호출과 이에 따른 서버로부터의 응답을 처리하는 Listener등에 대해서 다이어그램이 그려져 있다.

 

그림에 있는 각 상태에서 상태의 변화를 일으키기 위해 호출되는 함수들은 client(application)에서 server(media player service - server)쪽으로 binder를 이용해서 호출되는 함수들의 이름들이다. 

위의 상태 다이어그램을 다시 자세하게 Native Framework에서의 클라이언트서부터 서버로의 함수 호출과 이에 따른 서버로부터 클라이언트로 전달되는 메시지를 포함해서 그려보면 다음과 같다.

 

이 그림은 앞의 그림인 멀티미디어 응용 프로그램의 상태 다이어그램을 Libraries(Native Framework) 레벨에서 다시 그려본 것이다. 여기서는 응용 프로그램에서 처리하는 것과 유사하지만, 실제로 응용 프로그램(JAVA)에서 호출된 함수가 Native Framework에서의 client인 libmedia.so의 어떤 함수를 호출하는지 보여주며, 해당 함수의 호출이 어떤 함수로 server쪽으로 호출되는지에 대한 함수 흐름과 상태의 변화를 보여준다. 

여기서 / 로 시작되는 것들은 client서부터 server로의 함수 호출이며, xxxComplete형태로 그려진 것은 server로부터 client로 보내지는 상태 변화에 따른 처리 결과 및 에러 메시지들이다.