vol42. Quitaについて調べてみた

疑問

何か技術情報を調べるためにググると、最近はよくQuitaのサイトに投稿されている記事 がヒットする。

「Quitaって何だろう?」
「Quita はエンジニアに評判がいいと聞くけどなんでだろう?」
「なんでみんな技術ネタはQuita に投稿するの?」

ふと疑問に思ったので、Quitaについて少し調べてみた。

Quitaは

  1. 日本で最大のプログラマーコミュニティー

    ユーザーはプログラマ。彼らは、クラウドに技術情報を投稿し、

    • 言語化することで自分の知識を整理
    • 自分の備忘録
    • 他者にも最大限貢献したい という目的を果たしている。
  2. 再利用可能な技術情報共有サイトというコンセプトに則って、サイトが設計されている

    • 情報の取得がしやすい仕組みを整えている。(フォローやストック、ニュース フィード機能など。)

Quitaの概要

  • プログラマの技術情報共有サービス
    • プログラミングに関する様々な知識を ユーザー同士が活発に共有
    • ユーザーは、プログラマーが中心
      • 97%が日本国内(都内から約半数)からのアクセス、男性が91.4%をしめる
    • 2016年時点で日本最大のプログラマーコミュニティとされている
  • 2011年にQuita を開発、公開
  • 運営は、Increments
    • 2017/12にエイチームの完全子会社に
    • ミッションは「エンジニアを最高に幸せにする」

Quitaの特徴

  • 再利用可能な知識の保存が目的
  • ニュースフィード
    • エンジニアに特化した
  • フォロー
    • 興味のある言語をフォローできる
  • ストック
    • 興味のある記事をストックし、後で閲覧できる

感想

確かにQuitaのサイトを覗いてみると、UIは情報を検索するのに、使いやすそうな印象を受ける。 日本のエンジニアを応援するようなサービスが増えるのは、1エンジニアとしても嬉しい。

海外ではみな技術ネタはどこに投稿するんだろう? 今度しらべてみよう

vol41. home theater room をつくろう

https://4.bp.blogspot.com/-RCQZkNkDQyM/WOdD2he7-UI/AAAAAAABDmk/VVOWD2QL22ITGLmLFl-i8KLR8JVhwYaigCLcB/s800/projector_home_theater.png

ミシガン州に住みはじめてはや1年経過。移住当初は文化の違い、言葉の違いに色々大変
な思いもしたが、最近は、ようやく余裕もでて日常生活を楽しめ始めるようになってきた

一軒家を賃貸しているのだが、アメリカの家には、地下室があるのが一般的。
finishされていない家も多数ある中、幸いなことに、我が家の地下室は物置場とfinishさ れている部屋が一つある。

これまで地下室はほとんど利用されず、たまに子供の遊び場として利用したのだが、家族が 子供の夏休みを利用して帰国し、自分の時間を確保できるようになったため 、このチャンス を逃すものかと、この部屋を念願のhome theater room にすることにした。

地下室のtheater roomは、涼しいので夏はとても快適。大音量を出しても、1階には多少音 が伝わるかもしれないが、寝室のある2階までには迷惑かからないので、真夜中にも好き な映画が音楽が楽しめる。

TVはリビングで使っていた55inch のSHARPのTVを移動、あとは、PS4とDVD/Blueray player (アメリカではregionが日本と異なるため、PS4アメリカのDVDは見れない。 Bluerayはregion freeなため視聴可能)を地下に移動する。あとは、音響だ。理想はもち ろん7.1ch !!

調べ始めると、アンプは思ったよりも安価で手に入る。

  • アンプ
    • Yamaha RX-V583
      • 7.1ch
      • $329
      • airplay 対応
      • Dolby Atmos/DTS:X 対応

www.amazon.com

あとはスピーカーだけど、ググるとうわーめっちゃ高い。一つのスピーカーに5万も払えないよー
。どうしようー。でいろいろ調べてみると、以下のやつが手頃で良さそう。まずはこのエ
ントリーモデルのやつから初めて、もし欲が出て来たら少しずつ買い足していこうかな。

  • Speaker
    • Yamaha NS-SP1800BL 5.1ch
      • $149

www.amazon.com

