プロトコルは、特定のプロトコルを使用するために必要になるリソースへの アクセスを可能にする Libav 上の構成される要素です。
Libav のビルドを構成(configure)する際は、既定ではサポートされている全ての プロトコルが有効になっています。configure オプション "–list-protocols" を使うと 全ての利用可能なプロトコルがリストアップされます。
configure オプション "–disable-protocols" を使えば全てのプロトコルを無効にする ことができ、 "–enable-protocol=PROTOCOL" で特定のプロトコルを選択して有効にでき、 または "–disable-protocol=PROTOCOL" で特定のプロトコルを無効にできます。
ff* ツールのオプション "-protocols" はサポートされているプロトコル のリストを表示します。
現在利用可能なプロトコルの説明は以下の通りです。
定型的なものとして、Apple HTTP Live Streaming 準拠のセグメント化 ストリーム。セグメントを表す M3U8 プレイリストとしては、標準ファイル プロトコルによってアクセスされるリモートの HTTP リソースや ローカルファイルになります。 既定では HTTP ですが、applehttp URI スキーム名の後に "+proto" のように指定することで、別の特定のプロトコルを宣言することもできます。 ただし proto は "file" もしくは "http" です。
applehttp://host/path/to/remote/resource.m3u8 applehttp+http://host/path/to/remote/resource.m3u8 applehttp+file://path/to/local/resource.m3u8 |
物理的な連結プロトコル。
多くのリソースから順に、1つの独自のリソースであるかのように 読んだりシークしたりできます。
このプロトコルが受け取る URL は次の構文を持ちます:
concat:URL1|URL2|...|URLN |
ただし URL1、URL2、...、URLN は連結されるリソースの URL で、それぞれは異なるプロトコルを指定していてもかまいません。
例えばファイル列 ‘split1.mpeg’、‘split2.mpeg’、‘split3.mpeg’ を ‘avplay’ で読むには、次のコマンドを使ってください:
avplay concat:split1.mpeg\|split2.mpeg\|split3.mpeg |
多くのシェルで特別扱いされる文字 "|" をエスケープしなけばならないかもしれない ことに注意してください。
ファイルアクセスプロトコル。
1つのファイルから、または1つのファイルに向けて読むことができます。
例えば avconv でファイル ‘input.mpeg’ から読むには、次のコマンドを
使ってください:
avconv -i file:input.mpeg output.mpeg |
ff* ツールは既定ではこのファイルプロトコルを使います。 すなわち "FILE.mpeg" という名前で指定されたリソースは URL "file:FILE.mpeg" であるかのように解釈されます。
Gopher プロトコル。
HTTP (ハイパーテキストトランスファープロトコル)。
TCP 越しの MMS (マイクロソフトメディアサーバー)プロトコル。
HTTP 越しの MMS (マイクロソフトメディアサーバー)プロトコル。
要求される構文は:
mmsh://server[:port][/app][/playpath] |
MD5 出力プロトコル。
書き出されるデータの MD5 ハッシュを計算し、クローズ時にそれを指示された 出力もしくは(指定されていなければ)標準出力に書き出します。実際のファイルに 書き出すことなく muxer をテストするために使えます。
いくつかの例を以下に挙げます。
# エンコードされる AVI ファイルの MD5 ハッシュをファイル output.avi.md5 に書き出します。 avconv -i input.flv -f avi -y md5:output.avi.md5 # エンコードされる AVI ファイルの MD5 ハッシュを標準出力に書き出します。 avconv -i input.flv -f avi -y md5: |
フォーマットによっては(典型的には MOV)出力プロトコルがシーク可能である必要が あり、したがって MD5 出力プロトコルが一緒だと失敗することに注意してください。
UNIX パイプアクセスプロトコル。
UNIX パイプに書き出したり読み込んだりすることができます。
受け取る構文は:
pipe:[number] |
number はパイプのファイル記述子に対応する番号 (例えば標準入力なら0、標準出力なら1、標準エラー出力なら2)です。 number が指定されていなければ、既定ではこのプロトコルが 書き出しに用いられるときには標準出力が利用され、このプロトコルが 読み込みに用いられるときには標準入力が利用されます。
例えば avconv で標準入力から読むには:
cat test.wav | avconv -i pipe:0 # ...これは次と同じです... cat test.wav | avconv -i pipe: |
avconv で標準出力に書くには:
avconv -i test.wav -f avi pipe:1 | cat > test.avi # ...これは次と同じです... avconv -i test.wav -f avi pipe: | cat > test.avi |
フォーマットによっては(典型的には MOV)出力プロトコルがシーク可能である必要が あり、したがってパイプ出力プロトコルが一緒だと失敗することに注意してください。
リアルタイムメッセージングプロトコル。
リアルタイムメッセージングプロトコル(RTMP)は TCP/IP ネットワーク越しの マルチメディアコンテントのストリーミングに用いられます。
必要となる構文は:
rtmp://server[:port][/app][/playpath] |
受け取るパラメータは以下の通りです:
RTMP サーバーのアドレスです。
利用される TCP ポートの番号です(既定では1935です)。
アクセスするアプリケーションの名前です。たいていの場合 RTMP サーバー にそのアプリケーションがインストールされているパスになります。 (例えば ‘/ondemand/’、‘/flash/live/’、など)。
app で指定されうアプリケーションから参照され再生される リソースのパスまたは名前です。"mp4:"が先頭につくかもしれません。
例えば ‘avplay’ で RTMP サーバー "myserver" からアプリケーション "vod" で "sample" という名前のマルチメディアリソースを読むには:
avplay rtmp://myserver/vod/sample |
librtmp を通じてサポートされるリアルタイムメッセージングプロトコルとその バリエーションです。
構成(configure)の際に librtmp のヘッダとライブラリが存在しなければなりません。 "–enable-librtmp" で明示的にビルドを configure する必要があります。 有効にされるとネイティブの RTMP プロトコルは置き替えられます。
このプロトコルは、RTMP、HTTP トンネルによる RTMP (RTMPT)、暗号化 RTMP (RTMPE)、SSL/TLS オーバー RTMP (RTMPS)、そしてこれら暗号化タイプの トンネル版(RTMPTE、RTMPTS)をサポートするために必要ななるほとんどの クライアント機能と少数のサーバー機能を提供します。
必要となる構文は:
rtmp_proto://server[:port][/app][/playpath] options |
ただし rtmp_proto は各 RTMP バリエーションに対応する文字列 "rtmp"、"rtmpt"、"rtmpe"、"rtmps"、"rtmpte"、"rtmpts" の1つで、 server、port、app および playpath は RTMP ネイティブプロトコルで指定されるものと同じ意味を持ちます。 options は空白で区切られた key=val の形のオプション のリストを含みます。
さらなる情報については librtmp のマニュアルページ(man 3 librtmp)を見てください。
例えば、avconv を使ってリアルタイムに RTMP サーバーに向けてファイルをストリームするには:
avconv -re -i myfile -f flv rtmp://myserver/live/mystream |
‘avplay’ を使って同じストリーミングを行なうには:
avplay "rtmp://myserver/live/mystream live=1" |
リアルタイムプロトコル。
RTSP は技術的には libavformat でのプロトコルハンドラではなく、demuxer であり かつ muxer です。この demuxer は通常の RTSP (RTP 越しにデータが転送される; これは例えば Apple や Microsoft で用いられています)も Real-RTSP (RDT 越しに データが転送される)もどちらにも対応しています。
muxer はストリームを RTSP ANNOUNCE を用いて、それに対応しているサーバー (現時点では Darwin Streaming Server と Mischa Spiegelmock の RTSP server) に向けて送信するために利用できます。
RTSP のために必要となる構文は:
rtsp://hostname[:port]/path |
以下のオプションが(avconv/‘avplay’ のコマンドライン上で、あるいは
AVOption または avformat_open_input のコード内で設定するのに)
サポートされています:
rtsp_transport のためのフラグ:
下位トランスポートプロトコルに UDP を使います。
下位トランスポートプロトコルに(RTSP コントロールチャンネル内で交互にした) TCP を使います。
下位トランスポートプロトコルに UDP マルチキャストを使います。
下位トランスポートプロトコルに http トンネリングを使います。これは 受動的なプロキシに対して便利です。
複数の下位トランスポートプロトコルを指定することが許されており、その場合
一度に1つだけ試されます(1つの設定に失敗したら、次のものが試されます)。
muxer については、tcp と udp のみがサポートされています。
rtsp_flags のフラグ:
ネゴシエーションしたピアのアドレスとポートのみからパケットを受け取ります。
UDP 越しにデータを受け取る際に、demuxer は受け取ったパケットを並べ直そうと
します(これらが順番になっていない、もしくは全体的にパケットが失われている
かもしれないからです)。これを有効にするためには、 AVFormatContext の
max_delay フィールドで最大の遅延を指定しなければなりません。
‘avplay’ でマルチビットレート Real-RTSP ストリームを観る際、
表示するストリームとして -vst n および -ast n で
映像と音声それぞれを選択できます。そして作動中に v や a
を押すことで切り替えることが可能です。
コマンドラインの例:
UDP 越しのストリームを観る、並べ直しの最大遅延は0.5秒:
avplay -max_delay 500000 -rtsp_transport udp rtsp://server/video.mp4 |
HTTP トンネル経由のストリームを観る:
avplay -rtsp_transport http rtsp://server/video.mp4 |
他人に観せるために、RTSP サーバーにストリームをリアルタイムで送信する:
avconv -re -i input -f rtsp -muxdelay 0.1 rtsp://server/live.sdp |
セッションアナウンスメントプロトコル(RFC 2974)。これは技術的には libavformat のプロトコルハンドラではなく、muxer および demuxer です。 分離されたポート上で定期的にストリームに対して SDP を通知することによって、 RTP ストリームのシグナリングのために使用されます。
muxer に渡される SAP url のための構文は次の通りです:
sap://destination[:port][?options] |
RTP パケットはポート port の destination に対して送信され、
ポートが指定されていない場合にはポート 5004 に対して送信されます。
options は & で区切られたリストです。以下のオプションを
サポートしています:
通知を送りつける送信先の IP アドレスを指定する。 省略されていれば、通知は共通して利用されている SAP アナウンスメント マルチキャストアドレス 224.2.127.254 (sap.mcast.net)に、もしくは destination が IPv6 アドレスならば ff0e::2:7ffe に送信される。
通知を送りつけるポートを指定する、指定されなければ 既定で 9875。
通知と RTP パケットのための time to live 値を指定する、 既定では 255。
1が設定されれば、全ての RTP ストリームを同じポート対で送る。0(既定) ならば、全てのストリームは独自のポートに送られ、各ストリームは先のものより 2つ数字の大きいポート番号になる。 VLC/Live555 では、ストリームを受け取れるように、これを1に設定することが求められる。 libavformat で受信するための RTP スタックは各ストリームが一意なポートで送られる 必要がある。
コマンドラインの例は以下の通り。
VLC で観るために、ローカルサブネットにストリームをブロードキャストするためには:
avconv -re -i input -f sap sap://224.0.0.255?same_port=1 |
同様に、avplay で観るには:
avconv -re -i input -f sap sap://224.0.0.255 |
そして IPv6 越しに avplay で観るには:
avconv -re -i input -f sap sap://[ff0e::1:2:3:4] |
demuxer に与える SAP url のための構文は:
sap://[address][:port] |
address は通知のために待ち受けるマルチキャストアドレスであり、 省略されれば、既定の 224.2.127.254 (sap.mcast.net)が用いられる。 port は待ち受けるポートであり、省略された場合9875である。
demuxer は与えられたアドレスとポートで通知を待ち受ける。 いったん通知を受け取るとすぐに、特定のストリームを受信しようとする。
コマンドラインの例は以下の通り。
通常の SAP マルチキャストアドレスで通知される最初のストリームを再生するには:
avplay sap:// |
既定の IPv6 SAP マルチキャストアドレスで通知される最初のストリームを再生するには:
avplay sap://[ff0e::2:7ffe] |
トランスミッションコントロールプロトコル。
TCP url のために要求される構文は以下のとおり:
tcp://hostname:port[?options] |
外から入ってくる接続を待ち受ける
avconv -i input -f format tcp://hostname:port?listen avplay tcp://hostname:port |
ユーザーデータグラムプロトコル。
UDP url に要する構文は:
udp://hostname:port[?options] |
options は & で区切られた key=val の形のオプションのリストを含む。 サポートされているオプションのリストは以下の通り:
UDP バッファサイズをバイト数で設定する
バインドするローカル UDP ポートを上書きする
ローカル IP アドレスを選択する。これは例えばマルチキャストを送信し ホストが複数のインターフェイスを持つときに、どの IP アドレスの インターフェイスに送るか選択する際に便利です。
UDP パケットのバイトサイズを設定する
UDP ソケットの再利用を明示的に有効または無効にする
time to live 値を設定する(マルチキャストについてのみ)
UDP ソケットを connect() で初期化する。
この場合、送り先アドレスは後から ff_udp_set_remote_url で変えることができない。
送り先のアドレスが開始時に分からない場合、このオプションを
ff_udp_set_remote_url で指定することもできる。
これによって getsockname でパケットの送り元アドレスを見つけることができ、
書き出しの際 "destination unreachable" を受け取った場合には
AVERROR(ECONNREFUSED) を返す。
受信にlについては、これによって指定されているピアのアドレス/ポートからのパケット
のみを受け取るという効用がある。
udp プロトコルの avconv での利用例は以下の通り。
UDP 越しにリモートエンドポイントへストリームするには:
avconv -i input -f format udp://hostname:port |
188 サイズの UDP パケットを使い、大きい入力バッファで UDP 越しに mpegts 形式でストリームするには:
avconv -i input -f mpegts udp://hostname:port?pkt_size=188&buffer_size=65535 |
UDP 越しにリモートエンドポイントから受け取るには:
avconv -i udp://[multicast-address]:port |