안드로이드 MediaPlayer.prepare는() (때문에 스테이지 프라이트의 그것을인가?) API> 2.3 아주 오랜 시간이 걸립니다

Question

이

나는 서로 다른 장치에서 다음 오디오 스트림을 재생하려고 (이 질문은 부분적으로 Why does it take so long for Android's MediaPlayer to prepare some live streams for playback? 관련이있다) android MediaPlayer : http://newsstream1.publicradio.org.

기기 사이에 준비() 메소드의 지속 시간이 크게 차이가 있음을 알게되었습니다. < = 2.2 (1 초 미만) 및 기기> 2.2 (최대 30 초 소요될 수 있음)

기본 오디오 프레임 워크와 관련이 있습니까? (OpenCore VS StageFright)

누군가 이미 경험 했습니까? 그리고 StageFright 미디어 플레이어로 mp3 스트림을 읽는 더 좋은 해결책을 알고 있습니까?

Answer 1

글쎄, 파기 한 후에 로딩 시간이 MediaPlayer의 버퍼 크기 (펌웨어에 어떻게 든 하드 코딩 됨)에 달려 있으며, 그것을 변경하기 위해 할 수있는 일은 없다는 결론에 도달했습니다.

Answer 2

오랜 시간이 걸리지는 않지만, MediaPlayer API는 응용 프로그램을 원활하게 실행하는 데 사용하는 asyncPrepare() 메서드를 사용하는 것이 좋습니다.

Answer 3

고정 된 시간이 아닌 고정 된 양의 데이터를 버퍼링하는 것처럼 보입니다. NPR의 여러 유형의 비트 레이트를 모르는 사람이 자신의 머리 위로 떨어져 스트림의 경우, 데이터가 보이는 같은 :

MPR 뉴스 스트림 27 초 (http://newsstream1.publicradio.org:80/), 64 kbps의 MPR 클래식 음악 스트림 : 15 초 (http://classicalstream1.publicradio.org:80/)이 128kbps MPR 현재의 스트림 7 초 (http://currentstream1.publicradio.org:80/)이 128kbps 스트리밍 PRI 52 초 (http://pri-ice.streamguys.biz/pri1) 32 kbps의 는 별도로 두 128 kbps의 사이의 차이로부터 매우 좋은가 스트림 비트 레이트와 버퍼링 지속 시간 간의 상관 관계.

어쨌든 안드로이드는 오픈 소스이므로 언제나 자신이하는 일을 볼 수 있습니다. 불행하게도 prepareAsync()과 prepare()은 네이티브 메소드이며, 버퍼 관련 이벤트가 네이티브 프로세스에서도 디스패치되는 것처럼 보입니다.

MediaPlayer에 OnBufferingUpdateListener을 첨부하여 버퍼 상태에 대한 세부적인 업데이트를 시도 했습니까? 이벤트가 전달되는 비율과 버퍼가 여러 스트림에서 각 이벤트에 채우는 백분율을 비교하는 것이 흥미로울 수 있습니다. 당신은 스트림 비트 레이트에 대해 그것을 상호 참조 할 수 있습니다. 그리고 32 kbps에서 4 초의 버퍼링은 128 kbps에서의 버퍼링 1 초와 동일한 퍼센테이지를 채우면 당신이 답을 찾았을 것입니다. here.