« 2015年7月 | トップページ | 2015年10月 »

2015年9月

2015年9月 7日 (月)

Android TVでTvRemoteViewer_VBを使う

以前の記事でTvRemoteViewer_VBをChromecastに対応させた顛末を書きましたが、実際に使ってみて、PCの作業中にも独立して動いて悪影響を与えず、安価に増やしていける「ながら観」環境に最適と、我ながら気に入ってあっという間に追加で2個も買い足してしまったのですが、一方実況コメント付きの再生にはやや性能が不足気味なのが気になっていました。

単にテレビや録画再生を流すだけなら十分なのですが実況表示の負荷には弱いため、コメント表示数を絞らざるを得ない弱点はあります。
これは致命的ではないのですが、そうはいっても同じ作りのままでもう少し性能が上がればもっと使い易く万人向けになるのになぁ、と想像してある日ぼんやりとネットをサーフィンしていたところ、ぴったり来そうな機器があ~るじゃありませんか!

Nexus Player

製品の概要を調べたところ、何となくAndroidの名前を冠する事からも判るようにOSからしてChoromeOSではなくAndroidっぽいので、互換性がどの程度あるのか、あるいはまったく無いのか判りませんでしたが、たとえAndroidでもTvRemoteViewer_VBは普通に動くし、値段も1万円前後で年内なら2千円のクーポンが付くので実質8千円・・う~んこうなったら毒を食らわば皿まで・・・ということでポチってしまいました。(実際に皿型ですが。。)

もちろんこの目的ならもう少しだけ奮発すればスティックPC という選択肢もあり、前記事にある通りWin10EdgeのHLSサポート機能を活かせばより高性能な環境が得られます。(特に実況表示は非常に滑らかになると思います。)
しかしWindowsマシンなりに手間のかかる所はありますので、PCとして使う目的がないならこの辺が良い選択になるのではないでしょうか?専用アプリはまだいろいろ不安定な所があるようですが、単なる「Chromecast上位機種」として使う分には安定して使えることが確認できましたし、以下で説明するように性能は価格差以上のものがあります。

またAndroidTVはソニーやシャープのテレビにもこれから搭載されるそうで、いわゆる「スマート」な「テレビ」の今後の本命になる可能性もあるので、そのようなスマートテレビにもっとスマートな仕事をしてもらう連携機能としても重要・・というのは自分の行為に対する後付けの言い訳です。

さて、Amazonから届いて早速開封し、まずはモニタにつないでセッティングしてクロームキャスにロゴからして似ている Nexussettings0 キャスト機能らしきものも設定して、とりあえず何か反応はあるかな?と思ってクロームキャストと同じ手順でTvRemoteViewerから起動してみたところ

Nexuscast2

あれ?動いちゃった。クロームキャストと見分けがつかない勢いで動いてしまいました。動画の自動スタートも普通に出来ています。
ちょっと拍子抜けしました。これから1週間ぐらい悪戦苦闘するつもりだったのに。。