この世界は本当に「底のない沼」世界で、追求すればするほど、お金が湯水のようにとん
でいくみたい。スピーカー一つに何十万円もかけるらしいので気をつけなくては。。

vol40. RTP関連のRFCたち

RTPにまつわるRFCの内容を整理してみた。

RTP(Real-time Transport Protocol)。音声や動画などのデータストリームをリアルタイ ムに配信するための、通信プロトコル。でも、どういう仕組みで、リアルタイムを実現し ているのか?

RTPはアプリケーション層のプロトコルトランスポート層に通信オーバヘッドの軽く、再送要求のない、UDPを用いるだけでは不 十分なのか?

そんなことをふと疑問に思ったので、調べてみた。

一言でまとめると、UDPはsequence number がないので、順序の組み立てができない。 よって、RTPの「sequence number」を用いて、正しい順番にパケットを並び戻すことができる。 また「timestamp」を用いることで、意図的に遅延したフレームは破棄をすることで、 リアルタイム性を確保できる。

調べてみると、RTP基礎部分のRFCだけでもいくつかあるので、いかにまとめておく。

RTP: A Transport Protocol for Real-Time Applications

  • RFC number
    • RFC3550
    • RFC1889(obsolete)
  • 内容
    • RTP header の定義
      • 送信側のパケット送出タイミングを受信側でも復元できるようにする
        • 符号データのパケット化
        • 送信者のシーケンス番号とタイムスタンプ情報を送信
          • 受信側は、これを参照にリアルタイム性を確保
    • RTP header
            0                   1                   2                   3
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |V=2|P|X|  CC   |M|     PT      |       sequence number         |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                           timestamp                           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |           synchronization source (SSRC) identifier            |
         +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
         |            contributing source (CSRC) identifiers             |
         |                             ....                              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      

RTP Profile for Audio and Video Conferences with Minimal Control

  • RFC number
    • RFC3551
    • RFC1890(obsolete)
  • 内容
    • 符号データごとの具体的なフレーミング方法,すなわちRTPパケットのフォーマット
    • オーティオやビデオデータの圧縮方法ごとにペイロードフォーマットがある  それらを定義

    • 定義されている payload type (audio)

         PT   encoding    media type  clock rate   channels
                    name                    (Hz)
         ___________________________________________________
         0    PCMU        A            8,000       1
         1    reserved    A
         2    reserved    A
         3    GSM         A            8,000       1
         4    G723        A            8,000       1
         5    DVI4        A            8,000       1
         6    DVI4        A           16,000       1
         7    LPC         A            8,000       1
         8    PCMA        A            8,000       1
         9    G722        A            8,000       1
         10   L16         A           44,100       2
         11   L16         A           44,100       1
         12   QCELP       A            8,000       1
         13   CN          A            8,000       1
         14   MPA         A           90,000       (see text)
         15   G728        A            8,000       1
         16   DVI4        A           11,025       1
         17   DVI4        A           22,050       1
         18   G729        A            8,000       1
         19   reserved    A
         20   unassigned  A
         21   unassigned  A
         22   unassigned  A
         23   unassigned  A
         dyn  G726-40     A            8,000       1
         dyn  G726-32     A            8,000       1
         dyn  G726-24     A            8,000       1
         dyn  G726-16     A            8,000       1
         dyn  G729D       A            8,000       1
         dyn  G729E       A            8,000       1
         dyn  GSM-EFR     A            8,000       1
         dyn  L8          A            var.        var.
         dyn  RED         A                        (see text)
         dyn  VDVI        A            var.        1
      
         Table 4: Payload types (PT) for audio encodings
      
    • 定義されている payload type (video)

         PT      encoding    media type  clock rate
                         name                    (Hz)
         _____________________________________________
         24      unassigned  V
         25      CelB        V           90,000
         26      JPEG        V           90,000
         27      unassigned  V
         28      nv          V           90,000
         29      unassigned  V
         30      unassigned  V
         31      H261        V           90,000
         32      MPV         V           90,000
         33      MP2T        AV          90,000
         34      H263        V           90,000
         35-71   unassigned  ?
         72-76   reserved    N/A         N/A
         77-95   unassigned  ?
         96-127  dynamic     ?
         dyn     H263-1998   V           90,000
      
         Table 5: Payload types (PT) for video and combined encodings
      

