C-TOP/コメントログ - ESP @Wiki

• てす、てす、てす、、、 -- (esperance) 2006-03-06 21:40:53
• ブログのページではコメントを投稿する場所等がきちんと定まっていませんでしたので、こちらを使ってご自由に投稿してください。 -- (esperance) 2006-03-06 22:33:14
• こんばんわ。
  デブロッキングループフィルタ 2006/03/27の件ですが、妖精現実さんの速報メモをここにコピペしてみました。
  釈迦に説法ですがおヒマでしたらご笑覧下さい。ではまた。 -- (ばる) 2006-03-28 00:53:00
• こんにちわ。情報をありがとうございます。
  わたしも、このフィルタは確かにアニメには良いけど実写の場合はどうなのかなと思っていたところなので嬉しい情報でした。
  実写に適用するとのっぺりな感じになってしまうけど、切ったらきったで画質の乱れがもの凄いし。けど、ビットレートは使いたくない。っていうわがままなことを考えていますので、やっぱりフィルタはONにしています。
  SNOWコーデックや、mkvは気にはなりますが、例えばその形式でエンコードしたものを、パソコンに疎い人にあげても恐らく再生することができないでしょうから積極的に利用しようとは考えていませんです。
  このメモですと、AviUtilのデノイズプラグインのような処理を組み込めば、フィルタを切ってもよさげな感じに見えますね。
  懐かしや、Waveletプラグイン〜〜 -- (esperance) 2006-03-28 09:36:37
• １）x264のイン・ループ・デブロック
  リンク先はffmpegのコマンド"-obmc"(たぶんSnowとh.263+専用)のそのまたメモとして一時的に貼付けてみただけなので、
  MEncoderのドキュメント（様々なプレファレンスに関わるオプション）の方が良かったかもしれません。
  端的に書くとAVCは原理的にブロックまみれの画像しか吐けないので、後続フレームから参照される前に内部（インループ）でデブロックをかけているという事のようです。
  プリプロセスフィルタ（素材デコード後、エンコード前）をかけても、AVCのブロックは其の後で発生する事になります。
  再生時にデコーダ側でデブロックフィルタをかける手（ポストプロセス？）もありそうですが、Doom9コデックコンテスト2005でAVCでは画像が破滅するとありました。
  
  耳学問ですが先に仕入れてから手を出したんで、手許では切った事がないです^^;
  
  ２）プラグインの件
  ギブアップの件。
  
  MPlayer/MEncoderのビデオフィルタはソースコード"main/libmpcodecs"の中にあります。
  vf_pullup.cとか、vf_filmdint.cとかvf_hqdn3d.cとか
  色関係は良く解りませんがvf_hue.cとか？
  こいつらを挟み込めれば〜どうすりゃいいのかわかりませんが、「共通のソケット」みたいな仕掛けはあると思います〜Macでは無敵かも。一通りのものは揃ってるぽいですし。
  でもAviUtilのプラグイン流用する方が良さそうかも。
  
  以上長文失礼しました。
  ビデオフィルタ・プラグイン、Mac最大の弱点だよなぁ、と常々思うのでつい^^;。 -- (ばる) 2006-04-01 01:10:06
• 
  
  こんにちは。ご助言をありがとうございます。
  最近いつも助けていただいてばかりで大感謝をしています。
  
  RE: 1) の件
  ですが、そういう仕組みだったのですか、本当に勉強になります。私は、突撃するタイプなので押してはかるべしでいろいろとオプションをいじって、回り道をしています。
  なんというか、AVCがブロックまみれの画像をはき出すというのはちょっと衝撃的で、内部フィルタがどんだけ強いんだと驚いてしまいます。先日の件でもう今後このオプションは切らないでしょう。
  
  RE: 2)の件
  ですが、例のmencoderソースを覗いてみましたが、理解するには時間がかかりそうな予感がしています。というか、プログラミングではなく、フィルタリングとか変換とかの数学の分野みたいですのでちょっと大変そうです。プログラムに組み込むにしても時間がかかりそうな気が、、、
  RBGへエンコードもうまくいかず凹んでいます。そもそも変換式通りなのに、RとかGの値がマイナスに振れてしまったり、255を超過したりとうまくいってません。YUV→RBG→YUVの変換はうまくいきまが、中間生成物のRBGの値が〜、って感じです。また、調べれば調べるほどややっこしい分野、というか規格みたいで、気が遠のいています。
  が、この色相や彩度をかまうことが出来ないとエンコーダ以外の世界で起きている映像情報の欠落(YUV420の悲劇)をうまく補完することが出来ないのでなんとして実現したいです。WindowsのGUIとかは後回しで、現在この色関係をどうにかすることを最優先しています。
  
  最近取り組んでいるここら辺のことは、すでにプログラミングから脱却しているような感じですので、ちょっと勉強が必要だなと思う今日この頃です。YUV420画像を生成するところで、ばるさんのページを参考にさせていただいたりと、感謝・感謝の日々です。あのブログは素晴らしいです、もちろんエンコード以外の記事も楽しく読ませて頂いています。ではでは、、、 -- (esperance) 2006-04-01 16:38:33