しかし動きを詳しく調べてみると動作は全く同じではなく、何故かボリューム調整やミュートの機能は効かず、またライブストリームでのシーク動作も受け付けないなど、(ソフト制作した立場から見れば)いかにもシステムからは普通のAndoroid端末と見なされている面があります。
なぜそういう違いが出るのか調べてみた結果、Android TVとChromecastの面白い関係が判り、また結果として、完全にChromecastと同じ動作をするバージョンが完成しました。
 (→TvRemoteFiles ver1.37としてリリースしました。ダウンロードや導入方法はこちら

最初にも書きましたがAndroidTVは、今回テストしたNexus Playerのような外付け機器だけではなく、今後市販のテレビにも広く搭載される可能性があります。というかそういう方向性がGoogleとしても本命で、AppleTVやFireTVとの対抗の意味でもいち早くメーカーと組む数の勝負を仕掛けている感じですね。
もちろんそれらのテレビで正直にTvRemoteViewer_VBが動かせるかどうか保証はありませんが、TvRemoteViewer_VBは、AndroidTVの最大の存在意義と見なされる動画ストリーミング再生機能をそのまま使って動きますので、予想ではどのAndroidTVでも動き、画質の高いテレビであればその性能をフルに活かせると思います。
(家電メーカーがこぞってAndroidTVやFirefoxOSを採用し始めたのは、皆「スマートTV」の重要性に突然目覚めたからではなく、YouTubeのようなアプリを今後Google等はガラパゴスな環境用には提供してくれないのが明確になったからと思われ、まんまと誘導されたとも言えます。
したがってわざわざAndroidTVを載せたのにストリーミングアプリの機能が省かれるという事は有り得ないと思われ、また例えばAndroidTVには限定した映像出力しかさせないというのも、YoutubeやNetflixの4K動画が映る事を売り物にしたいという電機メーカーの思惑からすれば馬鹿げてますので、制限なしに各社自慢の高画質エンジンもしっかり使えると思います。)

せっかく買った最新型テレビなのに色々な機能が使いにくくて気に入らない場合、TvRemoteViewer_VBをその上で動かすことで活用シーンが広がるかもしれません。(まあある意味乗っ取る形になるのですが。。)

という感じでAndroidTVで動かすのはいろいろ面白い広がりがあるかもしれませんので、今回独立した記事にしました。

1.AndroidTV (Nexus Player) の準備

Nexus Playerの筺体は図のようになります。

Nexuscastabout

Chromecastと比べれば随分大きいのですが、Chromecast自体が非常に小さいので大きく見える面もあり、Nexus Player自体の大きさは大きめのハンバーグ程度です。
とはいえ流石にテレビにぶら下げたままという訳にもいかず、ちょっとした設置スペースが必要になります。給電はUSBではなく電源コンセントが必要です。
またHDMIケーブルは付属していませんので別途必要になりますが、HDMIケーブルは意外と太くて嵩張りますので、設置方法を考えて必要十分な長さのものを入手してください。

ちなみにカバーは細めのマイナスドライバー等で慎重にラッチを外せば開き、中は以下のようになってます。(但し通常は開く意味はありませんし真似すれば保証対象外になりますので以下略;ただこうやって中の構造を知っておいたことは個人的に後日役立ちました。)

Nexusplayerinside1s

Nexusplayerinside2s

図の真ん中にある楔形のものはアンテナか何かと思いましたが、単なる錘のようです。
図の左側の金属板は明らかに冷却板で、右側の金属版もEMC対策と冷却板を兼ねていると思います。基板の表側(上の写真)の上にあるグレーの部分にアンテナらしきパターンがあり金属板に覆われない位置にありますので、
Nexusplayerinside3s

ここがWiFiアンテナになっているのでしょう。
更に基板上の金属板を外せばモジュールも見えて来ると思いますが、かなりしっかり貼り付けてあり一緒に何が外れるか予想がつかなかったので、とりあえず腑分けはここまでにしておきます。
いずれにしろ本来の基板やアンテナの大きさからすれば筺体は半分ぐらいで良い筈で丸い必要もありませんね。最初の製品化ということで印象に残るデザインという意味もあるんでしょう。次の世代からは四角くなって大きさ重さも半分になりました、ということになるんじゃないでしょうか。

閑話休題、HDMIでテレビ/モニターに繋げば初期設定が始まりますが、あちこちに解説記事がありますので、例えばこの辺の記事を参考にすれば良いです。実質必要なのはWiFiの設定とGoogleアカウントの設定のみで、文字入力がゲーム機のようなカーソル入力という点を除けば簡単です。(Googleアカウントはここで入力するよりログイン済みのPCやスマホからペアリングする方が簡単です。)
Chromecastと違って、5GHz帯のWiFiもしっかりサポートしています。電波状態の良い設置場所ならそちらの方が速いですし、WiFi帯域の使い分けの点でも有効活用すると良いと思います。

で、これで利用するための肝心のキャスト機能の設定ですが、これは実は端末名だけ設定すれば、あとはデフォルトで動くことが判りました。
端末名の設定は以下のようにおこないます。

Nexussetting1 基本メニューの「設定」から

Nexussetting2 「端末情報」を選び

Nexussetting3 次に「端末名」を選びます。

あとはゲーム機と同じような文字入力画面になりますので、ユニークな端末名を設定してください。(ここではNexusTV1 と設定しています。)

これだけでAndroidTV 側の設定は終わりです。簡単ですね。
なぜか端末名がデフォルトのままでは次のキャストの対象にならないようですので、ここだけは必ず設定してください。

2.TvRemoteViewer_VB on Android TVの動作と特長

次にこれをTvRemoteViewer_VB で使う手順ですが・・実はこれ以降はChromecastと完全に同じになります。

Chromeブラウザ、あるいはAndroidの専用アプリからキャスト先デバイス一覧を呼び出すと、以下のように

Nexuscast1

設定した端末名がリストに現れます。これを選択すれば、あとはリモコン機能再生場所指定機能で操作できるようになります。
ということで操作方法はリンク先をご参照いただければ良いです。

ただしアプリ本体の操作上の違いは全くないのですが、付属しているリモコン

Nexusremo
の「戻るボタン」にはお気をつけください。

通常のリモコン操作では多用するボタンですが、一旦Castが始まるとこれを押しただけでCastアプリが終了してしまいますので、リモコンはどこかに隠した方が良いかも。(TvRemoteViewer_VB動作中は付属リモコンの操作は全く不要です。それどころかNexus Playerは起動と同時にTvRemoteViewer_VBの操作を受け付ける状態になりますので、設定時や他のアプリで使う時以外は付属リモコンは不要になります。)

以上のように機能についてはChromecastと完全に同じですが、性能はだいぶ上のようで、私がjavascript処理能力の簡易指標にしている「ファイル再生リスト読込み限界件数」で比較すると

Nexuscapacity Nexus Playerの場合

Cccapacity Chromecastの場合

4倍近い性能差があり、手許の機器と比較してもiPad2より少し上の能力で、HLS動画再生支援も強力です。絵のような弾幕状態では

Nexuscast3

Chromecastの数倍多くのコメ表示にも耐えられ、コメの動きも滑らかです。
(但しPCと比べればコメントは微妙にカクつきますが、Chromecastだと性能上の制約からコメントのリフレッシュレートを意図的に下げざるを得なかったのに比べると、Nexus Playerにはそういう制約も殆どなく、十分に自然な動きになります。)
ただそれでも限界はありますので、もし動画再生が追い付かなくなったらコメント数上限を絞るか、解像度を下げてみてください。

また、長時間使っていたり待機させていると、コメントのカクつきが大きくなったり画面が止まりがちになったりなど、動作自体が重くなることがあります。そういう時はとりあえず、リモコンの基本タブにある「ページを再ロード」をやってみてください。

Ccremo3_reset

これを押すと、レシーバーアプリを再起動しますので、ある程度動きは回復します。

ただし根本的にはメモリにゴミが溜まっていくのが動作が重くなる理由なので、そういう時にはトップページ「Cast」タブのデバイス操作かAndroid用専用アプリから「キャストを停止」あるいは「デバイスアプリ強制終了」を選んで一旦NexusPlayer/Chromecastを切り離した後、再度デバイスを接続してストリームに再接続してください。
内部的にブラウザが再起動されてバッファのゴミも掃除され、元のきびきびした動きに戻ります。

後日、この「長時間動かしていると動作が重くなる」という問題がいろいろ動作条件を変えても起きるため、「CPUの過熱によるスローダウン」が起きているのではないかと疑ってみました。(同じBay Trail系Atomを使ったスティックPCでもスローダウンの問題が報告されていたのが理由です。)
そこで、図のようにフタを開けた状態でCPUの風通しを良くしてみたところ

Nexusplayernaked

かなり問題が起きる頻度が減りました。どうやらNexus Playerで動作が重くなる原因の1つに、「CPUの過熱」がというのが結構な頻度であるようです。特に上記のような「内部ブラウザの再起動」で状況が改善しない時は、まずはこの現象が疑われます。

ただしこの対策は、「フタを開けるだけでなく基板も一旦外す。」「CPUが表側に来るように上蓋にネジ穴を穿けて基板をそちらに固定し直す。」「CPU直上あたりにヒートシンクを接着する。」というようなちょっと大胆な工作が必要ですので、「オクで売ったりせずこれで遊びつくすぜ!」ぐらいの蛮勇のある工作好きでないとここまでやるのは躊躇すると思います。それでも、スローダウンの現象が頻繁に出る時には触ってみて熱くなる方の面に熱が籠らないように置き直す、とか、風通しの良いところに置く、ぐらいの対策でも効果はあるのではないかと思います。

Nexus Playerは「Chromecastの狙いどころはいいんだけどちょっと性能や安定性が物足りない」 という方にお勧めのデバイスになります。
Chromecastには後継機種の噂もありますが、作りからしても熱対策上、これと同じレベルまで一気に性能向上することもないと思います。ただ性能を上げればより使い易くなるのはこのNexus Playerが良い見本になるので、期待したいですね。

以上がNexus Playerの性能概要です。これがAndroidTV一般の話となると、メーカー製テレビに搭載されたエンジンの能力はそれぞれのメーカーの考え方次第だと思います。ただ予想するとこれと比べて悪くはならないんじゃないかと思います。
理由は最初にも書きましたし、またモバイル機器ほど省電力のために妥協する必要も無いので、性能のためにこれと同じ程度のコストはかけられるのではないかと。

3.Android TV対応の概要

使い方の話は以上で終わりで、以後はTvRemoteViewer_VBをAndroid TVに対応させる上で手を加えた点の概要です。

最初に書いた通り、Nexus PlayerはTvRemoteViewer_VBに何も手を加えなくても動き、最初からリモコンアプリでの操作が可能でした。

ただしUserAgentを見ると以下の内容になっており
Nexusuagent

今までの判定基準だとAndroid端末上のChromeブラウザそのものと見なされる内容で、確かに動画再生は「Projekktorの上で動いている」「通常のAndroid端末」の動作をしていました。むしろ何故いきなりリモコン制御できたかの方が不思議でした。
(通常のAndroid端末でもリモコン制御ONにできるが、デフォルトではOFFになっており、トップページで設定する必要がある筈。)
これを調べてみたところ偶然ですが、以下の仕組みが働いていました。

Nexuscc

今回のNexus Playerも Chromecastと同じ仕組み、つまり同じSenderアプリとReceiverアプリがそのまま動くので、Chromecast用に作ったアプリが今回いきなり使えたわけです。(Googleではこの仕組みをGoogle Castと呼んでいますね。)

TvRemoteViewer_VBはこの仕組みの上で、(Chromecastの記事でもご説明しましたが)Receiverアプリ上にiFrameという一種の仮想環境を作って、そこでコントローラ区画とアプリケーション区画を動かします。

コントローラ区画は最初にReceiverアプリ(マスター)からデバイスIDを受け取り、これをcookieを経由してアプリ本体に知らせます。この「デバイスIDお知らせcookie」が存在することでアプリ本体は自分がリモートで動いていると理解してリモコン制御用のタスクを起動する仕組みになっており、今回いきなりリモコン制御が効いたのはこれが理由でした。

しかし動画プレーヤーの選択については従来この仕組みではなくUserAgentの内容を見て判断しており、こちらではAndroidタイプと判断されたため、Androidで何も設定していないのと同じ状態の動画プレーヤーが起動したわけです。

これでもAndorid環境で常用される機能が動いているわけで、だから不便という訳ではなく、むしろChromecastではブラウザ上でNativeのHLSは動かなかったのに、この場合標準的なAndroid端末としてもNative HLSをサポートしていて(だからこそProjekktorが動いた)総じてそれほど悪くはないのですが、機器の使われかたからすれば

1)アプリから音量制御ができない。
2)ライブストリーミングやエンコード未了のファイル再生でシークができない。