RTP Payload Format for H.264 Video

  • RFC number RFC6184 RFC3984(obsolete)
  • 内容
    • h264 をRTPにのせる為のpayload format を定義
    • 3種類のpayload structure を用意

      • Single NAL Unit Packet
        • 一つのNAL unitを一つのRTP message で送信する
      • Aggregation Packet
        • 複数のNAL unitを一つのRTP message で送信する
      • Fragmentation Unit
        • 一つのNAL unitを複数のRTP message に分割して送信する
            Table 1.  Summary of NAL unit types and the corresponding packet types
          
            NAL Unit  Packet    Packet Type Name               Section
            Type      Type
            -------------------------------------------------------------
            0        reserved                                     -
            1-23     NAL unit  Single NAL unit packet             5.6
            24       STAP-A    Single-time aggregation packet     5.7.1
            25       STAP-B    Single-time aggregation packet     5.7.1
            26       MTAP16    Multi-time aggregation packet      5.7.2
            27       MTAP24    Multi-time aggregation packet      5.7.2
            28       FU-A      Fragmentation unit                 5.8
            29       FU-B      Fragmentation unit                 5.8
            30-31    reserved                                     -
          
    • Ethernet AVB IEEE1722 で定義されているstream format の一つであるCVFを用 いて、h264 を送信する際も、このプロトコルを利用する

            Value  Name          Description      
            0      MJPEG     MJPEG Format  (RFC 2435)  
            1      H264      H.264 Format  (RFC 6184) 
            2      JPEG2000  JPEG 2000 Video (RFC 5371)  
            IEEE1722-2016 Table 20 format_subtype field for RFC Format より
      

vol39. 日本 vs ポーランド戦で思うこと

mainichi.jp

サッカーW杯2018、1次予選 第3戦の試合をTV観戦した。

結果は0-1の敗戦だったが、日本代表は勝点4で、同H組2位を争うセネガルをフェアプレイ ポイント差でかわして、決勝トーナメントに進むことが出来た。

でも、観戦している中で日本代表がとった戦術について、いろいろな感情や思いが湧いて きた。きっと、この後、賛否両論、いろいろな意見がネットを中心にとび交うであろう。

その中の一つの意見として、自分もここに意見を述べてみたいと思う。

状況

状況はこうだ。

酷暑、前試合から中3日という状況だったため、日本代表は、先発を6人いれかえ、コンデ ィションのよい選手を優先させた。

試合内容は、日本代表が優勢、後半もチャンスがいくつかあった。しかし、後半14分にフ リーキックから失点。この時点ではコロンビア-セネガルは0-0の同点だったため、追いつ かないと決勝トーナメントに進めない状況。乾を投入し、点を取りにいくが、チャンスを つくれない。ボールも持てない。逆に、カウンターで更に失点する危機が多数。川島の2 度のスーパーセーブでなんとか持ちこたえる状況。

そんな中、 後半29分に、コロンビアが1点決めた。この時点で、セネガルと日本は勝点 数、得失点数、総得点数が共に同じ、直接対決は引き分け、という珍しい状況が起きた。 この場合、フェアプレイポイントと呼ばれる、もらったイエローカードやレッドカードか ら算出されるポイントで上位が判定される。そのフェアプレイポイントの差で日本が2位 の状態となった。

日本は攻めに行くも、まったくボールも奪えず、ボールを奪ってもまともな攻撃ができな い状況。その後、日本は長谷部を投入。セネガルがこのまま負けることを願い、守りには いったのだ。

ボールを保持した状態では、まったく攻めずにボールを回すだけ。守備では、カードをも らわないように接触プレーをさけてのディフェンス。ポーランドも勝っているので、特に ボールを追いかけない。観客からは大ブーイング。結果的にそのまま0-1で日本敗戦のま ま、試合終了。セルビアも0-1でコロンビアに破れ、試合終了。 結果、日本の決勝トーナメント進出が決まった。

感じたこと

この試合を観戦し終わって感じたことは、決勝トーナメントに進めるのは素直に嬉しい。 日本代表の試合が少なくとももう1試合みれるから。

