아마 아프리카를 포함한 대부분의 업체가 ffmpeg/libav를 자체 빌드해서 쓰고 있을 겁니다. 반면 유투브 앱은 순수 안드로이드 API만을 사용해 jni없이 개발되었습니다. 여기에서 호환성 차이가 크게 나게 됩니다. 특히 ffmpeg를 넣은 경우 이를 빌드시 준 옵션에 따라서 cpu 아키텍쳐에 따라 동작 안하는 상황이 올 수가 있습니다. (개인적으로는 오히려 아톰이 이런 걸 멀쩡하게 돌리는 경우가 있다는 게 놀랍습니다.) 예를 들어, 고화질 영상을 소프트웨어 가속으로 재생하려면 NEON관련 가속이 필요한데 이는 구형 CPU등은 지원치 않습니다. 아톰에서 안 도는 이유가 이것때문일 수도 있고요.

그리고 jni단에서 뻑이 안나도 OpenGL ES등을 쓸 경우 출력하는데서 문제가 날 수 있습니다. 예전에 비슷한 프로젝트에 참가해본 적이 있어서 기억하는데 원래 별 탈이 없을 터인 코드도 특정 환경에선 탈을 일으키거나 하는 경우가 있었습니다.

문제는 이래도 대부분의 신형 ARM CPU에서는 돌아야 한다는 점인데, 안 되는 환경이 많다면 그건 무슨 이유인진 모르겠군요.

저는 의문이 드는게 도대체 표준 방식이 무엇인가 고민하게 됩니다.

스트리밍 관련 개발 업무를 얼마간 해본 경험으로 얕은 생각이나 말씀드려 보면... 스트리밍에서의 표준이라고 볼 수 있는 것은 네트워크와 코덱 뿐입니다. 이들을 준수한 상태에서 어떻게 디코딩할 것인가는 사실 표준화 영역이 아니거든요. 또한 표준화 영역이라는 것들도 따지고 보면 '표준'이란 말을 붙이기 매우 모호한 상태가 현재입니다. 동영상 스트리밍에 있어서의 실 요구는 호환성, 성능(디코딩 측면 뿐 아니라 서버 측면에서의 퍼블리싱까지도), 플로우 컨트롤, 보안 등 매우 다양한데 각각의 프로코콜들은 부족한 부분이 있거나 표준 자체가 매우 모호하고 심지어 적절한 레퍼런스 찾기도 어려운 것이 현실이에요. 이러다 보니 표준이 가지는 힘이라는 것이 유독 특화 어플리케이션 영역에서는 힘을 쓰기 어렵게 되기 쉽상이구요. 

좀더 간단히 풀자면 단지 디코딩의 측면만으로 스트리밍 전체를 바라보기에는 무리가 있고 심지어 일반화된 코덱을 채용하고 있다고 하더라도 특정 동영상 포맷을 재생하듯이 간단히 광범위한 호환성을 답보하기 어려울 수 있는게 현실입니다. 따라서 앱의 단말 호환성이 개선되어야 한다는 시각으로 접근해야 하지 않나 싶습니다.