という点は弱点になります。これらはアプリ側が動作を抑止しているのではなく、実際に該当コマンドをシステムに送っても効かない、つまりシステムとして通常のAndroid上のHTML5アプリと同じ抑止をしていることがわかりました。

まあ2) は付加的機能なのでまだ良いとしても、1)は利用上困ります。
(スマホ・タブならボリュームボタンで直接調整すれば良いですが、AndroidTVの場合はテレビ用のリモコンで音量操作するか、またリモコンのないモニタ等では直接モニタを弄るしかありません。)

どうしたもんだろうと考えながらふとChromecastでプレーヤーを実装する際に利用したライブラリとAPIの解説

https://developers.google.com/cast/docs/player

を見直したところ、根本的な話ですがこれは「Chromecast」用の解説ではなく、「Google Cast」用の解説ということに気が付きました。

なんだ、簡単ですね。AndroidTVのCast機能もGoogle Castの仕様に則っているとすれば、今まで「Chromecast」用と思って作った造りをそのままAndroidTVにも適用して、同じライブラリと同じAPIを利用すれば(つまりChromecastと全く同じアプリ動作にすれば)、1) のボリュームコントロールも標準で使えるようになるわけです。

また2)については前記事で比較したものがあるのですが、「最も出来の良いChromecastのHLS再生の機能」がそのまま使えるようになります。
実際にChromecastと同じロジックが動くようにしてみたところ、「速いChromecast」として全く同じ操作ができるようになりました。

このライブラリがどうやってAndorid&ブラウザ上の制約を取り払ってその辺の機能を加えているのかは謎です。ちなみに通常のAndroidでこのライブラリを使おうとしても弾かれますので、何らかのファームの機能と連携しているものと思われます。

