title
わたしの日記は日々の出来事の鬱憤晴らしの毒だし日記がメインです。 相当病んでいます。くだを巻いています。許容出来る方のみのアクセスをお願いします。 また、この日記へのリンクは原則自由にして頂いても結構ですが、 写真への直リンクを張るのはご遠慮下さい。内容に関しては、一切保証致しません。
カテゴリ一覧 Network, Internet, IPv6, DC, NTT, Comp, Linux, Debian, FreeBSD, Windows, Server, Security, IRC, 大学, Neta, spam, , 生活, 遊び, Drive, TV, 仕事,
過去日記:



2018年08月18日() [晴れ]

[Network][Internet][TV] DTCP-IP で遊ぼうか、やっぱり、HDMI Extender で遊ぼう。

奈良にHDDレコーダーやテレビなどいろいろな家電があり、録画したものを東京でみたいと思ったとき、実装をどうしようか悩んでおり、解決方法が無いか模索していた。その中で、DTCP-IPを流す方法。しかし、技術仕様に7msの壁があり、想定内であったものの、やはり通らず。

東阪には、L2の網が引かれており、その上にVLANが流れてる。単純にL2ですべて延伸はしたくないため、広域VLANを作り、バックボーンセグメントとして設計、そこに各拠点毎のルータが接続され、経路交換には、OSPFが使用されています。このあたりは、 841M導入時にはまったネタを参考に。WiFiはCisco FlexConnectにより一元管理、およびお互いのVLANに足を伸ばせるようになっています。
話を戻して、DTCP-IPはL2でないといけないので、専用のVLANを東阪に敷設してのばしましたが、RTTの問題で、結局NG。proxy arp + L2 Bridge でごまかそうかとおもって、しらべていたところ、「日本のちゃんとしたメーカ製レコーダは、共有鍵生成プロセス中に時間測定してるはずなので難しいと思います。」といったコメントをとある人からいただいた。うーむ、難しいなぁ。あきらめて、ひとまず、HDMI Extender over IP を使用してみることに。

今使用しているルータの制約で、300Mbpsが上限。メーカーから評価機を借りて負荷試験したら、東阪では、800Mbpsを簡単に超えれたが、今のところ買い換える予定は無しの為、東阪のスループットは300Mbps程度。HDMI Extender のスペックをいろいろと調べていると、80Mbpsやら、100Mbpsといった帯域幅を要求するとあるので、これなら、HDMI Extender over IP でも、3本は通る計算。ということで、いろいろと調査した結果、要件に合いそうなものを適当に2機種購入。

どちらも調べてみると、怪しい表記ではあったモノの、どちらもover Ethernetに対応している様子。スイッチをかましてもいけるとのこと。
ただ、373側はHDCP対応、891はIR対応だが、HDCP対応とは記載が無い。同一メーカーのようだが、Amazonでいろいろと調べてみると、あちこちにOEMを出しており、891には、HDCP対応という記載は無かった。ちなみに、どちらもCECには未対応の為、テレビからHDMIデバイスを操作することは出来ないので、IR対応の891も併せて購入している。

まずは届いたので開墾の儀。

パッケージおよび、373(左)、891(右)

外観パッケージは同じのようだ。見た目の区別は付かず、サイズも同じ。
開封してみると、Amazonの商品紹介と同じく、そのまま。


LAN側インターフェース


HDMI側およびACアダプタインターフェース



上から


裏面から

ACアダプタは5V 1Aのもの。うまく使えば、USBから供給可能なので、宅内に、HUBやオーディオの同軸→光の変換、HDMIセレクター、Amazon FireTVなどそういったデバイスが多い場合は、 Anker PowerPort 6 Lite (30W 6ポート USB急速充電器)といった、各ポート1A供給できる6ポート程度のUSB充電器などを用意すればよいだろう。今となっては、QCやUSB Type-Cなどが始まり、古くなったUSB給電アダプタを余らしているところも多いだろうから、そういうのを転用しても良さそう。その際は、 USB-DC電源供給ケーブル センタープラス 1m (Φ5.5/2.1mm 標準DCプラグ)といったモノを準備すればよいだろう。※ サイズは、Φ5.5/2.1mm 標準DCプラグ だと思いますが、はかっておりませんので注意してください。

ということで、届いたので、電源を入れて、動作確認。



作業用のスイッチとして、我が家では Panasonic Switch-M8eG や、 BUFFALO BS-G2108URといったスイッチを大量に採用しており、予備機も潤沢にあるので、今回は、一般家庭を想定し、BUFFALO BS-G2108URを使用してみた。

