Windows 11 Insider Preview(Dev Channel) Build 22449.rs上で
Firefox 91.0.2(64bit)を使用し、

・YouTube Live（超低遅延モードに設定されたライブ配信）
・mildom（視聴設定で低遅延モードを有効化したライブ配信）
・ツイキャス（ライブ配信）

を視聴すると音声のみにロボのようなノイズとスローモーションが発生します。
また、

・Twitch（視聴設定で低遅延モードを有効化したライブ配信）

では発生せず、何れの配信サービスでもアーカイブされたライブ配信のログや、動画としてアップロードされたものでは発生しません。
上記から、恐らくサービス→視聴者へのライブ配信プロトコルにMPEG-DASHを使用していることが条件な気がしています（TwitchはHLS）。
Edgeなど他のブラウザでは再現しないことは確認済みです。

OSを最新ビルドにアップデートしたのに起因して発生した現象なので、Windows側の変更が影響しているのは確実なのですが、
それがバグなのか、あるいは今後それが仕様となるのでFirefox側で対応しなければならない問題なのか不明なので
こちらとWindowsのフィードバック Hubの両方に報告を上げています。

マシン環境は
・自作機
CPU: Ryzen 9 3950X
MB: Gigabyte X570 I AORUS PRO WIFI
Graphic: Gigabyte AORUS GeForce RTX 2080 Ti XTREME 11G
DRAM: G.SKILL F4-3600C16D-32GTZN(16GBx2 kit)
Strage: CFD販売 CSSD-M2B1TPG3VNF + CSSD-S6B01TMG4VT(2枚でRAID0)

上記マシンにUSB（チップセットから直接生えているレーン）
でヤマハのAG06（ミキサー）を接続し、
そこへ24 bit/48000 Hzで出力したものをミキサーのモニタ出力で聴いています。


※公式フォーラムに英語で報告する語学力がないのでどなたかフィードバックを上げていただくことは可能でしょうか？

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

yutaogasawara さん、EarlgreyTea と申します。


検証環境も用意できませんし、ライブ配信にも詳しくはないので、残念ながらあまりお力になれそうにありません。


Windows 11 Insider Preview 環境でのことですから、まずは Microsoft や関連コミュニティの方に報告されて、情報収集されることをおすすめいたします。


まず大前提として、Firefox はアーキテクチャやライセンス等の理由により、 MPEG-DASH をネイティブサポートしていません。

Bug 1263150 Adding native support for MPEG-DASH

OSプラットフォームやサードパーティソフトウェアに依存していますので、ネイティブサポートしているであろう Edge とは状況が異なることになります。


どちらのことを指しているのでしょう。
Support Forums | Mozilla Support のフォーラムへの投稿でしょうか。
それとも、 https://bugzilla.mozilla.org/ へのバグ報告でしょうか。

英語に関しては、中学程度の英語力で、機械翻訳（Google翻訳や DeepL翻訳など）を使えば問題ないはずです。
なるべく簡単明瞭な日本語で書いてそれを機械翻訳で英語に翻訳、それを日本語に逆翻訳しても意味が通るように調整するのがコツだと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

yutaogasawara さん、maji とゆ者です。


mildom と ツイキャス は普段使わないのでワカリマセンが
YouTube Live を

Windows 11 Insider Preview Build 22000.176
Firefox 91.0.2(64bit)

で使ってみましたが
私の手元では yutaogasawara さんがお困りの事象は出ません。
わざわざ「超低遅延モードに設定されたライブ配信」と記されてるので
どこか動作確認するのに指定ポイントあるのかな？


同じ Windows 11 Insider Preview でも
Build 22000.176 では問題が無く
Build 22449.rs で問題事象が出るのであれば、
私も OSアップデートにて引き起こされたものだと思います。
ただし
私の PCはハード的な事情にてコレ以上アップデート出来ないので
最新でのテストは出来ません。

後は EarlgreyTea さんに同意です、

では。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

EarlgreyTeaさん、majiさん始めましてyutaogasawaraと申します。

早速お返事いただき感謝いたします。


・FirefoxのMPEG-DASHサポート状況

FirefoxにはMPEG-DASHのネイティブサポートが無いとのことでご教授いただいたリンク先のフォーラム等を参照してみたのですが、
FirefoxはMSE（Media Source Extensions）APIのサポートを行っていて、
その先にストリーミングサービス側が用意しているHTML5プレイヤー（dash.js, hls.js, shaka-player etc.）がある状態なのですね。
そしてデコードはOSの組み込み、あるいは外部からインストールしたライブラリを使う。
H.264等のプロプライエタリなコーデックのデコードを行う場面がある以上、Firefoxに内装するのが不可能であるのは納得です。
（そのためにW3CもMSE APIを開発したのかな？）


・YouTube Live（超低遅延モード）について

