Android MediaPlayer プロキシで拡張する

標準のMediaPlayerコンポーネントにプロキシを実装すると、一見思われるよりも多くの利点があります。 この記事では、これがどのように機能するか、およびそのような技術の開発の見通しについて詳しく説明します。



長い間、 メディアライブラリアプリケーション用のAndroid向けメディアプレーヤーの最も成功した実装を探していました。 ExoPlayerをテストしました。 flvの平凡なサポートはありません。 開発者は、この形式のサポートを追加する時間はないと言いました。 次に、Vitamioを使い始めました。 そして、Vitamioは最初はだいたい適切ではないソリューションのように見えましたが、そのCrossle開発者と話をした後、私は彼からの助けを期待できないことがわかりました。 彼はバグを修正せず、一般にこのプロジェクトに携わっている人はほとんどいません。 バグが多かったので、標準プレーヤーに戻りました。 彼は私に最速で最もバグが多いように見えました。 もちろん、ExoPlayerやVitamioほど多くの機能はありません。 だから私は自分でそれらを追加する方法を学び始めました。

VideoViewを使用せず、カスタムプレーヤークラスを作成しました。 私はすべての機会にたくさんのイベントを追加しました。 プレーヤーはtextureViewに基づいています。 私は、プレーヤーをバックグラウンドで再生し、アクティビティを再作成するときに方法を探していました。 これはSurfaceView ... TextureViewでは機能しませんでした-正常に動作します。 くるくる回って、曲が...音楽が流れます。 プレーヤーをサービスに転送する理由が見つかりませんでした。 そして、なぜ、そしていつでもすべてがうまくいく。 理由が表示されるとすぐに、サービスが作成されます。



プレーヤーのキャッシュを作成し、FTPから再生するという2つの簡単なタスクがありました。 これは私のプレーヤーの1人のユーザーから尋ねられました。 彼は、FTPプロトコルをサポートするNASから音楽を聞きたいと考えています。

プログラマーとして、最初はプロキシを記述する必要があり、このプロキシを介してHTTP <> FTPリクエストの変換とデータ転送を整理する必要があることを理解しています。 これはImmortalPlayerプロジェクトで行いました。



将来、このプロキシはVItamioで使用できるようになり（キャッシュではあまりうまくいきません）、すべての形式を再生し、すべてのプロトコルをサポートする完全なコンバイナーを取得できます）、これはお勧めしません。 さまざまな形式が良いだけでなく、悪いので。 プレーヤーは、メインフォーマットと、すべてではありませんがいくつかのセカンダリを連続してサポートする必要があります。 これにより、ユーザーにとってよりクリーンで高品質の素材が得られます。 さらに、フォーマットのサポートは、プレーヤーレベルではなく、システムレベルの組み込みコーデックで行う必要があります。 Vitamio-オーディオとビデオが同期していないという多くのバグがあり、パフォーマンスが低下し、apkアプリケーションのサイズが10〜15メガバイト増加します。



主な機能：



アクセス権を定義します。

AndroidManifest.xml

<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WAKE_LOCK" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Wake_Lock-デバイスがスリープモードのときにプレーヤーが再生を停止しないようにします。

WRITE_EXTERNAL_STORAGE-キャッシュをデバイスの外部メディアに書き込みます。



MainActivity.java

 proxy = new HttpGetProxy(); proxy.setPaths("/ProxyBuffer", videoUrl, BUFFER_SIZE, NUM_FILES, getActivity().getApplicationContext(), false, ftplogin, ftppass, false); String proxyUrl = proxy.getLocalURL(); textureView.setVideoPath(proxyUrl);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスの新しいインスタンスをプロキシ変数に割り当てます。 そして、パラメーターを設定します。

proxy.setPaths（キャッシュを保存するフォルダー、インターネット上のファイルへのリンク、キャッシュサイズ、キャッシュ内のファイル数、コンテキスト、削除されたファイルの削除？、FTPログイン、FTPパスワード、FTP互換モード？）;

プレーヤーのプロキシパスを取得しますString proxyUrl = proxy.getLocalURL（）;

プレーヤーtextureView.setVideoPath（proxyUrl）を開始します。



プロキシはすでに行proxy = new HttpGetProxy（）;。から開始されます。 proxy.stopProxy（）を停止するコマンドがあります。 このコマンドはローカルソケットを閉じて、プレーヤーからの要求を待機し、スレッドプロキシは終了します。 おおまかに言って、まだ穏やかな方法は見つかっていません。



読み取り専用プロキシの作成方法を推測するのは難しくありません。 メモリカードには書き込まれません。 これはまだ実装されていませんが、BUFFER_SIZE、NUM_FILESの値をゼロに設定すると、すべてのファイルが削除されます。



プレーヤーのアルゴリズム：



プロキシの最初のバージョンを作成した後、プレーヤーの機能に出会いました。 これが何に関連しているかはわかりませんが、大きなflacファイルでは問題が発生します。 プレーヤーはこの種類のファイル用に完全に設計されているわけではないため、再生のアルゴリズムにバグが残っています。



通常の再生は、2つのクエリから始まります。 なぜ私にはまだ誰も謎ではありません。 つまり プレーヤーはファイル全体を要求し、最初の50kb〜100kbを読み取り、接続をリセットします。 ファイル全体をもう一度要求し、ファイルの先頭から再度読み取りを開始します。 さらに、要求は開始バイトとともに行われます。

私は2つのストリームプロキシを作成しようとし、2つのストリームを読み取ろうとしていると考えましたが、プレーヤーは頑固に2つのリクエストを同時に送信したくありませんでした。 一貫してのみ。 さらに、彼は最初の接続をほぼ即座に切断します。