HDMI Extenderの紹介には、帯域幅80Mとか100Mといった表記しかなく、また、製造メーカーも不明であり、詳細を調べることが出来なかった。
まず、LEDを見ていただきたいのだが、オレンジ色でLinkUpしている。すなわち、100Mで上がっているということだ。多くても上限で100Mbpsの能力しか無いということ、L2遠伸をしても、実効帯域300Mbpsあるので、影響は受けないということになる。

さて、環境がそろったところで、次の組み合わせ試験を行った。

いずれの組み合わせもOK。ついでに、空きポートにPCをつないだところ、そちらにもパケットが来ており、他のポートと同様に点滅することから、フラッディングしている様子。
これは、想定範囲内で、 Amazonのレビューに次のようなコメント

1つのLANハブから各部屋に有線LANを通していて、そこに接続をすると全てのハブがビージー状態になってしまいます。(使ってないところまでピカピカと点滅する)←うまく説明できない

すなわち、ブロードキャストに投げるような粗悪な実装か、マルチキャストをしているのではないかと、容易に想像が付く。今回、IGMP未対応のスイッチを使用しているので、フラッディングしているように見えるが、正常。実際にパケットをみてみると、次のようなメッセージ。

15:45:05.858549 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052)
    192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024
15:45:05.858667 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052)
    192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024
15:45:05.858784 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052)
    192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024
15:45:05.858901 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052)
    192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024
15:45:05.858902 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], prot
15:45:05.859019 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052)
    192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024
IP Multicast については、英語の WikiPedia:Multicast addressがてっとり早く詳しいが、226.2.2.2 は RFC5771によると、
225.0.0.0 - 231.255.255.255   (7 /8s)    RESERVED
となっている。宛先mac address 01:00:5e は、RFC1112で定義されたアドレス。
01-00-5E-00-00-00 - 01-00-5E-7F-FF-FF	0x0800	IPv4 Multicast (RFC 1112), insert the low 23 Bits of the multicast IPv4 Address into the Ethernet Address (RFC 7042 2.1.1.)

上記の背景からIP Muticast を使用していると断言出来る。

さて、ではスループットについてしらべてみよう。IGMP未対応のスイッチのため、フラッディングしてくるので、同じトラフィックがPCでも見ることが出来る。
すなわち、プロミスキャス・モードに切り替え、テスト用端末のインターフェースで受信したトラフィック量をモニタしてみた。

$ ifstat -b -i eth1
       eth1
 Kbps in  Kbps out
64244.03      0.00
53804.32      0.00
49787.48      0.00
49209.97      0.00
50719.70      0.00
63823.11      0.00
69301.00      0.00
68460.17      0.00
64678.62      0.00
58649.50      0.00
52736.90      0.00
47499.17      0.00
51966.95      0.00
58729.38      0.00
67817.21      0.00
68894.07      0.00
68828.96      0.00
$

上記から、映像を送信している場合は、最大でも、70Mbps程度使用していることになる。300Mbpsの有効帯域があると言うことは、4本のHDMIが通ると言ってもよい。4chですよ、4ch。すごいね。

尚、真っ黒の画面を送信した場合は、10Mbps程度、HDMI入力をOFFにした場合は、ほとんどパケットの送信は無かった。電源が入っている限り、トラフィックを出すと言った仕様では無いこと、映像によって、帯域は可変で、10Mbps〜70Mbps程度の幅があることがわかった。

参考として、HDMI の Source に使用した機器は、 パナソニック プライベート・ビエラ UN-15T5のチューナーに接続、測定した。

さてさて、これだけでは、本記事としては面白くないということ、端末にIPアドレスが付与されているということで、scanなどを行ってみた。

# nmap -sP 192.168.168.0/24

