NHKラジオ公式サイト「らじる★らじる」で音声がゆっくり再生される
-
すでにバグレポートはしてあるのですが、情報共有の意味でこちらにも書いた方が良いかと思い、書き込みました。
NHKラジオの公式サイト「らじる★らじる」で、ストリーミングの音声を再生すると、なぜか通常より遅く(ゆっくりと)音声が再生されてしまいます。
NHKラジオ らじる★らじる
http://www.nhk.or.jp/radio/?area=tokyo実際音声が再生されるページ↓
http://www.nhk.or.jp/radio/player/?ch=r1
http://www.nhk.or.jp/radio/player/?ch=r2
http://www.nhk.or.jp/radio/player/?ch=fm私はこのサイトをほとんど使った事がないので、いつ頃からこの不具合が発生するようになったのかは分かりませんが、Twitterで不具合ツイートを見かけたので試してみたら、私の環境でも再現したのでバグレポしました(※ちなみにバグナンバーは「VB-29100」です)。
【私の環境】
Vivaldi Snapshot 1.10.862.6
OS:macOS Sierra 10.12.5なおOpera Stable 45(45.0.2552.888)でも試してみましたが、こちらでは問題なく、通常スピードで音声が再生されました。
-
この不具合に関してツイートされてた方に質問したところ、気づいたのは5月21日か28日のどちらかなのだそうです。またOSはWindows 7(64bit)を使ってるそうです。
当該ツイート↓
https://twitter.com/healthio/status/872105426195812352 -
@zyxwj そうでしたかぁ〜!
-
@kyu3a @zyxwj
ご報告・情報提供頂き、ありがとうございます。
以前から対応着手している不具合(VB-26260)と同現象の可能性がございます。
VB-26260の修正が上がりましたら、私も「らじる★らじる」で検証致します。 -
@zyxwj 詳細な報告をご提供いただき、誠にありがとうございます。ご指摘の通り、使用しているデコーダーに起因する課題もございます。
「らじる★らじる」の場合は、日本へのVPNがないと聴けず、オスロから作業をしている私には検証にやや不自由を感じるため、検証画面のスクショまで頂けるのは大変心強く感じます。改めて、修正中のVB-26260と同件である可能性を認識いたしました。現在メディア系は集中的に修正しておりますので、最新のスナップショットや正式版アップデート(早速本日もございます)にてお試しいただき、可能な限り鮮度の高い情報を頂けると幸いです。今しばらくご不便をおかけ致しますが、よろしくお願い致します。 -
@shiroitori 情報をご提供いただき、ありがとうございます。ご迷惑をおかけしており申し訳ございません。本件は現在修正中です。修正完了次第、こちらのトピックでもご連絡致します。よろしくお願い致します。
-
@zyxwj さん、こんにちは。調べてくれて、ありがとうございます!こんな仕組みになってるんですねぇ〜!私はプロバイダーは「コミュファ」を使っているのですが、IPアドレスで海外判定されてるかもなんて…思ってもみませんでした。(^^;
-
私の環境
- Gentoo Linux 64bit
- Vivaldi 1.11.917.17 snapshot 64bit
で
http://www.nhk.or.jp/radio/soundcheck/step2.html
にアクセスし再生したところ、とくに音声がスローになる現象は起きませんでした。私の環境では、別途h.264やaacが含まれたffmpegデコーダーを導入しているので、やはりデコーダーに起因する不具合な気もします。
手元にWindowsでffmpegデコーダーを導入していない環境もありますので、チェックします。
以下に
vivaldi://media-internals
から取得した情報を貼り付けておきます。render_id: 10 player_id: 1 pipeline_state: kPlaying origin_url: http://www.nhk.or.jp/ url: blob:http://www.nhk.or.jp/d929c6d8-37c4-4bfe-b088-bbc2aeae7b03 duration: 190.133374 found_audio_stream: true audio_codec_name: aac seek_target: 150 audio_dds: false audio_decoder: FFmpegAudioDecoder debug: Detected AAC midstream configuration change PTS:149984000 Sample Rate: 48000 vs 24000, ChannelLayout: 3 vs 3, Channels: 2 vs 2 audio_buffering_state: BUFFERING_HAVE_ENOUGH pipeline_buffering_state: BUFFERING_HAVE_ENOUGH event: PLAY
-
@zyxwj said in NHKラジオ公式サイト「らじる★らじる」で音声がゆっくり再生される:
@kyu3a ipだったら他のブラウザで同じ現象になるはずです。
…ですねぇ〜。(^^;>
@zyxwj said in NHKラジオ公式サイト「らじる★らじる」で音声がゆっくり再生される:
マイナーブラウザーなのでuser agentかデコーダーがnhkの方ではじかれているんじゃないでしょうかね?
一応今UserAgentSwitcher使って、UAを「Chrome」と「Firefox」、「Opera」に切り替えてみましたが、やはり同じ様にスロー再生されました。…なので、やはりデコーダーが関係してるのかも…しれません。(^^;
ちなみに「Safari」に切り替えたら、再生ボタン部分がグレーアウト(?)してて、ボタンが押せなくなってしまいました。
-
アップデートしても、NHKラジオ らじる★らじるの音声がスローモーションになる症状は改善しません。一方、Operaでは正常に利用できます。http://www.nhk.or.jp/radio/
-
Windows 10 で FFmpeg 等未導入の環境では,下記のような Audio Decoder となるようです。
AAC ファイルのようなのに WMFAudioDecoder が用いられており,どうもバッファリングが適切にできない様子なのか“info: ChunkDemuxer:”のエントリが表示されていません。また,“error: Failed to reconcile encoded audio times with decoded output.”というエラーも表示されており,適切にデコードできていない様子にも見受けられます。
ただの PC オタクの所見ですので,参考までに…。- render_id: 32
player_id: 1
origin_url: http://www.nhk.or.jp/
frame_url: http://www.nhk.or.jp/common/aplayer/ifr.html
frame_title: 音声プレーヤー
url: blob:http://www.nhk.or.jp/0efd35f9-8389-4b78-a56a-54b480317e3f
pipeline_state: kStopped
duration: 242.399999
found_audio_stream: true
audio_codec_name: aac
seek_target: 150
audio_dds: false
platform_pipeline_status_list: 9
audio_decoder: WMFAudioDecoder
error: Failed to reconcile encoded audio times with decoded output.
audio_buffering_state: BUFFERING_HAVE_ENOUGH
pipeline_buffering_state: BUFFERING_HAVE_ENOUGH
event: WEBMEDIAPLAYER_DESTROYED
一方,( PortableApp.com 版で確認になりますが)Google Chrome の場合は下記のよう。
- render_id: 9
player_id: 1
origin_url: http://www.nhk.or.jp/
frame_url: http://www.nhk.or.jp/common/aplayer/ifr.html
frame_title: 音声プレーヤー
url: blob:http://www.nhk.or.jp/fe505c6f-803a-42dc-844a-dc8f9b27c292
info: ChunkDemuxer: buffering by DTS
pipeline_state: kPlaying
duration: 283.359999
found_audio_stream: true
audio_codec_name: aac
seek_target: 150
audio_dds: false
audio_decoder: FFmpegAudioDecoder
debug: Detected AAC midstream configuration change PTS:149984000 Sample Rate: 48000 vs 24000, ChannelLayout: 3 vs 3, Channels: 2 vs 2
audio_buffering_state: BUFFERING_HAVE_ENOUGH
pipeline_buffering_state: BUFFERING_HAVE_ENOUGH
event: PLAY
- render_id: 32
-
ちなみに,こちら - Download latest stable Chromium binaries (64-bit and 32-bit) - でビルドが公開されている“No sync • No WebRTC • No Widevine”版にて確認すると,プレイヤー部分でエラー等はなく通常再生されているような表示になりますが,音声はデコードされないので何も再生されません。
そのため,Vivaldi で音声再生が適切にされない要因はデコーダーによるものと特定はできそうに思われます。- render_id: 13
player_id: 1
origin_url: http://www.nhk.or.jp/
frame_url: http://www.nhk.or.jp/common/aplayer/ifr.html
frame_title: 音声プレーヤー
url: blob:http://www.nhk.or.jp/2356bfb8-ff4c-44de-8061-3c8faa82cc8e
info: ChunkDemuxer: buffering by DTS
pipeline_state: kStopped
event: WEBMEDIAPLAYER_DESTROYED
一利用者の提案でどうかというのもありますが,VPN を通すことで問題が生じるということであれば,リモートデスクトップ環境で日本国内に設置された PC 環境から検証を行うという方法は考えられるかと思います。
こちらで試せるのが日本→日本の環境なので参考になるかは定かではありませんが,TeamViewer 経由で接続した PC 環境でも再現は容易です。
- render_id: 13
-
こちら のスレッドで,CNBC の動画音声が遅くなるというやり取りがされていますね。
Media Internals で確認すると,らじる★らじると同様に音声 CODEC が AAC のようです。
render_id: 33
player_id: 3
origin_url: https://www.cnbc.com/
frame_url: https://www.cnbc.com/2017/10/31/consumer-confidence-october.html
frame_title: consumer confidence october
url: blob:https://www.cnbc.com/959d62c3-1aab-4994-9baa-57f884f8c86a
info: Selected video track: []
pipeline_state: kPlaying
found_audio_stream: true
audio_codec_name: aac
found_video_stream: true
video_codec_name: h264
audio_dds: false
platform_pipeline_status_list: 9
audio_decoder: WMFAudioDecoder
seek_target: 0
video_dds: false
video_decoder: GpuVideoDecoder
error: Failed to reconcile encoded audio times with decoded output.
audio_buffering_state: BUFFERING_HAVE_ENOUGH
video_buffering_state: BUFFERING_HAVE_ENOUGH
height: 720
width: 1280
pipeline_buffering_state: BUFFERING_HAVE_ENOUGH
event: PLAY
debug: Skipping audio splice trimming at PTS=6037142us. Found only 45us of overlap, need at least 1000us. Multiple occurrences may result in loss of A/V sync.
duration: 52.94145 -
@kyu3a @zyxwj @shiroitori @knokmki612 @uccha @Ivarn
長らくお待たせいたしました。間もなく公開予定のスナップショット1.15.1147.23より、本件の修正が入っております。更新後も依然音声がゆっくり再生される場合は、OS情報とともにご一報ください。 -
@takaaki Mac版(OSは10.13.4)でも、最新のスナップショット(1.15.1147.21)で問題なく再生できました!対応ありがとうございます♪
-
@kyu3a @zyxwj
良かったです!本件クローズといたします。(ついに。。。!)【今回の問題ー修正概要】
AACが持つオプション機能のうち、データ転送のためサンプルレートを圧縮し再生時に拡大させるものがあります。(参考:https://www.weblio.jp/wkpja/content/HE-AAC_HE-AACの概要 )処理対象のサンプルレートが圧縮されたものなのか再拡大されたものなのかをコード側が混同している場合があり、その結果、誤った出力結果になることがありました。特定のサンプルレートとAACのオプションがあって初めて発生する現象のため、原因の追求が困難となり、修正に至るまで時間を要しました。(実はNHKの「らじる★らじる」が、原因追求とテストケース作成のための大きなヒントとなりました。)
-
おぉ!
当方でも改善を確認できました。蛇足ですが,しばらく忙しくて自動更新のみしか追えていなかったのですが,改めて確認してみたところでは 1.15.1147.21 で挙動の改善は確認できず,1.15.1147.23 で問題なくなっていた様子です。
たしか,ブログの snapshot 更新記事でサウンド関連の修正の文言を見て 1.15.1147.21 版に更新された当初にも確認していた気がします。 -
勘違いでした。
[Media] Slow audio VB-36469
上記修正項目が 1.15.1147.23 のアップブログ記事に Changelog として記載されていますね。
RSS でブログ記事を追っていて,忙しいなか散発的に参照していたのでバージョンを混同していたのかもしれません。
ブログ記事の URL にも“more-html5-audio-fixes”とありますね( *´艸`)