でも、これは、後悔する戦い方だったと思う。

もし、セネガルが点を決めて追いついていたら、日本は決勝トーナメントに行けなかった 。その為に、決勝トーナメントにいけなかったら、本当に悔やんでもくやみきれない、他 者依存の戦い方だ。

それよりは、リスクを犯して1点を取りにいき、同点を目指して勝点を奪い、自力で決勝 トーナメントに進む戦いを目指してほしかった。後半失点するまでのパフォーマンスを見 ていたら、日本が攻めにいって、ポーランドから1点を奪える可能性は十分にあったと思 う。

反対論

客観的に考えるために、反対論を考えみよう。

リスクを犯して1点を取りにいき、2点目をポーランドに奪われた時にどう思うだろうか? やはり悔しい。後に、守りに入ればよかったと後悔するか?確かにするかもしれない。

失点後のパフォーマンス。著しく攻めてを欠き、ボールが繋がらず、セカンドボールが奪 えない。

  • 攻めの交代選手を入れて得点できる可能性、その時の失点する可能性
  • 守りに入って、カードを貰わずに失点しない可能性
  • セネガルが得点するであろう可能性

これらの可能性をすべて鑑みて出した結論が、西野監督のチョイスだったのだろう。 そういった意味では、結果論でいうと、正しい決断だという意見も一定の理解はできる。

まとめ

でも、そもそも何故、選手はワールドカップに出場したいと思うのか?

ワールドカップには、世界最高レベルで、全世界が見守る中で、自分達の力を試すために 、試合自体を楽しむために出場したいのではないのか?セネガル戦で、守って勝つより、 自分たちのプレーをして、みんなでカバーしながら戦おうという選択をして、守りきった ではないか!!あの時の気持ちを出してほしい。

もう一度言う。日本代表が予選を突破できたことは本当に嬉しい。 でも、もし全く同じ状況に、将来もう一度直面したら、その時は、ぜひとも戦ってほしい。 チャレンジしてほしい。それが皆に勇気を与えると思う。感動を与えると思うんだ。

勝っても負けても、日本代表として、日本人でよかった、 日本人が誇らしいという思えるような戦いを期待する!!

がんばれー、日本!!

追記 (2018/6/30)

試合後1晩が経ち、メディアには様々な意見がとび交う。 自分もいろいろな意見を聞き、西野監督の試合後の記者会見の模様をみて、出てきた思いは、

  • 世界の最前線でやっている人間こそ、肯定的な意見を表明している
    本当に厳しい世界で戦っているからこそ、なにがあっても結果を求める姿勢が大事なの ではないか?
  • 同じ日本人なのだから、仲間を守らなくてどうする?

試合中は、試合をみていても楽しくなかったし、やる気のないプレーに怒れたりもしたけ ど、その後冷静になってみると、西野監督や選手達も複雑な思いをもった決断だったんだ と改めて理解できた。そして、そういう中で、短い時間で判断し、結果をもぎ取った。

世界でも賛否両論があるが、ここは、日本のサポーターとして、日本人とて、日本代表を後 押しできるよう、決勝トーナメントに連れて行ってくれた監督の判断を支持したい。

本当に難しい戦いになると思うけど、もしベルギーに勝ったら、すべてが報われるような 気がする。がんばれ、日本!!

vol38. windows10でmDNSの問題を解決する

先日、windows10で名前解決の問題にぶち当たった。windows10からLAN接続されている機 器に対してpingが通らないのである。

結論からいうと、windows10に実装されているmDNSを無効にして、3rd party のmDNSをイ ンストール(bonjour)したら問題が解決した。

windows10に3rd partyのmDNSをインストールしても、window10で実装された標準mDNS が優先的に使用される、かつ、このmDNSがバグってる(予想)ので、うまくうごかなかった模様 。レジストリを修正して、標準mDNSを無効にしないといけない。

解決に丸1日以上かかったので、うっぷんばらしと、今後の備忘録代わりにブログに投稿 しておく。

問題の概要

ホスト名(hogehoge.local)でターゲットを指定すると、ホスト名が見つからないと怒られ る。IPアドレス指定は問題なしなことから名前解決の問題。 ホスト名指定でも、ping に-4オプションを加えとipv4指定すると動くが、-6とipv6指定すると動かない。 以下はそのログ。