Starting Nmap 7.60 ( https://nmap.org ) at 2018-08-18 15:50 JST
Nmap scan report for 192.168.168.55
Host is up (0.0046s latency).
MAC Address: 00:0B:78:00:60:01 (Taifatech)
Nmap scan report for 192.168.168.56
Host is up (0.0088s latency).
MAC Address: 00:0B:78:00:60:02 (Taifatech)
Nmap scan report for 192.168.168.148
Host is up (0.0058s latency).
MAC Address: 00:0B:78:00:60:A4 (Taifatech)
Nmap scan report for 192.168.168.1
Host is up.
#

基本的にはTxとRxの出荷のMacAddressは連番になっているようで、891については、.55(Tx), .56(Rx)となっていたが、373は、.55(Tx)、.148(Rx)となっていたので、Tx側モジュールをそのまま使うには、IPアドレスが重複する可能性がある。ちなみに、同時にTxを2つつないだ場合の挙動は未確認。後ほどテストをしてみます。
mac addressからして、Taifatech となっており、oui.txt によると、下記の通り。

000B78     (base 16)            TAIFATECH INC.
                                8F-1 No.289, Sec.2  Guangfu Rd.
                                Hsinchu    300
                                TW

台湾の会社で、調べても、 Taifatech Inc. Announces PC2HDTV Full HD Interactive Solution that Goes Beyond Wireless Displayという記事ぐらいしかヒットせず、他は、oui の情報程度。リリースには、「@taifatech.com」というドメイン表記はあり、whois をしてみたところ、失効した形跡は無いが別物のように見える。情報がなさすぎる。ということで、nmapによる追試験を行ってみると、次のような結果に。

どちらもHTTPがあいている様子。というこことは、ブラウザでアクセスするに限るということ。

ここでファームウェアの更新も、IPアドレスの変更も出来るようで、また、Uart Bpsとあることから、内部におそらく、シリアルコンソールがあると思われる。そのため、ここで触ると、何か楽しいことがあるかもしれない。尚、Tx/Rxおよび、モデルによっても全く同じWebUIであったため、891 Txのみのスクリーンショットとしている。

なお、HTTPを手で叩いてみたところ、httpd の finger print など何も返さなかったので、さらに追試験してみると、次のような結果に。

sh-3.2# nmap -p 80 -O 192.168.168.56
Starting Nmap 7.70 ( https://nmap.org ) at 2018-08-18 22:42 JST
Nmap scan report for 192.168.168.56
Host is up (0.00074s latency).

PORT STATE SERVICE
80/tcp open  http
MAC Address: F0:0C:0C:00:00:80 (Unknown)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: proxy server
Running: Blue Coat embedded
OS CPE: cpe:/h:bluecoat:packetshaper
OS details: Blue Coat PacketShaper appliance
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.08 seconds
sh-3.2#

明らかに、このOSは間違っているだろう。尚、HDMI Extender の起動は数秒で終わっているため、組み込みLinuxとも違うのか。謎である。

さらに調べていたところ、HDMI Extender は IP Multicast なので、vlc などで拾うことが出来ないか実験、調査していたところ、下記のような情報が。

考えることは同じだ。環境を作れば、パケットを拾い、PCでキャプチャすることも可能のようだ。

ローカルの試験は完了したので、L2遠伸で遠くの拠点に映像を伝送しようかとおもうが、チューナーは一カ所においてあるため、NHK対策にちょうどよい。NHKは放送の受信機を設置した場所に取り立てにくるとのことなので、こういった映像だけ伝送する場合は対象外だ。NHK対策に、実家にチューナー、拠点にモニタ+HDMI Extenderによる映像の伝送などを試してみるとよいかもしれない。

さらに最近は、インターネット回線に対して、頭の悪いキチガイ集団は、課金をしようとしているようだが、専用線を調達して一カ所から集中のゲートウェイを作れば、インターネットとしての契約は1つで済むので、この問題も解決出来るだろう。
キチガイ対策に検討を祈る。

[ コメントを読む(0) | コメントする ]

[Internet] Ad DNSブロッキングおよび、kawango DNSブロッキングの実装をしてみたら、超快適だった

ちまたで、kawangoが暴れているDNSブロッキングというネタがあり、元々実装を検討していたものについて、便乗してみました。
アドDNSブロッキング最高!!

前置きはよくて、本題。
iPhoneを生活環境で使用しているが、電車の中でネットサーフィン(死語)をしていると、あまりにも広告がうざく、スクロールを行おうとしたところに広告や動画が流れ、閉じようとしても、閉じるボタン小さく、誤爆でクリックを狙うような、悪質なモノが非常に多い。私は、MVNO SIM + WiFiで使用しているため、容量も3GB程度しかなく、糞みたいな広告で通信料および、お金が擦り落とされるのが非常に腹正しく、何かする方法がないか考えていた。もちろん、部屋でゴロゴロとしてPCでネットを見ていても、広告があまりにもうざく、嫌気を指していたので、対処するべく実装に至った。そのほか、 @kawango2525の頭の悪さに、こいつの関係するサイトもブロッキングする実装とした。

仕込んだ結果こういう様子。すっきりすっきり。テスト用に用意した端末で見比べて欲しい。これほどすっきりする。


ハムスター速報


はちま寄稿


PCブラウザでいくつか。こちらは広告が出ないはず。


どうだろう、すっきりしているかと思います。モバイルの時は、LTEやモバイル用WiFiルータ等で使うときは必ずといってもいいぐらいVPNで生活しているので、必ずこの恩恵を受けれるので、とてもすっきりします。最近だと、mineoの糞仕様で、画像の劣化をさせるといった愚行もあり、こういった影響も受けません。
また、adblockなど、ブラウザのプラグインや拡張機能に入れる方法もありますが、これはこれで、ブラウザが重くなるなど、なるべく使用したくはないのです。ただ、URI単位でのブロックが出来ないので、やはり、そこは3rd partyに任せる必要はありますが、ずいぶんすっきりします。

実装方法は簡単。家の中は、ADがあるが、個別に制御は厳しい為、AD管轄以外は、forwarder に指定し、unbound を参照させることとして、unbound をフルリゾルバとして構成した。個別にhostsファイルとして配布しても結果、127.0.0.1 とし、local port があいていないため、refuse させることにより、結果同じものが得られるが、すべての端末に配布が必要となること、メンテナンスが容易ではないこと、モバイル端末では適用できないといった事から、DNSブロッキングを採用した。

いくつか自前で生成を行い、まとめサイト、アダルトサイト、各企業のサイトなど訪問し、DNSのquery log の記録、および、閲覧し、HTMLの確認等を行い、目立ったサイトを個別に設定。その上で、外部のリストに頼ることにしました。
外部のサイトで、都合のよいリストとして、 280blockerというサイトがあり、ここで、リストを配布しており、これを、unboundに仕込めばOK。awkを使用すれば、ワンライナーで、生成も出来る。

unbound.conf
---
include: "/etc/unbound/blocking.conf"
---
tomo@ns4:/etc/unbound$ cat blocking.conf
# tomocha custom
local-zone: "spcdnpc.i-mobile.co.jp." static
local-zone: "fpc.googlesyndication.com." static
local-zone: "tpc.googlesyndication.com." static
local-zone: "googletagservices.com." static
local-zone: "googlesyndication.com." static
local-zone: "adservice.google.co.jp." static
local-zone: "adservice.google.com." static
local-zone: "asg.to." static
local-zone: "mediad2.jp." static
local-zone: "dtiserv2.com." static
local-zone: "aimg.fc2.com." static
local-zone: "ane.yahoo.co.jp." static
local-zone: "rd.ane.yahoo.co.jp." static
local-zone: "ard.yahoo.co.jp." static
local-zone: "ad.noahpass.jp." static

#kawango
local-zone: "dwango.co.jp." static
local-zone: "dwango.jp." static
local-zone: "nicovideo.jp." static
local-zone: "nicovideo.com." static

local-zone: "XN--TCK4B396VYDP.JP." static
local-zone: "XN--TCKA4EB0270EBXWA.JP." static
local-zone: "XN--K8J9A3DWB6G12A.JP." static
local-zone: "XN--BCK9A3DWB6G0D.JP." static
local-zone: "XN--UCKYBYGQA.JP." static
local-zone: "DEHOGALLERY.CO.JP." static
local-zone: "DWANGO.NE.JP." static
local-zone: "DWANGOCONTENTS.CO.JP." static
local-zone: "JNCA.OR.JP." static
local-zone: "KADOKAWADWANGO.CO.JP." static
local-zone: "MAGES.CO.JP." static
local-zone: "NIWANGO.CO.JP." static
local-zone: "NNN.AC.JP." static
local-zone: "PEDIANEWS.CO.JP." static
local-zone: "VIRTUALCAST.CO.JP." static
local-zone: "NICOBLOG.J.P" static
local-zone: "BLOMAGA.JP." static
local-zone: "NICOBLOMAGA.JP." static
local-zone: "NICOCAS.JP." static
local-zone: "NICODRM.JP." static
local-zone: "NICOSEIGA.JP." static
local-zone: "IKEBUKUROCOSPLAY.JP." static
local-zone: "M-SC.JP." static
local-zone: "SIMG.JP." static
local-zone: "KADOKAWADWANGO.JP." static
local-zone: "N-JUKU.JP." static
local-zone: "FSMILE.JP." static
local-zone: "NICOMATOME.JP." static
local-zone: "COSPLAYAGENCY.JP." static
local-zone: "NICONICO.JP." static
local-zone: "NICOHONSYA.JP." static
local-zone: "DENOU.JP." static
local-zone: "ASCIIDWANGO.JP." static
local-zone: "NICOFARE.JP." static
local-zone: "NICOFERRE.JP." static
local-zone: "NICOFALLE.JP." static
local-zone: "NIKOFARE.JP." static
local-zone: "NIKOFERRE.JP." static
local-zone: "NIKOFALLE.JP." static
local-zone: "D-UE.JP." static
local-zone: "POLICYWATCH.JP." static
local-zone: "NICOFARLE.JP." static
local-zone: "SMILEVIDEO.JP." static
local-zone: "ARTILIFE.JP." static
local-zone: "CELL-NET.JP." static
local-zone: "NICOMOBA.JP." static
local-zone: "KA-DW.JP." static
local-zone: "CHOKABUKI.JP." static
local-zone: "TWOFIVE-IIV.JP." static
local-zone: "BIGFENCE.JP." static
local-zone: "NICOGAME.JP." static
local-zone: "NICOAPP.JP." static
local-zone: "ENGAGEPRINCESS.JP." static
local-zone: "NICODIC.JP." static
local-zone: "EIOU.JP." static
local-zone: "NICOGA.JP." static
local-zone: "J-AFILIA.JP." static
local-zone: "CUSTOMCAST.JP." static
local-zone: "NIWANGO.JP." static


# 280blocker.net by 2018.07.30
# https://280blocker.net/files/280blocker_host.txt
略

static なのは、 Unbound,知ってる? この先10年を見据えたDNSunbound.conf(5)を参考に、「NXDOMAINかNODATAを返す」とある。 厳密には、

ローカル データに一致したら、クエリーに回答します。一致しないときには、クエリーに対してnodataあるいはnxdomainを回答します。ゾーン頂点ドメインのlocal-dataとして存在するときには、否定回答として回答にSOAが含まれます。

とあり、今回、local-zoneのみの定義のため、nodata もしくは NXDOMAINを応答しています。drop してしまうと、応答しなくなり、いつまで経っても表示されないことから、NXDOMAINを応答するように仕込でいます。

ところで、 NNN.AC.JP(学校法人角川ドワンゴ学園) 登録日:2018/07/03ってなんじゃ?また怪しいこと始めるのかな?

結果、とても快適。また、iPhoneなどで、からなずVPN経由でネットサーフィンをしているため、VPN先のリゾルバを参照しているため、もちろんこの影響は受けない。
280blockerは商用利用はNGなので、自前でリストを整備し、さくらのVPSでDualStackで実装、IPv4/IPv6ともにVPN/トンネルで応答できるようにして、サービスをすれば、IPoE環境からアクセス出来るようにすれば、PPPoE輻輳問題の解消、また、広告DNSブロッキングも平行して、使用出来、快適かもしれれないので、こういったサービスを始めるとよいかもしれない。作るのは簡単。運用と決済システムを考えないと事業にならないから、ちょっと面倒かな。

まあ、このあたりでDNSまで仕込めば、完璧。 さらに、モバイルからアクセスする環境として、OpenVPNや、 SoftEther VPN オープンソース版などを組み合わせて使うとよいかな。そうすると、簡単にL2TP/VPN環境が構築出来る。

 さくらのVPS で IPv4 over IPv6ルータの構築

あ、 さくらのVPSで実装するときは、 このリンクから、おねがいしやす!生活かかってるんで!
IPv4/IPv6 DualStackで気軽に使えるのは、他はConoHaぐらいかな。ただ、GMO嫌い。

ということで、Ad DNS ブロッキングリゾルバプロジェクト的なモノをつくって、実証実験しませんか。もしくはそういうオプションサービスをISPで始めると面白いかもしれませんね。そういう会社いないっすかね。

[ コメントを読む(0) | コメントする ]

[TV][Internet] FODが見れない! Ad DNSブロッキングの弊害

DNSブロッキングされた環境で、FODを視聴しようとすると、かなりの広告がブロックされているのがわかる。
データー量にして、相当なモノだろう。また、フレッツのPPPoE輻輳などで、昨今話題のなかで、見もしない広告は、無駄なトラフィックを発生させ、悪害以外何でも無い。

だが、本編開始をしたところで、始まらない...


おそらく、FODのCMがDNSブロッキングにより、ブロックされたため、CMが再生出来ず、次に進まないという実装だろう。
Error になると、次に進まないという仕様であれば、いつまでたっても視聴出来ない。さあ、FODに問い合わせでいつまで経っても視聴できないといじるのもヨシ。 配信が終わるといって、意地悪な問い合わせをしてみるのもヨシ。

外部リストを使い、自動更新をしているため、レコードをコメントアウトしても一時しのぎにしか過ぎないので、解消方法を探す。探す方法として、HLSのchunkfileを探し、tsファイルを wget して、直接再生する方法も考えたが、著作権保護の為、ライセンスが無いとそのままでは視聴出来ない。 ffmpegなどを使い、ライセンスファイルを喰わせて、デコードすれば、目的は達成できるかもしれないが、保存が目的では無いこと、複雑なことをしないといけないので、この手法は対象外。
とはいいつつも、まずは、Chromeの標準のデバッグツール(F12)を使い、リクエストのあったファイルをしらべ、そのなかから、「chunklist.m3u8」というのを探す必要はある。



中身はテキストファイルで、下記のような内容。

$ w3m -dump_source https://fod-plus7.hls.wseod.stream.ne.jp/www08/fod-plus7/_definst_/mp4:video645810020me1134f43.mp4/chunklist.m3u8 | head -n 20
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:17
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="https://fod-plus7.hls.wseod.stream.ne.jp/www08/fod-plus7/_definst_/mp4:video/56789/5645/5645810020me1134f43.mp4/key.m3u8key"
#EXTINF:16.016,
media_0.ts
#EXTINF:16.016,
media_1.ts
#EXTINF:16.016,
media_2.ts
#EXTINF:16.016,
media_3.ts
#EXTINF:16.016,
media_4.ts
#EXTINF:16.016,
media_5.ts
#EXTINF:16.016,
media_6.ts
#EXTINF:16.016,
$

この場合は、chunkfile.m3u8 からみて、相対パスに、media_0.ts 〜 のファイルがあると言うこと。このあたりは、前項のスクリーンショットにもあるが、これを連続してつなぎ合わせて、動画を再生される。サーバー側の実装としては、httpd が上がっておれば、何でもよく、サーバー側で対処をしなくてもよいというメリットがあり、スケールアウトさせやすいことから普及したと私は思っている。ただ、http で chunkfile を 取得出来ると言うことは、そのファイルに対して保護が出来ないことから、ライセンス情報を別に組み合わせる必要があるのだろう。また、この「EXT-X-KEY:METHOD=AES-128,URI=」にあるURIが暗号化された鍵の様子。セットでgetしておいてもよい。

技術的背景はこの程度にしておき、簡単に視聴する方法があり、ごくごく一般的な汎用動画再生プレイヤー VideoLAN(VLC)を使っえばよい。これは、HLS Streamingにも対応し、著作権保護にもきちんと対応しているため、なにもしなくても視聴が可能であった。このFODも例外では無い。
VLCは各OS、ディストリビューション毎に配布されているオープンソースのプレイヤーで、多岐にわたる環境で視聴可能だろう。ブラウザみたいに負荷も高くなく、快適に視聴できるはずだ。

起動して、URLをペーストするべく、Ctrl + V と叩くと、ネットワークストリームを開く事が出来る。メディアから開いてもよい。


そうすると、簡単に再生ができること、広告も入らないし、このままテレビなどに映像転送をしてもよいだろう。非常に利便性がよくなった。


さらに、配信元のサーバーから、HLS Stream 用のchunkfileは公開停止後しばらくファイルが残っているため、URLさえメモをしておくと、しばらく視聴が出来るようだ。これは、ブラウザで一度開いておき、放置していても、一定期間見れるのと同じで、猶予期間を設けているのだと思われる。出張などで見れない場合の見逃し再生として非常に重宝するので、とてもありがたい。ちなみに、VLCにはストリーミングの保存機能もあるようなので、使ってみると面白いかも。

余談: 朝起きれず、かつ、HDDレコーダーの空きが無く録画をし忘れたため、FODで見逃し放送をみようとしたところ、はまってしまったので、この記事を書きました :)
さらに、ffmpeg をうまく使えば、暗号化された動画をデコードできるかもしれませんが、今回の目的の趣旨と外れるため、紹介はしません。

[ コメントを読む(0) | コメントする ]

Diary for 1 day(s)
Powered by hns HyperNikkiSystem Project




(c) Copyright 1998-2014 tomocha. All rights reserved.