• 
  なんとなく、'libavcodec yuv rgb' でぐぐってみたら、img_convert()という関数があるみたいで、簡単にRGBへきちんと変換できるみたいです。完璧に見落としていました。なきそうです、昨日ほぼ徹夜なみにがんばったのに、、、orz
  お騒がせしました。 -- (esperance) 2006-04-01 17:11:53
• 
  ■アスペクト比 2006/04/02の件について質問をば。
  
  するってえとあれでしょうか。ここに書かれているような動画はQTではヘンなふうに再生されると思われますか？
  
  手許では必ず横640に統一するのでPARとかSARは未知の世界です^^;
  以前、702x352にクロップしたものを間違って640x480にスケーリングしてしまった事があります。（ソルティレイ#01 オーロラの降る街）
  QTPlayerは当然640x480（全員顔が面長）で再生しましたが、
  VLCはなぜか縦352のまま、16:9（見た目はこっちが正常）で再生しました。
  これはまた別の話かも知れませんが、VLCをQTより重視するキッカケになりました。
  あ、今見たらMPlayer(OSX)も正しい縦横比だ。
  >Movie-Aspect is 1.77:1 - prescaling to correct movie aspect.
  >SwScaler: using unscaled Planar YV12 -> Packed YUY2 special converter
  >VO: [macosx] 640x480 => 850x480 Packed YUY2
  
  でけーっすw
  -- (ばる) 2006-04-03 02:44:35
• 
  こんにちは。ちょっとコメントが長くなりそうですので、ここにページを作成しました。
  多分こうなるのでしょう。 まちがってたらごめんなさい。
  
  -- (esperance) 2006-04-03 19:59:37
• 
  有り難うございます。長らく謎だったSARを肚に落とせるかも知れません。
  
  SAR（Sampling Aspect Ratio）=長方形ピクセルの縦横比。くらいの考えで良さそうですね。
  16:9と4:3の中間解像度である720x480を、いろんな縦横比の長方形ピクセルを使ってなるたけみっちり使おうという事と理解しました。
  こうしたサイズでエンコードするみなさんは、将来のH.264対応DVDを焼く事を視野に入れている、といったところでしょうか。
  
  
  ■無効領域について
  
  「無効領域あり」＝TVキャプチャくらいに考えてます。
  これは「NTSCセーフ」とか「TVセーフ」などと呼ばれるものと同一と思います。TV放送の映像に入っているブラウン管に表示されない「遊び」の領域で、黒帯ではなく映像が入っている（事もある）そうです。
  
  「無効領域crop」は
  パソコンでしか見ないけど、TVに映したときと同じ範囲しか要らない。と言う場合に使うのだとか。
  この場合、TVに映すとさらに「無効領域」が削られて表示されるそうです
  縦の480をキープしているのは、そうしないとインタレ解除フィルタで不都合が出る為と思われます。
  
  「無効領域なし」の720x480素材がどのような形で存在するかは不明です。 -- (ばる) 2006-04-04 04:46:57
• 無効領域というのは、拙blogで書いていたClean Apertureという概念に相当するものでしょう。
  <http://blog.so-net.ne.jp/MyCometG3/2006-01-27>
  <http://developer.apple.com/quicktime/icefloe/dispatch019.html#cleanap>
  QT Movコンテナではこの値を保持していますが、QuickTime Playerではこれを参照せず、Video Trackのmatrix atomとmovieのmatrix atomを掛け合わせて最終的な出力ピクセル数、ピクセル比を決定します。
  <http://developer.apple.com/documentation/QuickTime/APIREF/WorkingWithMovieSpatialCharacteristics.htm>
  ここまでの話はmovコンテナにおける話ですが、mp4コンテナにおいても同様の概念が存在するはずです。
  
  QuickTime Playerの動作は、clean apertureを参照せず、全体を表示しようとします。clean apertureはあくまで最終出力先に対する設定なので、この参照データはテープやビデオやフィルム出力において参照するものとして扱っているようですね。
  
  結局、clean apertureを用いて、実質的なcropを実現することはQuickTime Playerでは出来ないようです。
  
  ／／
  
  >マックのライン入力の音声を録音できるソフト
  こういうのですかね？Classic OS 用のソースですけど、Carbonにしてコマンドラインツールに落とすことはできるかと。タイマーないしSIGINTを受けたら停止処理をするような書き方でよいでしょう。
  <http://members.jcom.home.ne.jp/kaneko.takahiro/QTtools.html>
  <http://members.jcom.home.ne.jp/kaneko.takahiro/SimpleRecorder.c.sit.hqx>
  -- (MyCometG3) 2006-04-10 13:06:23
