back to TOP

admin |  RSS
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

M.2 (エムドットツー)(旧称 Next Generation Form Factor, NGFF) は、コンピュータの内蔵拡張カードのフォームファクタと接続端子について定めた規格である。 - M.2|Wikipedia



Intel 9シリーズチップセット搭載マザーボードから徐々に見かけるようになったM.2ソケット。

気付けば、ノートPCのWifiカードまでもminiPCIe接続のWLANからM.2接続に変わっていました。
実装密度的にはM.2の方が細かく、柔軟性も高いので近年のデバイスの小型化には貢献しているのかと。

という前置きはどうでもいいとして、本題はM.2ソケットのKeyIDと呼ばれるものです。

これはM.2ソケットが、SSDからWifiカード、WigigやGPS、Bluetooth、WWAN等の拡張インターフェイスの全てに対応可能なように作られているため、KeyIDで使用可能なデバイスを指定しましょう、というもの。

因みにこれは仕様上のものであり、換装しようとしてもBIOSの制限であったり、USB結線が無かったり、ということもあるので注意。

現状、市場で見かける製品は、A,B,E,Mkeyの四種類。
Keyの位置はソケット側から見て、右からA-Mの順。

分かりやすいように、M.2→miniPCIeの変換カードを作っているメーカーの表をお借りします。
引用元:ビープラス・テクノロジー http://www.hwtools.net/Adapter/M2MP1-jp.html

M2keyID.png

ここにはNVMe接続のSSDが載っていません。
NVMe接続ののSSDはMkey(ソケット左端)です。

Z97-A.jpg

現在販売されている一般・自作向けのマザーボードのM.2ソケットはほぼMkeyです。

NVMe接続のSSDはMkeyのみを持つのに対して、SATA接続のSSDはB+Mkeyなので、SSDならどちらでも挿せる、ということですね。

ノートやタブレットでは、SATAのみしか使えない(ソケットBのみ)、みたいなこともあります。

また、インテルワイヤレス製品選択ガイド
http://www.intel.co.jp/content/www/jp/ja/wireless-products/wireless-product-selection-guide.html

見ていると、Wigig対応+Wifi+BTの
Intel® Tri-Band Wireless-AC 18265
Intel® Tri-Band Wireless-AC 17265
s-l1600.jpg

は、
Wifi+BTのカード
Intel® Dual Band Wireless-AC 8265
Intel® Dual Band Wireless-AC 8260 http://amzn.to/2eUZu6e
Intel® Dual Band Wireless-AC 7265 http://amzn.to/2eV2Je1
Intel® Dual Band Wireless-N 7265

にあるEkeyがありません。

BTにUSB2.0、WifiにPCIeを1レーン、WigigにPCIeを1レーン使う都合上(且つKeyAの”Displayport”)?でしょうか。

錯覚で長さが違うように見えますが、長さは一緒です。
結論として、タブレットPC等で、Ekeyならば、Wigig非対応、Akeyならば可能性アリ!ということです。
Wigigのドックはまだ高いので、802.11adの普及が楽しみです。

参考までに、Venue11の7130はEkey、7140はAkey。(7140の横幅的に3030を刺すのは厳しそうですが。)

にしても802.11acのカード安くなりましたね。
Wigig対応のカードは横幅が広いので(8265は2230,18265は3030?)要注意。

さらにWWANカードはBkeyで、USB接続のみを使用するようです。
ANT30MOやME906J等。

おや、BkeyのスロットにUSB接続の機器を突き刺せそうですね・・・?

スポンサーサイト
Cable4k1.png
自宅はCATV局(イッツ・コミュニケーションズ)の地上波パススルーが導入されており、安定した録画生活が送れている。
※BS・CSは屋根上アンテナからの混合であり、BSCSパススルーではない。勿論トラモジ”でも”配信されている。

チャンネルはNHK-G、NHK-E、NTV、EX、TBS、TX、CX、MX、TVKと、田舎に比べるともうこれだけで十分であるのだが、
サービスの解説によれば、チバテレビとテレビ埼玉がトランスモジュレーション方式で区域外再放送されている。

CATVのSTBにB-CASとC-CASが入ってることからわかるように、B-CASで処理するチャンネルと、C-CASで処理するチャンネルがある。
トラモジチャンネルは全てC-CASだと思っていたのだが、地上波とBSチャンネル(一部の、110度衛星全てではない)に関してはB-CASで処理しており、加えてそれぞれのカードによってPCで録画できるようだということが人柱の皆様のお陰で分かった。

※B-CASで処理していても、俗称STB-IDチェックと呼ばれるブロックが有り、BS放送に関しては、”チューナー側”で見られなくする処理が行われる(頻度も可能性もCATV局によって異なるらしい)。
これはチューナーの独自実装であり、B-CASの通称毒電波とは異なるので、PCのチューナーであれば無関係ではないかという予想ができる。(追記、約半年、PCチューナーでブロックされることはありませんでした。)

