Layer 2: 別名MP2。かなり稀少。その名称からMP3の方が良いと思う人が多いのだろう。Wikipedia(英文)によると、256kbits以上では MP3 よりも音が良い。
Layer 3: MP3と呼ぶほうが有名。これはオーディオ・フォーマッ トの .avi であり、最も互換性が高い。音質は'平均的'。すなわち、全てのフォーマットのうちでいちばん悪い。しかしファイルはとても小さくなるので、単にビット レートを上げればしあわせになれる。エンコードは LAME (LAME Ain't an MP3 Encoder ~ これは頭文字からつくった名称だから無視していい。LAME は MP3 エンコーダだ)。
AAC、 別名Advanced Audio Coding、別 名MPEG-4 Part 3、別名MPEG-2 Part 7(まぁ、AACでいいだろう)詳細はwikipedia(英文) 。音質はMP3よりも良い。恐らく他のどのコデックより良いだろう。
AACには三種類の 'プロファイル' がある。LC (Low Complexity)、HE (high efficiency)、そして HEv2 (High Effiency version 2)。LC は"ノーマルな"プロファイル。一般的なAACファイルはLCだ。もしも概ね64kbits以下でエンコードするなら(大体の目安。Neroは75- 80kbit程度を使う)、HEにしても良いだろう。このレベルのビットレートではその方が音が良い。同様に、さらに40kbits程度まで下げるなら HEv2を。
ただし、これは理想の話。現実には、作成できるプロファイルに制限のあ るAACエンコーダもある。また、256kbitのAAC-HEv2ファイルを作る理由も無い。そうしたものは256kbitのAAC-LCより音が良い わけでは無く、再生互換性の問題も生じるからだ。再生できるプロファイルに制限のあるデコーダもある(現時点では、まさにiTunes/iPodsだけがHE および HEv2プロファイルをサポートしていない。おそらく将来は対応するだろう。たぶん)。
AACが定義するその他のプロファイルとしては、Main profileとLong Term Prediction (LTP)がある。これらはどちらも非常に面白いのだがツールはほとんど無い。ほぼFAACのみだ。
主なAACエンコーダは三つある(他にもあるがこれらが一般的だ)。
完全にパテントフリーのオーディオコデックで、音質はAACに肉薄する。各所のテストで一等と評価される事もある。'ふつうの'ビッ トレートでは違いはぎりぎり首の差だ。一般的に Ogg Vorbisと呼ばれるが、ここではオーディオコデックのみを指す Vorbisと呼ぶ。というのは他のコンテナで使う事もあるからだ。Oggはコンテナの名前で、一般的にはVorbisはこれに入っている事が多い (.ogg)。Vorbis は、Xiph organizationが他の変なコデックと一緒に開発している。一般的なコデックは一つも無い。
DolbyスタジオによるATSC A/52 規格に準拠したもの。Dolby Digital AC3 は、Dolbyの、基本的にはロシー(*ロスレスの逆*)なオーディオコデックだ。彼らが長年開発している包括的なコデック群のひとつ。DVDと、大半の Digital TV放送でスタンダードに使われている。もしも 音声がAC3 audio のファイルがあったら、通常は音声は素材のままと思って良いだろう。それが望み得る最善の音質だ。しかしながら、ほかのロシーコデックと比べると、非常に 非効率的でディスクスペースを喰う。
DTS (Digital Theater Systems) は極めて高ビットレートのオーディオコデックで、エンコードにおいては先ず使われない。DVD規格の公式コデックだが、対応は必須では無いのでDTSをデ コードできないDVDプレイヤもある。巨大なもの (768 kbps) とむちゃむちゃ巨大なもの (1,536 kbps)の二通りがある。448kbitの 5.1 AC3 の方が768kbitの 5.1 DTSよりも音が良い事に注意。ひらたく云うと、ディスクスペースの無駄でしか無く、これファイルに突っ込むヤツは切腹すベシ。
1
00:00:20,000 --> 00:00:24,400
In connection with a dramatic increase
in crime in certain neighbourhoods,
Style: Default,Arial,40,16777215,16777215,16777215,-2147483640,-1,0,1,1,1,2,30,30,25,0,0
Dialogue: Marked=0,0:25:50.40,0:25:53.06,*Default,Comment,0000,0000,0000,,Kakarrot-o!!
Style: Batou,Century Gothic,28,&H00C0C0C0,&H00000000,&H00000000,&H7F000000,0,0,0,0,100,100,0,0,1,1,1,2,10,10,10,0
Dialogue: 0,0:13:00.11,0:13:03.77,Batou,,0000,0000,0000,,Both our faces aren't meant for mirrors.
timestamp: 00:18:40:752, filepos: 0000aa000
<TextSample sampleTime="00:03:35.980" xml:space="preserve">Please excuse me.</TextSample>
$ which otoolXcodeとX11は入れてある。gccは4.0.1(たしかintel対応一発目)。
/usr/bin/otool
$ otoolなにやら深そうな単語が並ぶ。
Usage: otool [-fahlLDtdorSTMRIHvVcXm] <object file> ...
-f print the fat headers
-a print the archive header
-h print the mach header
-l print the load commands
-L print shared libraries used /*使われているシェアードライブラリを表示*/
-D print shared library id name
-t print the text section (disassemble with -v)
-p <routine name> start dissassemble from routine name
-s <segname> <sectname> print contents of section
-d print the data section
-o print the Objective-C segment
-r print the relocation entries
-S print the table of contents of a library
-T print the table of contents of a dynamic shared library
-M print the module table of a dynamic shared library
-R print the reference table of a dynamic shared library
-I print the indirect symbol table
-H print the two-level hints table
-v print verbosely (symbolicly) when possible
-V print disassembled operands symbolicly
-c print argument strings of a core file
-X print no leading addresses or headers
-m don't use archive(member) syntax
$ otool -L /usr/local/bin/mplayer続いてMEncoder
/usr/local/bin/mplayer:
/usr/X11R6/lib/libXext.6.dylib (compatibility version 6.4.0, current version 6.4.0)
/usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0, current version 6.2.0)
/usr/X11R6/lib/libXv.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/X11R6/lib/libXinerama.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/X11R6/lib/libXxf86vm.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libSDL-1.2.0.dylib (compatibility version 8.0.0, current version 8.2.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenAL.framework/Versions/A/OpenAL (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libfaac.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libmp3lame.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libiconv.2.dylib (compatibility version 6.0.0, current version 6.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 6.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.4.9)
/usr/local/lib/libpng.3.dylib (compatibility version 3.0.0, current version 3.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/local/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)
/usr/local/lib/libungif.4.dylib (compatibility version 6.0.0, current version 6.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/X11R6/lib/libfreetype.6.dylib (compatibility version 6.3.0, current version 6.3.0)
/usr/X11R6/lib/libfontconfig.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libmad.0.dylib (compatibility version 3.0.0, current version 3.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7)
$ otool -L /usr/local/bin/mencoderただ、手許のシステムはいろいろぐちゃぐちゃな筈なのでこのまま先進む前にシステムを入れ替えたほうが良いだろう。
/usr/local/bin/mencoder:
/usr/local/lib/libfaac.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libmp3lame.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libiconv.2.dylib (compatibility version 6.0.0, current version 6.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 6.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.4.9)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libpng.3.dylib (compatibility version 3.0.0, current version 3.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/local/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)
/usr/local/lib/libungif.4.dylib (compatibility version 6.0.0, current version 6.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/X11R6/lib/libfreetype.6.dylib (compatibility version 6.3.0, current version 6.3.0)
/usr/X11R6/lib/libfontconfig.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/lib/libmad.0.dylib (compatibility version 3.0.0, current version 3.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.7)
本文中でIsoMedia fileに言及する事があります。IsoMediaとは、MPEG-4 Part 12規格に由来する全てのフォーマット~MP4、3GP、そしてMJ2K file~の一般名称です。MJ2K fileのサポートはまだGPACではテストされていません。
version 0.2.4以降、MP4BoxはIsoMedia fileのin-place rewrite(入力ファイルの上書き)を行います。この動作は -out Filename オプションで変更できます。
古いバージョンのMP4Boxでは、既存のIsoMedia file(例えばAFILE.mp4)を上書きせず、出力はout_AFILE.mp4のようになっていました。出力ファイル名を変更するには -out Filename オプションを使います。
version 0.2.4以降、MP4Boxは常にファイルを0.5秒間隔でインターリーブ(*交互配置*)し、メタデータを先 頭に書き込みます。これはHTTPスト リーミングに便利なようにです。
通常、MP4Boxは新しいIsoMedia fileの生成時に一時ファイルを作成します。作成場所はOSによって異なりますが、一時ファイル作成に使うドライブやパーティションに充分な空きや書き 込み権限が無いケースもあります。このような場合に一時ファイルの作成場所を変更するには -tmp path_to_dir オプションを使います。
MP4Boxはaudio/video/imageのトランスコーディング(メディアトラックを他の符号化形式に再エンコードするこ と)ができません。 トランスコードには他のツールが必要です。
version 0.2.2以降、プロンプトでオプションの順番を気にする必要は一切ありません。
このページのドキュメントは最新版のMP4Boxについて書かれるものですから、時にGPAC CVSでなければ使えないオプションに言及する事があります。もしも手許で使えないオプションがあったらアップグレードして下さい。
このオプションの多くは入力ファイルの保存方式を指示す るものです。作成、変換、既存ファイルの変更全てに使えます。
-tmp dirMP4Box は以下のファイルを規格に適合した IsoMedia fileに変換できる:
RAW フォーマットとその拡張子:
AV コンテナとその拡張子:
テ キストフォーマットとその拡張子:
変換コマンドの書式は MP4Box -add inputFile destinationFile。こ のオプションは複数ソースからメディアをインポートするのに使う。一般的なMP4boxビルドでは最大で20個の-addコマンドが使える。 destination file が無い場合は自動的に作成し、トラックを追加する。destination fileを削除したい場合は、 -new オプションを追加する事。
MP4Box はinput fileの全体ではなく、任意の量をインポートできる。指定書式は -add inputFile%N、N はインポートする秒数。インポート開始位置は任意指定できないので、常に先頭からになる。
-add オプションを使う場合、MP4Boxは自動的にデフォルトのBIFS と OD トラックを作る。出力ファイルが可能な限り ISMA 1.0 standard に適合するようにだ。出力ファイルの拡張子が .3gp または .3g2だった場合、MP4Box は自動的に 3GP(2) 規格に適合するファイルを書き出す。これは、MP4Box で-addを使うと、システムトラックが除去される事を意味する。これを避けるには -keepsys オプションを使う事。出力ファイルの拡張子が.m4aの場合、MP4Box は自動的に iTunesが必要とする情報を書き込む。
既存のIsoMedia fileを-addオ プ ションでインポートする際、MP4BoxはMPEG-4 または 3GPP(2)規格に適合しない全てのトラックを自動的に 除去す る。そうしたトラックも残したい場合は -keepall オプションを使う事。
テキストインポートに関する注意 : SRT または SUB fileをインポートする際、MP4Boxはデフォルトで字幕が映像の下端に出るようにレイアウトオプションを指定する。したがって、ビデオトラックがま だ一つもないファイルに字幕ファイルをインポートするのは良く無い(デフォルトのSRT/SUBインポートは、デフォルトのserif フォント・フォントサイズ18・ディスプレイサイズ400x60になる)。3GPP timed textに関する詳細は、http://gpac.sourceforge.net/doc_ttxt.php。
メディアをインポートする際に使える各メディア固有のオ プション。non-IsoMedia fileに使えるオプションは、対象のメディアトラックに -info オプションを使う事。例: MP4Box -info 2 file.mpg
-dref :2.から。太字オレ。現実問題として、レコード会社が説得される見込みは薄い。
・結論
レ コード会社は欧州の企業が多い(注:欧州は消費者保護や独占禁止や打倒米国企業者の関係でDRMへの圧力が強い)。アップル に他社へのFairPlayライセンス供与を求めるよりレコード会社を説得してくれ。
4.から。太字オレこの攻撃を、ある程度弱める必要を感じているという事だ。たとえば、こういう論評が出るだけでも緩和は緩和だ。
欧州の一部国家では、FairPlay を開放して、他社製品との互換性を確保するようよう求める声が上がっている。
3.から
iTunesが他の音楽プレーヤーでは働かない、という事 は、欧州で攻撃の的になっています。そこでは、Apple社の制限に「anticompetitive(相互運用性が無い)」というレッテルが貼られてい るのです。
過去8ヶ月の間に、ドイツ、フランス、ノルウェー、オランダといった国の消費者の権利保護グループが Apple社を告訴しています。Jobs氏は彼のエッセイの中で、4社の最も大きい音楽会社のうち3社は欧州の会社なのだ、と皮肉っています。
2. から
(DRM反対論は) 興味のない一般には「頭のおかしい何でもフリー論者のたわごと」くらいにしか思われていないだけに、ジョブズという人物から平易な言葉で語られたというだ けでも意義があります。
MPEG-4規格は"マルチタレント"、あらゆるニーズに応える事を狙っていますので、方式が 3つあります:
1)ビデオビットストリームレベルで指定する方式:
現時点ではこれが最も実用的で、広く使われているやりかたでしょう。PARを指定できるコデック(例:3ivx、ffmpeg/ffvfw、XviD)を
使って、出来上がったAVIをMP4 muxerでMP4にmuxします。この場合、MP4 muxerはなんでも構いません( 3ivx
mp4 muxer, MP4Box or mp4UI)。
既にエンコード済みのビットストリームのPARを変更するには、MPEG-4 ASPではMoitahの MPEG4 Modifier、AVCでは hhanhの ARChange
を使います。もっとも、MP4BoxではどちらのフォーマットでもPARを変更できます。
自動アナモルフィック再生に対応したプレイヤは、VideoLAN、MPlayer。DShowでは、3ivx、Nero か Haali
parsers と XviDの組み合わせ(ARをautoに)、3ivx("force overlay"を使う)、Nero か
ffdshow("overlay mixer"を使う)のdecoder filter。
MP4
では"Composition
Matrix"を使う方式も定義しています。これはアスペクトレシオを変更したり、ピクチャを回転させたり、複数のレイヤーを扱ったり、再生中にオーディ
オストリームを二個ミックス(台詞と音楽が分離している映画など)したり、、、、。
Quicktime/Pro
ではこうしたたくさんのcompositionを扱う事ができます。Movie -> Get Movie
Properties -> Video/Sound Track -> Size/Layer/Volume/...
。またそうしたcompositionを持つMP4ファイルを正しく再生できます。
最も幅広いオーサリングができる方式です(Q9)。AR の変更もできます(例えばTransform2D.scaleを使うなど)。BIFS control streamの作成と再生にはGPAC project tools、つまりMP4BoxとOsmo4を使いましょう。
はい。
タイムコードファイルを使います。これをMP4ファイルにくっつけるか、ASPならn-vopsをドロップさせます。
MP4の大きなアドバンテージの一つは相互運用性と、オープ ン規格な事(ライセンスフリー!)です。これをサポートする非常にたくさんのツールが、全てのプラットフォームで出ています。Mac、Linux、 PocketPC、そしてもちろん Windows。
まず始めに以下の二つが必要です。
splitter/parser filter:再生中に、コンテナファイルを内蔵するストリームに分割するもの(audio, video, subtitles)。
decoder filter:エンコードされたストリームをデコードするもの(例えば ffdshow、3ivx、CoreAAC)。
話がずれますが、AVI用のsplitterをインストールする必要が無いのは、デフォル トでwindowsに入っているからです。
話を戻して、こうしたフィルタを含んだパッケージが入手可能です。MP4のストリーミングについては、Apple
と MPEG4IPが無償で良いツールを公開しています。
ストリーミングサーバとしては、Appleの Darwin Streaming Serverが使えま
す。ガイドはeverwicked とlinuxjournalにあります。
ライブストリー
ミンでは、Linuxのみですが、MPEG4IP の mp4live
が使えます。ガイドは everwicked と MPEG4IPにあります。Windowsでは MPEGRecorder
が使えます(どうやらmp4liveのポートのようです)。
ViTooKi
の toolも試すと良いでしょう(オープンソースのストリーミングサーバ、Player、その他)
Cata
からも、オープンソースのMP4ストリーミングサーバが出ています。
MAC では Live
Channel を見て下さい。
ストリーミング放送の
MP4を再生するには、AppleのQuicktime、RealのRealPlayer
10、MPEG4IPの WMP4Player、Dicasの mpegableおよび EnvivioTV (この二つは dshow
playerです)そしてGPACの Osmo4 (最後の二つは streamed advanced
content/user interactivitiyもサポートしています(Envivioのインタラクティブ・デモ))。
また、 MediaFrame
(demos)
と IBM (interactive demos)のjava
appletを使うと、プレイヤをインストールしなくてもMP4ストリーミングを再生できます!。
MPEG-4規格はAVC/H.264で最新で、技術的にも素晴らしく、state-of-the-artのビデオ符号化フォーマットです。
AVC/H.264 ビデオ符号化規格は2003年に二つの団体で策定されました。ISOのMPEGとITUのVCEG です。ITUは国連の下部組織で、H.263フォー マット(主にビデオ会議のソフトに使われてい ます)を策定した機関です。
AVC/H.264 規格そのものの開発はJVTが 開発にあたりました。これにはMPEG とVCEGの専門家が参加しています。
MPEGサイドから見ればこの規格は MPEG-4 Part 10 (ISO 14496-10)、ITU サイドから見ればH.264 (ITU の文書番号)。 AVC(Advanced Video Coding)という "正式な" タイトルはMPEG側がAACと 並べた時のバランスを考えてつけたものです。
AVC/H.264規格は4種類のプロファイルを定義しています。Baseline、Main、 Extendedお よびHigh Profile。この下にさらにレベル(*参考)による分類があります。
DVD バックアップには、High Profileを次項の符号化ツール(* 要素技術*)と一緒に使うのが一番向いているようです。
MPEG-4 ASP (*試訳)の符号化ツールも読んで下さい。GMC以外はAVCでも使えます。
AVC/H.264では、ビットストリームの記述方式(マクロブロック・タイプ、モーションベクトル+参照インデックス、、、)に、 MPEG-4 ASPより先進的なエントロピー符号化ツールを使います。二種類のエントロピー符号化が 定義されています。
CABACは、AVC/H.264デフォル トのCAVLC (別名UVLC)よりも強力な圧縮方式で、ビットレートを約10~15%節約できると言われています(特に高ビットレート時)。CABACもCAVLCも ロスレスで画質低下が一切ありません。し かしエンコードとデコード速度は低下します。
Loop/Deblocking Filter:(他に、インライン フィルタ、インラインデブロック、などとも)
プレフィルタ(例えばavisynthが行う エンコード前のフィルタリング)や、ポストプロセス/フィルタ (デコーダが最終出力前に行うもの)に対して、ループフィルタはエンコード工程の中で、各フレー ムがエンコードされた後にかけるものです。
厳密にはエンコードの 後、但し、後続フレームの為の参照フレームとして使われる前 の時点です。これは特に低ビットレート時のブロックノイズ減少に効果があります。しかし、エンコードとデコードは遅くなります。
Variable Block Sizes/Macroblock Partitions:
MPEG-4 ASPでは、イ ンター4V、またはインター4MVを使うと、16x16~8x8ピクセルの間でブロックサイズを変える事ができました。
AVC/H.264 では、モーションサーチの精度を決めるマクロブロックの大きさを、4x4ピクセルまで下げる事を提案していま す。これは、8x4のように段階的に下げて行く事もできます。ブロックサイズは映像内容に応じて可変です。
各マクロブロックにどの 程度のブロックサイズを与えれば最も効果的か、その判断 が賢いものが良いエンコーダと呼ばれるでしょ う。
Multiple Reference Frames:
MPEG-4 ASPでは、参照フレームにできるのは直前のフレームのみでした。
AVC/H.264のインター・モーション・サーチでは、複数の 候補から参照フレームを選べるようになりました。
つまり、ビデオコデックはASPのようにシンプルに直前フレームを参照するか、そ れとももっと前のフレームを参照するか自分で 決められると言う事です。 例えば、Pフレームは直前のIフレームよりももっと前のフレームを参照できます。
このため、新しいタイプのIフレームが必要になり ました。IDRフレームです。これはIフ レームの一種ですが、後続のフレームに自分よりも前を参照する事を禁止します。複数参照フレームを使うとエンコード、デコード速度は低下し、カットも IDR フレーム単位でしかできなくなります。
Weighted Prediction:
Weigthed Predictionを使うと参照フレームに「重要性」を付ける事が出来ます。例えば、直前の映像を(ブライトネス方向に) スケーリングできます。
これは特にフェードのある場面、後続の映像が直前の映像によく似ている場合に効果的で す。
明転で明るさが増す場合は除きます。また、フェードを使った場面転 換のような、クロスフェードには効果がありません。
Rate Distortion Optimisation (RDO):
RDO を使うと、エンコーダは2種類の選択肢があるような場合に、それがいかなる局面であれ、最も効率の良い符号化方式を選べるようになり ます(例えば インター符号化とイントラ符号化のどちらを選ぶか、モーションサーチ方式の選択、などなど)。
RDO はAVC/H.264 仕様書の定義にありません。しかし、この新しいアプローチを最初に導入したのはH.264レファレンスソフトウェア(JM)です。他のコデックもRDOを 組み込む事が出来ます。例えば、既にRDOを装備しているXviDのVHQモードのように。
現 在入手可能なAVC/H.264の実装は以下の通りです。
x264、Nero、Apple、Sorenson、Elecard、Moonlight、VSS、mpegable、Envivio、Hdot264 (binary)、DSPR、JM (レファレンスソフト) (binary)、ffmpeg、Philips、FastVDO、Skal、Sony、その他いろいろ。
現 在の実装の中には非常に低速なものがあります。
現在、x264とNeroDigitalの AVCエンコーダは良い速度と画質を実現しているように見えますが、AVCが非常に先進的なビデオ符号化形式である事に変わりはなく、古いCPUでの エンコード・デコードは非常に時間のかかるものになるでしょう。
DVD フォーラムとBlu-rayディスクアソシエーションが現在一般的なDVD フォーマットの後継を目指して活動しています。これはいわゆる High Definition コンテンツ (現行DVDより大きな映像サイズ)と呼ばれる物で、名称をHD-DVD と BD-ROMと言います。
HD-DVDでは、 MPEG-4 AVC/H.264は対応必須のビデオコデックです(こ こに書かれている通り)。
Blu-rayも、MPEG-4 AVC/H.264をビデオコデックに含めました(こ こ(pdf直リン)にあるように)。
以上の事から、AVC/H.264 は、現在DVDの中で使われているMPEG-2 のように、広くサポートされる次世代ビデオフォーマットになるものと思われます。
白黒映画は動画エンコ最大のテキだと思っていたのですが、結構充分なものができました。
もともとXvidでも白黒にはなかなか苦心していたが、闇階調の苦手なx264では文字通り見れたものではなかった。
2005年末、まだMain
Profileで作っていた頃のメモには、1024kbps、640x272、Avg
QP(I)12にもかかわらず、夕闇の中の合戦シーンで闇階調のブロックノイズ多発。群衆の顔なども潰れきっている。印象派のゾンビのようだ。大半のシーンは問題無い。
とある(オレだけ
ど)。
今から見るとscenecut=30と、そりゃブロックノイズが出て当然な設定になっているが、その後、nofast_pskipが登場した後(2006年初頭)でも「第三の男」とか、「ローマの休日」といったロー・モーションな映画で酷い闇階調ブロックが出てトラウマになった。
ビットレートを上げれば全体的な質感は上がるが、闇階調ブロックが出がちな箇所が変わらなかった事から、可変ブロックサイズやskip/directなど、マクロブロックの新しい符号化ツール(要素技術)のチューニングを待つべきと考え、手許では2006年2月頃から白黒映画を録画をやめてしまった。
x264 (r600)コマンド対応でちょっと知識が増えたので一年ぶりに白黒映画を録ってみたところ、頭書の通り、悪くない結果になったのでメモっときます。基本的な設定は070115 -結果&設定篇と大して変えてないです。![]() | ![]() | ![]() |
男の子のコート、このへんのグレイより濃い衣服で闇階調ブロックが出がち。特に背広で目立つ。 壁とか道とか、全く動かない部分では、もう少し濃い色でないと出ない。 女の子のカーディガンは要警戒だが、この三人はほとんど身じろぎもしないせいか、闇階調ブロックは気にするほどでなかった。 |
左端の人のように生地に模様のある衣類では闇階調ブロックはさほど出ない。むしろプリプロセスの方が重要。字幕用にpp=l5を使っているので生地の質感がランダムに荒れる。 右の三人は闇階調ブロックまみれになるかと思ったが、気になるほどではなかった。 |
影の多い場面は「闇階調ブロックノイズ」のビッグチャンス。その気で探すとやっぱちょっと出た。 もう少し影が多かったり、ピントの合ってない奥や手前がもっとべっとり影だったり、パンと複合してたらさらにヤバかったと思う。 |
===MENCODER_PASS2===Avg QP(P):20.40、SSIM 0.987、可もなく不可もなし。落語でもこの程度になる事はある。
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities Altivec
x264 [info]: slice I:1066 Avg QP:18.23 size: 28453 PSNR Mean Y:46.57 U:57.57 V:57.25 Avg:48.13 Global:47.78
x264 [info]: slice P:110035 Avg QP:20.40 size: 6992 PSNR Mean Y:44.95 U:56.56 V:55.83 Avg:46.52 Global:46.15
x264 [info]: slice B:78303 Avg QP:21.96 size: 2700 PSNR Mean Y:44.82 U:56.20 V:55.44 Avg:46.38 Global:46.00
x264 [info]: mb I I16..4: 3.8% 76.0% 20.1%
x264 [info]: mb P I16..4: 0.4% 4.1% 0.9% P16..4: 55.6% 10.4% 5.8% 0.3% 0.2% skip:22.4%
x264 [info]: mb B I16..4: 0.0% 0.3% 0.1% B16..8: 24.7% 1.8% 3.9% direct: 3.2% skip:65.9%
x264 [info]: 8x8 transform intra:75.6% inter:65.8%
x264 [info]: direct mvs spatial:90.4% temporal:9.6%
x264 [info]: ref P 81.0% 10.0% 6.3% 2.7%
x264 [info]: ref B 88.0% 7.7% 2.8% 1.5%
x264 [info]: SSIM Mean Y:0.9873008
x264 [info]: PSNR Mean Y:44.907 U:56.417 V:55.676 Avg:46.470 Global:46.097 kb/s:1024.01
Video stream: 1024.052 kbit/s (128006 B/s) size: 1011221843 bytes 7899.767 secs 236757 frames
SEC ; 36527
TIME; 10:8.47
$ mencoder 1952US_ライムライト(字幕).mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=24:scenecut=65:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=1:threads=2:8x8dct:turbo=1 -passlogfile 1952US_ライムライト(字幕).264.log -vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o /dev/null
$ mencoder 1952US_ライムライト(字幕).mpeg -nosound -ovc x264 -x264encopts bitrate=1024:bframes=3:b_adapt:weight_b:b_pyramid:keyint=240:keyint_min=24:scenecut=65:qp_min=10:qp_max=51:qp_step=4:qcomp=0.6:ratetol=4:deblock:deblock=0,0:cqm=jvt:cabac:direct_pred=auto:nofast_pskip:nodct_decimate:nointerlaced:noglobal_header:psnr:ssim:pass=2:threads=16:me=umh:me_range=32:subq=7:frameref=4:mixed_refs:8x8dct:partitions=all:trellis=2:brdo:bime -passlogfile 1952US_ライムライト(字幕).264.log -vf pullup,softskip,pp=l5,crop=720:480:0:0,scale=640:480:::4,hqdn3d=4:3:6,harddup -sws 9 -zoom -ofps 24000/1001 -of rawvideo -o 1952US_ライムライト(字幕).264
たとえば、2時間じっとだれかの話を聞き続ける。というのは結構シンドイことだと思う。
そうだそうだと相づちを打っても応えてくれない、ため息をついてもぜんぜん気付かない。
一方的に自分のペースで言いたい事を言い続けるばかりの相手だったら、かなりツライと思う。
映画はとても受け身の姿勢を強いられるものだ。
携帯でメール打つ人も居る。退屈な映画でなくてもする人は居る。
一応マナー違反だそうだが、よく考えてみるとそのくらいで集中力を妨げられるというのも妙な話だ。
人はなぜ映画館でメールを打つのか。
2時間じっと、一方的に受け身でいること自体がもともと不自然だからだと思う。
本やマンガは自分のペースで読み進む事ができる。
芝居やコンサートで、客席の空気を感じ取らない演者は居ない。黙って見るのがマナーなジャンルであれ、逆にマナー違反なジャンルであれ。
ゲームの場合、基本的に受け身なのはCPUのほうだ。
力関係の比率は色々だし、相手が人間では無いケースもあるけれど、どれもコミュニケーション、少なくともインタラクティブな要素を持っている。
一般的な娯楽の中では、映画と、テレビだけが違う。
※補足
svn co svn://svn.videolan.org/x264/trunk x264x264 のAPIに変更があれば、MPlayerのソースコードも変更されます。ですからMPlayerも常にSVN版を使うのが良いで しょう。おそらくこの状況は x264が「リリース」されたら変わると思います。それまでの間、x264は極めて「unstable」と考えるべきでしょう。というのは、プログラミン グ・インタフェイスが変更の対象になっているからです(*参考記事:MEncoderの-x264encopts、大規模改訂*)。
./configure && make && sudo make installこれで libx264.a が /usr/local/lib に、そして x264.h が /usr/local/includeにインストールされます。
./configure && make && sudo make installこれでMEncoderのconfigure スクリプトがx264を自動検出するハズです。
もとよりAppleの宣伝は誇大広告 だが、最近のTVCMは酷い。Winコケにする他にアイデンティティねーのか?。
真にMac
OSXのセキュリティが優れているのなら、ミッション・クリティカルな分野が雪崩をうって採用する。
Winがひどいかどうかは知ら
ないが、少なくともAppleはMS同等のセキュリティコスト(金額、人員、時間)はかけていない。
現状、Winよりセキュリティが問題になりにくいのはシェアのおかげであって、これに関してAppleの能力が優れているという事は、無い。
彼らはこれから経験値を積み上げる必要があるのだが、セキュリティ対策というのは地味な仕事だ。
できてて当然の事だし、そのために
客が喜んでお金を払うという性質のものでもない。
もともとAppleが短いサイクルで新版OSを発
売するのは、そうしなければ開発コストが調達できないからでもある。
いきおい、開発は人目を引く派手な新機能が中心となりがちで、
話題になりにくい地味で複雑な部分は後回しにされがちだ。
(VISTAの新機能はほとんど実装済みなのは良いが、Finderの表
示遅延はいつになったら改善するんだ?)
セキュリティの為に3年も次のOSを延期するような芸当は不可能だ。
今のところ大きな問題が起きていないのは事実だが、シェアが上がれば必ず起きる。
あの宣伝につられるようなダメな部類のドザが乗り
換えて来るのは、迷惑だ。
◆◇◆
といって別にセキュリティに詳しいわけではないので、スラドに出たthe
Month of Apple Bugs (MOAB)のまとめ(1, 2)を読んでも良く解らない。
詳しそうな人の評価を
読んでみると、
#2 Mac信者よ、Macを捨てよ(狐の王国:2007年02月14日)というレベルであるらしい。
いくらWindowsがひどいったって、こんな大量に未修正の脆弱性が出たりしないっての。
~
俺もWindows がセキュアだとは微塵も思ってない。だが脆弱性対応はしっかりやっている。それは叩かれた歴史があるからだろう。
Appleはユー ザーに絶賛されても叩かれることは無い。ユーザーの体質が信者体質だからだ。
~
ならばMac信者よ、Macを捨てよ。Appleを叩くことこそがAppleのためだ。
そ れを潜り抜けてこそ、本当に現代的なOSを提供できる企業になれるだろう。
信者はどこの世界にも居る。Macユーザーの全てが絶賛体質でも信者体質でも無い事は2ch/新Mac板に明らかだ。
Microsoft に対する冷静な批判が存在するのは切実に羨ましいが、それは雑誌やwebの情報源が分散しているからだ。根本的な原因は水平分業と垂直統合(部材調達から 搭載アプリケーション、情報の公開・非公開まで全てAppleのコントロールが効く)というビジネスモデルの違いにある。マカーになった本田雅一さんや、 どうやらなりそうな岡田有花さんが厳しい批判記事を書こうと思ったしたとしても、言葉を丸めざるを得ない局面、というのが出て来ると思う。原因は「ユー ザーの体質」などという曖昧なものではない。十把一絡げにしないで欲しい(まぁ外からはそう見えるだろうなとは思う)。
それからAppleは"本当に現代的なOSを提供できる企業"を目指してない。
◆◇◆
端的に象徴してるのはアップル社名変更、Apple Computerから"Apple Inc"へ(engadget: 2007 年1月9日)。
自分がAppleの方向性を疑いだしたのはMac OSXに移行してからだが、「コンピュータ」として使い続けるにはなんだか息苦しいなと思っている。適当に挙げると、
だい
たいMac OSXでサードパーティ製ソフトは一度絶滅してるわけで、なにがしたいんだか不可解だったが、Intel移行のあたりでなんだか見えて来た。
『すいませんパソコンはもうヤメます。これからはAppleソフトの専用機買って下さい。』
ってのを10年くらいかけて言ってたわ
けだ。一年に一文字くらいのペースで。
移行期間を非常に長くとっているのでユーザー負担は少ないと評価する向きはあるけども、どー
だろう。自分の実感としては使いでが減ってるんだが。
手許ではMacで、しか、
扱えないファイルは極力作らないようにしていたり。
偉大なるJobs猊下はApple以外がソフトを作れないよ うにしたいご様子。セキュリティ対策としては最も安あがりだろう。
2006/07/11-PCWatch-本田雅一の「週刊モバイル通信」- PC業界がAppleに学べること
「ジョブズ氏は40~50年という長期に渡 る事業計画を持っており、現在のAppleはその計画に沿って順調に運営されている」 と福田氏は話す。
~
ジョブズとその側近たちは「汎用コンピュータを使う時代から、コンピュータを応用して特定の目的に使う専用機が主流になって いく」と読み、現在へと続く製 品企画の基本的なポリシーになっているという。
Appleはハードとソ
フトとユーザーエクスペリエンスとコンテンツ・ディストリビューションの閉鎖的な垂直統合を目指している。
ひらたく言うと、Mac
に関わる全ての支払いが直にAppleに入る世界を目指している。
図に
するとこうなる。
個人的な嫌悪感はともかく、これはこれでミモノだと思っているあたりが信
者なんだけどね。
やめといたほうがイイっすよMacは。
いまのとこ
ろはまだ辛うじて「パソコン」だし、なんだかんだ言ってOSの設定(システム環境設定)で悩む事はまず無いけども。
むかしむかし
くつしたをはいたねこが
せかいのちゅうしんで あたらしいせかいのはじまりをつげた。
ねこのことばは わからないのだが あれはなにを いっていたのか
なと たまに思う。
数日前からアクセス数が増えている。通常の三倍です!って
感じ。
原因は、一ヶ月ほど前の記事「続・
あたらしい著作権のはなし」が "はてブ・ホットエントリ"に出たから。
"はてブ・ホット エントリ"は一日で平常化するものだが、今回は他のソーシャルブックマーク等にも連鎖し、 最終的に「FC2ブログの人気記事」に飛び火した。これは「FC2ブクマに登録されたFC2ブログの記事」というマイナーな二段抽出ランキングで(すいま せん)、なにしろ被ブクマ数7名、、、で、一位。24日になってようやく二位に落ちた。ランク外の6位に落ちるまではしばらく高アクセスが続くだろう。ブ クマして下さった方に感謝。
一方、一訪問あたりPVは有意に落ちた。もともと1月は1.5~1.6程度。2/5を境に2.1~2.8と向上した。これはゼロから 自作したテンプレートに変更した直後だから、みんないろいろ探したかったんだけどアクセシビリティが悪かったんだと思っていた。はてブに出たのが2/18 日。これを境にもとの1.5程度にまで落ちた。
2/25日に至り、一日で数百件のいわゆるスパムトラバが付いた。
というわけで、動画エン コードに興味のある方のコメントをもらおうというコンタンでやってる身としては、プラスなんだかマイナスなんだかわからん、というのが正直なところです。
ならそんな記事書くなって言われりゃそうなんですけど。でも気になるでしょ?エンコやってると。著作権とか特許とか地デジとか コピワンとかテレビの業界構造とかアニメの産業構造とか、視界の端にちらついてキモチ悪くないですか?けっこー悩んだもんおれ。エンコしてっけどアレどー のかなーとか、x264使ってるけどコレいーのかなーとか。なんでコピワンとかあそこまですんのかなーとか。なんでこんな にアニメ多いのかなーとか。もしかしてこーゆーブログの存在自体、だれかの迷惑になるのかなーとか。
ノイズな
ら、デノイズするのが、エンコ厨(わからんわからん。
Tag:あたらしいXXのはなしは、
そのへんの疑問を考える上で、自分が脳内でざっとひいた補助線です。それ以上のものではありませんし、またそれ以下でもありません。あれはこのブログにあ
るべきものだし、いつか
は書かなきゃいけないものでした。これからも書くことはあるでしょう。
だ
から、はてブのホットエントリのような場所に出て、動画エンコードとは全く関係のない文脈で読み取ったリアクションが出たのは、世間知らずな話ではありま
すが、予想外でした。
はっきり申し上げますと、あれを起点に持論を展開されるにせよ、なにかの参考になさるにせ よ、反発をお持ちになるにせよ、面白いと評価されるにせよ、自分としては「ふーん」というカンジです。わたしはわたしの目に映るものをわたしのアタマで消 化してわたしのコトバで書きました。誰かを怒らせたり傷つけてしまったかもしれないけれど、私にとって のほんとうを書きました。あなたがあなたの目に映るものをあなたのアタマで消化してあなたのコトバで書いていただければ、それがなんであろうとありがたく 拝読します。
その上で。
通常通り、検索でこのブログにたどり着くエン コ厨にとって有用性・相補性・発展性が無いトラバは、スパムと看做して 削除します。テーマの社会的重要性・記事単体の完成度・書き手さんの動機は考慮しません「まずエンコ厨、次に周辺事情、最後にソレ以外」。その判断は自分 で考えて自分で決め、その結果は自分が背負います。詳細はカ テゴリ:☆ここについてをご一読下さい。
いやアクセス増えりゃ普通は喜ぶもんなんですけど、碁に興味の無い人 が碁会所にどやどや入って来るのもまぁ、いろんな見方がありますわな。でも中にはそれがキッカケで碁に興味を持つ方もあるかも知れませんしね。あると嬉し い のですが。巨乳なら別に興味なくても嬉しいですが(黙れ。2月24日までの離脱率は 全体平均 で51.13%。は てブ・ターゲット(表中の1位)は90%に近い。閲覧時間も約3分だから、読んで頂いている。離脱率が高いのは、そこが来た人 の目標地 点って事。つまり大量の人がはてブ・ターゲットに直行直帰。
2007:02/01 - 02/24 | |||||
---|---|---|---|---|---|
\ | ペー ジタイトル | 固有の訪問数 | ページビュー数 | 平 均閲覧時間 | 離脱率 |
1 | 続・あたらしい著作権のはなし | 1984 | 2112 | 163.3 | 89.82 |
2 | Top | 1347 | 1909 | 99.02 | 38.14 |
3 | MeGUIガイド_x264の設定 | 239 | 417 | 183.73 | 39.09 |
4 | MPEG-4の基礎5-ISO14496-10(ビデオ)- AVC | 231 | 257 | 204.51 | 56.81 |
5 | 縦横(アスペクト)比 | 225 | 257 | 355.88 | 70.82 |
6 | cat:動画全般 | 180 | 268 | 52.26 | 30.22 |
7 | tag:MPEG-4 | 161 | 242 | 61.28 | 39.26 |
8 | tag:x264(r600)コ マンド対応 | 150 | 256 | 83.61 | 29.69 |
9 | MP4_faq | 149 | 178 | 320.18 | 55.06 |
10 | cat:MPEG-4全般 | 147 | 222 | 65.48 | 31.08 |
11 | cat:-x264encopts | 136 | 222 | 101.67 | 32.43 |
た
とえば、5位の
「縦横(アスペクト)比」も離脱率が高いが、これは"アスペクト比"を軸にググると、そこそこ出て来る。
SAR/PAR/DARは比
較的需要も高く、このブログの中では直行率が高いほうだと思う。全ての人に完全な答えを提供することなどできないにしても、自力で"アスペクト"という単
語までたどり着いてくれれば、検索開始
からソリューション発見までの時間をなにがしか節約できている。ハズだ。そしてたどり着いたページに「知
識を具体化するために物事を学ぶのではなく、独創的に応用するために、原理から学ぶべきである。」
があったら?大半はヒクだろう。しかし幾ばくかは深入りするのでは
ないか?少なくとも去年のオレなら、する。さらにそのうちの幾ばくかはブログなり2chなりに情報を出す。ハズだ。わたしはそれがほしい。どのみち、全て
の人にとっての完全な答えなど存在しない。
タグやカテゴリの離脱率が低いの
は嬉しい。ここには去年のオレがたくさん来る。もしかし
た
ら来年のオレも居るかもしれない。せいぜい200人ばかりのブラウジング・ルートがx264+aac.mp4のクリティカル・ポイントを教えてくれる。お
いらがドコに深入りすべきかを見せてくれる。このブログは、オレのエンコード工程の一貫であり、IPDSサ
イクルのIであり、情報分析の要である(より一般的にはPDCAサイクルといいます)。
これに対し、はてブ類から来た人は:
「テレビで来る
客」だ。
テレビに出た店にわーっと行って、テレビで見たメニューを注文し、おいしーとかいまいちとか、まぁ良くあるような感想を言って、去
る。
たぶん二度と来ない。
きっと後で「あ、ソレしってるしってる!」「あ、ソコ行った行った!」「あ、ソレ
見た見た!」と言い合うのが、楽しいのだろう。
たぶん翌日には忘れる。
はてブは使ってないけど、おいらだって、"はてブトップエントリ"は見てるし、どっかで同じ事やってんだろうし。それに文句を言う筋
合いは無い。
一方、ウチは常連さん相手のちんまい店なわけだ。一見さんの評論家気取りにうまいのまずいの言われても、お相手は致し
か
ねる。
どっちが上とか下とか悪いとか正しいとかでは無い。WEBにはどちらも必要だ。住み分ければ済む話。
「テレビで来る客」なら話は早い。テレビに出なきゃいい。
一ヶ月前の記事がブクマされた理由だが、どうもYouTubeでJASRACをコケにするビデオというのが人気を取り、その余波がこっちに来たっぽい。
最も早い
ブッ
クマーカーは2/17日、お気
に入り被登録数14、この日はこの方一人。失礼ながら、此方が起点とは考えにくい。
翌18日の一人目が被登録数336。これが
Maxで、この日のウチに30人ほどのブックマーカーさんが後に続いている。
おそらく、この336名へのリーチを持つ ブックマーカーさんが「テレビ局」だ。
この方に「取材おことわり」する方法があれば、それが「住み分け策」なわけだが。んー、ひらたく言うとRSS吐いてる
以上、この方からは隠れようが無い。
なにより、ブ
クマするのはその人の勝手だ。彼らはそれぞれ自分の脳内コンテキストで情報をピックアップしたいだけだし。
あー斯界の最高峰であら
せらるる方々がRSS吐かない理由はこれかー。なるほどー。ぢゃRSSは止めない。意地で。
ならばこのブックマーカーさんの興味を ひきそうな記事を封印すれば済むが、なにを書くかはおれの勝手だ。小手先のテクニックとしちゃ考えん事もないが、それを主軸に据 えたら負けだわな。いやナニにってんでねーけどタマシイ的に。
取材拒否の店戦術、却下。面白みに欠けまくる。
ならば若干のプロパガンダを試みてみよう。
アルファブック
マーカーは、こうした人々の需要に応えています。
テレビを、1:Nの独占型マス・コミュニケーショ
ン・メディアとすれば、
"はてブ・ホットエントリ" は、n:N(少
数対多数)の寡占型マス・コミュニケーション・メディアです。
おんなじおんな じ。どちらも「情報の流通回路にボトルネックがある」わけですから、デ メリットも同質となります(質は一緒だけど量はちがうよ)。
ボトルネックがあるなら、アクセス稼ぎは簡単です。例えばマッチポンプ:
2.と3.は併行で進め、
様々なX,Y軸候補を試作する。対立軸はひとつでも良い。上限は2個。難解になるから。
4.1.の「まだWeb上に存在し
な
い視点」はこの作業過程でヒラメく(参考)。要約が必要なのはこのためです。軸の候補をどれだけ思いつくかがカ
ギ。
も
ちろん現実には経験値がものを言う。地道に蓄積あるのみ。競
合は星の数。スピードが武器。
ワイドショーや週刊誌と同じです。センス無用・主張無用・"日本語で
OK"。短く・簡潔・明瞭に。対立の構図を叩き込め!
この工程は、簡単に定型化・分業化・組織化できます。自動化も夢では無いで
しょう。
その中から一定レベルのものをブックマーカーが選び、編成し、放送するわけです。
こちらはさらに簡単に定型化・分業化・組織化でき
ます。はてぶ。自動化も既にあるようです。そ
れぷら。
個々のアルファブックマーカーの好みは見てりゃ掴めますから、まずはそこを狙いましょう。
コンスタントにヒット記事を生産できるようになれば「ハロー効果(後述)」が発生し、RSS購読者数も増えます。
5名程度でチーム
を組めば、意図的なサ
イバーカスケードも夢ではありません。
だってほら、能力ってやる気の事だし。
「はてブ文脈」で記事を読む限り、意識は「はてブ文脈」の支配下にあります。
そうして読んだ記事を起点になにかを書く限り、その記事も「はてブ文脈」の支配下にあります。
たとえば:
『JASRACをコケにするビデオ』⇒「続・
あたらしい著作権のはなし」。
この順番で情報を摂取した人は、その文脈(集合的な無意識の意識)の支配下にあ
ります。そこから出て来た記事は、私がその記事を書いた文脈とは全く異なりますので、自分には読んでも把握しきれないものがあります。肯定であれ、否定で
あれ、完成度が高かろうが低かろうが。
これは、当該記事に頂いたトラバの話をしています。
すくなくとも自分は、集合的無意識の文脈下で書かれ
た記事にオリジナリティ・コピーライト・尊重に値する原著作者の名誉、といったものは、知覚しにくかったです。ワイドショーや週刊誌にオリジナリティ・コ
ピーライト・原著作者の名誉、といったものが、法律的にはあるのでしょうけど、って思うのと近いです。
基本的に、頂いたトラバは全
て読ませて頂く事にしているのですが、世間的には「スパムトラバ」と見なされるようなトラバの中にも、よほど普段からこのブログを読み込んで下さっている
と感じさせるものがあります。
「その人なりに普段から考え
ている文脈」ではなく「はてぶに出てたからオレもオレも」で記事を書くと、TVのニュースみて「すげぇ」とか「ひでぇ」とか言うのと大同小異になりがちな
のでは
ないでしょうか。
誠に僭越な話ですが、当該記事に頂いたトラバのうち「その人なりに普段から考えている文脈」の存在が知覚できな
かったものは、消させて頂きました。残させて頂いたものも自分にきちんと理解できたわけではありませんし、それが正しい保証もありませんが、そーしろとさ
さやいたのよ。あたしのゴーストが。
もちろん、これは誰が悪いという問題ではありません。
ブックマーカーやブロガーの倫理感や責任感は至って平均的な
レベルのハズです(理由は数が多いから)。
それが高いか低いかは文字にする意味がありません。個々人が自分のソレと比較して決める
問題です。
そもそも「ナニが原因だ!」「何々が悪い!」と解答を欲しがる態度はなんの役にも立ちません。むしろ、それこそ
が諸悪の根源です。
人を叩いてもほら、カラ騒ぎにしかなんねーから普通。
最近だと、子供のいじめ⇒校長いじ
め⇒マスコミ叩き⇒みんな飽きて、いまどうなってんの?しらなーい。
でしょ?
問題解決は、システム的に行うものです。
もしも、現在のはてブの状況
になんらかの問題があるならば、それは人々の倫理感や責任感が低いのではありません。
それは無数のブックマーカーが
「はてブ」でできる範囲で、その有効性を最大限に活用
する方法を探して努力を重ねた結果に過ぎません。
そして無数のブロガーが、その有効性を最大限に活用する方法を探して努力を重ねた
結果に過ぎません。
逆に言えば、倫理感だの責任感だのはシステムで規定可能です。
アクセス数を欲しがった瞬間に、オレはテレビ局となる。
アフィリエイトを付けた瞬間に、オレはテレビ局となる。
ブロガーとしてのオレの倫理観や責任感は、オレではなく、使う道具に規定される。
自分はBlueDotを 使っています。
それはそれとして、はてブコメントは読ませて頂きました。 やっぱ嬉しいし。
三分の二くらいに はコメントがなかった。まぁ、ブクマだし。タグを読むものだよねきっと。「JASRAC」に、なるのかアレわ。ふーん。「あとでよむ」っていうのは、 まぁ、読まないよね^^;なん かザッピングっぽいな。
ついてたコメントは、概ね楽しんで頂けたようで嬉しかったです。みなさん冷静ですな。ふたつほど、「◯◯には反対、XXには同意」 とい う、引用と異論と総論を押し込んものがあった。100字にそれを押し込むのは時間かかったと思うし、読む方としても喰い足りないなぁ。それではてブ、やめ たんすよオイラ。たくさん書くならBlueDotいいすよBlueDot。
やっぱテレビの前でわいわいダベってる雰囲気はありますね。ニュースを一緒に見て、あーだこーだ言う。と。
そ
ればかりでもナニだが、それも楽しげ。
どこで読んだか忘れましたが、そういうのは社会の統合性を保つのに不可欠な要素なのだそうで
す。
ところで。
小寺さんがフィードバックの少なさを嘆いていたのを思い出した。自分が直接エンコに関係しない記事を書く時は、小寺さん
のカキモノがキッカケになる事が多いので、読み返す読み返す。
ネットから長文が消えたいくつかの理由 (3/3)(小寺信良さん: 2007年02月05日)
※太字オレ
筆者がやるように、サーチエンジンから逆リンクを辿ってやってくるという可能性は、考えてもいないだろう。今多くのブログはこのような「ブックマーク系」 となり、ブラックホールのような存在となった。その人に何が入力されたのかはわかるが、出力がほとんどない。
文 章を書くのが苦手という人は少なくない。だがあなたが何かモノを考えるときには、なんらかの言葉が脳内で鳴り響いているはずである。人間は言葉なしに、考 えることはできない。またこれができるから、人間は動物から袂を別って進化したのである。
言葉なしにできる の は、「感じる」ことだけだ。しかしただ感じているだけでは、次の行動を自分で論理的に類推することができない。遺伝子の命ず るままに反応するだけである。
性
狷介にして権高な
文体になりがちなオイラは、小寺さんの「のへっ」とした文体が大好きなの
だが、これはなかなかキツい言い回しだなぁと思った。これはいつもの小寺さんでわない。ヤサグレコデラさんだ。だってオマエラソレデモニンゲンか
あっ!って言い切ってる、よねこれ。実はこの先はさらにスゴい。草稿段階では、ガラスを割ったり先生を殴ったりする暴力コデラさんだったんでわないかとい
うく
ら
い、激しい。アタマの良い人はそういう行動を潔しとしない。代わりに大上段な理屈で周囲の圧倒を試みるものである。つまりこれは「盗んだバイクで走り出す
コデラさん」である。
などと勝手な事を想像しているウチに、フィードバックの少なさが寂しくなるほどだったのだなと思った。
そこで「ハ
ロー効果」というのを思いついた。
自分は「喰い足りない」で済んだけど、職業ライターの小寺さんには追加効果「ハ
ロー効果」がある。それがフィードバックを減らす。
ハ
ローっていうのは「後光」の事で、仏様とかキリスト様とかのアタマの後ろから出てる光の事。ハロー効果ってのは窓を背にして話すと説得力が増すという、心
理学だか交渉戦術だかの用語だ。でもここでは「権威」とか「有名」みたいな意味で使いますよ。
うおーこれは小寺 さんが書いたものだーと思うとやっぱオレ平伏して読むし。読み込むし。BluDot のタグに「小寺信良」って付けて疑問持たな いし。そりゃもう天竺から来たありがたいお経も同然であり、うかつに意見など挟もうものなら恥をかくばかりでなく稲が枯れ疫病が流行りカミナリに打たれて 死後裁きに会ってはら いそさ 行けなくなったりしねぇだか?と思う。ついでに天国で私を待つという100人の巨乳処女がおれのぶんだけ全員微乳に格下げされたりした 日にゃあ、死ぬに死ねない(死ねばいいのに)。
いやマジで。わたくし決してウソは申しません。
方
便は大好きですけど。方便と巨乳?ん~~~~~~~(死ねばいいのに)。
まじめな話「根拠の無い仮説だが24fpsのほ うが記憶に残る説」とか、自分は小寺さんの記事でなければ、読んだ瞬間に「それわインターレース縞など見えないってのと同様の社会適応だべ?」と思っ たと思う。24fps撮影ってほとんど映画だし。60Hz映像に比べれば中身が大きく偏っている。と、思い立ったのは三日くらい 後の話で、その間は「お~、そーゆーものなのかー」と平伏していた。脳はともかく、肚のほうではいまもしてる。だってコデラさんの直感なんだぜ?切り捨て ちゃイケナイ気がする。
WEBの敷居が下がれば、全体の平均値 も下 がる。相対的に「ハロー効果」は上がる。さらにマスコミの信頼性が落ちても「信頼性の高い情報需要」は無くならない。てゆうかむしろ上がる。このぶんも個 人ポインタの「ハロー効果」に乗っかって来るんじゃないか説。ひとびとの依存心と言って も良い。
やな言い方だがそれが現実だとおもわれ。「ブックマーク系ブラックホール」には打つ手がない。WEBの敷居が下がれば、全体の平均値も下がる。選択肢が多くなると人は自分で選ぶのをヤメるもの だ。一方でアクセス狙いのコピペログ、煽り志向のマッチポンプログ、アフィリエイト狙いのテレブログは増えてゆく。テレビやマスコミに「情報を選んでもら うスタイル」に慣れた人々のWEB流入は今後さらに増える。団塊世代とかどうよ?退職後にメディアに対する姿勢変えるなんて無理よ普通。「はてブ・ホット エントリ」はいつか必ず納豆騒動の起点となる。場合によっちゃマスコミの権威がぐんっと揺り戻すシナリオもアリだと思う。
、、、 サムい時代と思わんかね?とか言ってる場合ぢゃないよな。別にサラミス一隻しか無いわけで無し(なんのハナシだよ。
この国には、はてブとは毛色の異なるSBMが必要だ。
はてブ文化圏、てのがあるかどうかは知らないけど、国内のソーシャル・ブックマークはもう ちょい分散したほうが良いと思う。独占は腐敗と停滞を産む。独占は腐敗と停滞しか産まない。
BlueDotには 充分に長いコメント欄、ブクマのパーマリン ク、それを見た人が書き込めるコメント欄、が揃っている。印象を長々と書きたい場合も吐き出せる。てゆうか吐き出してるオレ。てゆうかただのコピペログに なってる。これで「オリジナリティの無いコピペ記事」 はあんまりここには書かないで済んでる、、ああ、いえ、すくなくとも主観的にはですけど。で、そこに突っ込んだコメントを拾って「このブログの下書き」に してる。これをFC2のサービス上で完結できればそらもうそっちの方が断然ラクなわけで。
SBM版天下三分の計、と洒落込むにはも うひとつ、ライブドア・クリップにも期待したい。RSSリーダでBloglinesを超え、さらに自前のブログ・サービ スも持っているからには、こちらにも「ブログのネタ帳」を志向して頂きたい。「ブログのネタ帳SBM」に期待する要素はナニカ? 500文字以上を受け付けるコメント欄は当然として:
それはアウトライン・プロセッサと、TiddlyWikiを合体したもんが欲しいだけなんちゃうんか<オレ。
あとはてなはWiki
を始めたらすごい強そうに思うんだがなぜやらないんだ。
たぶん、あのねこは こういったのだとおもう。
じょうほうかくめいは ひとのかくしんです
ぎじゅつが ひとや しゃかいを かえるのではなく ぎじゅつを てにした ひとりひとりが じぶんでかんがえて じぶんでかわるのです。
技術に使われているあいだは、後世、歴史家が情報革命と呼ぶ事は
ないでしょう。
だってそれならただの技術革新で充分ですからね。
生きてる間に見てぇなぁ。
ま、テレビの客も年に一回く らいなら悪く無い。気をつけよっと。
ageha にオリジナル無し
そ の他、書いてる途中で浮か んだことども
*メジャーならそれが全てか?常識は全てか? ブログとはなにか?日
記?ニュースにコメントするも
の?
オレの目には『テンプレート付きデータベース・アプリケーション』に見えた。すくなくともFC2に関
する限りは、そうだ。
ならその真価をしゃぶりつくしましょうってのが此方で、
ありがたくおコボレにあずからせて頂いております。
(自慢げにゼロから自作したテンプレートとか書いてなかったか?書いたよな?<オレ)
今のデザインなら日本表現規制史年表 1868~1993もそのまま取り込める。システム 上、1970元旦が限界くさいのだが。
*普段からスパムも全部読むしオレ。
なにを考えてうちなんぞにと思って読むと、結構楽しい(あと巨乳)。*それにしてもなにかの厭がらせのように長い
もしも、全部読んで下さった方がいらっ しゃいましたら、ありがとうございます。おつかれさまでした。m(_ _)m$ /Users/ageha07/Desktop/ffmpeg_SVN-r8028u
FFmpeg version SVN-r8028, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --cross-compile --arch=powerpc --cpu=G4 --enable-static --disable-shared
--enable-gpl --disable-vhook --disable-ffserver --disable-ffplay --enable-amr_nb --enable-amr_wb
--enable-pp --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libdts --enable-liba52
--enable-libogg --enable-libvorbis --enable-libtheora --enable-xvid --enable-x264
libavutil version: 49.3.0
libavcodec version: 51.33.0
libavformat version: 51.10.0
built on Feb 20 2007 05:58:55, gcc: 4.0.1 (Apple Computer, Inc. build 5367)
usage: ffmpeg [[infile options] -i infile]... {[outfile options] outfile}...
Hyper fast Audio and Video encoder
-L | ライセン スを表示 |
-h | help を表示(*オプション抜き実行で出る*) |
-version | version を表示 |
-formats | 利 用できるformats, codecs, protocols, ...などを表示 |
-f fmt | 特 定フォーマットの使用を強制 |
-i filename | 入 力ファイル名 |
-y | 出 力ファイルを上書き |
-t duration | 録 画時間(*recording time*)を指定 |
-fs limit_size | ファイルサイズの上限を指定 |
-ss time_off | 開始時刻のオフセットを指定 |
-itsoffset time_off | set the input ts offset(*不詳*) |
-title string | タイトルを文字列で指定 |
-timestamp time | タイムスタンプを指定 |
-author string | 著作者を文字列で指定 |
-copyright string | コピーライトを文字列で指定 |
-comment string | コメントを文字列で指定 |
-album string | アルバム名を文字列で指定 |
-v verbose | ロ グ表示の量を指定 |
-target type | ターゲットファイルタイプを指定 ("vcd", "svcd", "dvd", "dv", "dv50", "pal-vcd", "ntsc-svcd", ...) |
-dframes number | recordするデータフレームの数を指定 |
-scodec codec | 特定の字幕コデックを強制 ('copy' to copy stream) |
-newsubtitle | 現在の出力ストリームに新しい字幕ストリームを追加 |
-slang code | 現 在の字幕ストリームにISO 639 language code (3 letters) を指定 |
-vframes number | record するビデオフレーム数の指定 |
-r rate | フ
レームレートの指定 (Hz value, 分数,または簡略形 (*29.97 などを正確な分数値に内部変換するとおもわれ*) ) |
-s size | フ レームサイズの指定 (WxH または簡略形) |
-aspect aspect | アスペクトレシオ指定 (4:3, 16:9 or 1.3333, 1.7777) |
-croptop size | クロップ幅上 (in pixels) |
-cropbottom size | クロップ幅下 (in pixels) |
-cropleft size | クロップ幅左 (in pixels) |
-cropright size | クロップ幅右 (in pixels) |
-padtop size | set top pad band size (in pixels)(*不詳*) |
-padbottom size | set bottom pad band size (in pixels)(*不詳*) |
-padleft size | set left pad band size (in pixels)(*不詳*) |
-padright size | set right pad band size (in pixels)(*不詳*) |
-padcolor color | set color of pad bands (Hex 000000 thru FFFFFF)(*不詳*) |
-vn | ビ デオのdisable |
-vcodec codec | 特定コデックの強制 ('copy' to copy stream) |
-sameq | 素 材に等しい画質にする (VBRになる) |
-pass n | pass 番号の選択 (1 or 2) |
-passlogfile file | 2パスログファイル名の指定 |
-newvideo | 現 在の出力ストリームに新しいビデオストリームを追加 |
-pix_fmt format | ピ クセル・フォーマットの指定(*不詳*) |
-intra | イ ントラフレーム(*Iフレーム*)し か使わない |
-vdt n | discard threshold(*閾値を破棄?*) |
-qscale q | 映 像を固定量子化エンコード (VBR) |
-qdiff q | max difference between the quantizer scale (VBR)(*量子化スケールの最大幅?*) |
-rc_eq equation | レートコントロール方式を式で指定 |
-rc_override override | rate control override for specific intervals(*不詳*) |
-me method | 動 き予測方式の選択 |
-me_threshold | 動き予測の閾値 |
-strict strictness | 規格適合性を尊重する度合い |
-deinterlace | インターレース解除 |
-psnr | 圧 縮されたフレームのPSNRを算出 |
-vstats | 映 像符号化の統計をファイルにダンプ |
-vhook module | insert video processing module(*不詳*) |
-intra_matrix matrix | specify intra matrix coeffs |
-inter_matrix matrix | specify inter matrix coeffs |
-top | top=1/bottom=0/auto=-1 field first(*インターレースの フィールドオーダー指定?*) |
-dc precision | intra_dc_precision(*不詳*) |
-vtag fourcc/tag | force video tag/fourcc(*ビデオタグまたはfourccの強制*) |
-qphist | QP ヒストグラムの表示 |
-vbsf | bitstream filter (*不詳*) |
-aframes number | record するオーディオ・フレーム数を指定 |
-ab bitrate | オー ディオ・ビットレートを指定 (in kbit/s) |
-aq quality | オー ディオの品質を指定 (各codecによる) |
-ar rate | サ ンプリング・レートを指定 (in Hz) |
-ac channels | 音声チャンネル数の指定 |
-an | オー ディオをdisable |
-acodec codec | 音声コデックの強制 ('copy' to copy stream) |
-vol volume | 音 声ボリュームの変更 (256=normal) |
-newaudio | 現 在の出力ストリームに新しいオーディオストリームを追加 |
-alang code | 現在のオーディオストリームにISO 639 language code (3 letters)を指定 |
-atag fourcc/tag | オー ディオタグ/fourccの強制 |
-absf | bitstream filter(*不詳*) |
-scodec codec | 字 幕コデックの強制 ('copy' to copy stream) |
-newsubtitle | 現在の出力ストリームに新しい字幕ストリームを追加 |
-slang code | 現 在の字幕ストリームにISO 639 language code (3 letters) を指定 |
-vc channel | ビデオ・グラブ・チャンネルの指定 (DV1394 only) |
-tvstd standard | テレビ規格の指定 (NTSC, PAL (SECAM)) |
-isync | sync read on input |
-map file:stream[:syncfile:syncstream] | 入力ストリームのマッピングを指定 |
-map_meta_data outfile:infile | 入力ファイルをもとに出力ファイルに書き込むメタデータ情報を指定 |
-benchmark | add timings for benchmarking(* どう訳すのだこれわ*) |
-dump | 各 入力パケットをダンプ |
-hex | パ ケットをダンプする際にペイロードもダンプ |
-re | 入 力をネイティブ・フレームレートで読み込む |
-loop_input | ルー プ(今のところ静止画のみ対応) |
-loop_output | ループをサポートしているフォーマットでループ回数を指定(0で無限ループ) |
-threads count | thread count(*不詳*) |
-vsync | ビ デオ同期方式 |
-async | オー ディオ同期方式 |
-vglobal | ビ デオのグローバルヘッダの保存タイプ |
-copyts | タ イムスタンプのコピー |
-shortest | finish encoding within shortest input(* 不詳*) |
-dts_delta_threshold | timestamp discontinuity delta threshold(*不詳*) |
-ps size | パ ケットサイズを指定。単位bits |
-muxdelay seconds | demux-decode delayの最大値指定 |
-muxpreload seconds | demux-decode delayのイニシャル値指定 |
ページ タイトル | 固 有の訪問数 | 離脱率 | memo | |
---|---|---|---|---|
総合計 | 15,877 | 51.25% | ||
1 | 続・あたらしい著作権のはなし | 2166 | 89.51 | |
2 | ageha | 1623 | 38.76 | |
3 | MPEG -4の基礎5 - ISO 14496-10 (ビデオ) -AVC | 289 | 57.89 | 2/11に全面見 直し。 |
4 | MeGUI ガイド_x264の設定 | 286 | 40.00 | 初出1/21。
MeGUIは中期的な汎OSエンコ環境候補(mono, AviSynth 3.0)。リンク集を付加すべきか? |
5 | 縦 横(アスペクト)比 | 267 | 71.29 | |
6 | カ テゴリ:動画全般 | 236 | 32.85 | 適切な離脱率とい うのはあるだろうなぁ。 |
7 | MP4 faq | 227 | 58.87 | 2/11に全面見 直し。 |
8 | tag:MPEG-4 | 213 | 40.89 | タグのand検索 ができれば良いのだが。 |
9 | カテゴリ:MPEG-4全般 | 189 | 31.25 | タグとカテゴリの and検索ができれば良いのだが。 |
10 | MP4Boxの主要コマンド | 188 | 60.85 |
種 類 | 比 率 |
---|---|
Win | 82.75% |
Mac | 12.04% |
Linux | 2.96% |
その他 | 2.25% |
種 類 | 比 率 |
---|---|
PPC | 71.49% |
Intel | 28.51% |
種 類 | 比 率 |
---|---|
XP | 85.61% |
2000 | 10.75% |
Vista | 1.51% |
98 | 1.43% |
Server 2003 | 0.53% |
NT | 0.10% |
ME | 0.07% |