C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping hogehoge.local
ping 要求ではホスト hogehoge.local が見つかりませんでした。ホスト名を確認してもう一度実行してください。

C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping 192.168.100.18
192.168.100.18 に ping を送信しています 32 バイトのデータ:
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64

C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping fe80::2fc:70ff:fe00:1
fe80::2fc:70ff:fe00:1 に ping を送信しています 32 バイトのデータ:
fe80::2fc:70ff:fe00:1 からの応答: 時間 <1ms
fe80::2fc:70ff:fe00:1 からの応答: 時間 <1ms

C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping hogehoge.local -6
ping 要求ではホスト hogehoge.local が見つかりませんでした。ホスト名を確認してもう一度実行してください。

C:\Program Files (x86)\Microsoft Visual Studio 14.0>ping hogehoge.local -4
hogehoge.local [192.168.100.18]に ping を送信しています 32 バイトのデータ:
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64
192.168.100.18 からの応答: バイト数 =32 時間 <1ms TTL=64

システム構成

システム構成は以下の通り

  • PC A (Windows10)
  • PC A (Linux Debian(Vmware on Windows10))
  • PC B (Windows7)
  • 機器A (Linux: hogehoge.local)
  • avahi daemon を利用して、mDNS をサポート。機器名はhogehoge.local

システム内の機器はEthernet Switch を通じて接続。システム内のすべての機器はipv4, ipv6対応している。

詳細

以下詳細。

  • PC A(windows10)から機器A(hogehoge.local)へのpingで名前解決ができない

    • ipv4指定にすると(ping -4) 問題なし
    • ipv6指定にすると(ping -6) 問題発生
  • PC A(Linux Debian@vmware)からの機器へのpingでは問題なし

  • PC B(Windows7)でも問題なし

    • 標準状態では、ipv4, ipv6指定共に、問題発生 これは、windows7ではmDNSはサポートされていないから。 windowsでは、DNSサーバーがなしの名前解決のプロトコルとして、LLMNRが採用されているが Linuxではこのプロトコルはサポートされていない。
    • bonjour for windows といった3rd party 制のmDNS cleinet をインストールする とipv4, ipv6共に動作するようになる
  • その他

    • windows10にもbonjour install してみたけどNG.

問題解決方法

冒頭にも述べたように、結論から言うと、windows10のmDNSの機能を無効にし、他のmDNSクライアントを 用いることで問題が解決する。

  1. mDNSを無効にする
  2. 3rd party のmDNS client をインストールする

これで動くようになった!!

いろいろ情報を集めたけど、最終的な決めてとなったのは以下の投稿。感謝!!

http:// https://superuser.com/questions/1330027/how-to-enable-mdns-on-windows-10-build-17134

vol37. mDNSとは

Linux 上で、avahi を使って、名前解決をする仕組みを知りたかったので調べてみた。 UDPの上位レイヤーで動作するmDNSというプロトコルを使用している。

mDNS とは何か

  • multicast DNSの略
  • 通常のDNSは、DNS server に問い合わせ名前解決を行う。
  • mDNSは、マルチキャスト転送で、ネットワーク内のデバイスに問い合わせる事により、
    名前解決を行う
    • DNSサーバーがいらない。
  • RFC6762で規定

名前解決の流れ

  • client は、mDNS query メッセージをマルチキャストで投げる
  • 対応する機器はmDNS response メッセージをマルチキャストで応答
  • mDNSは、マルチキャストアドレス 224.0.0.251、UDP 5353ポートを使用
  • IPv4, IPv6のIP address の問い合わせは、query のType field で指定
    • Type field: 0x01 (ipv4)
    • Type field: 0x1c (ipv6)

      mDNS query メッセージ

      f:id:john-rama01:20180614071616p:plain

      mDNS answer メッセージ

      f:id:john-rama01:20180614072209p:plain

zeroconf との関係

  • 名前解決は、zeroconf 3つの技術のうちの1要素
    1. ip address の割り当て
    2. 名前解決
    3. device の位置の特定
  • avahi はzeroconf を実現するためのLinux上での実装。applebonjourという実装。

