0

私はレガシーポッドキャスティングサービスを扱っていますが、代わりにHTML5を利用するのに良い時期のようです。私たちのユーザーは私たちのウェブサイトからこのサービスにアクセスします、そしてこれらの匿名のユーザーが私たちの移行でシームレスな経験を持っているといいでしょう。MediaElementの使用を計画しています。

わからないことが心配です...すべてのようです。このフォーラムを使用して背景情報を尋ねても大丈夫ですか？

「ストリーミングメディア」の定義についても明確ではありません。一部の人々は、非永続データのライブブロードキャストを指すためにこの用語を特に使用します。私たちのポッドキャスティングサービスは静的MP3ファイルを使用しています。したがって、その重要な価値は、ダウンロード時にデータを「再生」するようにクライアントを強制することです。この望ましいクライアントの動作を実現するバックグラウンドの魔法は何ですか？

Firefoxがこの魔法を自動的に実行するようになったことに気づきました。このかなり明白な機能を追加するのになぜ20年かかったのですか？

静的データのストリーミングと従来のデータ転送の最大の違いは、シーク機能です。10個の音楽トラックを1つのプレイリストファイル（昔ながらの考え方のアルバム）にまとめると、ユーザーは最後までジャンプできるはずです。介在するデータなしで追跡します。これには、元の応答を変更する、途中で発行された要求が必要です。これらのメカニズムは、HTMLとは何の関係もありません（HTML5のように）。Flash、RealAudioなどは、独自のコーデックに加えて、HTTPに対する独自の拡張機能を作成したに違いないと思います。HTML5は、HTTP標準に対応するアップグレードなしで、メディアストリーミングをどのように標準化できますか？

ピーター・ヒッグスが仮想ボソンの性質を定義しているような気がします。明らかに、この形式のストリーミングを実行するために必要な要求/応答を処理するためのプロトコルがあります。しかし、その存在を確認することすらできないので、サーバーの動作について質問するのは推測のようです。それでも、HTML5準拠のブラウザがどういうわけか私のレガシーサーバーと互換性があるというのは、信頼の飛躍のようです。

シンプルでなければなりません。私は何が欠けていますか？

ありがとう！ジム

4

3 に答える 3

-1

The most generic application I can think of is the Flash Player in YouTube. I used WireShark to examine the HTTP requests. Unexpectedly, everything is passed as URL search arguments instead of HTTP headers. Here is a list of the arguments:

  • source
  • ipbits
  • ip
  • cpn
  • range
  • mv
  • ratebypass
  • newshard
  • key
  • factor
  • mt
  • ms
  • keepalive
  • id
  • fexp
  • algorithm
  • burst
  • sparams
  • cp
  • sver
  • itag
  • signature
  • upn
  • expire

For all packets examined:

burst=40
algorithm=throttle-factor

Only the range argument seems to vary from request to request:

range=13-1781759
range=1781760-3563519
range=3563520-5345279
range=5345280-7127039
range=7127040-8908799

To summarize, these findings seem consistent with everything that's been discussed in this thread. So while I understand that this protocol is a proprietary extension written by the company that owns flash, HTML 5 is supposed to create a standardized replacement. I'm still hoping someone will answer the basic question: What is the underlying protocol that emulates these features of Flash? Possibly, HTML5 will not incorporate all these features. But that answer is important, too.

-Jim

于 2013-03-25T15:09:06.080 に答える
-1

私は自分自身の質問に答える方法がわかりません。たぶん、私にできる最善のことは、ばかげた憶測を失格にすることです.

私の元の投稿の要約：

  1. この望ましいクライアントの動作 (マルチメディア データのオンザフライ処理) を実現するバックグラウンドの魔法は何ですか?
  2. MP3 オーディオを「オンザフライ」で再生するようになった Firefox の変更点は何ですか?
  3. HTTP 経由のストリーミングを実現するために使用されるプロトコルは何ですか?

Multimedia Mike's answerをどのように理解しているかに基づいて、適切なコーデックにアクセスできる場合、ブラウザは「その場で」データを処理します。したがって、Q1 に対する答えは、コーデックを含む FlashPlayer や SilverStream などのプラグイン クライアントを提供することです。言い換えれば、すべてがプロプライエタリまたはオープンのいずれかのコーデックに要約されます。同様に、Q2 の回答は、HTML5 に準拠するために、Firefox には (詐欺師またはフックによって) MP3 コーデックが含まれるようになったというものです。

マルチメディア プレイリスト トラックを個別のファイルとしてロードするというマイクの提案は、基盤となるプロトコルに関する質問には明確に答えていません。私の特定のプロジェクトでは、控えめなシークは機能のダウングレードであり、おそらく受け入れられません。

私は現在、シーク要求を処理している間、クライアントがTCPレベルで接続を無作法に切断していると想定しています。そして、「HTTP Range」を指定する新しいリクエストを発行するだけです。逸話として、この説明は、私が経験した不格好で信頼できない反応と一致しています。他のプログラマーとのいくつかの会話は十分に活発でしたが、私はまだ信頼できる答えを持っていません.

于 2013-03-16T20:05:26.813 に答える