私はこれをテストするための iPhone を持っていませんが、私の同僚によると、以下のスニペットにあるような埋め込みメディア ファイルは、iPhone が WLAN 接続または 3G 経由で接続されている場合にのみ機能し、接続時には機能しないとのことです。 GPRS経由。
<html><body>
<object data="http://joliclic.free.fr/html/object-tag/en/data/test.mp3" type="audio/mpeg">
<p>alternate text</p>
</object>
</body></html>
iPhone が (3G ではなく) GPRS を使用して接続しているときに iPhone ブラウザで再生されるメディア ファイルの URL の例はありますか?
iPhone YouTube アプリケーションは、EDGE 経由で接続した場合、Wi-Fi 経由で接続した場合よりも低品質のビデオを自動的にダウンロードします。これは、ネットワークがはるかに遅いためです。この事実から、Apple は EDGE 経由で MP3 をダウンロードしないという設計上の決定を下すだろうと私は信じている。ブラウザには、ビット レートが十分に低いかどうかを事前に知る方法はありません。そのため、再生に時間がかかりすぎるサウンド ファイルでユーザーを苛立たせる (ダウンロード中に電話がかかってくるのを防ぐ) よりも、ユーザーに悲しみを与えず、Wi-Fi ホットスポットを見つけるように促した方がよいでしょう。
私はその制限に気づいていませんでした。プロバイダーがバイト単位で課金している可能性のあるセルラー データ サービスでは、潜在的にデータ量の多い OBJECT または EMBED タグを無効にすることは理にかなっていますが、それが理由である場合、3G でも機能することは理にかなっていません。 GPRSだけではありません。
おそらく、問題は基本的なデータ スループットの 1 つですか? 自分自身 (または私自身) が iPhone を持っていないため、同僚の発言をテストするのが難しくなります。
GPRS は Wi-Fi や 3G よりもはるかに遅いことに注意してください。ウィキペディアによると、GPRS は 56 ～ 114 kbps の全二重スループットを提供しますが、そのすべてがダウンロード方向にあるわけではありません。最適なスループットを取得し、ダウンロード速度としてすべてを取得したとしても、典型的な 128 kbps mp3 を即座にストリーミングするには十分な速度ではないことが既にわかります。このフォーラムの議論
を見るとGoogle で取り上げられた例として、GPRS の顧客 (その地域の EDGE プロバイダーである Telestra を使用していない顧客) は約 40 kbps を取得しています。したがって、質問が示唆するように、3Gland やその中間ではなく、EDGEland で立ち往生している場合、30 秒の mp3 を再生するのに約 20 秒のバッファリングが必要になります。また、OBJECT や EMBED のような動作があいまいなタグを使用すると、ブラウザーがそれをどのように解釈するか、また、開始前にすべてをダウンロードするのではなく、ファイルをインテリジェントにストリーミングしようとするかどうかについての保証はありません。
したがって、あなたの同僚は、テストとして選択した埋め込みメディアが再生を開始するかどうかを確認するのに十分な時間待たなかった可能性があります (彼がそこで 17 KB のテスト用 mp3 を使用していないと仮定します)。iPhone には実際にこの制限がある可能性もありますが、人々は iPhone について他の好きでない点について十分に声を上げてきたので、Google は私のクイック検索で明らかになったよりも、この制限にもっと積極的に取り組んでくれると思います。別の可能性としては、現在 iPhone に同梱されている Safari のビルドの制限であり、将来のバージョンまたは別のブラウザで変更される可能性があります。
結局のところ、問題は、どのようなユーザー エクスペリエンスを本当に求めているかということです。GPRS の埋め込みオーディオは読み込みに時間がかかり、ユーザーはエクスペリエンスを楽しむことはできません。また、ページにアクセスすると再生が開始されるはずで、ナビゲートする前に読み込まれない場合、ユーザーはエクスペリエンスを楽しむことができません。あちらへ。その場合、それは努力する価値のある目標ではないかもしれません。