ここが今回の大きな気付きで、むしろ今まで各種プラットホームの性格の違いを見てきたことで、AndroidがベースならAndroidと同じ癖があるだろうという自分の先入観が邪魔していたことが判りました。
実際はGoogleとしてはChromecastもAndroidTVもCastアプリについては「Google Cast」という共通のプラットホームにしていて、OSの違いはライブラリが吸収するようになっていたわけです。
もちろんもっと細かい所を見ていけば違いは出て来るのかもしれませんが、原則Google Castの仕組みに沿ったアプリを組んでおけばどちらも高いレベルでの互換性があることになります。

ちなみにTvRemoteViewer_VBはこの方針で行くとして、(後日わかった余談として)一部のGoogleCast対応アプリではこの互換性の対応をきちんとやっていないものもあるのが判りました。
具体的な例はGoogle自身の「YouTube」で、Chromecastでは操作側の音量バーに連動するのにNexusPlayerでは操作端末での音量調節ができません。(テレビのリモコンで音量調節しろ、とガイドまで表示されます。) Media Player Libraryを使っていないように思えますが、あるいはYouTubeの「Cast」ボタンは色形こそ同じCastボタンに見えても元々GoogleCastとは別系統のアプリ連動の仕組みであって、後付けでChromecast連動機能も追加している気もします。(AndroidTVで動いているのはGoogleCastアプリではなく専用アプリで、使い勝手が違っているようにも見えます。なにしろGoogleCastを全くサポートしていない筈のFireTVに対しても同じ手順で「Cast」できますので。)

さて閑話休題、残る問題はどうやってアプリ側がGoogle Castの上で動いている時に「自分はGoogle Cast上で動いている」と自覚させるか、です。
UserAgentでは
Nexusuagent

「通常のAndroidの内容」に加えて「Nexus Player」のような文字がありますが、これは当然ソニーやシャープのテレビでは異なるので汎用性がありません。

そこで、この節の最初の話に戻って、Cast特有の仕組みに統一することにしました。

Nexuscc_2

つまり、Google Castで動くアプリは必ず専用のSenderとReceiverアプリが介在しますので、ここからコントローラ区画とアプリ本体に「今Google Castで動いてるよ」というサインを送れば良いわけです。
具体的にはデバイスIDを知らせるのと同じタイミングで、「Google Castで動いている」という識別子を伝えるようにしました。

今のところこの仕組みで動くのはGoogle Castだけですので、単に「Castで動いている」だけでも良いのですが、後々「Apple TVで動いている」という仕組みも必要かもしれませんので。。

ちなみに、Android TVはちょっと工夫すれば普通のAndroid用アプリも導入できますので、( →参考
例えばDolphin Browserを導入した上で普通のAndroid端末として、マウスやキーボードを使ってTvRemoteViewer_VBを動かす、という(当初私が想定した)方法もあると思います。
但しその場合通常のAndroid上HTML5アプリに特有の(ボリューム操作不能のような)癖が出ますので、今回のようにGoogle Cast機能を活用するやり方が最もシンプルです。
AndroidTVを名乗る製品であれば必ずGoogle Castをフルサポートする筈ですので(でなければGoogle先生がAndroidTVと名乗る事を許可しないと思います)、AndroidTVを採用する製品で広く使えるアプリとなり、また今後出て来る様々なCastデバイスでの互換性も担保されるのではないかと思います。

2015年9月 1日 (火)

Windows10 Edge環境でネイティブサポートされたHLS再生をTvRemoteViewer_VBで活用 およびiOS/Androidのネイティブプレーヤー機能追加

1.TvRemoteViewer_VB(TvRemoteFiles v1.35) のWindows10 Edgeサポートについて

Windows10では今年初の段階でHLSのネイティブサポート予定がアナウンスされており(→参照記事) その後ぱったりと情報がなくなったので気にはなっていたのですが、最近ようやくWin10を1台導入してみましたのでテストしてみました。

結果、現在のところChromeもFirefoxもWindows10でのHLSネイティブはサポートしていないことが判ったのですが、Windows10から添付された標準ブラウザのEdge上であれば(また今のところその環境でのみ)HLS再生が標準サポートされていることが判りました。

ただEdgeはMSが敢えてIEを捨ててまで開発しただけあってWebkit系のCSS表現とも高い互換性がありますが、相変わらずChromeにもFirefoxにもない強烈な癖があり、IEほど明確な非互換ではないものの対応は結構大変でしたが、サポートバージョンのTvRemoteFiles ver1.35をようやくリリースいたしました。→導入手順はこちらを参考に。

Edgerel1

実際にEdgeで動かしてみると標準サポートの威力は絶大で、フルHD・倍速のような高解像度の映像でも軽いCPU負荷でヌルヌルと動きます。
動きが滑らかで発色も良く、また実況コメを大量に表示し続けても映像が乱れることも殆ど無いことなど、今のところ(Windowsで視聴されている方にとっては)最良の再生環境だと思います。

(尤も過去にはこれ以外のPC環境ではFlashを使ったエミュレーションが動いていましたので差は大きかったのですが、現在はEdge以外のPC環境でもhls.jsが使えるようになって、それなりにH/Wアクセラレーションが効くようになったため、大きな差というほどでもなくなりました。それでコメが重い時の安定性など、どちらでも使える環境ならまだまだHLS完全サポートのEdgeの方が一枚上かと思います。)

Edgerel2

また、この記事の後TVRemoteViewer_VBに実装されたハードウェアエンコード機能を併用すればサーバ側の負荷も軽くなり。現在ではスティックPCを使ったローエンドサーバーでも楽にフルHD配信ができるようになっています。
それにEdgeを組み合わせた環境なら軽量PCでも配信、再生、実況表示を楽にこなせるシステムが出来上がります。
(実際地上波の場合だと、ローカルのチューナーから直接TVTestで再生して実況流すより負荷は軽くなるほどです。MPEG2の再生にH/W、OSとももはや最適化を止めてしまったのが理由なのですが。)

TvRemoteViewer_VBを使う方でWindows10にアップグレードされた方は、これだけでもWin10を導入した甲斐があるのではないでしょうか?

ただしご利用に当たっては、Windows10対応の最新のグラフィックドライバの導入も必ず行ってください。私の環境(IvyBridge インテルHD4000)では、WIndows10を導入しただけでは動画再生時のCPU負荷が70%を越える状態でしたが、インテルのサイトから最新ドライバを入れたところ10%前後に落ち着き、絵も滑らかに動くようになりました。

1)使い方