• おおお、MyCometG3様　コメントをありがとうございます。
  
  >無効領域というのは、拙blogで書いていたClean Apertureという概念に相当するものでしょう。
  
  とのことですが、MP4コンテナで同様なことが可能かどうかちょっとわからないです。そもそも、この端の領域を指定する方法があるのかどうかもわかりません。というか無いようでして、MP4ムービーの作成では、ストリームそのもののサイズと、MPEG4ヘッダ(多分ですが)におけるSampleAspectRatioのみ設定できます。ですので、問題のこの領域をどうにかする方法は、その存在すらもわかりませんです。すみません。ちなみに、この無効部分はデコード完了時にスキップというか、ストライドを調整することによって、エンコード時の入力データでは、すでにその部分の情報を落としたものを利用しています。
  
  出力ピクセルというかサイズに関してですが、再生時にVLCでは補正されるムービーも、Quicktimeでは補正されないんですよね。で、勝手な推測では、QuicktimeはMP4コンテナのSampleAspectRatio情報を、少なくともH.264ストリームに関してはうまくハンドルすることができない、と思っています。で、現状は、デコード結果をリサイズし、SARを1:1にすることで、VLCにおいて再生してもきちんとしたサイズになるようにプログラムを実装しています。
  
  そもそも、MPEG4のファイル構造がどうなっているのか私がわかっていないという問題があるのですが、、、
  
  とにかく、映像エンコードに関しては厄介なことが多すぎて、深みにはまりまくる状況になっていて、げんなりしています。Quicktimeがもう少しHighProfileやB-Frameについて賢くなってくれるといいのですが。
  
  MyCometG3さんの 'movencoder' の発展を楽しみにしています。あの超強敵のQuicktimeフレームワークを利用したソフトをお作りになった力量に(情熱)に脱帽です。今度使わせて頂きます。というかソースを拝見させて頂くかも知れません。そのときは、ご連絡いたします。
  
  最後に、
  >マックのライン入力の音声を録音できるソフト
  
  の件ですが、Windowsに逃げました。爆)
  情報をありがとうございます。CoreAudioフレームワークを使いこなせたらよかったのですが、ちょっと無理な感じがして逃避いたしました。
  
  コメントをありがとうございました。ではでは、、、 -- (esperance) 2006-04-10 21:44:55
• x264のWindowsGUIを探していてここを見つけまして、早速DLして起動してみたのですが、「このアプリケーションの構成が正しくないため、アプリケーションを開始できませんでした」というエラーが出て起動しません。
  何か必要なDLLなどがあるのでしょうか？ -- (D) 2006-07-04 22:08:18
• 
  コメント＆ご使用いただきありがとうございます。
  
  そうだったのですか。Win機が１台しか無いため、検証がおろそかになってしまっていました。申し訳ございません。
  
  現在調査中ですが、しばらく時間がかかってしまうかも知れません。できれば、ご使用のWindowsのバージョンを教えて頂けると嬉しいのですが。 -- (Esperance) 2006-07-04 22:55:18
• お返事ありがとうございます。
  バージョンは、WinXP Pro version 2002 SP2です。
  -- (D) 2006-07-04 23:11:05
• 
  情報をありがとうございます。
  当方でも、あらたにWindowsをインストールして実行したところ、同様の問題が発生いたしました。
  
  原因突き止めと修正に少しお時間がかかってしまうと思います。申し訳ございません。
  
  修正が完了した際に、またご利用をいただけると嬉しいです。
  -- (Esperance) 2006-07-04 23:41:04