YouTube Liveの超低遅延モードというのは配信者側から視聴者側へのディレイが1～3秒ほどと極小になる配信者側の送出設定でして、
視聴者側からもYouTubeプレイヤー内に統計情報を表示することで確認できます。


・プロトコルがMPEG-DASHであろうと推測した理由

上記したような超低遅延配信（mildomやツイキャスも同程度の遅延）であることから
配信に使われているプロトコルはWebRTCかMPEG-DASHの2択であろうと推測しました（HLSでは仕様上5秒程度までが限界）、
さらにYouTubeでは動画のコーデックがH.264, AV1 or VP9、音声がAAC or Opusの何れか（どの形式になるかはYouTubeが行うトランスコード次第）
になるので、使用できるコーデックの仕様上WebRTCが除外されます。


英語に関しては機械翻訳を併用すれば書くだけはできると思ったのですが、如何せんレスポンスを返すのが難しそうだなと思い躊躇してしまいました。
何れにしてもMSのフォーラムで議論すべき案件であるというのはごもっともですのでそちらのルートを当たってみます。
ありがとうございました。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36 Edg/93.0.961.38

自分が配信する場合は自分でオプションを選びますからわかりますが、
どの配信者がどの配信で超低遅延モードを使用しているという予備知識がないと難しい気がします。
遅延設定がタグに設定されて検索できるとよいですが・・・
ちなみに下の統計情報の場合は、「通常の遅延」モードということになるでしょうか。「超低遅延」モードの場合の表記は何になるか、予め知っておきたいです。


実際の遅延時間からの推測だったのですね。


頑張ってください。
進展ありましたら、こちらにも共有していただけるとうれしいです。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

yutaogasawara さん、maji です。


その後の進展どんな状況でしょうか？

-----

以下、ちょっとだけテスト続けてみました。


その後に別の機材を用意し Build 22458 の環境を新規に作ってる中で
本件テストしてみましたが、
やはり私の手元では
yutaogasawara さんがお困りの事象は出ません。

ここで掲示された範囲では

　Build 22000 問題無し( maji )
　Build 22449 問題事象発生( yutaogasawara さん)
　Build 22458 問題無し( maji )

てな感じ、です。
そもそもどんな手順でどう操作すれば事象再現するかあたりがちゃんと整理されてないのですが、
yutaogasawara さんの方の
その後の進展状況等をお教えいただけるとウレシイです。

-----

では。

# テストしたのは Windows 11 Insider Preview Build 22458 ですが、
# ここへの投稿は Linux Mint から行っています。

_________________
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

yutaogasawaraです。

なぜ直ったのか判然としないのですが、
先程Firefox 94.0(64bit)で問題が解消しているのを確認しました。
（OSは現在Build 22489.1000です）


こちらへ投稿を行ったあと、YouTube Liveでは何故かたまに上手く再生できることがあったのでなにか条件がないかと記録をとっていたのですが、
どうも超低遅延設定が有効な配信動画のページを開いたときに設定される平均バッファ量が2秒を切ると音声が壊れることを確認しました。
プロトコルに限らずライブ配信動画は1秒程度に細切れになったMPEG4やVP9、AV1などの動画をダウンロードし次々と再生し繋げているので、
このバッファ量は回線の帯域やブラウザのI/O処理能力をもとに安定しかつ最小になるよう自動で決定されるのですが、
これがFirefoxのI/O処理能力を超えて過小に設定されるため音声と映像の同期が取れなくなるようでした。

回線が時間帯によって輻輳している可能性もあるかと思ったのですが、
我が家は運良く日時に限らず常時上下とも200Mbps以上を維持できているのでそこは無視できそうです。
v4のインターネットへはインターネットマルチフィードのtransixを利用しDS-LiteプロトコルでIPIPトンネリング（自家ルータはヤマハのNVR500）を行っているので
レイテンシが通常より大きくなる可能性はあるのですが、YouTubeの場合はv6ネイティブなのでそこもクリアできていそうです。

また、本来は音声と映像の同期が取れなくなるような状況になればバッファを大きくとって処理が追いつくよう調整されるはずが、
なぜか配信動画のページを開いた瞬間に設定されたバッファ量にロックされてしまいそのまま壊れた音声が流れ続けていました。


Insider Buildの更新・Firefoxの更新があるたび、
また、問題の起きている自作機がRyzen 9 3950Xを搭載しているので例のWindows 11でレイテンシが増大する問題のパッチを当てたあとなど
環境に変更があるたびに問題の起きていたサービスを巡回し確認していたのですが、
今回Firefox 94.0で問題が解消していました。

また、バッファが追いつかなくなった場合にちゃんとバッファが大きく再設定されるようになっていました。


リリースノートにストレージやJavascript周りの高速化やメモリ使用量の削減・CPU使用率の低下などが多く挙げられていたのでそのあたりの改善が効いたのかな……？
なぜ直ったのだろう………

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0