使い方は特に従来のものと大きく変わることはありませんので過去の解説記事をご参照いただければ良いのですが、従来とちょっと違う面、また再生能力以外にも便利になった面がありますので、補足説明いたします。

準備

Edgeの設定→詳細で以下のように、「ポップアップをブロック」が「オフ」になっていること、「クッキーをブロックしない」になっていることを確認し、違っていたら変更してください。

Edgesettingpupcookie

① ボリューム操作

ネイティブプレーヤーは(格好の良し悪しは置いといて)マウスオーバーやタップで図のような

Edgerel3

コントロールが表示され、Play/Pause、動画の(ブラウザ機能ではない)全画面表示等が可能ですが、音量の調整は図のように

Edgerel4

一応縦のスライドバーで調整はできるのですが、画面の中にかかってしまうため、実況表示中は(実況の下に入って)操作ができなくなります。
そこで上図の中央部にあるように代替のボリュームコントロールが使えるようにしました。

ちなみにコントロールにある音量マークは、縦のバーが表示された状態でもう一回クリックすればミュートのON/OFFになります。

なお、2.でご説明するiOSやAndroidのHLSネイティブサポートでは、両者ともモバイルの制約でHTML5によるボリューム制御が出来ませんので、この音量バーも表示されません。音量調整はスマホ/タブのボタンでおこなってください。

また進捗バーは何となくいろいろ使えそうに見えるのですが実は(エンコード済みのファイル再生以外では)役にたちません。
ところがEdgeのNative HLSプレーヤーはコマンドを使えば、実はライブ(TV)ストリームやエンコード未了のファイル再生ストリームでも、シークが可能なことが判りました。その機能を次に解説いたします。

② ライブ(TV)ストリームでシーク操作。エンコード未了のファイル再生でもシーク操作

EdgeのTVストリーム再生画面では、従来にないシークボタンが追加されています。

Hlsseek1

これを使えば「今プレーヤーが蓄積しているバッファの範囲内であれば」 再生位置を前後に移動させることができます。
ボタンでシーク位置を指定すると、移動可能な範囲にあれば上図のようにボタンが明るいグリーンになり、それを押すことで移動が実行されます。

移動可能範囲外なら下図のようなダークグレーとなり、押しても何も起きません。(数字はリセットされます。)

Hlsseek2

このボタンで移動できる範囲はバッファの状態によって変わり、再生開始直後はほとんど移動範囲は無いか僅かしかないものの、数十秒も経てば1~2分の範囲で動けるようになります。(ただし前方へはリアルタイムの10秒遅れぐらいまでで、それ以上前には進めません)
移動直後はバッファがクリアされますので連続の移動はできませんが、数十秒でバッファが溜まってまた動けるようになります。

以上のようにそれほど大きな移動はできないのですが今まではなかった機能であり、「今のシーン見逃した!ちょっともう一回見たい。」という時に役立つのではないでしょうか?

一方ファイル再生でも今までストリーム再起動しなければ出来なかった「エンコード未了状態でのシーク動作」が、バッファ範囲内であればできるようになっています。
従来のファイル再生ではエンコード未了状態でシークボタンを操作すると、図のように青いボタンで移動時間が表示され、

Hlsskip1

これを押すことでストリームが再起動されて再生位置を移動していました。
これはこれで確実な動作なのですが、再起動を伴うためタイムラグがあるのが弱点でした。

それがEdgeでは図のように

Hlsseekfile1

バッファ範囲内であればグリーンのボタンになり、押すことでクイックな移動が可能です。
移動可能な範囲は再生開始直後にはありませんが数十秒後にバッファが溜まれば、前後3~4分の範囲なら動けるようになります。(移動直後はバッファがクリアされますので連続移動はできませんが。)

チャプタースキップボタンでも同じ操作性が実装され、

Hlsskip2

ボタンがグリーンの範囲内であれば瞬時に移動します。
移動時間から言ってもCMスキップ等に丁度良いのではないでしょうか?

ファイル再生の場合は、バッファ範囲外の移動先であればボタンの色はグリーンから青に変わり、通常のストリーム再起動によるシーク動作に変わります。

なお、プレーヤーのバッファ状態は刻々変わりますので、シーク時間を調整しているタイミング(数字ボタンを押す度に範囲判定が行われます)と、実際にシークを発動するタイミングでバッファの位置がずれ、結果として意図に反してストリーム再起動が発動する場合もあります。
この辺はベストエフォート型の処理ですのでご了承ください。その辺の動作を避けるためには限界地点までの移動ではなく、ある程度余裕を持った幅で移動することがお勧めです。

2)注意点

ブラウザの全画面モードは未実装 → 実装されました。

Edgeは動画単独での全画面表示は最近対応したのですが(上記2 のコントロール右端にボタンがあります)、ブラウザ自体の全画面表示は未だ対応しておらず、ウインドウを最大化しても上下に枠やアドレスバーが表示されたままになります。

 

ブラウザの全画面モードがあればリモコンとの組み合わせによってテレビのような使い方ができ(→参照)、より実用的なのですが、この辺は開発が間に合わなかったのではないかと思います。