この件に関して、STBの上り回線(10-55MHz)が関係あるのか、と思ったが、C-CASと紐付けられたSTB-IDでなければ弾く、ということのようで、ケーブルモデムも無関係のようです。
(ITU-T J.112 annexB他DOCSISに非対応(=ケーブルモデム非搭載)のSTBも多数存在する)

まずはCATV、ついでにスカパー光ではどういう方式で運用されているのか、スカパースレに書いた内容を転記しつつ。
スカパー! プレミアムをPCで視聴 18©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1472610075/
※間違いもあるだろう、推測も多いので参考までに…



IP伝送=DOCSIS3.0/3.1=MCNS=スカパー光?=ITU-T J.112 Annex.B
※スカパー光は、MCNSドライバで動いているという報告があります。

結論から言うと、以下のようになります。
DOCSIS=MCNS∋ITU-T J.83 annex.B=スカパープレミアム光

何故なら、チューナーカードの、識別がDVB-C(J.83のA、C)とMCNS(J.83のB)と分かれていたから。

CATVのRF伝送の規格と統合すると以下のようになります。

→J.83 Annex.A=DVB-C //欧州
→J.83 Annex.B ∈MCNS //米国
→J.83 Annex.C=ISDB-C //日本

日本のCATVの”放送”はISDB-Cで運用され、シンボルレートは5274、ほぼ64QAMで運用され、256QAMまで存在する模様。

調べていて気が付きましたが、DOCSIS=ITU-T J.112 Annex.Bというのは間違いのようで間違いではないみたいです。
DOCSISといえば、ITU-T J.112 Annex.Bを”一般的に”指し、J.112の付帯規格(Annex.A/B/C)がそれぞれ、欧州、北米、日本の仕様となっているというのだ。
さらにJ.112 Annex.BはDOCSIS1.0であり、DOCSIS2.0はJ.122、DOCSIS3.0はJ.222に規定されている。ややこしい。

というわけで、J.83が放送の変調方式について規定したもの(=物理層)、J.112が双方向通信(DOCSIS)の規格で、それぞれの付帯規格が対照になっている、とのことのようだ。
※J.112の物理層はJ.83に規定されているものを利用する

で、IP(Internet Protocol)方式とRF(Radio Frequency)方式は、前者は映像信号を”パケット化”、後者は”変調”して送り届ける。
即ちスカパープレミアム光含めて、放送はRF方式。(物理的な同軸/光は無関係)



確認の為、ケーブルモデムを取り外して、周波数帯、シンボルレートを調査してみました。

CATV7.pngCATV8.pngCATV9.png

そう、インターネットとVODに関しては、シンボルレートが”5360(256QAM)と5057(64QAM)”と、まさにAnnex.Bの規格。
放送に関しては、シンボルレートが5274、即ちAnnex.C。
結局日本仕様の規格は作ったものの、DOCSISのインターネット機器に関しては、国内で開発せず、北米版を導入した、ということのようです。

※画像で二箇所16QAMとなっていますが、信号星座図を見ればわかるように、どう見ても256QAMと64QAMです。(MCNSのモードでも同じ認識だったので、まぁなんかの間違いでしょう。)

余談ですが、6MHzの帯域幅でSRが5360の256QAMの波は8つありました。
DOCSIS3.0はチャンネルボンディングで異なる帯域を束ねることができ、現時点でのインターネットサービスは最大160Mbpsのプランまで提供されています。計算すると4つの帯域を束ねていることになりますね。(42.88Mbps*4≒160Mbps)
理論上320Mbpsも可能ですが、利用者ごとの速度を担保するためにはこれが最適なのでしょう。

詳細な周波数とチャンネル対照表は後ほど別の記事にする予定です。