nsswitchとは

  • Linux における名前解決の為のclient system(avahi はmDNSの為の、server systemの
    位置づけ)
  • local file, mdns, dns 等複数ある名前解決手法のうち、どの手法を用いて、どの順序
    で名前解決をするかを決める。
  • 設定ファイル

      /etc/nsswitch.conf  
      hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns  
    

    優先順位は、files(/etc/hosts), mdn4_minimal, dns, mdns の順序。
    miinimal はホスト名に.localが含まれていないと名前解決を行わない
    mdns4 はIPv4のみ
    mdnsはIPv4, IPv6双方で名前解決を行う。

  • ping hogehote.local とうつと、上記の設定では、まず/etc/hostsの中身を確認し、次に
    mdns ipv4 プロトコルで、名前解決を試みる。失敗したら、dns server に問い合わせを行い、  最後に、mdns (v4, v6) で解決を試みるというながれ。

vol36. Ethernet AVB / Milan プロトコル

本日、MILANプロトコルが発表された。

Ethernet AVB/TSN に基づいたPro AV 向けのプロコトルで、Certified デバイス間の相互
動作を保証する。概要をまとめてみたい。

MILANとは?

  • AVB/TSNの上位layer(アプリ層)のプロトコル
    • Certified されたAVB/TSN デバイス間の相互接続性を保証する
    • アプリ及びNetwork layerへの要求を定義
      • compatible media streams, formats, media-clocking, redundancy
        and controller software.
  • Pro AV アプリ向け
  • 2018/6/5 にプレスリリースされた

Creators

AVnul Alliance 内のPro AV Marketの企業

  • AudioScience
  • Avid
  • Biamp
  • d&b audiotechnik
  • L-Acoustics
  • Luminex
  • Meyer Sound

概要

  • AVB protocol base (gen1)
  • Stream Format はAAF、Media Clock RecoveryにCRF、Device Discovery やConnection
    Management にAVDECCを採用
  • Redundancy に対する項目もあるが、それを実現するために、どのプロトコルをサポ
    トしないといけないかは規定していない。
  • user-driven protocolとのことなので、user の要求に基づいて、仕様が追加されていく形になるだろう

White Paper

以下、Whilte Paper のポイントを列挙

http://avnu.org/wp-content/uploads/2014/05/Milan-Whitepaper_FINAL-1.pdf

  • Ovewrview
    Milan creates the endpoint solution layer for professional
    audio equipment based on the following AVB IEEE stan-
    dards:

    Therefore, Milan defines a set of technical profiles for these
    IEEE standards dedicated to professional audio endpoints:

    • Media Clocking Specification
    • Stream Format Specification
    • Redundancy Specification
    • AVDECC Specification for Endpoint
  • Media Clocking Specification

    • What Format and Sample Rates are supported?
      • mandatory 48kHz
      • optional: 96kHz, 192kHz
    • CRF (Clock Reference Format) defined in IEEE 1722-2016.
  • Stream Format Specification

    • AAF 32bit (mandatory)
      • max 8ch per stream
    • High Capacity 32 bit (optional)
      • max 56ch per stream
    • High Capacity 24 bit (optional)
      • max 64ch per stream
  • Redundancy Specification

    • duplicating the network infrastructure into two independent logical
      networks (e.g. a broken cable or power loss of a bridge). By
      connecting endpoints to both networks, seamless redundancy can be
      achieved.
    • Milan does not specify a particular implementation, rather defines the
      gen- eral requirements that implementations must adhere to in order to
      achieve interoperability.
  • AVDECC Specification for Endpoint

    • The Milan AVDECC specification provides a consistent set of
      requirements that provides the following features:
      • Automatically discovers the addition and removal of pro audio
        devices on the network
      • Retrieves the entity model of the discovered pro audio devices
      • Connects and disconnects streams between the discovered pro audio devices
      • Obtains status information about the discovered pro audio devices
        and their connections
      • Controls the discovered pro audio devices
  • 参考
    http://avnu.org/milan/
    http://www.inavateonthenet.net/news/article/avb-based-milan-protocol-promises-to-boost-open-standards-networking