![]() |
![]() |
録画したものはライブラリ画面で一覧する。 スマートプレイリストも作れるようだ。 |
録画日時やEPG情報が残る。 |
![]() |
|
マイレー ト、シリーズ番号など、iTunes的な管理情報が付加できる。 |
![]() |
録画ファイ ル名は[タイトル 日付 放送時刻.mpg]になる。いやWinの人はナニイッテンノ?と思うかも知れないが、FW版は[Cap00x.mpg]だったんだよ! |
◆「ソーシャルブックマーク雑感 その2」:観測気球--2006/06/12ここには「複数のソーシャルブックマークサービスに同時に投稿するスクリプト」なんて のもある。残念ながらIE専用なのだけど、スゲェ。
「ソー シャルブックマーク管理ツール」 を作っている関係もあって、いろんなソーシャルブックマークを使ってみている訳ですが、今のところ、どのサービスも一長一短があって、このサービスだけ 使っていれば間違いない、という理想的なソーシャルブックマークは、まだ登場していないように思われます。ユーザ数からいけば、海外では del.icio.us、日本では はてなブックマークなんだけど、コメントの字数制限が厳しいのもこの2つだったりします。
2006/07/11-PCWatch-本田雅一の「週刊モバイル通信」- PC業界がAppleに学べること国内でそれができるのはSCEと任天堂くらい、他に無いと思うんだけども。 PLAYSTATION3を「パソコンとして」見てもらう事から始めないとイケナイのが弱みだ。
「ジョブズ氏は40~50年という長期に渡る事業計画を持っており、現在のAppleはその計画に沿って順調に運営されている」 と福田氏は話す。
~
ジョブズとその側近たちは「汎用コンピュータを使う時代から、コンピュータを応用して特定の目的に使う専用機が主流になっていく」と読み、現在へと続く製 品企画の基本的なポリシーになっているという。
~
しかし最初からコストをかけてプラットフォームを作り、それに継続的に改良を加えていくという手法ならば、Appleなり の魅力を引き出すことができ る。フルモデルチェンジのサイクルを長く取り、その代わりにデザインや改良に対して多くの 資源を投入するという手法は、現在のコストとスペック最優先で作 られるPCとは対極的だ。
wikipedia:タイ王国軍
タイ王国軍隊の総帥すなわち(名目上の)最高責任者として国王があり、その下に首相が置かれ国防省が置かれている。なお国防大臣は2004年現在文民のみがなることが出来る(ただし、退役軍人は文民と見なされている)。
$ mencoder /Users/USERNAME/Movies/Coyote/Coyote_OP.mpeg \■結果
-nosound -ovc x264 -x264encopts \
threads=2:cabac:bitrate=1024:keyint=240:keyint_min=1:scenecut=55:bframes=3:b_adapt:weight_b:b_pyramid:qp_min=10:qp_max=51:\
qp_step=4:qcomp=0.6:ratetol=4:deblock:deblockalpha=0:deblockbeta=0:cqm=jvt:nofast_pskip:direct_pred=3:nodct_decimate:psnr:\
pass=1:me=3:subq=7:frameref=4:mixed_refs:8x8dct:i8x8:8x8mv:b8x8mv:i4x4:4x4mv:trellis=2:brdo:bime \
-passlogfile /Users/USERNAME/Movies/Coyote/Coyote_OP.264.log \
-vf pullup,softskip,pp=l5,crop=704:352:4:64,scale=640:352:::3,hqdn3d=4:3:6,harddup \
-sws 9 -zoom -ofps 24000/1001 -of rawvideo -o /Users/USERNAME/Movies/Coyote/Coyote_OP.264
MEncoder dev-SVN-r19918-4.0.1 (C) 2000-2006 MPlayer Team
AltiVec found
CPU: PowerPC
success: format: 0 data: 0x0 - 0x75eb9af
MPEG-PS file format detected.
VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 8001.2 kbps (1000.1 kbyte/s)
[V] filefmt:2 fourcc:0x10000002 size:720x480 fps:29.97 ftime:=0.0334
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Opening video filter: [harddup]
Opening video filter: [hqdn3d=4:3:6]
Opening video filter: [scale w=640 h=352 param=3]
Opening video filter: [crop w=704 h=352 x=4 y=64]
Crop: 704 x 352, 4 ; 64
Opening video filter: [pp=l5]
Opening video filter: [softskip]
Opening video filter: [pullup]
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 720 x 480 (preferred colorspace: Mpeg PES)
[PP] Using external postprocessing filter, max q = 6.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try adding the scale filter, e.g. -vf spp,scale instead of -vf spp.
VDecoder init failed :(
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b
Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2))
==========================================================================
VDec: vo config request - 720 x 480 (preferred colorspace: Planar YV12)
[PP] Using external postprocessing filter, max q = 6.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
Unsupported format Planar I420
swScaler: Unknown format is not supported as output format
Couldn't init SwScaler for this setup
FATAL: Cannot initialize video driver.
Exiting...
まるも製作所:2004年5月19日(水) I420 の I
Interlaceの I ではなくて Indeo の I だったりする。判っている人の方が多いとは思うけれども、為念。
I420 と YV12 の違いは単純に Cb と Cr の順序 (I420 は Cb, Cr の順で YV12 は Cr, Cb の順)だけで、I420 ならインタレースで YV12 ならばプログレッシブなどという保証はどこにも無かったり。Microsoft の世界で 420フォーマットの色差がインタレースとプログレッシブのどちらかを通知する方法って DirectShow の VIDEOINFOHEADER2ぐらいしかないので、MPEG-2 デコーダでフラグを考慮した 422 変換させる方が安全確実。
RealProducer 10 ユーザ ガイド:第3章 インストール、、、非常に基本的なフォーマットという印象を受けた。
YUV12
この形式は I420 としても知られています。I420 は RealVideo コーデックが利用するネイティブな色形式です。I420を入力として使用すると、エンコードする前に色形式を変換する必要がなくなるため、パフォーマンスが向上します。
$ mencoder -vf format=helpなにも出てこない。こいつが原因かと思ったぐぁ、ffmpegX版でも同じだった。
MEncoder dev-SVN-r19923-4.0.1 (C) 2000-2006 MPlayer Team
AltiVec found
CPU: PowerPC
Name Type Min Max
fmt Image format No No
$ make uninstall
$ make distclean
$ ./configure
※Jarod(x264.nl)では、Rev.573以降でvfwおよびインストーラは外されました。MEncoderはたぶんvfw相当なので、ちょっと気になります。
事実上x264.exeに移行することになります。
900 名前: 名無しさん@編集中 Mail: sage 投稿日:2006/10/01(日) 19:04:34 ID:pMv6VZRm
遂にきたか、長かった… 今後更新履歴みるのが楽しみに。
904 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 21:14:10 ID:0g7yKvdU
r570 | pengvado | 2006-10-01 04:41:22 +0200 (Sun, 01 Oct 2006) | 2 lines
support interlace. uses MBAFF syntax, but is not adaptive yet.
905 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 21:18:33 ID:E2aegN8f
サポートしたけど適合してないってどういう意味?
907 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 21:42:35 ID:a7SYXf6g
MBAFF - MB Adaptive Field Frame
適応的に、フィールドとフレームを切り替える
まだどっちか固定になってるんでしょ。
フィールド固定なら一応インタレース対応だけど
フレーム固定なら今までと変わらないね。
913 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 22:40:38 ID:gf101Dq5
Picture Adaptive Frame FieldとMacroBlock Adaptive Frame Fieldとの
違いがいまいちわからない
pure interlaceとは違うんだよな
909名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 21:54:33 ID:ZHoH6M/H
45%の人が使ってるのに切捨てとは
910 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 22:24:31 ID:TLCSnsgz
これでCLI覚える為の踏ん切りがつきました、アリガトウ
912 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 22:37:20 ID:uchwyHZ8
なんで切り捨てになるんだ?
もしそうなら急いでsynthを覚えなければorz
914 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/01(日) 22:41:00 ID:uchwyHZ8
nlで落としたんだがインストーラーじゃないよな・・・
cliでパス指定しろってことかぁぁぁぁ
vfwオワタorz
誰か優しい人がいたら混合フレームレートを処理する方法が書いてあるサイトをorz
986 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/03(火) 06:59:02 ID:hx+Lfe7D
綺麗でも他のオプション使えないからVFW使わないんだよ
テスト目的なものだろこれ?
937 名前: 名無しさん@編集中 Mail: sage 投稿日:2006/10/02(月) 04:22:29 ID:L6I6l2OJ
解除の誤爆だの連結ミスだのに
気を回さなくていいからずっとインタレだな。本数が多くなるとやっぱ楽チンがいいわ
944 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/02(月) 11:06:35 ID:IoDx2zKL
>>942
少なくとも自分は今までインタレ保持について必要性は感じなかったが。
実装については嬉しく思うが、今後も使うことはないと思うぞ?
945 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/02(月) 11:12:12 ID:XG6nlH+n
全編周期一定の綺麗なテレシネもの以外は、自分はアニメでも
インタレ保持だな、昔はvfrとか好きでやってたけど、今はつらくなった
949 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/02(月) 12:13:58 ID:Le3HhJdF
>>947
おれも、おれも。
PVとか60のはやっぱインタレが良いよな。
あと大河ドラマがインタレつかえるのがマジうれしい。
936 名前: 名無しさん@編集中 Mail: sage 投稿日:2006/10/02(月) 03:25:14 ID:flQzRs/J
インタレとか不要だし。
AviUtlなら混在だろうが何だろうがばっちり完璧に解除できるし。
985 名前: 名無しさん@編集中 Mail: sage 投稿日: 2006/10/03(火) 05:06:19 ID:R1av9My0
VFWの方が絶対綺麗なのに…メクラばっかりでこまる
https://trac.videolan.org/x264/timelineから抜粋
■10/05/06:
- 10:15Changeset [581] by pengvado
- no more vfw
- 03:57Changeset [579] by pengvado
- accept mencoder's option names assynonyms (api only, not in x264cli)
0.素材ファイル※Bフレームを使った場合、.mp4書き出しは不可(06/10月現在)。あと字幕や副音声は触った事ないです。
│
1.コンテナ判定
│
2.映音分離(demux)
│
┌┴─────────────────────┐
│ │
3.コデック判定(映像) コデック判定(音声)
│ │
4.対応コデック呼び出し 対応コデック呼び出し
デコード デコード
│ │
5.フィルタ フィルタ
(-vf、インタレ解除・デノイズ等) (-af、詳細不詳)
│ │
6.指定コデック呼び出し 指定コデック呼び出し
エンコード エンコード
(-ovc x264等) (-oac faac等)
│ │
└┬─────────────────────┘
│
7.映音統合
(指定コンテナにmux、コンテナヘッダ書き込み。-of )
│
8.ファイル書き出し
(-o)
MacDTV.com 2005.11.05 Video iPod
AppleProVideo製品ユーザならば、無料で付属するCompressor(様々な圧縮を担うツール)によって、H.264書き出しをバッチ処理や分散レンダリング(複数のMacを使って高速分散処理)を行うこともできます。具体的には、
Lunatilia-2006/10/16:x264は厳密にはCodecではなくライブラリ
Windows環境では ffdshow + Media Player Classic 6.4.x.x との連携が一番使いやすいとは思いますが、これは個人的主観になりますので何ともいえません。
他のOSでのデコード環境はageha氏 のところを参照してください。
Changeset 588
Timestamp: 10/10/06 07:05:55
Author: pengvado
Message: no more decoder. it never worked anyway, and the presence of defunct code was confusing people.
//
デコーダはもう無い。いずれにしてもまともに動作した事など無かったし、死んだコードを残しておいても混乱の元なので。
槻ノ木 隆のBBっとWORDS-その86「AVIの生い立ちとそのコーデック」(2006/07/10)
それにも関わらずAVIフォーマットはいまだに現役であり続けています。その理由の大きな部分は、逆説的ですがコーデッ クを選ば ないことでしょう。例え ば、DivX NetworksのDivXを使ってエンコードする場合、フォーマットは(MP4やOGM/MVKなども対応していますが)AVIにするのが一般的でしょ う。また、DVフォーマットの場合も、Windows環境ではやはりAVIにするのが一般的です。最近利用が始まった H.264でも、やはりAVIを使う ことが多いようです。
新しいコーデックを作っても、それをサポートするためのファイルフォーマットがなければ利用するのは難しく、新しいフォーマットを作るとなる と、それを再生するためのプレイヤーや、生成するためのエンコーダも用意しなければなりません。ところがAVIフォーマット を使うと、コーデックさえ提供 すれば、プレーヤーやエンコーダはすでにあるものを使うことができるので、非常に手軽だからです。そして、新しいコーデッ クが最新技術(DivXもそうで すし、H.264もそうですが)を提供してくれれば、AVIフォーマットは十分魅力的です。そういうわけで、 MicrosoftはWMVを前面に押し出し ているものの、AVIは引き続き使われ続けるでしょう。
MPEG2デコード | ビデオフィルタ | エンコード | .mp4化 |
---|---|---|---|
DGMPEGDec(D2V) | AviSynth | x264cli(rawvideo.264) | mp4box(.mp4) |
MPEG2デコード | ビデオフィルタ | エンコード | .mp4化 |
---|---|---|---|
MEncoder | MEncoder | MEncoder(rawvideo.264) | mp4box(.mp4) |
![]() |
![]() |
![]() |
主人公は翼が生えた少女。 彼女は人なのか、鳥なのか。それとも天使なのか。 |
自分たちと外見の違う少女を人々は追い回します。検疫にかけて隔離すべきだと騒ぐ役人や、 | 新興宗教の教祖に祭り上げようと狙う誘拐犯が登場し、悲劇が少女を待ち受けます。 |
![]() |
人間というのは、相手がなにものかを分類しないと、安心できない性質を持っています。 ですから、自分と違うものに出会うとショックを受けて、排除してしまおうとするのです。 だからこそわたしたちは、知識だけでなく、寛容な心を持つ事が大切なのです。 それが、チャップリンが映画『Freak』で描きたかったテーマだと思います。 |
![]() |
![]() ![]() |
|
聖NOVA's教会。GOD IS WATCHING YOU. | VTOLで突入する警官隊。武装して待ち受ける信徒たち。 | 突入ドア上部に明滅するサインは"KILL" |
![]() |
応戦するも、 | |
![]() |
訓練を受けたプロには敵わない。 ※警官たちはそれぞれの死角を補い合うように、連携して動いている。
例えばこの前のコマに居たのは真ん中で射撃している警官一人だけ[Aとする]。このコマには彼をを追い抜いて手榴弾を投げる役(左端[B])と側面の援護役(右から二人目[C])が入って来ている。Aが突入して進路を開き、Bが手榴弾で制圧し、後続のCと三人で一定面積を確保する。これをちょっとずつ繰り返して前進している。ように見える。番号を振らなかった警官達は5メートルくらい先で同じ事をする別チームだと思う。走ってるし。 これに対して信徒たちは発射弾数は多いが、動きに連携が見られない。非効率だ。 |
|
![]() |
![]() |
![]() |
進路脇の部屋も容赦しない。 彼の役目は数秒間、テキの動きを止める事だ。 射撃音を聞かせるだけで良い。弾数は最小限。 |
テキの動きが止まっている数秒の間に 後続が手榴弾。んで、先へ。 |
制圧完了。これで中の人は死なないまでも、戦えない。 宮崎駿と書いて日本一アニメの巧い軍事オタクと読む。 |
![]() |
![]() |
![]() |
マスクの下はフツーの人 | ||
![]() |
![]() |
![]() |
マスクの下はフツーの人 | 検疫班登場 | 連れてかれてしまいました。 |
Sir Charles "Charlie" Spencer Chaplin | 宮崎駿 | |||
---|---|---|---|---|
年齢 | 概要 | 年齢 | 概要 | |
1952 | 63 | 事実上の国外追放 | 11 | - |
1963 | 74 | - | 22 | 学習院大学政治経済学部卒業。東映動画入社。漫画家への未練を断ち切れずにいた。 |
1964 | 75 | - | 23 | ソ連製長編アニメ映画『雪の女王』に強い感銘を受け、アニメーションを一生の仕事にしようと決意。 |
1969 | 80 | 『The Freak』執筆 | 28 | 『太陽の王子 ホルスの大冒険』(場面設計・美術設計) 『長靴をはいた猫』(原画)、 『空飛ぶゆうれい船』(原画) |
1971 | 81 | - | 30 | 『どうぶつ宝島』(アイデア構成・原画) |
1972 | 83 | アカデミー賞特別賞。 20年ぶりのアメリカ入国 |
31 | - |
1973 | 84 | - | 32 | 『パンダコパンダ』(原案・脚本・場面設定・原画) 『パンダコパンダ 雨ふりサーカスの巻』(脚本・美術設定・画面構成・原画) |
1974 | 85 | - | 33 | 『アルプスの少女ハイジ』(場面設定・画面構成) |
1975 | 86 | - | 34 | - |
1976 | 87 | - | 35 | 『母を訪ねて三千里』(場面設定・画面構成) |
1977 | 88 | 逝去 | 36 | 『あらいぐまラスカル』(原画) 『草原の子テングリ(画面レイアウト(部分))(ノンクレジット)』 |
1978 | - | - | 37 | 『未来少年コナン』で演出家に転向 |
1979 | - | - | 38 | 『ルパン三世 カリオストロの城』(初監督・脚本) |
Encoding H.264 using the x264 Command Line InterfaceのZero 1氏から頂いたコメント。試訳。
私があのガイドを書いてから x264にはいくつかの良い改善がありました。マルチスレッド(複数CPUでのエンコード)が高速化し、画質劣化が非常に少なくなったのは喜ばしい事で す。極めてnegligable(*意味不明*)です。推奨。
x264 core:54 svn-611M | |
---|---|
Frame-type options: | |
--pre-scenecut | Faster, less precise scenecut detection.Required and implied by multi-threading. 高 速だが正確性に劣るシーンカット検出。マルチスレッディングが必要。 |
Analysis: | |
--mvrange <integer> | Maximum motion vector length [-1 (auto)] モーションベクトルの最大長さ [-1 (auto)] |
--mvrange-thread <int> | Minimum buffer between threads [-1 (auto)] スレッド間の最大バッファサイズ [-1 (auto)] |
Input/Output: | |
--non-deterministic | Slightly improve quality of SMP, at the cost of repeatability repeatability (*不詳*)と引き換えに、SMP(Symmetric Multiple Processor、対称型マルチプロセッサ)の品質を若干向上。 |
x264 revision 610 - sliceless threading - what's new#9 (Doom9, akupenguin)端的に答えると:新しいオプションはどれも使う必要が無い。
Short answer: you shouldn't need to use any of the new options.
--pre-scenecut might possibly be useful for fast 1pass single-threaded encodes, but is mostly just so I can compare the two scenecut algorithms without invoking the other threading stuff.
OBMCについて
具体的な実装の細部までは分かりませんが、概念的にはだいたいこういうことだそうです。
DivX、XviDなどの動画で、ビットレートが足らないときなど、もともとそんなものはないのに、マス目状の線が出てしまうのは、 よく見かけると思いま す。ブロック単位に分割してから各ブロックを処理しているので、ブロックの中身をきめ細かにしてとなりのブロックと滑らかにつながるようにできるだけの情 報量がないと、ブロックの境界の線が目立ってしまうわけです。
MPEG-1ではブロックのサイズが固定(のっぺりしていておおざっぱに切ればいいところも同じに切るし、複雑なところで繊細に処理 してほしいところでも 細かく切ってくれない)なのですが、新しいコーデックでは、ブロックサイズを都合に合わせて動的に変えたり、長方形にしたり…と、 これはx264 (AVC)のユーザなら、設定の検索オプションのところで、いっぱい種類があるのをよくご存知と思います。
しかし、可変ブロックであっても、ブロック境界があることには変わりないので、効率は上がったとはいえ、原理的にブロックノイズが回 避できているわけでは 全然ないわけです。
AVCやWMVやRV10では、それを緩和するために、インループ・フィルターをかけています。特にRV10ではインループが明示的 に設定できるので、気 が付いた方も多いと思いますが、自分がエンコードした結果を自分で(エンコード中に)デコードしてみて、ブロックノイズの原因になる誤差が蓄積していない か確認し、必要に応じて補正をかけるわけです。 AviUtlなどのノイズフィルターなどは、コーデックに行く前にかけるプレフィルターですし、 ffdshowなどの後処理はコーデックから出てきたデコード結果を調整するものですが、インループは前でも後でもなくコーデック自体の中でかけている フィルターです。
しかし、このデブロッキングというのは、案外、実写とは相性が悪いです。ブロックノイズが出ない代わり、繊細なテクスチャー、人の肌 のきめなどがツルンと してしまいます。ただ、たいていのアニメでは、もともとツルンとしているので、この(本来は欠点の)性質がかえってランダムノイズを消して、良い感じに なってくれます。実際、ソースのノイズがデブロッキングの副作用(副作用の副作用?)で勝手に消えてくれることさえあります。とはいえ、自分で発生させた ブロック境界を消すための補正情報にレートを回すのは、巧妙ですが、本質的には無駄です。自分でノイズを作っておいて、それの消し方をコーディングするわ けですので。最初からブロック境界がなければそういう二度手間にならず、自分で汚したものを直すのに必要な情報量を、本質的なテクスチャーに回すことがで きます。
で、SNOWが実装したOBMCですが、 OBMCは、本当はh263にも規格上はあったそうなのですが、実際には使われなかったようです。 GMC同様h264では規格から外されてしまいました。
名前のとおり、オーバーラップしたブロックの動き補償です。碁盤の目のようにきっちり切るのでなく、各ブロックが少しずつ(上下左右 斜めの8方向とも)重 なって定義されています。言い換えれば、古典的な切り方での境界付近のピクセルは、実は両側のブロックに属しているわけです。一般に、各ピクセルは4ブ ロック(実装によっては3ブロック)に同時に属し、それらの加重平均をとることで、区切りの線が目立たず「とろんと」滑らかになります。段差ができる原因 が最初から回避されているわけです。段差を補正するインループ回路も確かに巧妙で効果的ですが、最初から段差ができないようなブロックを重ね合わせた取り 方、というのは本質的に素晴らしい発想でしょう。ただ、一つのマクロの動きを何重にもコーディングして、デコードのときにも重ね合わせて平均をとるので、 計算量(CPU負荷)の問題はありますが、まあ、少し未来にはハードが発達して何とかなるのではないでしょうか。
「波」の重なりで図形を表すウェーブレットも、そうした従来型のアーティファクトを克服するのに貢献するはずです。まあ、これも計算 量が大変そうです が…。
開発者の方から説明してもらったことを生半可な理解で受け売りしているのでちょっと(かなり)間違ってるかもしれませんが、あの SNOWの「とろん」とし た雰囲気と異様な美しさは、だいたいそんなような感じ…らしいです。そして、その計算がたいへんというのは、計算量が多くてもリニ アの計算なので、 GPUでハード的に実装するのは原理的には簡単らしいです。そうすればCPU負荷も問題にならないはずです。
来年4月、すべての携帯電話にGPS(日経パソコンオンライン:2006年 10月11日)根拠は総務省の報道資料っぽい。
※太字オレ
GPSモジュールを内蔵した携帯電話が、来春以降一挙に広がりを見せそうだ。きっかけ は、第3世代(3G)携帯電話へのGPS搭載の義務付けだ。
総務省は事業用電気通信設備規則を2006 年1月に改正・公布し、2007年4月に施行する。改正の大きな柱の一つが、携帯電話からの緊急通報機能を充実させる、通 称「日本版e911」だ。施行後に発売される3G端末は、原則としてGPSモジュールの内蔵が義務付けられる。 対応端末から110番/118 番/119番へ緊急通報した際に、通報者の位置情報をGPSで測位し、警察・消防・海上保安本部に自動通知する仕組みを構築する。
事業用電気通信設備規則の一部を改正する省令案等に係る情報通信審議会答申及び意見募集の結果(2005 年12月20日)これより新しいのは見当たらなかったので、その後速やかに省令等は改正されたっぽい。
※太字オレ
(1) 情報通信審議会に諮問した省令案
○事業用電気通信設備規則(昭和60年郵政省令第30号)の一部を改正する省令案(PDF)
電気通信事業者の電気通信設備のうち音声伝送役務を提供するものについて、緊急通報を扱う場合には、次の機能を有することを規定します。
1) 緊急通報の発信場所を管轄する警察機関、海上保安機関又は消防機関へ接続する機能(中略)
2) 緊急通報を発信した端末の電気通信番号及び位置情報を通知する機能
3) 通話中の回線を保留する機能
情報通信審議会の答申及び皆様から寄せられた御意見を踏まえ、速やかに省令等の改正を行うこととします。(施行日は、平成19年4月1日を予定しておりま す。)
2007/11/01追記:x264cli svn-680に準拠した本記事のアップデートがこちらにあります。
MeGUI | x264cli | MEncoder | 常用値 (MEncoder) |
|
---|---|---|---|---|
![]() |
Deblocking: デコード中のインループ・デブロッキング・フィルタを使用。指定範囲は二つとも -6 から 6の範囲。Deblocking strength はデブロック強度、 Deblocking Threshold はデブロックをかける映像の量を指定する。 | --no-deblock -f, --deblock <alpha:beta> |
(no)deblock deblock=<-6-6>,<-6-6> |
deblock(使用) 0,0 |
Enable PSNR
calculation:
このボックスをチェックすると、x264 はログに PSNR情報をジョブの終了後に書き出す。若干遅くなる。 |
--no-psnr | (no)psnr | psnr(使用) | |
Number of
threads:
マルチコア・システムを持っている場合に、この値を増やしてそのメリットを活かす。複数のフレームを同時に処理できる。マルチスレッド化に伴う画質劣化は
取るに足りない。推奨値は 0。これで x264
はCPUのコア数を検知して最適なスレッド数を使う。このオプションを使うには、MeGUI settingsの Automatically
set
number of threads をdisableにすること。 |
--threads <integer> | threads=<1-16> | 1st,2 2nd,16 参考 |
|
fourCC: AVI
などのコンテナがコデック判定に使う4CCの指定。 |
対応なし | 対応なし | 非使用 | |
AVC profiles:
この設定は、AVCの特定プロファイルに沿った設定をする際の助けとなる。選択されたプロファイルを超えるオプションが指定できなくなる。 |
対応なし | 対応なし | 参考 | |
AVC Level: 特定のAVCレベルに沿ったエンコードをしたい場合に使う。 選択されたレベルでは使えないオプションを指定出来なくするようにはしないので、ツールメニューの "Validate AVC level" でチェックする事。 | --level <string> | level_idc=<10-51> | 参考 |
MeGUI | x264cli | MEncoder | 常用値(MEncoder) | |
---|---|---|---|---|
![]() |
Zones:
Zoneの使い方はこのドキュメントの目的を超えるが、ここでzoneの定義と適用する
Quantizer または重み付けを指定する。 |
--zones | zones | 非使用 |
Custom Commandline Options: x264(cli)の追加コマンドを使いたい場合はここに入力する。x264(cli)に新しい機能が追加されたが、MeGUI のアップデートがまだの際などに使う。 |
MeGUI | x264cli | MEncoder | 常用値 (MEncoder) |
|
---|---|---|---|---|
![]() |
VBV Buffer Size: VBV Bufferの最大サイズ | --vbv-bufsize <integer> | vbv_bufsize=<value> (ABR or two pass) |
未指定(default) |
VBV Maximum Bitrate: Video Buffer Verifierの最大ローカルビットレート | --vbv-maxrate <integer> | vbv_maxrate=<value> (ABR or two pass) |
未指定(default) | |
VBV Initial
Size: VBV bufferのイニシャル占有率。 1.0 = full, 0.0 = empty。 |
--vbv-init <float> | vbv_init=<0.0-1.0> (ABR or two pass) |
未指定(default) | |
Bitrate Variance:
ビットレートの変動範囲。 1.0 = pure VBR, 0.0 = pure CBR |
--ratetol <float> | ratetol=<0.1-100.0> (ABR or two pass) |
4。 番組ごとに地味にサイズが変わる。 |
|
Quantizer
Compression: quantizerの変動範囲。 1.0 = pure CQ, 0.0 = maximum change |
--qcomp <float>か? | qcomp=<0-1> か? (ABR or two pass) |
未指定(default) | |
Temp. Blur
of est. Frame complexity: curve compression(*不詳*)の前にquantizer curveに適用する時間軸ブラーのレベル。時間軸ブラーは量子化程度の一貫性をもたらす。この値を増やすと、映像は真のCQに近づく。 (*適用量子化値の急激な変動を多少滑らかにするものか*) |
--cplxblur <float> | cplx_blur=<0-999> (two pass only) |
未指定(default) | |
Temp. Blur
of Quant after CC: curve compression(*不詳*)の後でquantizer curveに適用する時間軸ブラーのレベル。この値を増やすと、映像はCQに近づく。 |
--qblur <float> | qblur=<0-99> (two pass only) |
未指定(default) | |
Chroma ME:
動き予測の際に、彩度情報も動きの検出に使う |
--no-chroma-me | (no)chroma_me | chroma_me(使用) 要、subq>=5 |
|
ME Range: 動き予測機構が使
う最大捜索範囲(マクロブロックの中で) |
--merange <integer> | me_range=<4-64> | 1st,16 2nd,32 実用範囲16-32程度 |
|
Scene Change Sensitivity:
シーンチェンジと看做すフレーム間の変更をパーセンテージで指定。範囲0-100。-1はシーンチェンジ検出なし。 |
--scenecut <integer> | scenecut=<-1-100> | 実写40(default) アニメ65 |
|
ME Algorithm: 動き予測
に使うサーチアルゴリズムの選択。Exhaustiveはピクセル単位となり、凄まじく遅い。 |
--me <string> | me=<name> | 1st,(turbo) 2nd,umh |
|
Subpixel refinement:
サブピクセル予測に使うアルゴリズムとパーティション決定に使う方式の選択。RDO (Rate Distortion Optimisation)
を選ぶとBフレームにRDOを使う。 |
-m, --subme <integer> | subq=<1-7> | 1st,(turbo) 2nd,7 |
|
Keyframe Interval:
I-frames間の最大間隔 |
I, --keyint <integer> | keyint=<value> | 240または300 | |
Min GOP size: I-frames 間の最小間隔 | -i, --min-keyint <integer> | keyint_min=<1-keyint/2> | 実写,24または30 アニメ1 |
|
Noise reduction: プ リプロセス・ノイズリダクション。0 = disabled。 | --nr <integer> | nr=<0-100000> | 非使用 |
MeGUI | x264cli | MEncoder | 常用値 (MEncoder) |
|
---|---|---|---|---|
![]() |
Quantizers | |||
Minimum Quantizer: x264が使う最大量子化値 | --qpmin <integer> | qp_min=<1-51> (ABR or two pass) |
10 | |
Maximum Quantizer: x264が使う最小量子化値 | --qpmax <integer> | qp_max=<1-51> (ABR or two pass) |
51 | |
Maximum Quantizer Delta: 連続フレーム間における量子化値の最大変動幅 | --qpstep <integer> | qp_step=<1-50> (ABR or two pass) |
実写4 アニメ8 |
|
Credits Quantizer: For use if you set the credit starting point in the preview window. | 不詳 | 不詳 | 不詳 | |
Factor Between I and P frame Quants: IフレームとPフレームの量子化値換算 係数。Iに適用された平均量子化値にここの値を掛けたものがPに適用される。 | --ipratio <float> | ip_factor=<value> | 未指定(default) | |
Factor between P and B frame Quants: P フレームとBフレームの量子化値換算係数。Pに適用された平均量子化値にここの値を掛けたものがBに適用される。 | --pbratio <float> | pb_factor=<value> | 未指定(default) | |
Chroma QP Offset: 輝度に適用する量子化値と彩度に適用する量子化値のオフセット。 | --chroma-qp-offset <integer> | chroma_qp_offset=<-12-12> | 未指定(default) | |
Quant Options | ||||
Trellis: Trellis RDO の適用。最終マクロブロックのみか、常時かを選択。要CABAC | -t, --trellis <integer> | trellis=<0-2> | 2 要CABAC |
|
Number of Reference Frames: 複数参照フレームの最大数。 |
-r, --ref <integer> | frameref=<1-16> | 1st,(turbo) 2nd,4 |
|
Mixed: マクロブロック・パーティション単位で参照フレームを個別に選べるようにする。 |
--mixed-refs | (no)mixed_refs | mixed_refs (使用) |
|
CABAC: 圧縮効率の高い encoding stream syntaxを使う。 | --no-cabac | (no)cabac | cabac(使用) | |
No DCT Decimation: | --no-dct-decimate | (no)dct_decimate | nodct_decimate (非使用) |
|
No Fast P-Skip: スキップ検出の非使用。画質向上 |
--no-fast-pskip | (no)fast_pskip | nofast_pskip (非使用) |
|
Quantization matrix: 使用するカ
スタム量子化マトリクスを指定。You must specify the custom matrix. (*mustの意味不明*) |
--cqm <string> --cqmfile <string> |
cqm=<flat|jvt|<filename>> | JVT | |
Macroblock Options: 各 マクロブロックパーティションの使用可否 | -A, --partitions <string> | partitions=<list> | 1st,(turbo) 2nd,all |
|
B-Frames: | ||||
Number of B-Frames: B-Frames (B-VOPs)の最大連続数 | -b, --bframes <integer> | bframes=<0-16> | 3 | |
Adaptive B-Frames: B-Frames の連続枚数を映像内容に応じて自動調節。 | --no-b-adapt | (no)b_adapt | b_adapt (使用) |
|
B-Pyramid: B-Frames も参照フレームに使う | --b-pyramid | (no)b_pyramid | b_pyramid (使用) |
|
RDO for B-Frames: B-Frames にRDOアルゴリズムを使う | --b-rdo | (no)brdo | brdo(使用) 要subq=6以上 |
|
Weighted Bi-Prediction: B-frames を参照フレームに使うかどうかの精度が高まる | -w, --weightb | (no)weight_b | weight_b (使用) |
|
Bidirection ME: 動き予測の精度最適化に前後両方向の時間軸を使う。 |
--bime | bime | bime (使用) |
|
B-Frame Mode: B-Framesのモーションベクトル予測方式。Autoでフレーム毎に最適な方式を選ぶ。 |
--direct <string> | direct_pred=<name> | auto | |
B-Frame bias: B-Framesの挿入傾向を調整。高い程Bを使う傾向が増える。低い程減る。 |
--b-bias <integer> | b_bias=<-100-100> | 未指定(default) |
コンテナは全てのものを統合するパートです。映像(実際の画像)、オーディオ、その他に必要なものは全てコンテナの中に入れておく必要があります。複数のファイルをZipアーカイブの中に入れるような感じです。
コンテナが必要な理由は次のようなものです:
サブページ「コンテナ(英文試訳)」に様々なコンテナの情報があります。
ビデオストリームには実際に表示される映像データが入っています(ここで"動画ファイル"と言う場合はオーディオとビデオが入ったものを指します。"ビデオストリーム"は映像のみの場合に使います)。ひらたく言うと、圧縮された映像です。
これも Matroska のみの機能。 SSA/ASS字幕をmuxする時に、小洒落たフォントを使いたいがそれが再生されるコンピュータにあるとは限らない、といった事があります。Matroskaファイルのそのフォントをアタッチしてしまえば、vsfilter(デファクトのdirectshow用字幕レンダラ)がそのフォントを使って字幕を再生してくれます。
これが何なのかは説明する必要はないでしょう。フォーマットによりチャプタのスタイルは異なります。以下はMatroskaの例です。
<Chapters>
<EditionEntry>
<EditionUID>1</EditionUID>
<EditionFlagHidden>1</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<ChapterAtom>
<ChapterUID>1</ChapterUID>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterDisplay>
<ChapterString>Part A</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>2</ChapterUID>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterDisplay>
<ChapterString>Part B</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterTimeStart>00:09:48.000000000</ChapterTimeStart>
</ChapterAtom>
</EditionEntry>
やっかいですね。次はOGG フォーマットのチャプタです:
CHAPTER01=00:00:00.000
CHAPTER01NAME=Chapter 1
非常に簡単です。もちろん、Matroskaのほうが機能が豊富です。ここでは深入りしませんが、オーダード・チャプタについてだけ少し解説しておきます。
再生時に、動画ファイルの一部分として、他のmatroskaファイルを参照するチャプタ。例えば、TVシリーズをエンコードしたとしましょう。まず、全エピソードのオープニングとエンディングをカットしてそれぞれ独立したファイルを2個作ります。次に、本編ファイルにオーダード・チャプタを使えば、再生時にオープニングとエンディングを自動的に再生してくれます。
MKV と MP4コンテナに埋め込める機能。再生時に使うアスペクト(*縦横*)比の値、 anamorphic再生とも言います。例えば、16:9の映画を4:3のアスペクト比でエンコードした場合、MKVにmuxする際に再生時のアスペクトを 16/9と指定してやれば、再生ソフトは自動的にそのアスペクト比にリサイズして再生してくれます。