さらに余談。
→ITU-T J.382=DVB-C2
4K8K等次世代の方式となり、複数搬送波を使用するISDB-Cの次世代規格(NHK方式、(TSMF: ITU‐T J.183の拡張)との競合。
どちらが採用されるのかはわかりません。J:COMは両方でテストしたようです。
ニュース記事などを見ていると国際標準のJ.382が優勢か。

追記:JCTEAの2017年の資料によれば、2014年12月、「J.382/6MHz仕様を有線一般放送の伝送方式として採用した」とのことです!チューナーだけはなんとかなりそうですね。

2017/7追記:ケーブル技術ショーによれば、J.382方式は実際CN比不足で問題があったことから、日本では複数搬送波伝送方式のJ.183拡張方式を軸に進めていくこととなったそうです。
J.382を導入するために同軸を交換するくらいなら、FTTHで3.2GHzまでのBSCSパススルーを実施することになるだろう、とも仰っていました。
実際展示されていたモジュレーターも住友電工様、日本通信機様、ミハル通信様などすべてJ.183拡張方式のみでした。


参考資料:
J.83 ANNEX C(ケーブルテレビシステム委員会報告概要(案))
ケーブル伝送路の高度化|日本ITU協会
J.112 Annex B|ITU
ITU-T SG9における4K/8K関連標準化動向



PanasonicのSTBのページ
TZ-LS300PW/TZ-LS300P/TZ-LS300F
を見ると
デジタル放送 受信変調方式:64QAM(Annex.C)
ケーブルモデム 受信変調方式:64QAM/256QAM(Annex.B)
とありますので、上がITU-T J.83 Annex.C、下がAnnex.Bということで間違いはなさそうです。



と、ここまで書いてきましたが、CATVの”トラモジチャンネル”をTS抜きするにはどうすれば?と言う話です。

参考:
PCでケーブルテレビのCSを視聴・録画する方法 - NAVER まとめ
http://matome.naver.jp/odai/2142756819904448701

基本的にDVB-Cの派生なので、大抵大丈夫だと思いますが、正確にはJ.83 Annex.C対応のチューナーが必要です。
海外のサイトでは、ISDB-Tの表記はありますが、ISDB-Cの表記は見かけないので注意が必要です。

買うとすれば、TBS Technologiesか、ドイツのDigitalDevicesがオススメです。
他のメーカーのも色々と購入しましたが、安定動作はしていません。また別記事で…。




この記事を書いている現在、EDCB、Spinel導入などはまだ終わっていないのですが、とりあえず、
”サービスチャンネルリストに存在しないはずのチャンネルの波が存在した”ことだけ報告しておきます。

Cable4k1.png
Cable4k2.png
atx.png

というわけで、続きます。
 LINE LIVE を眺めた  2016/10/01 (Sat)
WM2Bl_iA.png
こんばんは。内容は保証しません、というかただのメモ。
6月に調べて諦めてた案件です。

FRESH by AbemaTV を眺めた
http://nyarudiary.blog.fc2.com/blog-entry-102.html
FRESH by AbemaTV をもう一度眺めた(仕様改変に対応する)
http://nyarudiary.blog.fc2.com/blog-entry-107.html

の派生、というかLINELIVEバージョン。いつも通りffmpegを使用していきます。録画・保存用に。

PCで見れるタイプのものは、ブラウザの通信を監視していれば
http://lss.line-cdn.net/p/live/超長いハッシュ/720/chunklist.m3u8
みたいなのが降ってきますので、そのまま投げればOKです。

他の解像度が欲しい場合、同時に降ってくる
https://lssapi.line-apps.com/v1/live/playInfo?contentId=live/ba/番組ハッシュ(LIVEの場合)
https://lssapi.line-apps.com/v1/vod/playInfo?contentId=live/ba/番組ハッシュ(VODの場合)
live/pba/XXXというのもありますが、何故分けているのかは不明。個人/企業(チャンネル)ではなさそうです。

LIVE配信の場合、上の中身は

{
"type" : "live",
"playUrls" : {
"abr" : "http://lss.line-cdn.net/p/live/XYZ(例外)/abr.m3u8",
"144" : "http://lss.line-cdn.net/p/live/XXX/144/chunklist.m3u8",
"aac" : "http://lss.line-cdn.net/p/live/XXX/aac/chunklist.m3u8",
"720" : "http://lss.line-cdn.net/p/live/XXX/720/chunklist.m3u8",
"480" : "http://lss.line-cdn.net/p/live/XXX/480/chunklist.m3u8",
"360" : "http://lss.line-cdn.net/p/live/XXX/360/chunklist.m3u8",
"240" : "http://lss.line-cdn.net/p/live/XXX/240/chunklist.m3u8"
},
"imgUrl" : "https://scdn.line-apps.com/obs/r/live/ba/番組ハッシュ__lastscene.jpg",
"snapshots" : null
}


※生配信のabrだけハッシュが別
→生のabrにはスマホユーザーが集中するからだろうか?
配信終了後は

{"code":40,"message":"not found live streaming."}


VODの場合は

{
"type" : "vod",
"playUrls" : {
"abr" : "http://lss.line-cdn.net/vod/XXX/abr.m3u8",
"144" : "http://lss.line-cdn.net/vod/XXX/144.m3u8",
"aac" : "http://lss.line-cdn.net/vod/XXX/aac.m3u8",
"720" : "http://lss.line-cdn.net/vod/XXX/720.m3u8",
"480" : "http://lss.line-cdn.net/vod/XXX/480.m3u8",
"360" : "http://lss.line-cdn.net/vod/XXX/360.m3u8",
"240" : "http://lss.line-cdn.net/vod/XXX/240.m3u8"
},
"imgUrl" : "https://scdn.line-apps.com/obs/XXXXXX/f960x540",
"snapshots" : [ {
"url" : "http://lss.line-cdn.net/img/XXXXXX",
"posSec" : 500
}, {
"url" : "http://lss.line-cdn.net/img/XXXXXX",
"posSec" : 1500
}, {
"url" : "http://lss.line-cdn.net/img/XXXXXX",
"posSec" : 2500
}, {
"url" : "http://lss.line-cdn.net/img/XXXXXX",
"posSec" : 3500
}, {
"url" : "http://lss.line-cdn.net/img/XXXXXX",
"posSec" : 4500
} ]
}


※VODは複数のサムネが生成されるようだ。

となっており、abr(Adaptive BitRate streaming用?)他、5種類の解像度+音声が定義されていました。
6月時点では音声のみのストリーム(aac)は無かったので、ラジオ向きの改善、ってことなんでしょうかね。

Fresh by AbemaTVの場合、”番組ID”はURLから見つけられますが、LINLIVEの場合はちょっとややこしい。
一応ここでは番組IDならぬ番組ハッシュとでも呼びましょうか(今更。

ここでちょっと一息、"LINE LIVEアプリ 友だち限定公開"というものについて。

PCブラウザでは以下のようになるので見れない。LINELIVEのアプリ入れる為には他人の個人情報まで売らなきゃいけない。
いやまぁ、LINEを入れてる時点で変わりはないのかもしれませんが、無駄にスマホで見る必要無いですよね。
スマホのメリットとしてはコメントが見れる、打てる、くらい。
公式的にPCで見れないというのは致命的なので改善すべきだと私は考えます。
1_20161011223323de3.png

閑話休題。というわけで

\生放送中に/

https://live.line.me/r/channels/チャンネルID/broadcast/番組ID

<meta property="og:image" content="https://scdn.line-apps.com/obs/r/live/ba/番組ハッシュ__lastscene.jpg/f960x540">

見つけた。つまりLIVE中ならメタデータ(OGP=Open Graph protocol)から番組ハッシュをコピーしてplayinfoを得ることが出来るってことだ。
アプリ限定公開でもここは変わりません。

\放送が終わると/

<meta property="og:image" content="https://scdn.line-apps.com/obs/XXXXXX/f960x540">
に変わっていた。これは番組IDではないようだ。

まぁアーカイブが公開されていればplayInfoは多分降ってくるのでわざわざ調べる必要もないですね。
非公開・限定公開の場合も番組ページにヒントが有りますので頑張って探すと良いかと。反転ヒント。


→”data-broadcast”
本当は全部これで良いんですが一応お察し下さい。
→番組ページが消えていたらGoogle他のキャッシュを当たるとOK。大抵何処かのロボットが巡回してます。

最後に保存編。
/720.m3u8、または/720/chunklist.m3u8
中身はこんな感じ。
無題
音声のビットレートはFresh by AbemaTVより高めのAAC(LC) VBR192kbps/22.05KHz。
映像H.264_AVC BP@L4.1、VBRでMax.2200kbps、Freshより低め。
可変フレームレートなのは同じ。Baseなのか…とも思いますが幅広く、という点では良いかと。
まぁ配信者がスマホからだったりするので大して意味は無い。

というわけで先程のplayinfoで得られたメディアプレイリストをffmpegに投げて保存完了。
MPEG2-TSコンテナの仕様の違いによりそのままtsで保存すると多分シークに失敗します。

ffmpeg.exe -i "http://lss.line-cdn.net/p/live/XXX/720/chunklist.m3u8" -c copy -bsf aac_adtstoasc out.mp4


ffmpeg.exe -i "http://lss.line-cdn.net/vod/XXX/720.m3u8" -c copy -bsf aac_adtstoasc out.mp4



ストリーミング対応にするなら、-movflags faststartをつける。

追記:一部修正しました。各種配信メディアはユーザーの取り合いで本当に大変そうです。LINELIVEはオタク配信向けでは、ない、ですね。
ブートドライブを作るときに、今まで使ってきて失敗したことがないソフト、その名も
「Windows 7 USB/DVD Download Tool」

Microsoft純正だし日本語も標準、そして安定感。

で、WindowsのISO(ディスクイメージ)が必要なわけですが、
Microsoftから普通にダウンロードすることが出来ます。

とはいっても、普通の操作ではアップグレードツールを使え、ということなのか、
ISOをダウンロードすることは出来ません。

ということで、
https://support.microsoft.com/ja-jp/help/15088/windows-create-installation-media
にアクセス。

そしてブラウザのUserAgentをAndroidスマホ等に変更して、上記ページ下部のWindowsバージョンを選択すればISOがダウンロード出来ます。

おわり。

※Windows7の場合は”ダウンロード時に”プロダクトキーの入力が必要。
Powered by FC2ブログ
Copyright © rencontRe Lab All Rights Reserved.