→という状況が意外に1年半も続きましたが、無事、「ブラウザ全画面表示」が実装されました。

Shift + Windowsキー + Enter

で全画面⇔ ウインドウ表示が切替えできます。
私のようにイスにもたれかかってマウス操作でテレビを見る者にとっては、キー操作が必要なのはもう一声、という所ですが、もはやテクニカルな問題ではいので、そのうちクリック操作もサポートすると思います。

また、「テーマの選択」で黒を選んで、枠やコントロール類を黒くすることで多少引き締まった雰囲気にすることもできます。

Trvedgebg

以上、Windows10のEdgeはかなりタイトなスケジュールで開発されたと思われ、まだ怪しい動作や足りない機能も多いのですが、今後追加されていくものも多いと思います。(但し開発者向け機能はChromeに習ったのか、バグはともかく機能は現状でも豊富です。)
今のところ、HLSが標準サポートされている点だけでもこれ用に使ってみる価値があると思います。特に省電力PCやスティックPCなど、非力なPCでも高解像度の動画が無理なく鑑賞できるのは意味があるのではないでしょうか?
(ただしChromeもFirefoxもAPIで排除するわけにもいかないでしょうから、じきにHLS標準サポートするようになると思われますが。)

ちなみにWindows10そのものの動作検証はまだまだですが、いままで使った限りではWindows8/8.1に移行する際の注意点とそれほど変わっていないと思います。(すなわちWindows8/8.1への移行を経験された方なら同じような点を注意すればOK)
なお今回はFast Bootのマシンに上書きインストールしてみましたが、8→8.1移行で経験したような起動が遅くなる問題は起きませんでした。
うまく対策したのか、それとも上書きインストールに見せかけた完全な新規導入(?)になってるために結果として問題が起きないのかは判りませんが、取り敢えずその点は有難かったです。

その他の注意点としては、VMWare Workstation系のネットワークはまた厄介が生じてますね。MSの伝統がまたまた健在といったところでしょうか。
具体的には、Win10にするとBridge接続は使えなくなり、NATで外に出るしかない状態になります。ネット上にはブリッジを再導入すれば良いとか一旦削除して再導入すれば良いとかいくつか情報はありますが、どれも不確実な手段です。なかなかこれに対するMSの所業は手が込んでいる感じですね。
しかしこの問題も2016/9にリリースされたVMware12.5 でようやく解消しました。今後利用される方はそれ以降バージョンにアップされることをお勧めします。
(それ以前のバージョンでは対応策としてここにある手順が必要でしたが、その手順を使っていた場合、12.5に移行する際にハングすることがありますので、Virtual Network Editor(vmnetcfg.exe)で追加した仮想アダプターやMicrosoft Network Adapter Multiplexorは削除してネットワークの設定を元に戻した上でVMWareのバージョンアップをおこなってください。)

3)Windows 10 Mobile 対応

Windows 10 Mobile 上のEdgeも動作環境として互換なので、基本は動きますが、某掲示板で一部表示が乱れるという情報をいただきました。
現物は持っていませんでしたが、MicrosoftがVisual Studio 2015上で動くMobileエミュレータを提供していることが判りましたのでそれを使って検証し、問題個所を修正いたしました。(TvRemoteFiles v1.36以降)

モバイル環境では元々画面サイズに比べてドットピッチが細かいので -webkit-text-size-adjust でフォントサイズの調整をおこないますが、この解釈が他のモバイル環境と微妙に違っていたのが表示乱れの原因でした。
また何故かUserAgentに"Android"の文字列があるためAndroid環境と取り違えた動作があり、それも修正しました。

こんな感じで使えます。

Win10mov3 Win10mov1

画面の大きさは別として操作性は通常のWindows10 Edgeと同じになりますが、以下の特性があります。

① 他のモバイル環境と同様に動画の自動スタートはできないので、視聴開始時にはスタートボタンを押してください。

② 一方iOS、Androidとちょっと異なる点としてプログラムからのボリュームコントロールは出来るようです。(少なくともエミュでは) したがって代替のボリュームコントロールを付けたままにしています。

2.iOS/Android ネイティブプレーヤー機能の追加について

 1.のEdgeで動かす際は、現在TvRemoteViewer_VBで標準的に使っているProjekktorというメディアプレーヤーは読み込まずに、ブラウザ標準のHTML5ビデオプレーヤーを直接使う作りに変えています。
実はこれはもともと、Chromecast対応時に作ったロジックを汎用化したものです。今回はそれにEdge独特の癖を吸収するロジックを加えています。
(Chromecastは追加のライブラリが必要とはいえ、動作はHTML5標準のvideoタグに準じています。)

こうやってせっかく作ったロジックですのでさらにこれを、もともとHLSをネイティブサポートしているiOS/Android 環境でも使えるようにしてみました。

利用するにはトップページの管理タブにある以下の項目をチェックしてください。

Hlsrel1

本来ProjekktorはHLSが標準サポートされている環境では内部的にその機能をきちんと使うので、(例えばiOS/Android環境では標準プレーヤーの上に被さる形で動いている。) 今までわざわざ標準プレーヤーを直で使う必要は無いと思い、プログラムの共通化の観点でもProjekktorのみをインターフェースにした作りにしていたのですが、
1.でご紹介したEdge環境では何故かProjekktorとの組み合わせがうまく動かず、必要に迫られてHLS Nativeのみで動くものを作りましたので、せっかく作ったんでと試しにiPadやAndroidでも動かしてみると、実はいくつか便利な機能が追加で使えることが判りました。

① iOS環境ではEdgeのケースと同じように、ライブ(TV)視聴中やファイル再生開始直後でもシーク操作ができる。
 (Androidは残念ながらこの機能サポートしません)

② Android環境で動画全画面化するとうまく操作ができなくなる現象が(標準ブラウザやChromeで)起きていたがこれが解消し、全画面化⇔ブラウザ表示の切替えもスムーズになる