• Esperance 様
  
  先日は当方のブログへのご訪問およびコメントのご投稿ありがとうございました。
  以前に“How to Use ffmpegXメモ”の“ばる様”からこちらのURLを教えていただいていた上、ご訪問しても何の連絡も差し上げず失礼いたしました。
  先ほどからこちらのWikiをじっくりと読ませていただいているのですが、参考になる記述がとても多く、感謝している次第です。
  現在、EsperanceXP Light rev98 を使いつつこの記事を書いています。
  直感的なインターフェースで使いやすく、すばらしいソフトウェアだと思います。
  現在のところ、Windows Vista Beta 2 (Build 5384) と Windows XP Home Edition SP2 の両方で動作確認を行っていますが、XP Home SP2のほうでは問題なく動作しています。
  Vista Beta 2 のほうでは、Beta版の仕様なのか、エンコード開始直前のファイル名の決定で躓きました。
  Windows の Beta 版や初期導入版ではよくあることですので深刻には考えていません。
  
  本日は上記のことをお伝えすることと、もう一つの目的として、お願いがありましたのでこちらに投稿させていただきました。
  大変恐縮なのですが、こちらの ESP@Wiki を私のブログのリンクに貼ってもよろしいでしょうか？
  ご返答お待ちしています。 -- (Sylphide) 2006-07-08 00:53:41
• 
  Sylphide様　こんにちは
  
  まずは、動作確認等の情報をありがとうございます。Vistaで試せるとは、羨ましい限りです。
  
  さて、当サイトのリンクに関してですが、ご自由になさって下さって結構です、といいますか、どうもありがとうございます。
  
  少し話はかわりますが、以前にお伝えしたかもしれませんが、GPL系のライブラリとWindows開発環境との相性は経験上よろしくなく、そこで無駄なロスタイムがかかってしまうかもしれません。ですので、よろしければ当プロジェクトのコンパイル済のライブラリをヘッダファイルとあわせてご利用ください。
  それとライブラリ系等でなにかありましたら、ご質問下さい。私自身、開発を通じてかなりハマりまくっていますので、ランダムな確率で何かのお役にたてるかもしれません。
  ムービーの本質に関しては、ばる様の足下にも及びませんが。
  
  それでは、研究開発をがんばってください、いつも影ながら応援していますよ。
  -- (Esperance) 2006-07-08 12:24:44
• Esperance様、ご無沙汰しています。
  
  例の件、まだ実装には至っていないのですが、話し合いを繰り返すうちにバケモノ染みた物になりそうです…
  SD -> HDコンバートの精度を重視するようにしますので、通常の720x480とは違い、ディスプレイ領域をかなり使用することは明白です。
  というわけで、所属研究室の先生が『最低3つディスプレイいるよな？』ってな話が出てきました…
  
  1つは設定用
  1つはソースと直接編集用
  1つは最終出力用
  
  です。
  何か、自分が考えてたより凄いものになってしまいそうですが、内部エンジンはEsperance様のライブラリを参考に作っていきたいので、またご指導のほどお願いします。
  ちなみに入力は主にMPEG2をターゲットにしていますが、出力はライセンスとか絡むと困りますし、PC用動画の作成を謳っていますので、おそらくH.264 High Profileをデフォルトにすると思います。
  
  長文、失礼しました。
  -- (Sylphide) 2006-09-18 22:52:36
• 
  Sylphide様
  
  お久しぶりです。お返事が遅くなってしまい、申し訳ございません。
  
  コメントからどのような方針で進んでいきそうなのかが垣間見えてとても楽しみです。ただ、なんといいますか、猛烈なペースで進んでいかないと、、、な気もしますね。ですので、出来る限りライブラリでコンパイルできない等の無駄なロスをしないように私の出来るサポートをしたいと思っております。
  
  私の場合は、本体作りながら研究ともマージさせていたのでかなり大変でした。けどオブジェクト指向を突き詰めていってなるべくお互いに独立で干渉しないようような構成にすることによって、社会人となってからも趣味として遊べるものができたと思います。
  
  というわけで、話がそれましたが、ちょくちょくプログラミングをしたりして、早い段階でどのようなところに落とし穴があって、構造として本質的に映像・音声というのはどうなっているのかという感覚をつけていくと良いと思います。特に、デコードしたデータ(YUV420に多くの場合なるのですが)、つまり１枚の写真を抜き出す処理というのを早めにものにするのが吉かと。
  
  それプラス、Sylphide様の情熱をぶつけることで、スーパーなものができるのではないかと期待しております。
  -- (Esperance) 2006-09-21 00:26:22
