« Chromecast(クロームキャスト)とTvRemoteViewerで未来型テレビを作る | トップページ | Android TVでTvRemoteViewer_VBを使う »

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で動かしてみると標準サポートの威力は絶大で、高解像度の映像でも軽いCPU負荷でヌルヌルと動きます。
今までPC環境ではHLSはネイティブサポートされていないため、プレーヤーのFlashフォールバック機能を使ったエミュレーションを使っていたのですが、720p解像度までなら普通に見られると思っていたもののさすがにフルHD 1920x1080や、もっと低い解像度でも1000コメ/分のような実況弾幕状態になると動きがカクついたり絵が追い付かなかったで無理があるなぁ、と思っていました。
ところが今回比べてみるとフルHDどころか、どの解像度でもフレームレートの差は(数字で測ってはいませんが)明白で、動きが滑らかになりますし、発色の良さ、動きやコメの多い場面でも映像が乱れることも殆ど無いことなど、今のところ(Windowsで視聴されている方にとっては)かなり差があります。またフルHDの視聴も実用的です。

Edgerel2

ただフルHDだとさすがにサーバ側が従来型のソフトウェアエンコードでは高負荷(1ストリームでもウチの4コアSandyBridgeでは一杯一杯)になる方が問題だったのですが、この後TVRemoteViewer_VBに実装されたハードウェアエンコード機能でその問題も解消しました。現在ではむしろスティックPCを使ったローエンドサーバーでも楽にフルHD配信ができるようになっています。
その際Edgeを使えば視聴側PCも負荷なく滑らかな再生が可能で、またその状態で勿論実況表示やシーク動作も軽快に動くようになります。

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 のコントロール右端にボタンがあります)、ブラウザ自体の全画面表示は未だ対応しておらず、ウインドウを最大化しても上下に枠やアドレスバーが表示されたままになります。

ブラウザの全画面モードがあればリモコンとの組み合わせによってテレビのような使い方ができ(→参照)、より実用的なのですが、この辺は開発が間に合わなかったのではないかと思います。
要望も結構多くじきに対応すると思われますので、それまでは枠の表示は許容するということで。
気休めかもしれませんが「テーマの選択」で黒を選んで、枠やコントロール類を黒くすることで多少引き締まった雰囲気にすることもできます。

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点という感じです。

« Chromecast(クロームキャスト)とTvRemoteViewerで未来型テレビを作る | トップページ | Android TVでTvRemoteViewer_VBを使う »

デジタルTV、TS抜きチューナー」カテゴリの記事

コメント

12/17 追記 TvRemoteFiles ver1.59でほぼ問題解消したと思います。お試しください。
なお、全体的にiOS 9.2はシステムへの負荷が重くなっているようです。解像度を上げ過ぎるとなかなか動画が開始せず、一見ハングしたように見えるかもしれませんので、そういう時は解像度を下げてください。一度動作が重くなったら電源をOFF/ONして、メモリーをクリアするのもお勧めです。

************
その現象が時々起きるのは把握していますが、原因は正直言って判っていません。iOS環境以外でもうまく開始できない事はありますが、プレーヤーのスタートボタンすら効かなくなるのはiOS環境だけです。
とりあえず新しいバージョンには対症療法としてスタートを補助するボタンを付けましたので、お試しください。

TvRemoteFiles ver1.58 で
コントロールエリア最上列(「番組表」「サムネイル」ボタンの右あたり)に、iOS、MacOSX環境で動画開始を補助するためのスタートボタン(小)を付けました。
http://www.dotup.org/uploda/www.dotup.org657057.jpg

ただし毎回、というのは頻度が高すぎだと思いますので、バックグラウンドで何か重い処理やアンチウイルス等が動いていないか、他のブラウザではどうか、いろいろ確かめて見るのをお勧めします。

どこに書こうか迷ったのですがこちらに…
TVRemoteViewer_VB_1.77 12/15版を利用しています。(単にサーバ再構築が今日だっただけで深い意味はありません。)
TVRemoteFiles1.5.7を利用させていただこうと思ったのですが、Windows10のChromeなどの環境では問題なく動作するものの、
iOS9.2のiPhone6sPlus、同9.1のiPad第四世代ではSafari、Chrome、Lunascapeともに
左上のボタンを押しても真ん中の再生ボタンを押しても無反応で何も再生されませんでした。
TVRemoteViewer_VBのみのピュアな環境を作ってみたら(見た目はともかく)うまくいきました。
(そのかわりこっちの方法だとPCではこの記事の通りHLS対応のEdge以外で再生できませんが、サーバの性質上それは些細なことです)
見たところ、サーバとRecTaskの動作/ログには特におかしなところはないのですが、TVRemoteFilesを使う場合どこを確認すればよいのでしょう?
というか、以前はProjekktor入りのをiOSで使ってても特に支障はなかったので、iOSの方で仕様が変わったのかもしれませんが。
僕は2chを見られない病気なのでそちらの方で既に話題になってたら申し訳ありません。

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/570024/62195460

この記事へのトラックバック一覧です: Windows10 Edge環境でネイティブサポートされたHLS再生をTvRemoteViewer_VBで活用 およびiOS/Androidのネイティブプレーヤー機能追加:

« Chromecast(クロームキャスト)とTvRemoteViewerで未来型テレビを作る | トップページ | Android TVでTvRemoteViewer_VBを使う »

フォト
無料ブログはココログ
2017年4月
            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            

ウェブページ