③ Projekktorのライブラリはそれなりのサイズがあるので、これを外すことでモバイル環境で起動が速くなる。

④ iPad最新モデルであれば「ピクチャ・イン・ピクチャ」機能がブラウザ表示状態から直接呼び出せる。

まあ②③.はともかく、①はProjekktorが敢えてクロス環境での動作を統一するために省いていた機能と思われます。
確かにプラットホーム別に処理をいちいち分けるロジックはちょっと面倒で、Projekktorが使えたことで今まで開発が非常に楽だったのも事実なのですが、こうやって対応出来てしまうとやはり使える環境では使えたほうが便利だと思い、TvRemoteFiles ver1.35でこれらネイティブ機能が使えるようにし、安定動作が確認できたことでTvRemoteFiles 1.39以降ではiOS/Mac/Androidでこれがデフォルトになるようにしました。(敢えてチェックを外さない限りネイティブプレーヤーを利用します。)

各プラットホーム・HLSネイティブプレーヤーで使える機能を表にすると、以下のようになります。

Hlssummod

シーク等の実際の操作方法は1.のEdgeと同じですので、iOSで使う場合もそちらを参照してください。またリモコン機能のシーク/スキップボタンも今回、このHLSネイティブプレーヤーのシーク機能に対応して、色の変化で判るように拡張されています。

比較のため、同じHLSプレーヤーを使ったChromecastを加えてあります。
(尚、Chromecast/Googlecastでは当初と比べて最新バージョンの使い勝手が変わっていますので、変更箇所を赤字にしてあります。)

以上、特にiOS環境では動作も軽くなりますので、ぜひ使ってみてください。
.

3.(補足)Microsoft Edge アプリ互換性の注意点

記事中で癖が強いと言いながら具体的な事を書かないと役に立たない情報になってしまいますので、ポイントだけメモしておきます。(あくまで私が使った範囲内で気が付いた点です。)Edgeでも動くようなアプリの開発を計画されている方向けなので、関係ない方にはあまり意味のない蛇足です。

1)サイトの信用度が低いと判断すると、そこで作成したcookieが強制的にセッションクッキーにダウングレードされてしまう。

どのようなサイトを信用高い、低い、と判断するのかよく判っていませんが、TvRemoteViewer_VBのようなプライベートサーバは信用してくれないらしく、設定情報のクッキーがブラウザ終了のたびに蒸発する、という現象に悩まされました。
結局1か月ぐらいの保存期間を指定したはずのcookieを、強制的にブラウザ終了とともに削除される"セッションクッキー"にダウングレード、という処理がEdge側でおこなわれているようです。

クッキーのダウングレード機能自体はIEの時代からあったもののちゃんとカスタマイズができたのですが、Edgeにはろくなカスタマイズ項目もなく、簡単には対策できないようです。
結局Edge環境ではパーマネントCookieの利用は諦め、少々の速度低下は許容した上でWeb Storageを代替で使うことにし、元のcookie関連共通関数の中に埋め込んでアプリ本体から見れば同じ処理になるようにしました。

このようなセキュリティ機能の良し悪しは別の話で、他のブラウザと大幅に異なる振る舞いでカスタマイズも出来ないのは問題だと思います。イントラサーバでWebアプリを組んで、Cookieを認証等に使っている企業ユーザーで困った事になるかもしれません。(尤も敢えてEdgeを使わなければ良いのですが、そうと気づくまでシステム部門の人が悩むことになると思います。)

2)httpでのキャッシュが効き過ぎる

普通にブラウザを操作する時、例えば http://www.nifty.com/test.html を開いて読むときは、ブラウザ側は読んだ内容をキャッシュに保存して、次に開くときにも変化がない、あるいは余り時間が経っていないと判断すればniftyのサーバへは殆どアクセスせず、キャッシュの内容が再表示されます。
ユーザーが単なる再表示ではなくサーバーに最新の記事を取りに行ってほしいと希望すれば、改めて「最新の情報に更新」のようなボタンで指示をすることでサーバにフルアクセスが行き、最新のものが読み込まれることになります。

ここまでは普通のブラウザ操作での動きですが、人間が操作するのではなくjavascriptプログラムが http://www.nifty.com/test.html というurlを指定してアクセスする際は、キャッシュを利用するかどうかはブラウザによって微妙に違います。

① プログラムが「同じデータを後から読み直す目的」で同じurlにアクセスするのは有り得ない。敢えて同じurlにアクセスする際は最新データの取得が目的と考えられるので、必ず最新のものを再読込する

② javascriptは人間が読みやすいように加工するのに使われている程度だろうと考え、ブラウザ直でのアクセスと区別しない。再読込するかどうかはtest.html の中身によって判断。ダイナミックページ(javascriptが中身を毎回自動生成するようなページ)は毎回再読込し、スタティックページではキャッシュをできるだけ活用する。

だいたい①と②の間のどこかになると思いますが、大抵は①に近いと思います。
ところがEdgeはほとんど②と思われる動作が標準になっていることが判りました。

まあ確かにライブラリのように画面遷移する度に読み込まれるようなファイルをキャッシュしてくれるのは有難い面もあるのですが、肝心のプログラム動作では、TvRemoteViewer_VBでは端末からサーバに頻繁に

 http://サーバアドレス/WI_GET_PROGRAM.html

のようなuriが送られ、サーバ側はそれに対応した情報(最新の番組情報やストリームのステータス)を返しますが、ブラウザから見ればこれは静的HTMLに見えるので、Edgeはキャッシュのデータを返せば良いのだと勝手に判断し、サーバにはuriすらほとんど送られません。