• はじめまして、24fpsと30fpsの混合ソースをカクカクしないようにエンコードできるソフトを探して、あっちこっちうろうろしてましたがようやく理想のソフトに辿り着けました。
  いっそwindowsでaviutlを一から使おうか、と思い詰めてたところだったので本当に感謝です、ありがとうございます！
  EspOSXLightrev.110を使わせていただいてますが、とても快適です。ただ、進捗バーが進まず、残り時間は増えていきます…一応報告までに。
  Macmini coreduo1.66Ghz/High Profile/Bフレーム/デインタレースで12〜16fpsほど出てます。ちなみにBootCamp上のXPでも同様の設定で試用しましたが8〜10fpsでした。
  使用環境 OSX10.4.8　winXP sp2 -- (ink) 2007-02-12 22:26:40
• 
  ink様
  
  初めまして。ソフトをご利用いただきましてありがとうございます。また、嬉しいお言葉、本当にありがとうございます。
  
  >進捗バーが進まず、残り時間は増えていきます
  そうなんですよ。とか言って。普通にキャプチャした素材などでは、きちんとトータルタイムをムービ中に保持しているのですが、切り抜いたり加工したものっていうのは、その情報が欠落しているためにそのようにバグッてしまいます。
  今は、気力がなくて対応しかねています。
  
  なかなか、気まぐれに作成していますので、時々見てやってください。また、何かこういう機能がというものがあったらリクエスト下さいませ。おそらく、開発の原動力となるでしょう。
  
  ではでは、ありがとうございました。 -- (Esperance) 2007-02-15 00:33:00
• ああ、なるほど納得です。もう今や、残り時間が1100〜1200時間以上になると「あ、そろそろ終わるー」という、なんか間違った使い方をするくらいに慣れてしまいました。
  ちなみに色々試して、結局ハイプロファイル・インタレ保持で書き出すことにしました。FrontRowできちんと鑑賞できる事を目指していたのでハイプロファイルもインタレ解除もネックとなっていましたが、それをMyCometG3さんのavc1Decoderが見事に解決してくださいました。素晴らしい連携！
  あとはQTで縦横比を4:3などにして参照ムービーとして保存すれば完璧です。VLCと遜色なくちゃんと見られます。すごいですｗ
  
  新機能追加は、ぜひお願いしたいのがありますよ！
  1.バッチ処理（？）で複数映像ソースを寝てる間にまとめて書き出し。
  2.終わったら音を鳴らすなどの方法でお知らせ。
  
  2はあればあったで邪魔かもしれないのでお任せしますが、1は是非とも！ -- (ink) 2007-02-15 11:05:08
• 度々すみません。ちょっと気になる事があったので投稿させていただきます。
  
  ESPで作ったファイルの映像と音声がずれているような気がして、
  FFMpegX(のx264)で同じソースからエンコードして色々比べてみましたところ、
  ESP動画は、FFmpegX動画と比較して明らかに再生時間が短いのです。
  何となくですが、ビデオトラックの先頭から何フレームかが抜け落ちているような。
  説明が分かりにくいのでQuickTimeのムービープロパティで比較した画像を
  置いておきますね。
  http://inktools.googlepages.com/ESPandFFMpegX.jpg&br()ちなみにFFMepgXで作成した動画にズレはありませんでした。 -- (ink) 2007-03-06 09:21:25
• 前略
  
  TVキャプチャ画像の保存にH.264を使用したいと思い、
  探し回った結果、esperanceに非常に興味を持たせていただいています。
  
  一点、気になることがあります。
  
  エンコード後の画像をきちんと確認したわけではないのですが、
  （H.264のインターレースをffdshowが正しく解釈するかも不明ですが）
  ソースを見ると常にデインターレースがかかるように思われます。
  
  Esperance::presetParamsの冒頭でesp->params->deinterlaceに
  1を上書きしているかと･･･。
  また、入力のwidthで600未満なら0としているのは･･･？
  
  出力はMediaInfoでもMP4Boxでもインターレースを示す記述が見られず、
  本当にインターレース保持となっているのかがわかりませんでした。
  
  的はずれでしたらすみません。
  
  ちなみにinkさんのご指摘は、ffmpegのMPEG2デコーダで先頭１フレームが
  欠けているバグのことと思われます。
  MEncoderでは2フレーム欠けることがあるようで現状ffmpeg/MEncoderを
  使用する限りは避けられないようです。
  インタレ限定のお話かもしれませんが。 -- (うなぴ) 2007-07-04 06:23:08
• 何でもする。舐めてあげるし。入れてあげる。d(´∀｀*)グッ☆ http://gffz.biz/ -- (素人です) 2011-12-08 02:04:12