これがすべての問題ではありません。 奇妙な機能の場合、ファイルの最初の部分の後、プレーヤーはファイルの終わりの読み取りを開始します。 端の前のポイントを選択し、端まで読み取ります。 たとえば、最後の200kb。 どうやら彼が最初に見つけられなかったか、何かをチェックしているデータを探しています。 その後、最初に読み続けます。

flacファイルの問題は、巻き戻し時のプロキシ速度が遅く、アルゴリズムが貧弱なことです。 flacを巻き戻すと、プレーヤーはストリームの適切な開始を検索します。 つまり 彼はどのバイトからもプレイを開始できません。 したがって、1〜6個のクエリを作成します。 現時点では、いくつかのタイムアウトが有効になっているため、プレーヤーはすぐに動作します。そのため、タイムアウトを1500ミリ秒でソケットの速度を上げました...タイムアウトなしでは、ソケットはアイドル時間で長時間ハングし、1-6リクエストではなく、1-2だけが発生します。 これにより、プレーヤーがスタートを見つける可能性が低くなります。 プレーヤーが先頭を見つけられない場合、サポートされていない形式に関するエラーが発生します。 タイムアウトは、ソケットのハングの問題を完全に解決しますが、プレーヤーアルゴリズムの問​​題は解決しません。 flacファイルを巻き戻すときにプロキシがなくても、プレーヤーは定期的に「サポートされていない形式」というエラーを出します。



チェック済み-プレーヤーは、プロキシの有無にかかわらず、同じ数のリクエストを行います。 プロキシを使用すると、リクエストの実行が少し遅くなります。 約50〜200ミリ秒...さまざまな変換とソケットの開閉により、最近のバージョンでは最小化されています。



HTTP、FTPのアルゴリズム：



最も時間がかかるのは、ソケットまたはスレッドを閉じるための手順です。 これらの手順から、場合によってはパフォーマンスを向上させることを拒否できます。

FTP RETRコマンドを使用して、ファイルを受信します。 ファイル転送を正しく中断するには、ABORコマンドが必要です。 はい、それは正しいことです。 結局のところ、一部のFTPサーバーは新しいコマンドを受け入れることですぐに動作できます。 つまり ABORコマンドなし-すぐにREST、RETRを実行すると、RESTで指定されたバイトから既に新しいファイルが取得されます。 ABORコマンドの送信には約100ミリ秒かかります...これにより、プロキシの快適性と速度が低下します。 このために、「FTP互換モード」が作成されました。 このモードでは、ABORコマンドが送信されます。 動作モードの選択をどのように自動化しようとしても、機能しませんでした。 したがって、私はそれを手動で行いました。 コマンドがなければ、ABORも機能するはずです。 中断する代わりに、新しい承認が発生するだけで、セッションに問題がある可能性があります。 FTPログを監視する必要があります-ほとんど毎回認証が発生する場合は、モードを有効にすることをお勧めします。



FTPサーバーの設定：



多くのテストはありませんでした。 21ポートが許可用に、1000ポート（おそらくそれ以下）がデータ転送用に開いているパッシブモードで正確に動作するはずです。 ファイアウォールで1000個のポートを開き、ftpサーバーで指定する必要があります。 同時セッションの数は10です。セッションのタイムアウトは10分です。 接続タイムアウト1分。



HTTPプロキシのアルゴリズム：







数字はアクションのシーケンスを示します。



FTPサーバーの場合、シーケンスはわずかに異なります。 プロキシには、インターネットが利用できない場合やサーバーからの応答がない場合に、ローカルファイルからの読み取りに切り替えるためのアルゴリズムもあります。 一部の場所では、アルゴリズムは非常に複雑です。 短いデザインを作成するために、できる限り努力しました。 まだ何かを減らすことができると思います。

FTPプロトコルを実装するために、Apache Commons Netライブラリーを使用しました。 FTPS、FTP over HTTP（実験的）、NNTP、SMTP（S）、POP3（S）、IMAP（S）、Telnet、TFTP、Finger、Whois、rexec / rcmd / rlogin、Time（rdate） ）および昼間、エコー、破棄、NTP / SNTP。

リモートサーバーからのデータの受信と特定のバイトからの開始をサポートするものに基づいて、プレーヤーのプロキシを作成し、マルチメディアを再生できると思います。



ファイル保存アルゴリズム：



改善する必要がありますが、今でもうまく機能します。 一番下の行は単純です-ファイル全体を聞いた場合、元の拡張子と名前に名前が変更されます。 検証は、ファイルが読み取られる時点でバイト単位で正確です。 拡張子ではなくファイル名の名前を変更すると、デバイスのマルチメディアスキャナーはそれが何らかのマルチメディアであることを認識し、スキャンを開始します。 また、ファイルが突然壊れた場合、デバイスが再起動する前に100％のプロセッサ使用率が得られます。 おそらく異なるAndroidシステムでは何かが異なりますが、4.4.2の私にとってはそうです。

現在の問題は、プレーヤーが要求し、読み取るもののみがキャッシュされることです。 プレーヤーが何も読んでいないときに、何らかの種類の再開を整理して、プレーヤーを要求するためにチャンネルをロードして遅滞なく停止しないようにする必要があります。 プレーヤーがインターネットから何も読み取らない瞬間をキャッチすることはできませんが。



Github：

github.com/master255/ImmortalPlayer

作業例：

play.google.com/store/apps/details?id=com.immortalplayer