このような通信手順は単に情報照会だけではなく端末プログラム側からのコマンド送信でも使われるのですが、プログラムがサーバにコマンドを送っているのにEdgeは勝手に単なるブラウジングと判断した上で、前に同じようなブラウジングリクエストがあったと解釈し、サーバには何も送らずに、前回サーバから返ってきた(実際は処理リターンコードの)画面をプログラムに返す、というような(アサッテな)動作をしてしまいます。
結果すぐに動かない状態になるものの端末側のトレースを掛けても何もエラーも見つからない、という困った状態になります。

結局上記のようなuriには必ず

http://サーバアドレス/WI_GET_PROGRAM.html?dummy=123456

というようなダミーの尻尾をつけ、123456を毎回変える(例えば現在のミリ秒単位の時刻)とすることで毎回確実なサーバ通信が行なわれるようになります。今回この手のサーバアクセスには必ずこの「尻尾」をつける改修をおこなって対策しました。

ただこのような動きは必ずしもEdge特有という訳ではなく、いろいろ確認してみるとAndroidのDolphin Browserも、条件はもっと限られますが同じような動きをするということが判りました。(リモコン機能がDolphin Browserでだけ効かない、という問題が偶然最近あったのですが、これが原因でした。)
そういう意味ではEdgeが悪いと言うのではなく確実な汎用性を持たせるためにはやらなければならない改修で、デバッガ機能が豊富なEdgeで問題が明確になったことで潜在的な問題を解消する良い機会にもなったのですが、それにしてもEdgeだけ随分違った動きをするな、と面食らったのは確かです。

3)エラー判定が厳しい

ChromeやFirefox等のような従来の処理系と比べて、文法的な間違いや「変数に対する不適切なメソッド適用」のような誤った処理をなかなか見逃してくれず、従来ならなんとか動いていたアプリがそういう場所で止まるケースが続出します。以下はほんの1例です。

HTML部品では、例えば<input>タグはもともと構成要素がないので終了タグ</input>は「不要」となっていましたが、HTML5では改めて「書いてはいけない」という規則になりました。→参考
ただ今までなんとなく書かれていた場合もあるということで、多くの処理系でエラーにはなっていなかったのですが、Edgeでは明確にエラーになりますので、きちんと直す必要があります。(直さなくてもそこで止まるわけではありませんが。) </br> のようにあまり深く考えずに使っていたものもエラーになります。

もう少し影響が大きいのはjavascriptの不適切な処理でプログラムが止まってしまうことです。例えば次のような構文の場合

 var text1 = object1.name;
 if (text1.indexOf("Tokyo") >= 0) 処理1;
 else 処理2;

もしobject1.name に何かの文字列がセットされていれば、その文字列にTokyoというフレーズが含まれているかどうかの場合分けをしたいというのが本来の意図です。
しかし もしobject1.name が定義されていない(=undefined) の場合、undefined な物にはindexOf() というメソッド自体が定義されていない筈なので不適切な処理ということになります。
そういう場合、PCのChromeなど多くの処理系では、メソッドの副作用が少ないと判断した場合はできるだけ処理を止めない配慮がされていて、条件式自体が成立しなかった = falseだったとして処理2が実行され、以後の処理が継続します。Firefoxはこの辺割と厳しいのですが、それでも大抵はWarningで留めてくれます。(というか、その辺が通るレベルまでデバッグされていたアプリが今まで多かったと思われます。)
ところがEdgeの場合はif文の条件式自体が間違っていると判断してそこでエラーを出し、以後の処理もおこないません。
こういう所はもちろん本来

 var text1 = (object1.name != undefined)&&(typeof object1.name === "string")?object1.name:"";
 if (text1.indexOf("Tokyo") >= 0) 処理1;
 else 処理2;

このように修正していかなければならないアプリのバグで、たまたま今までの処理系の親切さが仇になって発見できていなかったことになります。このあたりの「ユルさ」もjavascriptの魅力ではあるのですが、アプリが次第に大規模になって行ったり多くのプラットホームをサポートしていく際には次第に足枷になりえます。特にモバイル系プラットホームだとデバッグが容易ではない上様々なブラウザが使えることで代替手段も多いので、この辺のエラーが起きていてもなかなか発見しづらくなります。
こういう点にEdgeは厳しいのですが、デバッガ機能も豊富なので、一通りの処理を流していけばこういう個所が容易に発見でき、原因を判別して修正するのも容易なプラットホームだと思います。

今後はEdgeで動けば他の処理系でも動く、という事にもなるので本来的には有難い作りなのですが、従来のアプリでは割と高い頻度でこういう処理はある筈で、アプリがEdgeですんなりとは動かない原因になります。
こういったエラーへの許容度の狭さを直すべきとは言えませんが(特に「言語屋」は不適切な処理があればそこで止めるのが「親切」という考え方をするので、出来たばかりの処理系には有りがちな話ですね。)、しかしアプリ屋にとっては少なくとも他で動いていたアプリをEdgeで動かす際にきちんと検証が必要な理由になります。特に他人が作ったライブラリを活用している時は、そのライブラリ自体が内包していたバグで動かなくなるケースも起きますので、そういう点はちょっとやっかいかもしれません。(もちろん大所のライブラリはコードインスペクタで潜在的なバグにも対処済みと思われますしMicrosoft自身もEdgeの開発過程でテストしている筈でエラーは出ないと思われますが、小規模に流通しているライブラリは要注意だと思います。今回のEdge対応でネイティブプレーヤーのみで動く形に改修したのも、もちろんその方がシンプルに多くの機能が使えるのが一番の理由ですが、もともとの動機は今まで汎用プレーヤーとして使っていたProjekktorがEdge上でうまく動かず、中身も可読形式ではないので敢えて対応させるのが面倒だったのも大きな理由でした。)

以上、結果を知ってしまえば簡単な話なのですが、当初原因が判らず悩まされた問題はだいたいこの3点という感じです。

« 2015年7月 | トップページ | 2015年10月 »

フォト
無料ブログはココログ
2017年6月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

ウェブページ