アニメのエンコに賭ける青春って幸せ！

今のＩＴ時代に生まれて幸せだよね！
エンコに乾杯！
もうＶＨＳやＬＤなんてポイポイ！

アンチ関連スレ（↓撃破希望）
青春をアニメのエンコに浪費しちゃダメ！
http://pc.2ch.net/test/read.cgi/avi/1021476498/l50

↑　それは各板を巡回挑発してるﾁｮﾋﾞﾝスレ

>2
他の板にも「青春をアニメのエンコに浪費しちゃダメ！」
って立ってるってこと？
（俺アニメエンコしてるけどアニメや漫画系板は全く巡回
してないもんで）

ＭＰＥＧ（アニメ）
ＪＰＧ（エロ画像）
エミュレータ（ゲーム）
ＭＰ３（音楽）
全部ＰＣに入れてある。最高じゃ！

火事になったらＰＣもしくはＨＤＤ持って逃げる。
家族は助けない！

　　 ,,,..-‐‐‐-..,,,
　　 /::::::::::::::::::::::::ヽ　　　　　　　 _,..-‐‐-..,,,
　　l::;;-‐‐-:;;::::::::::::ヽ/／-‐,,__ ／:::::::::::::::::::::ヽ
　　l:l　　　　ヽ:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ヽ
　　ヽ　　 ／　　　:::::::::::::::::::::::::::::::::::::;-'^~~^'‐;;:l
　　　~ヽ/　　　　　　::::::::::::::::::::::::::U::ヽミ　　　.ll
　　　　/　／￣^ヽ　　　::::::::::::::::::::::U:::ヽ　　,.ノ ∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧∧
　　　 /　 |　　・　.|　　　　　:／￣^ヽ:::::::l'^~ .＜
　　‐/-,,　ヽ,＿,,ノ　　　　　 |　 ・　　|:::::::l　　＜
　　 l　　~^''　　　　　`‐'　　 ヽ.,＿,,ノ　　:l　　＜　　 |　ヽ　　　　　　　　　　　　　　　　　 　　 /￣￣＼
　　'''l^^~~~　　 　/￣￣ヽ　　　 -‐‐‐--l-　 ＜　　 |　　ヽ　　　＿＿　　　　　　　　　　　　　　　　　 ｜
　　　ヽ、　,,,,　　| |||!|||i||!| |　　　~^'‐..,,_/　　＜　　/ 　　　＼　　　|ノ　　　　　　――――　　　　　／
　　　　/ （:::::｝　| | |ll ll !!.| |　　　 ,,,,　イ~'''　 ＜ ／　　　　　 ＼　丿　アアァァ　　　　　　　　　　　｜
　　　 l:　　~~　　| |!! ||ll| || |　　 ｛:::::） ::l　 　 .＜　　　　　　　　　　　　　　　　　　　　　　　　　　　 ●
　　　l:　　　　　　| | ! 　　| l　　　 ~~　　l　　　＜
　　　l、　　　　　ヽ`ニニ'ノ　　　　　　 ,l＞ 　　　V V V V V V V V V V V V V V V V VV V V V V
　　　/^‐-,,____,,,,,,,,..................,,,,,,,__,,,.--ヽ
　　　~‐‐'~　　　　　　　　　　　　　^'‐‐~

闘おうよ！＞アニヲタ達

こ　の　板　も　Ｍ　Ｘ　厨　の　黒　い　影　に
　染　ま　り　つ　つ　あ　る　よ　う　だ　な　。　

MX?ﾌﾟｯ
今はfreenetだろ。

MXは誰が何をやってるかバレバレだからな・・・

あーあ、Ｗ杯つまらんね。

>>10
ｱﾆﾒ面白い？

Yaeh!スバッとアニメタイム！

aviutlのノイズ横線除去って時間喰うよね

>>13
そんなときはミンキーモモでズバッと解決！

　逝　っ　て　よ　し

アニメなんて黄金バットしか知りませんが何か

>>16
知ってる知ってる、大金持ちが正体なんだよね
ロビンていう子供の味方とかもいたよね

>17
大金持ちが酔狂で全身髑髏姿で小学生の女の子を追いかけるアニメ…（・∀・）ｲｲ!

_

なんなんだこのスレ

http://freehome.kakiko.com/tuk/iiyo.html

もう青春なんか終わってるし

自分で終わりと思った瞬間に終わるんだ！

俺は40になっても青春さ。

アニメの画面ってどうやって切り取るの？

やっぱりハサミでは？

鮎原さん！

（＾＾）

アニヲタはＭＰＥＧか？

（＾＾）

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

保守

age

てｓｔ

tst

てｓｔ

てｓｔ

tets

tets

またageられたので例によって移転。
というわけでここからは
アニメのエンコに賭ける青春を幸せにするためにAviUtlModを妄想をしたりしなかったりするスレ
をお送りします。
別名MakKiのチラシn(ry

過去スレ
http://pc5.2ch.net/test/read.cgi/avi/1021290135/76-
http://pc8.2ch.net/test/read.cgi/avi/1052933503/85-

エイプリルフール企画でTOPページをAviUtlModのお部屋に差し替えて見ましたが…
誰も見てないですかそうですか。

AviUtlModのお部屋自体は今まで通りの場所に存続ちう。
誰も気づいていないと思うとほんとに寂しいので掲示板に…だれかーー

>>http://pc8.2ch.net/test/read.cgi/avi/1021290135/109
そこはすでに過去スレなんですよこれが。

ほとんど進んではいないですが中止もしてないですよん。
ただ、Modのお部屋にもあるように、
>期待して裏切られても作者は一切の責任を負わないものとします。
ほんとに時間ないんです、勘弁してください。

目標：GW中に読み込んで表示させるところまで

まにあわなかたー
STLなんてなれないもの使ったせいで。。。さらに文字列処理に躓いて。。。
まぁいいや、ぼちぼちやっていこ。

ソフ板Utlスレの746氏にお応えして、頑張ってる証拠を(嘘)。
ttp://mksoft.hp.infoseek.co.jp/aviutlmod/ss.jpg

後ろに映ってるウィンドウプロシージャがやる気の無さを物語ってる('A`)

すごい勢いで晒されてるぅー
もはやここも時間の問題か。。。

こっちか
こっそり見守らせて頂きますね

俺たちってなんで生きてるの？

最近彼女出来たせいで撮り溜めたコピワンソースをキャプする暇がない

ttp://kukuku.ddo.jp/ku30/ku30.html　1648
シャープ感を増してみた。やっぱり職人さんが参加しないと盛り上がらないね

誤爆ｽﾏｿ

二度も上げられたうえ誤爆もされてるけどいい感じに廃れてるので移動しないということで。

>53
少し前に彼女出来たせいでAviUtlModを開発する暇がない。
いや、暇が無いのは本業が忙しいせいだが。学会逝ったりとか。

ソフ板よりコピペ。
確かに不便だけど、対処法は・・・右クリメニューに「全てのプロファイルに適用」をつけるとか？

741 ：名無しさん＠お腹いっぱい。：2005/10/21(金) 17:04:31 ID:6autrzl10
一つの映像の中で、プロファイルをいくつも作って編集しているのですが
編集し終わってから、新たにフィルタを全編にわたって掛けたい場合、
全てのプロファイルに一気に掛けるにはどうしたらいいですか

>>56
お疲れ様です。

Avisynth版の透過性ロゴフィルタ 使わせてもらってます。ありがとうございます。
AviUtlばかりじゃなく、Avisynthのフィルタも開発してください〜

120fps化したアニメを再圧縮しようとすると
フレーム数が多くなって普段４０分ぐらいで終わるのが2時間かかる
なんか良い方法はないでしょうか？

>>58
だから喪前はコピペするなと

すみませんでした。

行方不明リスト

AviUtl フィルタ [http://www1.speednet.ne.jp/~chiba_01/]
　　カラーイコライザ (c_equalizer.auf)
未定 [http://www.geocities.co.jp/SiliconValley-PaloAlto/2380/]
　　ウォーターマーク除去 (delwm.auf)
　　ウォーターマーク抽出 (wm_output.auo)
物置 [http://plaza25.mbn.or.jp/~jacing/]
　　32bit AVI input(32bit_avi_input.aui)
Maikichi's "Rubbish Box" [http://www21.u-page.so-net.ne.jp/xc5/maikichi/software.html]
　　DirectShow Reader for AVIUTL (Dshow.aui,DshowGrabber.ax)

SS更新
ttp://mksoft.hp.infoseek.co.jp/aviutlmod/ss.jpg

とりあえず画像を表示した。RGB24しか読めないけど。
次はデコーダ周りをいじくる予定。

アニメのエンコに賭ける青春って幸せ！

　　　　　　　　改め

アニメのエンコに賭ける青春って幸せ？

　　　　　　　　改め

アニメのエンコソフトの開発に賭ける青春って…orz

去年と同じですた。。。
ﾈﾀ用意してなかったんです…勘弁してください。

Doxygen導入してみる

期待age
いや下げるけど（ｗ

同じく期待age
sageでも気にしない方向で

期待して裏切られても(ry
むしろsage推奨で

Doxygen用のコメント書くのに忙しくて開発が進まないという本末転倒な状態ｗｗ

これまで書いた部分を整理できるからマイナスではないさ、きっと。
いずれ役に立つと信じて…

時間無ええええええええええええぇぇぇえぇぇぇぇぇぇえぇぇぇぇぇぇぇえぇぇぇぇぇ！！！！！！！！！！！！！

帰宅。疲れた。寝る。

甘辛の辛は唐辛子の辛じゃ無いんだよ！！！！！！！！！！！！！１１１１１１１
醤油の塩辛さだ馬鹿垂れが！！！！！！！！！！１１１１１１

カプサイシンなんていう神経毒を喜んで口にしてる奴等は
唐辛子の食べすぎで早死にするがいいわ

馬鹿げたブームの所為で俺の食べれるものが減っていく…
今に始まったことじゃないが。

どうでもいいけど、aviutlmodまだですか？
dougaα、reenaみたいなAvisynthのGUIフロントエンドでもいいから早く作ってよー
ずっと待ってるんだぞっ！

>>73
待ってるのはお前だけじゃないんだ
辛抱強く待つ精神が大事だぞ

>>74
ｽﾏｿ(´･ω･｀)

>>073-075
ｽﾏｿ('A`)

英文書いてみようと思ったけど無理でしたorz

開発そっちのけでAlexのAVI File Format Documentationを和訳ちう。
いずれAVIのMuxerも実装しなきゃならないから役には立つさ。
（むしろ誰かに作ってもらうために資料をそろえてるとか

>77
和文でいいから書いてよ。俺の代わりに。さぁ手足となって俺様に尽くすのだ

いちおう翻訳かんりょ。Alexに鳩飛ばさないと…

英文書くのたりー

今日の日記

鳩飛ばした。
ｺｿｰﾘHTML書き直し。

来年中にできそう？

Alexから鳩が帰ってきた。
Of course, that's fine with me.
だってさ。

よって公開
ttp://mksoft.hp.infoseek.co.jp/doc/avifileformat.html

>81
来年？そんな未来ことは知りませんよ、予知能力者じゃあるまいし。はっはっは
とりあえず、今年中に入力部分だけ完成させて公開できればいいな、と。
フィルタ部分や出力部分はまだまだ先。

やばい、AVIでのVBR音声の同期の新しい方法見つけちゃった…
とりあえずMP3では確認済み。
俺の予想が正しければ、VFRなVorbisでさえ同期取れてしまう。Nando超えたね。
どうしよう。どうするべき？どうしたい？どうなってんの？どういういことよ。

とりあえずAlexに鳩とばすのがいいか。もしくはDoom9に殴りこみか…
Mod完成させて実践するってのは時間かかりすぎるな…

年末の休みにMOD開発して実装、それが一番！

鳩飛ばしてみるとあんまり荒れなくていいかも？
doom9に投げると色々と論議してくれそうだけど…

その部分だけ実装したmodだそーぜ
形にすれば意欲もわくしテストもできる！

年末年始休みってなに？おいしいの？

wfx.nBlockAlignの値の扱いがはっきりしたら、とりあえずやり方ここに書きます。
Utlとmp3_input.auiとバイナリエディタがあればおｋ

学部生の実験の世話で徹夜明けです。おやすみなさい。

それはやり方ではなくて必要なものな気がする…
年末年始？当然休みなんてねーよ('A`)

おはよ。
やり方は、はっきりしたら、の後で書くって意味だったんだが・・・
まぁいいや。大体わかったので。

やり方：
�@ビデオとVBRMP3音声を用意
�AUtlでビデオを読んだ後、mp3_input.aui経由でVBRMP3を音声読み込み
�B再圧縮なしで出力。音声サンプリングレート/1152/インターリーブ間隔が
　ビデオのフレームレートより小さくなるようにインターリーブ間隔を設定
　（48000/1152=41.67なので、120fps化とかしてなければ大丈夫なはず）
�C出力ファイルをバイナリエディタで開き、音声のAVIStreamHeaderのdwRate, dwScale書き換える
　dwRate/dwScale = ビデオのフレームレート/インターリーブ間隔　になるように。
　（例えば、ビデオが30000/1001fpsでインターリーブ間隔が5なら、dwRate=30000,dwScale=5005）
�DWAVEFORMATEX::nBlockAlignの値も書き換える（MP3なのでMPEGLAYER3WAVEFORMAT構造体だけど共通だからｷﾆｼﾅｲ）
　AVIStreamHeader::SuggestedBufferSizeより大きい値にする。（同じでもいい）

構造体の場所は>>82のAVIファイルフォーマット参照。

WinXP環境持ってないんで、誰かテストしてくれると助かります。XP以外でもよろ。
あといろんなプレイヤでもやってみてください。

Win2k,WMP,MPCでは確認済み

一つ工程を書き忘れた。同期には関係ない部分だけど。
AVIStreamHeader::dwLengthの値も替えとかないといけない。
正確にはwbチャンクの数にするんだけど、とりあえずビデオのフレーム数/インターリーブ間隔で。

俺には何言ってるのかまったくわかんねーぜ
みんなｶﾞﾝｶﾞﾚ

ヘッダ書き換えツールをでっち上げるべきか。

MacOSX10.3:QT,DivXPlayerで確認。
MPlayerはシークできないので微妙だけど、再生した限りではずれてないぽい。

今日も予定通り徹夜コースけてーヽ('q`)ﾉ

バイナリエディタでなんとなく挑戦
したけどなんか間違った模様
再生不能

帰寝

ヘッダ書き換えツールでっち上げた。やり方とかは中のreadme。
ttp://mksoft.hp.infoseek.co.jp/aviutlmod/vbrsync.zip

こっちのURLも張っとく
ttp://mksoft.hp.infoseek.co.jp/aviutlmod/mp3_input.zip

AVIUTLでAVIとVBRなMP3を読み込んで、再圧縮無しインターリーブ3で出力
vbrsyncに放り投げて、AVIUTL出力時と同じインターリーブ値3を入力して書き換え
なんか間違ってる？

作り方に問題があるのかよくわからないけど
だんだんズレたり音が飛ぶ事があったりしてやっぱりだめっぽい。
ちなみにXPSP2な環境
テストに使ったのはMPC+ffdshow-tryoutsとMPlayer

やり方は大丈夫。
音が飛ぶとかって負荷の所為だったりしない？あるいはデフラグされてないとか。ありえないか。。
シークした時もずれてたりする？

シークしてもズレっぱなし
一昨日トラブってXP入れなおしたばかりだから断片化の可能性とかはないはず
CPU負荷眺めてても20%程度でかなり余裕あるよ

ヘッダちゃんと書き換わってるか確認してもらえる？
D&Dでやった場合、たまにExprolerがプレビューのために
ファイルの読み書き権を握ったままで書き込みに失敗する場合があるので。

D&Dじゃなくてコマンドラインでエラー出ずに終了してるのは確認できてるんですがね
バックアップ取ってStirlingで比較してみたところ
一応書き換わっているのは確認できてるけど合っているのかはよくわからないですね
色々手元のサンプル変えて試してるけど未だにズレないで大丈夫なのが一個もない・・・

むぅ、てことはXPでは使えないのか。。。

XPSP2使ってる友人に確認してもらったが、ズレてなかったそうだ。
やり方に問題ないなら、環境依存なのかも試練。

とりあえずAlexに鳩飛ばした。うまく伝わるだろうか…

なんかよくわからんがｶﾞﾝｶﾞﾚおまいら

2k使ってる人の所に持っていってみたがやっぱりずれていた
環境依存というよりも用意したファイルに問題ありそう…

別の人に適当なの作ってもらったらちゃんとズレてなかった
やっぱり用意したファイルに何か問題があるって事で確定

ぼちぼち原因探ってみます

検証乙。ということは同期の手法自体は問題なさそだね。

ｽﾝﾊﾞﾗｽｨ(;´Д｀)ﾊｧﾊｧ

薔薇スィー(;ﾟД｡)ﾊｧｰﾊｧｰ

一ヶ月以上にも及んだ徹夜実習ただいま終了。
毎週2回貫徹は正直疲れました。心身ともにぼろぼろです。
おやすみなさい。

Alexの反応はどうなのかなぁ

鳩帰ってこない…地磁気が乱れて迷ったのかなぁ…

VBR同期AVI出力実装までに必要なこと
・音声入力の実装
・デコーダ系の実装（省略可）
・デコーダプラグイン（省略可）
・出力系の設計と実装
・同期処理プラグイン
・AVI出力プラグイン

音声入力とデコーダ系は今年中に出来ると思うけど、そこから先がやっかい。
出力系の設計がヘタレてると他フォーマットへの応用が利かなくなるしなぁ。
OGG(OGM)とMKVの仕様を調べないと。できればmp4とかも。
誰か分かりやすい日本語ドキュメント教えて（もしくは書いて）ください

鳩が帰ってこない。どうやらAlexにシカトされたぽい。Mod作って実装するかー

STL…便利なんだけど、、、例外処理なんてキライだー

やっぱりdoom9に投げた方がよかったのかね

マルチストリーム対応作業難航ちう。いい処理方法が思いつかない…
入力系もう一回スクラッチから始めたほうがいいかな…？

>>114
doom9だと真っ先にwhy dont you use mkv?と突っ込まれるね。
hack is very fun!て返せば良いけどｗ
どしよかな・・・

入力系が行き詰まったままなので、しばらく放置して、VBR音声 in AVIについて文書でも書こうかしら

ABRってだめぽ？

ABRはエンコード時のビットレート管理方法が違うだけのVBR

予告どおり書いたので針
「AVIファイルでのVBR音声の同期方法」
ttp://mksoft.hp.infoseek.co.jp/doc/vbrinavi.html

最近規制に巻き込まれること多いな。。
ppp.dion全体って運営側はDIONに恨みでもあるんだろうか。

やっぱりABRだとちゃんと同期できないファイルが出来上がる・・・

>120
ん？どゆこと？
ABRで作っても出来上がったMP3ファイル見ればただのVBRMP3になるはずなんだけど。
詳しく。

再現したかも。ABRだとだんだん音が遅れてくね。
Utlの再生ウィンドウの時点でずれてるから、mp3_inputのバグの可能性が濃厚。

今までLameオプションかなと片っ端から疑って、ABRが悪いって見つけたつもりだったけど
input側だったか…

うーむ、家に戻ってデスクトップで試したら再現しないぞ？
ABRでも普通に同期取れてる。さて、またわからなくなった…

む、今使ってるのとWeb上のとでmp3_input.auiのタイムスタンプが違う！
ソース見ると、wfx.nAvgBytesPerSecの計算が改善されてる。…原因これか？

とりあえず差し替えたんで、検証よろ。
http://mksoft.hp.infoseek.co.jp/aviutlmod/mp3_input.zip

↑でABR同期ズレ問題解決
あっさりと解決してよかったよかった

また巻き込まれてたorz

>126
検証乙。
解決したというか、すでにされてたと言うか、、、小人さんありがとう。

マルチストリーム対応に向けて設計見直しちう。
入力の管理方法をソースファイル単位からストリーム単位にすることにした。

流用できるのはプラグイン管理部分だけだな…
スクラッチからの方が早いかも

マルチストリーム対応作業順調にすすんでます。
ビデオストリームは多分おｋ
音声ストリームはテストちう

あとデコーダ呼び出し部分を作ったら、今の酷すぎるUIを何とかしてから公開します。
その後はまず入力プラグイン（マルチストリーム対応AVI1.0）とかVCM/ACMデコーダとかの開発。
プラグインSDKまとめとくので誰かやってくれるっていうなら本体を進められるけど、
そんな暇人いないだろうなぁ…

ｷﾀ━━━(ﾟ∀ﾟ)━(｡Ａ｡)━(ﾟ∀ﾟ)━(｡Ａ｡)━(ﾟ∀ﾟ)━━━!!!!

暇過ぎるほどに物凄く時間余ってはいる

この土日は温泉逝ってくるので進展しません。今年度中には公開できると良いな。

>131
じゃ、まかせて良いかな？
デコーダプラグインの仕様変更すること決まってるんでアレだけど、基本は変わらないから。
ACMの使い方
(acmFormatSuggestで出力形式を調べる)
acmStreamOpenでACMストリームオープン
acmStreamSizeで出力サイズを取得
acmStreamPrepareHeaderで出力用の構造体を準備
acmStreamConvertで変換
acmStreamUnprepareHeaderで出力用の構造体を破棄
acmStreamCloseでACMストリームをクローズ
VCMの使い方
ICOpenでコーデックを開き
ICDecompressBiginでデコーダ初期化、形式を指定
ICDecompressでデコード
ICDecompressEndでデコーダを閉じ
ICCloseでコーデックを破棄

ﾜｸﾜｸﾃｶﾃｶ

aviutlのmodということで公開すればutlのプラグイン作者も色々手伝ってくれるように思う
更新するって強みがあるからね
ﾜｸﾃｶが止まらねーｗ

念の為言っておくけど、今年度中ってのは入力制御部分のみしかできてない状態での公開ですよ？
フィルタはおろか出力さえできない状態の。

http://pc10.2ch.net/test/read.cgi/avi/1158496416/294 から転載

http://www.faireal.net/ (2007-02-22の記事)

Windows Vistaで作ったAVIは壊れている VirtualDub作者が確認

Vista用のAVIFile関数のライブラリに不具合があり、
これを使った場合????AVIを書き出す多くのアプリがこれを使うのだが????ファイルのヘッダがかなりおかしくなり（注）、
Vista以外で再生できなくなることもある。VirtualDub (VD) の作者 Avery Lee がブログで明らかにした。

→ AVIFile library in Windows Vista creates invalid AVI files
http://www.virtualdub.org/blog/pivot/entry.php?id=145

VirtualDubは、APIを使わず自力でヘッダを書くので、Vista上でVDで書き出したAVIファイルは正常だが、
Vista上の他の一般のアプリで作ったAVIの読み込みに問題がある。
「Vistaで作ったAVIをXP上の古いWMPで再生したら、クラッシュした」とも報告している。

簡単に直せる問題ではないが、VD側では将来のバージョンで壊れたVista製AVIを正しく読み込めるように対応するようだ。

「Microsoftに苦情を言う以外、根本的な解決はない」とのこと。
サービスパックなどでライブラリが修正されるまで、
Vistaユーザーは、Vista上で動画作成（AVI作成、他形式のための中間形式としてのAVIも含む）を行うべきではないようだ。

（注）AVIファイルのRIFFヘッダは厳密に言うと、正しくないことが多い。
例えばVDMで書き出すと常にサイズがおかしくなっている。
しかしそれらは現実的にはまったく影響のない問題。
「かなりおかしくなる」というのは、そういう些末なレベルでなく、再生できなくなるほど壊れている、という意味。

修正ツールが既に作られてた。
ttp://doga.jp/2007/programs/vistaavi/index.html

うーんどうしたらいいものか...

;;;;;ヾ);;;)　　　　　　　　　　　　(;::));;;;;;;;;
;;;;;ヾ);;;)　　　　　　　　　　　　((;::);;;;;;;;;
　;;;;;ヾ);;;)　　　　　　　　　　 (;::));;;;;;;;;;
!l ;||}、　　　 _,,..,,,,_　　　　　　　 ;{ｌｌ;;
: :ll;| ~ヽxxx/ ,' 3　 `ヽｰっxxノ~ |!!;;:
;;;!l }　　 ﾐ三三三三三三彡'　　};!
|ｌ　!|　　 ｀^｀ﾞﾞ''"""~~ﾞﾞ"´~　 　 ﾉ;;::
ﾍﾊﾍゞ　　　　　　　　　　　　　"^ﾊﾌﾞﾍ

ごめ、葬式だったり引っ越しだったりで今年度中は�_
Synthのdelogo更新だけで勘弁して

まだ今年始まったばかりだYO!!
諦めたらそこで試合終了ですよ

規制に巻き込まれ杉。
delogoは更新完了。いんたれYV12にてこずったけどなんとか間に合った。
とりあえず引越し終わるまで停滞しますー

>141
今年はたっぷりあるけど、今年度はあと10日無いんだ。ゆるしてー

ネタ仕込み完了

いや仕込むよりも何か他のをｗ

まぁまて、引っ越し終わったばっかでPCしか箱から出してないんだ

嘘だけど。引っ越しは本当。

保守

進行状況どう？

進んでないっす。ちょっと別口のネットワークプログラム弄ってた。

Mod専用プラグインの仕様が拡張性低かったんで考え直し中。
GWはMod弄る予定。デコーダプラグイン周りをやっつけるのが目標。

うーむ、対応するデコーダが無かった場合でも開けた方が良いよね。
簡単な処理はできるように。コンテナの移し替えとか。

ソースストリームと編集ストリームを別々に弄らないといけないのか・・・ﾏﾝﾄﾞｸｾ('A`)

とりあえずビデオはデコーダプラグインの中を通るようになった。
次は音声でも実装。

今年中にaviutlmod完成して過疎ってたスレも大盛り上がり…という夢を見ました

たとえ盛り上がってもここ見てるのたぶん数人しかいないから。過疎は過疎

AVIsynthみたいなスクリプト使えるようにキボン

スクリプトの柔軟さとGUIでの画質調整、フレーム確認ができれば最強ｯｽ

プラグインSDKっぽいものすらできてないのにソレは無理だろｗ
でもavsfilterとかみたいに移植できたらいいね

それ前に考えたことあるんだけど、
スクリプト読んでフィルタとして働くフィルタプラグイン作れば
今のAviUtlでも可能じゃない？

おまいらおまたせ！

例のページからいろいろ落とせるようにしといた。ただし、過度な期待は禁物。
とりあえずこんな感じ。
ttp://mksoft.hp.infoseek.co.jp/aviutlmod/ss.jpg

それじゃ数ヶ月放置します。

了解
とりあえずいぢらせてもらうわ

ｷﾀ━━━( ´∀`)ﾟ∀ﾟ)*ﾟーﾟ)･ω･) ﾟДﾟ)´ｰ`)･∀･)￣ｰ￣)･Ａ･)´Д｀)丶｀∀´>━━━!

おちゅ＞＜

んでこれはプラグインさえ作ってもらえればば動くの？
てか放置するのかYO

入力プラグインはUtlのをそのまま使えるよ。
デコーダがRGB24bitとYUY2用しかないから、それ以外だとデコードはできないけど
入力プラグインさえあればファイル自体は読み込める。
YUY2は受け付けるけど、YUY2→RGBの変換を実装してないから表示は悲しいことになるがとりあえずｷﾆｽﾙﾅ。

やらなきゃいけないことを放置してModいじってたんで、
そろそろ取り返さないと本気で不味いので。

>>161
modってなにが新しいの？
他の動画編集ソフトでできないフィーチャーって何？

とりあえずこの辺を読んでくれ。
ttp://mksoft.hp.infoseek.co.jp/aviutlmod/aviutlmod.html#about

ぶっちゃけた話をすると、技術的興味でしかないんだが。

あ、いい忘れてた。
デコーダプラグイン無しだとRGBやYUY2すら受け付けないから、
pluginsdkのraw_dec.aumも放り込んでおいてください。

無くてもファイル自体は読み込むんだけどね。

ドキュメント読んだけど、ほとんど何も書いてないやんけｗ
オープンソースだから開発を有志でできるってこと？
ﾏｯｷｰはどんなもの目指したいの？
AVIUTLの機能を全部フォローした上で、機能拡張を目指すの？

あー技術的興味かぁ
別に金もらってるわけじゃないからねぇ

ドキュメントはソースコードのドキュメントだからねぇ。
引数と戻り値くらいしか書いてないよ。
doxygenでコメントが付いてる＝実装済み っていう見方をしただけな気がする。
あと、どこから呼ばれてるのか表示してくれるのは便利。

開発したい人は勝手にやってくれってスタンスじゃだめですか。
本気で有志を集めるならsourceforgeあたりに置いたほうがいい希ガス。
それよりも、プラグインを作る時に内部でどうなってるのか分かるように、ってのが大きいかな。

とりあえず妄想を列挙すると、
- Utlのプラグインが使える
- いろんなファイル形式/圧縮形式に対応（プラグインで拡張可能）
- AVIコンテナの性能を限界まで引き出す
- デコーダが無くてもコンテナの変換やカット編集くらいは出来るようにする
こんな感じか。

これからやりたいこと、
それをエンドユーザーにわかるようにｱﾅｳﾝｽしてくれるとわかりやすいんじゃないかなぁ
カット編集、VBR音声をGUIで正しくカットできるツールは今のところないからそれは新しそうっすねぇ
コンテナなんだけど、今現在AVI以外のマイナーコンテナ、mkv、mp4のGUIによる編集ってﾑﾘなの？
そういうのは全部プラッグインにお任せかな

これからやりたいこと：とりあえず本業の方を頑張るorz

AVIですらﾌﾟﾗｯｸﾞｲﾝにお任せですがなにか？

実はAviUtlの入力プラグインって現状のままでも結構応用が利くのよ。
圧縮ストリームをそのまま渡せるから。
AviUtlでもmkvの入力プラグイン作ればmkvを読めるし、
再圧縮なしでAVIに吐き出すことさえ出来るはずだよ。
ただしVCM,ACMでデコードできないとUtlが弾くけど。
誰も作ろうとしないのかな。

エンドユーザに分かりやすくってのはまだやりたくないんだ。開発序盤だし。
大部分がプラグイン任せになる予定だから、どちらにせよ初心者向けにはならないと思うけど。
現状ですでにプラグイン無しでは非圧縮AVIすら読めないしｗ

いっそのことCUIにしてしまおうかｗ
コアとUIを完全に分離してあるからわりと簡単。

まだその段階じゃないってことなんね

とりあえずCUI化には一票ｗ
応用が利きそうだし、他アプリとの連動もおもしろそう

研究だけど一応学業？ｶﾞﾝｶﾞﾚ

適当にデコーダ書けば他も読めるようになるって事かな
調べてみるか

プラグインSDKこっそり差し替え。Makefileが含まれてなかったのなおして、あとコメント書きまくった。
ついでにソースコードドキュメントも更新。書きまくったコメントが反映された。

本体mingwなんかで通るかなーとか試してみたけどさすがに無理かｗ
入力周りのプラグインいぢって遊ぶのが今のmodってところかね
ところで…sourceforge辺りに置いたり〜ってことはしないのかな

sourceforgeって便利？
ライセンスどうしようか考え中なのもあって保留してたけど、どうしようかな。

mingwでもコンパイルは通るようになった。
修正はtypename付け忘れが3箇所と、不要なtypedef1箇所削除だけですんだ。

でもリンクが通らないorz テンプレート周りでひっかかってる。
rpoファイルもリンクしてみたけど、シンタクスエラーとか出やがる。
mingwのバージョン変える元気はもう無いので寝る。

とりあえずファイル上書きしといたからあとよろしくー

sourceforge便利か？といわれるとそうでもないって感じ
CVSとかでソース管理とかで更新時の差分取れるのは便利かもしれまい

そういえばライセンスファイル入ってませんでしたね
おおっぴらにソースごと公開しちゃうなら、そこら辺で有名なLGPLとか？
でもヘタなライセンスつけると後が面倒か･･･

とりあえずmingw遊びしてくるー

ttp://sakuratan.ddo.jp/uploader/source/date40138.zip
mingwでmake出来たんで差分とmakefileうｐ
こんなの要る人居ないだろうけどｗ

俺にはお前らが宇宙語話してるようにしか聞こえんぜ

>176
gccほとんど使ったこと無いから助かるよ。ありがと。

>177
ok, i summarize and translate to the language on the earth for you.

173: it cannot be compiled by mingw....
　　by the way, how about make this project on sourceforge?
174: is sourceforge useful? i'm still thinking about it ....
　　anyway, i made the sourcefile correct.
　　now mingw can compile it but cannot link.
　　but i have no vigor. good night...zzz
175: some services are useful but....
　　ok, i'll diddle with mingw;)
176: i could make it by mingw, and i upload the differential files.
　　but who wants it? lol

どっちみち宇宙語はな(ｒｙ

>>178
てめえそんなのやる暇あるなら早く論文に纏めろと

YUY2悲惨なのどうにかしようと思ったけどさっぱりわかんねーｗ

>180
忙しい時ほど無駄なことをしたくなるのさ

>181
いちばん簡単なのはMainWindow::ShowCurrentFrameかCore::GetFrameRGBあたりで
画像取得した後でYUY2かどうか確認して変換にかけるとか。

RGB<->YUY2は内部形式を経由させたほうが色々楽だし、
内部形式への変換もプラグインにする予定だからVideoManagerクラス作る時に実装するつもり。

よくわからんけど、aviutlは内部色空間とか、丸め込み誤差が、とかで遅いけどsynthより高精度らしいじゃん？
それを自分で切り替えられるようにして欲しい

0.99の失敗を繰り返すのは嫌です。プラグイン使えなきゃ意味無いし。
速度重視するならSynthを使ってください。そっちのが便利だし。

---

内部処理についていうと、
・YUY2やRGB24bit,32bitでは、色の要素は各8bitの解像度を持つ。
・Synthは各要素8bitで処理しているため、フィルタ毎に8bit精度への丸め込みがおこる。
・Utlの場合、各要素を約16倍した内部形式でフィルタを掛け、出力の時に8bitへ丸め込む。

つまり、Synthでは四捨五入や切り捨てといった丸め込み処理誤差が蓄積するから精度が悪い。
Utlは喩えるなら小数点1桁まで計算しておいて、最後に四捨五入して整数にしているからようなもの。
そのため精はが良いが、各要素を16bitで保持しているため、メモリアクセスが倍必要になるから遅い。

遅い理由は実装方法にもありそうだけど。
FILTER_PROC_INFOから推測する限りUtlはPUSH型な設計。それに対してSynthはPULL型。
フィルタが前後フレームを参照する場合、PULLの方が無駄は少ない。
キャッシュで多少軽減されてるけど、func_procが同じフレームに対して何度も呼ばれることあるし。

まっきーの言ってることが半分も理解できません＞＜
開発っていうのも難しそうだけど、楽しそうだな

utlmodはmkv出力可で、タイムコードを挿入できるのが欲しい
俺スクリプトでEasyVFR改使って混合処理して、それutlに食わせて後からタイムコードを入れてmkvにMUXってやってるから手間なんだよね
…まぁmodじゃなくてプラグインの問題だと思うが(´･ω･｀)

そこら辺は出力プラグイン作れば現状のaviutlでもできますです。
混合処理周りも無理すれば何とかできる範囲だったりもします。
ただ誰も作らないというだけです…

タイムコード管理はmodに組み込もうとは思ってる。
入力、フィルタ、出力の間でやり取りできたほうがいいし。

出力はUtlの出力プラグインとは別の形を考えてる。
というのも、今のプラグインは非圧縮データしか渡してもらえないでしょ。
だからmkv出力プラグインを作ろうと思ったら
エンコードする部分もプラグインがなんとかしないといけないわけだ。
そんなんやってられっか。
modではエンコーダとマルチプレクサのプラグインを別にするつもり。

まぁ全部妄想でしかないんだけど。

>>187
妄想を早く実現汁！

('A`)

(・∀・)

('A`)

(・∀・)

ﾎｼｭという名の思いついたことメモ

入力はRGB24とYUY2のみ。RGB32は迷いどころ。無しでもいいか。
YV12はインタレフラグ気にするのﾏﾝﾄﾞｸｻｲから無しで。

タイムコードと音声同期を考える。音声にタイムコード必要？不要なほうが楽。
編集ストリームでのタイムコード反映方法考えないと。カット編集時とか。

フレームレート違いの音声組換えのときの問題どうしよう。
管理はフレーム単位じゃなくてサンプル単位の方がよかったかも。。。

あえてYV12対応とインタレ対応を
ただの二番煎じで終わっては欲しくないんで

どうせ内部形式に変換するんだから意味無くね？

ﾎｼｭという名の(ry

ソースを精読してる変態さんには周知の事実ですが、
今のAviUtlModって実はYV12対応していると言えなくもないのですよ。
AUIがYV12を渡す場合、デコーダプラグインが受け取りさえすれば問題ないし、
デコーダの返す形式はBITMAPINFOHEADERの形で通知されるので
ここがYV12であってもそのまま流れていきます。

この後、AviUtl内部形式に変換しないといけないんだけど、ここのインターフェイスを考え中。
もちろんプラグイン。
デコーダが今まで通りbmihを渡すならYV12->内部形式なプラグインも可能なわけだけど、
そんなの作るの面倒でしょ。デコーダがプラグインとして独立してる意味も薄れちゃうし。

だから、デコーダが返す形式をRGB24bitとYUY2に限定してしまって、
bmihではなくフラグで通知するように変更しようかと思ってる。
色変換プラグインはRGB24とYUY2だけを考えれば済むから楽だし、
デコーダだってどの形式で返すべきか悩まなくてすむし。

つまるところ、AUIがYV12を返す場合、YV12→YUY2なデコーダを用意すればいいってことです。
RFC

ﾎ(ry

aupをVFAPI読みこみした時のプラグインの問題

Utlのプラグインは普通のDLLなので、同じプロセス内だとメモリ空間が共有される。
つまり、プラグイン内部でグローバル変数を使っている場合、VFAPIに呼ばれたプラグインと
本体に呼ばれたプラグインで、この変数は全く同じアドレスに配置されることになる。
もしVFAPIと本体で別の値をこの変数に入れたい時はさあ大変。
お互いに上書きしあって期待通りには動いてくれなくなる。
あと、ヒープメモリを確保してアドレスをグローバル変数に入れて使う場合とかも問題。
ちゃんと考慮してないとメモリリークや開放忘れになる。
実例を挙げると、GNB氏のいくつかのプラグインで、aupのVFAPI読み込みをすると終了時にエラー吐くやつ。
グローバル変数でmallocとかしてて、終了時にfreeが2回呼ばれてると予想。
自分のプラグインでも同じ問題にぶつかった記憶が。

既存プラグインが考慮してくれてないので、こっちで対処しなきゃならないんだけど
必ずマッピングしなおすLoadLibrary()の自作が手っ取り早いかな。
RFC

//こういうネタ書き溜める用にぶろぐかうぃき始めたほうがいいのかなぁ。

なんかわからんけど難しそうだな
KENくんは凄かったってことか

確かにKENくんはすごいけど、このれはUtlに残された問題ってふいんき(←な(ry

簡単に言うと、aupをVFAPI経由でAviUtlに読ませた場合
プラグインがうまく動かない場合がありますよってこと。
で、その解決方法のメモ。

わかりやすいなｗ
期待してるZE

そういえばプラグイン側にもDLLインスタンス渡さなきゃいけないんだった。
LoadLibrary自作するとDLLインスタンスは独自になるからその値でWinAPI呼ばれると死ぬなぁ。
どうしよう。
APIをマッピングする時に独自関数をマップとか考えたけど、
インスタンスを引数にとるAPIを全部上書きとか無理だし。
必要そうなAPIだけ書き換えてお茶を濁すか。

tempにプラグイン自体をコピーとかでもいいけど、スマートじゃないしなぁ。。。

Flash PlayerがH.264対応に
ttp://www.itmedia.co.jp/news/articles/0708/21/news051.html

だそうで。FLV入出力プラグイン開発だれかやってくれないかな。

昔のソース眺めてて気づいたこと。
int fcc = '2YUY'とかやるとbcc32とclで結果が異なる。

AVIファイル内で"YUY2"と並ぶので、リトルエンディアン機だとfcc=0x32595559。
で、int fcc = '2YUY'とした場合
cl : fcc = 0x32595559
bcc32 : fcc = 0x59555932　←間違い

bcc32では fcc = 'YUY2' としなければならない。
どっちでもコンパイルするために、結局下のマクロ使うことにした。

#define FourCC(x1,x2,x3,x4) ((x1<<24)+(x2<<16)+(x3<<8)+x4))

int fcc = FourCC('Y','U','Y','2')

//mmioFOUCCは名前が長いから好きじゃない。4文字しか違わないけど。

こんなスレあったのか…。
マルチスレッド対応って出来るのかな。

(frame2処理)　　(frame1処理) 　(frame0処理)
filter1 -> (fifo) -> filter2 -> (fifo) -> filter3
各フィルタは別スレッドで動作

こんな感じにパイプライン処理できるようになることを期待してみる。

だいぶ前からだらだらとね。

最近の悩みはまさにマルチスレッド実装方法。卯tlスレの770は実は折れ。
キャッシュはFIFOよりLRUかな。

AthlonXP使いの酔狂です。
まぁ大体、フィルタリング部分のマルチスレッド化の構想はまとまったんだけどね。

あと、VCMデコーダ作ったんだけど、デコーダ周辺の仕様またちょっと変えようかと思って公開見合わせちう。
いつになるかはいつものとおり未定。

予定は未定

予定は未定で確定ではない

>>卯スレ681
更新したいのは山々なんだが、ほんとに時間なくて。ちなみに今帰ってきたとこ。
教授にさっさと投稿論文仕上げろとケツに火をつけられてるので・・・

外国人どものPCのサポートを誰かが代わってくれるなら多少時間もできるのに。
つーかなんで読めない日本語のOS使ってるんだよ。英語版くらい買えよ。
共用のMacなんてわざわざ英語のアカウントも作ったのになんで日本語でログインするわけ？
それで「読めないからCDの焼き方教えて」じゃねぇよ。
まじで自己解決能力のない奴はPC使うな

でもちゃんと教える弱い折れ・・・

時間無いけど思いついたのでメモ

入力プラグインでの音声はやっぱりサンプル単位のほうがよさげ。
で、タイムコードとサンプル番号の同期入力プラグインの仕事。コンテナに情報があるはずだから。
そして、音声デコーダはサンプル番号を変更するべきではない。（あくまで、「べきではない」）

さてデコーダのインターフェイスどうしよう。
手っ取り早いのがstartとlengthをデコーダに渡して、データ取得関数にそのまま渡してもらう。
デコーダ側でサンプル番号改変し放題。
ある程度隠蔽したほうがいいだろうか。もちろん改変したければできる形にして。

|・∀・)

昨日は99aで祭りだったようで。乗り遅れたよ。
YUY2<->RGB関連のバグは軒並み修正されたみたいですね。

気になるのはマルチスレッド関連。とりあえずplugin_sdkを確認。

input.h, output.hは変更無し。問題はfilter.h

110: int vram_yc_size; // 編集用画像領域の画素のバイト数 ( PIXEL_YC = 6 , PIXEL_YUY2 = 2 )
　コメントに PIXEL_YC=6, PIXEL_YUY2=2 が明示。YUY2フィルタ用かな。

119: // マルチスレッド関数用の定義
120: typedef void (*MULTI_THREAD_FUNC)( int thread_id,int thread_num,void *param1,void *param2 );
121: // thread_id : スレッド番号 ( 0 〜 thread_num-1 )
122: // thread_num : スレッド数 ( 1 〜 )
123: // param1 : 汎用パラメータ
124: // param2 : 汎用パラメータ
　exec_multi_thread_funcで起動される関数の型宣言。

128: void *(*get_ycp_ofs)( void *editp,int n,int ofs );
　ﾀｲﾎﾟ修正。すでに使われてない関数だったので気づかなかったとか？

453: BOOL (*exec_multi_thread_func)( MULTI_THREAD_FUNC func,void *param1,void *param2 );
454: // 指定した関数をシステムの設定値に応じたスレッド数で呼び出します
455: // 呼び出された関数内からWin32APIや外部関数を使用しないでください。
456: // func : マルチスレッドで呼び出す関数
457: // param1 : 呼び出す関数に渡す汎用パラメータ
458: // param2 : 呼び出す関数に渡す汎用パラメータ
459: // 戻り値 : TRUEなら成功
　子スレッドでfuncを起動。param1,param2はそのままfuncの引数になる。

460: int reserve[12];
予約領域消費

・multithread_filter.cppを見る限りでは、exec_multi_thread_func呼び出しすると
　thread_numだけスレッドが作られて、funcがその数だけ呼ばれる。
・これは動作確認してないから予想だけど、全てのfuncがreturnしたら
　exec_multi_thread_funcが終了、func_procから脱出。

処理の手順そのものは、フィルタが自前でスレッド作成するのと何ら変わらない気がする。
単に本体がスレッド数を管理できるというだけのシロモノくさい。

致命的な問題点を挙げると、
・W32APIを呼べないので、クリティカルセクションとかセマフォが使えず、確実な同期を取れない。
・原理的に画面分割不能なフィルタ処理は、マルチスレッドに出来ない。
・フィルタ内のスレッドが全部終了しないと次の処理に移れないから無駄が多い。
・フィルタ側で対応しないとマルチスレッド対応にならず、過去の遺物はシングルのまま。

祭りで騒がれているけれど、実体はあまり期待できませんね。

流石に毎回毎回スレッド生成はしてないと思いたいけどどーだろ。
# まー GetCurrentThreadId() してダンプしてみれば判ることなんだが。

とりあえず lanczos3 は MT 対応してみたけど YUY2 対応はきついなー。

yuy2_filter.cpp に
// YUY2フィルタモードについてはAviUtlの正式な機能ではなく
// テスト的なおまけ機能として考えていますので
// 試してみたい人のみ対応させてください。

とか書かれてるんで対応するか悩み中。

茂木さんにも見られてたのか。なんか恥ずかしいですよ。

毎回作成でないとするとどうやって実装してますかね。
関数とパラメタ送信したり同期とったりで結構大変なコードになりそうw

正直、YUY2モードの存在意義がわかりませんw
フラグとか用意されてないみたいなんで全てのaufのfunc_procが呼ばれるんですかね。
後でテストしないと。
YUY2対応してないフィルタがYUY2モードで呼ばれちゃうと困ったことになりそう。

んーと、こんな感じのコード書くだけなんで、そんなに大変じゃないです。

typedef struct {
void (* proc)(int thread_id, int thread_num, void *param1, void *param2);
void *param1;
void *param2;
int status;
} JOB;
#define JOB_STATUS_RUN 0
#define JOB_STATUS_FIN 1

typedef struct {
int active;
int thread_id;
int thread_num;
JOB job;
EVENT run_event;
EVENT fin_event;
HANDLE thread;
} THREAD_INFO;

THREAD_INFO *g_thread_pool;

unsigned int __stdcall worker_thread(void *arg)
{
THREAD_INFO *ti;
ti = (THREAD_INFO *)arg;

while(ti->active){
while( ti->job.status != JOB_STATUS_RUN ){
WaitForSingleObject(ti->job_run_event, INFINITE);
if( ti->active == 0 ){
return 0;
}
}
ti->job.proc(ti->thread_id, ti->thread_num, ti->job.param1, ti->job.param2);
ti->job.status = JOB_STATUS_FIN;
SetEvent(ti->fin_event);
}

return 0;
}

int setup_thread(thread_num)
{
int i;
unsigned thread_id;
THREAD_INFO *ti;

ti = malloc(sizeof(THREAD_INFO)*thread_num);
if(ti == NULL){
return NULL;
}

for(i=0;i<thread_num;i++){
ti[i].active = 1;
ti[i].thread_id = i;
ti[i].thread_num = thread_num;
ti[i].job.status = JOB_STATUS_FIN;
ti[i].run_event = CreateEvent(NULL, 0, 0, NULL);
ti[i].fin_event = CreateEvent(NULL, 0, 0, NULL);
ti[i].thread = (HANDLE)_beginthreadex(NULL, 0, worker_thread, r+i, NULL, &thread_id);
}

g_thread_pool = ti;

return r;
}

void exec_multi_thread_func(MULTI_THREAD_FUNC func,void *param1,void *param2)
{
int i;
THREAD_INFO *ti;

ti = g_thread_pool;

for(i=0;i<thread_num;i++){
ti[i].job.proc = func;
ti[i].job.param1 = param1;
ti[i].job.param2 = param2;
ti[i].job.status = JOB_STATUS_RUN;
SetEvent(ti[i].run_event);
}

for(i=0;i<thread_num;i++){
WaitForSingleObject(ti[i].fin_event);
}
}

これでラストです。

スレッド作成ってかなりコストが大きいので、最初にスレッドを作っておいて、
後は JOB を投入するだけにしとくというのは普通に使われる手法だったりします。

で、aviutl の方ですが、別フレームでも同じ thread_id のスレッドで
GetCurrentThreadId() 呼べば同じ ID が返ってきてたんで、この手法を
使ってるのだろうと推測してます。

YUY2 の方は

//---------------------------------------------------------------------
// YUY2フィルタ構造体のポインタを渡す関数
//---------------------------------------------------------------------
EXTERN_C FILTER_DLL __declspec(dllexport) * __stdcall GetFilterTableYUY2( void )
{
return &filter;
}

こんなのが追加されてますね。
サンプルでは同じフィルタ構造体を返してますけど、別モノを返すこともできそうです。

ミス修正

>>218 で
- WaitForSingleObject(ti->job_run_event, INFINITE);
+ WaitForSingleObject(ti->run_event, INFINITE);

>>219 で
- ti[i].thread = (HANDLE)_beginthreadex(NULL, 0, worker_thread, r+i, NULL, &thread_id);
+ ti[i].thread = (HANDLE)_beginthreadex(NULL, 0, worker_thread, ti+i, NULL, &thread_id);
- return r;
+ return TRUE;

やっぱりやっつけで書いたコードはあれですね。

ありがとうございます。コードまで書いていただいてすみません。
マルチスレッドプログラミングはまだまだ勉強が足りないようです。

Spy++で確認してみましたが、システムの設定でOKを押した時に
スレッドが作成/破棄されるようです。ということは茂木さんの予想通りでしょう。

GetFilterTableYUY2は完全に見落としてました。恥ずかしい限り。
寝不足で徹夜実験の合間にコード眺めても頭に入りませんね。

こぴぺ

586 ：名無しさん＠編集中：2007/11/06(火) 23:49:45 ID:8PGokvb1
AVIUTLは良くも悪くもこれ以上更新されることは無いと思ってた
できるものなら入出力プラグインで8ビットを超えた精度が扱えるようにならないかな・・・
例えば12ビットの内部形式そのままでもいいし
一般用途では8ビットで十分なんだろうけど、
より多ビットの、例えば10ビット精度の映像データが用意できる場合、
入力の段階でビット数を削らざる得なくて意味無いんだよね
とりあえずダミーの入力プラグインと実態の入力プラグインとして動作するフィルタプラグインで対処してるけど
やっぱり微妙につじつま合わせが難しくって

こんなこと期待するやついないよな〜

↑を考えてて行き詰まってるので整理。

[なぜ内部形式変換プラグインが必要か]
・SIMD化の効果が高そう→新しいSIMDが出たとき、プラグインの更新だけで済む
・あじさんの色域変換プラグインの存在
　本来RGB<->YCCの式を置き換えるものだが、内部形式の改変で実現してるからややこしいことになってる気がする。
　つまり、UtlのYC2->NTSC-RGB変換式を通すとsRGBになるようにYC2を改変しておく、というややこしい関係。
　sRGB<->Utl-YC2を定義するのが筋ってもんじゃないだろうか。（個人的な主義にすぎないけど）

これらをユーザが選択できたら便利じゃん、という発想。

[内部形式変換プラグインの機能]
・filter.hの yc2rgb(), rgb2yc()
・新たに導入予定の yc2yuv(), yuv2yc2() (YUY2<->内部形式)
・デコーダ出力→内部形式（デコーダ出力をRGB,YUY2に限っていれば上2つだけで済む）

224の解決策

1. デコーダが内部形式にデコードする（そもそも変換プラグインなんてｲﾗﾈ）
　　・SIMD化をデコーダがそれぞれ実装しなければならない（めんどい）
　　・変換プラグインの利点を全て捨てる勇気が必要

2. 高精度データ→内部形式な変換プラグインをサポート
　　・デコーダの返す形式によって変換プラグインは自動設定されなければならない
　　　→sRGBで扱いたくてもユーザに選択の余地がなくなる

やっぱサポート無理かも。

[ビデオのデコード形式]
RGB24bitとYUY2のみに限れば、次の情報だけで十分
フラグ(RGB|YUY2), Width, Height, (Pitch)
奇数幅なYUY2とか妄想したとき、Pitchあったほうがよさげ。

[音声のデコード形式]
Utlのfilter.hには
　オーディオ形式はPCM16bitです ( 1サンプルは mono = 2byte , stereo = 4byte )
と書かれてるので、それのみ可。
ただし、多チャンネルは扱えるようにする。

本体が必要とする情報は
Channels, SamplesPerSec だけでいい。
そこから適当に計算してWAVEFORMATEXを埋められる。

ソースみてたら、WidthとHeightは可変も許容するようにしてたことを思い出した。
てことはデコード形式の通知はフラグだけってことか。
pitchはどうしよう。RGBに合わせてで4byteアラインメントでいいか。
むしろ奇数幅YUY2は当面気にしない方向で。

音声の場合、可変サンプリングレートとか可変チャンネル数はサポートしなくていいよね。
いざとなったらデコーダ側で揃えてから吐き出すってことで。

AC3やAACのソースがあるので5.1ch(6ch)には対応できるようにした方がいいような。

読み間違えた。orz わすれｔ

多チャンネルは大丈夫。
サポートできないのは、同じストリームの中でチャンネル数が変化する変態ストリーム。
実在するかは知らないけど。

かぶった。わすれた

公開予定
・入力音声をサンプル単位で扱えるようにしたらとりあえず公開…近週中
・入力データとデコードデータのキャッシュを実装したら公開…近月中
ここまでで入力系は一区切り。
次はフィルタだろうな。近年中にはきっと…

//近いっていうのはたぶん1〜10くらいだとおもうんだ

(;´Д｀)ﾊｧﾊｧ

なんかWikipediaのAVIの記述があまりにもアレなので我慢できなかった。
//どう見てもﾀﾞｳｿ厨のﾀﾞｳｿ主体な内容臭いし。

IPのまま書いたけど、垢とって本気で書き換えてしまおうかな。

なんだかダイレクト編集

# MP4 とかのフレーム単位編集のみで、フィルタとかは一切なし
# ただしフレームプレビューは 1 フレーム未満の誤差で
# VFR にも完全対応

というのが世間の需要的にはそれなりにあるようなのですが……

と自分で作ってない気楽さで書きこんでみる

α版releaseﾏﾀﾞｰ?　（・∀・ ）っ/凵 ⌒☆ﾁﾝﾁﾝ

なんか矛先がこっちに ((('A`;)))
あからさまに工事中のページも晒されてしまったし。

作業は順調に放置中ですよ。ほら、じらした方が感じやs(ry

>236
フィルタより先に出力系整えたほうがいいかしら。
どちらにせよ色空間変換の都合で内部形式変換を先に作らないといけないけど。

>237
リリースしても良いけど脳内用だからそれ相応の想像力が要るよ？

とりあえず音声をサンプル単位の件は作業＼(^o^)／ｵﾜﾀ
デバッグ用に簡易WAVE出力付けてテストしたら予告通り公開予定。

明日は出かけるので早くて明後日、間に合わなければ来週以降。
デバッグついでにリファクタリングに入ってしまうとさらに遅れる予定。
内部的には多少大きな仕様変更だったんで、変数名とか混乱してるし。

あ、音声デコーダプラグインの作業がまだ残ってたorz

プロジェクトに参加したいです



printfしかできないけど

ありがと。
メンバーどうこうとかする気もあまり無いので、適当にコード送りつけてくださいな。

printfメインだと、CUIつくってくれると助かるかも。
AviUtlModUIから継承したクラスからAviUtlModCoreを呼び出す形なんだけど、
…どっちのクラスも仕様固まってないのが大問題。まだ無理か。。。

当面、折れのやる気を煽ってくださいｗ

+　　　+
　 ∧＿∧ 　+
　（0ﾟ・∀・）　　　ﾜｸﾜｸﾃｶﾃｶ
　（0ﾟ∪ ∪ + 　　　　　　　
　と＿_）__）　+

a3ｷﾀね。KENくんが頑張ってくれてるからModの出番は当分無くて済みそうｗ

> 入力プラグインの音声サンプル数が異常な値になるのを修正

これって出力プラグインのことかな？入力で異常になった覚えが無いんだけど。
（実は異常だったとしたら、Modも修正しないと。。。

>243
ﾃｶってるところ悪いんだけど、明日（というか今日）も別の予定入っちゃった。

茂木さん頑張ってるね。
TS保存できる環境持ってないからいまの所直接は関係無いけど。

まだTSを保存する方法が限られてるからすぐには大事にならなそうだけど、
このブレイクスルーで規制はどちらに転ぶかな。

声援ありがとうございます。
規制強化の方に向かうと痛いですな。現状維持にとどまって
くれれば状況がだいぶ改善するんですけど。

規制強化に向かって鎖国するとか、頭悪い方には進まない事を祈りつつ
しばらくは様子見るしかなさそうですね

こぴ10でのゴネ方見ると、1回くらいは規制強化に進むかもしれませんね。
その時は茂木さん（または有志）が数時間の作業で解決してしまうとか希望ー

iPodはじめ、これだけポータブルプレイヤーが浸透している昨今
5年後くらいには世論もあまりの不便さに気づいているでしょうし、
そうなってしまえば、それ以上の規制強化はやりにくいかと。

ここ数年が分かれ目ですな。

まちがえた。コピーは9回までだ。
あまりにも頭悪すぎな対策だからちゃんと覚えられてないやｗ

カネの問題だからねぇ。制限があるのとないので
実際にどれぐらい違うのかの違いがあるのかの統計を取る必要が……

でもそれは無理なので権利者側に有利な方向で進めるという姿勢は
当分崩されないでしょうなあ(ユーザは権利者ではないと見てるからね)。

それ以上に寄付金という名目の裏金ｇ（ｒｙ

著作権保護なんて建前で囲い込みの利権に過ぎないから無反応機で
あふれかえらないと変わらん気がする。
海賊版をなくすには安価で高品質（もちろんDRMなんかあったら台無し）の
正規版を提供するのが一番早い。
TV局や広告代理店なんかに中間搾取されないようにネット配信で販売してくれんかな。

中間搾取って結構重要よ。今は暴利むさぼってるけど。

ネット配信販売、あるいは通販なんかも個人個人でやってたんじゃだめだから
なんらかの団体がまとめないとうまくいかないんじゃないかな。
ボランティア団体とかだといいんだが。

AUIのマルチストリームフラグの値を変更。
デコーダの仕様を変更。
ビデオデコーダの呼び出しが必ずキーフレームから昇順になるようにした。
音声の扱いをサンプル単位にした。
テスト用WAV出力付けた。一応動いてる模様。
仕様変更にあわせてプラグインを修正。
ACM音声デコーダプラグイン作成（作業中）

ACMデコーダが完成したら放出しますよ。

乙彼

+　　　+
　 ∧＿∧ 　+
　（0ﾟ・∀・）　　　ﾜｸﾜｸﾃｶﾃｶ
　（0ﾟ∪ ∪ + 　　　　　　　
　と＿_）__）　+

ふみゅぅ、Synthスレでちょっと痛そうな人に噛まれた気がするぅ。
価値観の相違なのだろうか。

あー、Wikipediaのノートにも書き込みあるなぁ。
ちゃんとした反論もできるんだけど、水掛け論になりかねないし…
これも価値観の相違なんだろうなぁ。

とりあえずACMでデコードする所はできた。
あとはフォーマット名を取得すれば完成。

Utlとデコード結果を比較してて気づいたけど、UtlでPCM.wav出力する時
wfx.cbSizeは維持されるのね。何の問題もないけど。

同時進行乙

Wikipediaの件はまだだけどね。とりあえず参照されてるdoom9のスレを斜め読み。
…VFWでMultipleReferenceの話出てる?見つからなかった。。。

やっぱり痛い人だった。。。読んでくれないよ。。。
なんか馬鹿らしくなってきた。

揚げ足取りなんてするもんじゃないですね。

でもいかにも自分は詳しいぜな口調でおかしな事書かれると
つい突っつきたくなるんだよね。
間違った情報の蔓延を防ぐという建前を自分に言い聞かせながらｗ

大仁田厚氏、「アニメは文化だ！」と宣言
http://news.ameba.jp/weblog/2007/12/9130.html

浮上しちゃいましたな。interlace 420 -> 422 の件については

・変換するなら補間しろ
・でも変換するな (仕方が無い場合は最小限にとどめろ)

で同意が取れる話なんじゃないかと後づけの感想を抱いたり。

実際 YUY2 に変換しなきゃいけないのはそれしか受け付けて
くれないフィルタやら CODEC やらがあるからな訳で、

そいつらに補間なしで interlace 420 -> 422 変換したものを
与えて正しく処理してくれると期待するのが間違ってるんじゃ
ないのかなと。

あと、MultiRef には特に制限ないですよ。IDR でリセットされますし、
参照フレームはデコーダが保持しますから。
多分 b-pyramid (参照 B ピクチャ) と混同してるんだと思いますけど、
それも VFW (VCM) の 1:1 入出力の制限であって AVI の制限じゃない
ですし。
MP4 なんかでも 1:1 入出力 CODEC 使えば同様に B のデコード遅延は
発生します。

いくらなんでも見下しすぎだろ。
意味も無く変換する奴なんていない。
可逆とか劣化とか以前のレベル。

上げられてしまったけど、どしよう。ちょっと話続けたいんでとりあえずここで。

>262-263
いつもありがとうございます。
262の線でさっさと落ち着くと踏んで煽ったんですが、ちょいと想定外なほど盛り上がってしまいw

それでピラミッドについてなんですが、
10/11日記で言うγのディレイが変動することってあるんでしょうか？
--bframes 5以上の時、場所によっては1だったり2になったりとか。
--b-pyramidの説明を視る限りではなさそうなんですが、
and `may' cause a 2 frame decoder lag.となってるのがちょっと不安で・・・
ディレイが一定なら他ストリームのAVISTREAMHEADER::dwStartを適当に可算しても良い訳ですし。
究極的には、必要フレームを全部packしてしまえば十分回避可能であるとは思います。

>264
見下してるつもりはなかったんだけど、多少見下した方がいいのかもしれませんね。
てっきりConvertToYV12(interlaced=true)の計算式くらい知ってるものかと。。。

>265下２行取消し。。。恥ずいなぁ

and may cause a 2 frame decoder lag.
変な英語だな。ん？これってγ=2てことですか。
ううっ、x264あんまり知らないけど下手なこと書けないし。。。

>>265
現在の x264 実装ではないです。--bframes 7 とか 11 とかで --b-pyramid
試してみたことがあるのですが、参照 B フレームは中央の 1 枚しか入ら
ないので遅延は 2 フレームが最大になります。

ただし、--bframes 7 のときに

P0 b1 B2b b3 B4a b5 B6b b7 P8

のように (P0, P8, B4a, B2b, b1, b3, B6b, b5, b7 と) エンコードする
H.264/AVC 実装があると、そちらでは 3 フレームの遅延が発生します。

pack は pack されてる参照フレームの出力タイミングをどうやって CODEC に
通知するかという点が問題になります。MPEG-4 (14496-2) では Not Coded と
いう特別なフレームが規格で用意されていたので規格と矛盾することなく
packed bitstream というハックをすることができたのですけど、H.264/AVC
だとそれがないんですね。

一応ACMデコーダ完成したっぽい。
明日か明後日くらいに放出できたらいいな。

>>268
詳しい解説どうもです。
H.264にはNotCodedが無いんですか。知りませんでした。
規格としてはピラミッドは何段にでも出来て、
遅延もそれに応じて変わってくるのもありえるわけですね。

となるとこの辺の機能をAVIで扱うには制限があると。

NULLパディングのタイミング調節で出来ないこともなさそうですが、
あまり現実的ではないですね。

# >>119の新方式を応用すると、NULL無しでのVFRも出来そうなんですが
# それこそハックなので考慮しないってことで。

B 関連のデコード遅延は AVI の問題に含めるべきかどうか微妙なんですよね。
現状、AVI の再生環境は完全に DirectShow のみになっている (VLC Player
のように自前で全部面倒を見てるプレイヤーは除いて) わけで、DirectShow
環境では VFW の single in, single out に縛られる必要は本来ないはずなん
ですよ。

　AVI Splitter -> Dec(ffdshow) -> Render

上のフィルタグラフで再生するときに、デコーダ内部でバッファして、表示
順どおりに正しいタイムスタンプを付けてレンダラーに渡してやればいいだけ
なんですから。(A/V 同期はレンダラーがタイムスタンプを見て勝手にやって
くれる)

例えば、

　I0 -> I0 として出力
　P4 -> デコードだけしてまだ出力しない
　B2 -> デコードだけでまだ出力しない
　b1 -> b1 として出力
　b3 -> ここで B2 を出力
　P8 -> b3 を出力
　…途中略…
　EoS 通知 -> バッファ分を順次出力

ということが DirectShow ではできるはずなんですね。

この場合、AVI 段階で VFW を救おうと下手に対策する (拡張 AVI 出力での
β対策とかが例として適切です) と DirectShow 環境ではかえってズレが
発生することになります。

実際のところ ffdshow はどーゆー処理をしているのだろうと映像フレームに
タイムスタンプを焼き込むフィルタを作って実際の数値を確認してみようかと
したのですが……。

FLV 出力とか STD-B25 とかに浮気を始めて途中放置になっちゃってます。

>270の点は認識してます。

ディレイすること前提なAVIが浸透している現状、
理想論だけを書くのもどうかなとちょっとだけ躊躇してます。
AVIの記事であってVFWの記事では無いのだから良いとは思いますが。
少なくとも、ピラミッドでないBフレームだけなら、一定のディレイとして対処できますし、
実際に対処している例もあるということで。まだ書いてませんが。

Dshowの例は、デコーダによるタイムスタンプ書き換えを許容するかどうかな気もします。
個人的な考えでは、タイムスタンプを付加するのはスプリッタの仕事であって、
デコーダは触るべきでないと思います。
ストリーム間の同期情報がコンテナにあるはずですし、
デコーダが他ストリームを意識することは普通は無いでしょう。

そう考えると、AVIではフレームの並び替えをしないほうが良いのかもしれません。
タイムコードがフレーム番号で静的に決まってしまうので。

I0 -> I0出力
b1 -> バッファ,出力無し
B2 -> バッファ
b3 -> バッファ
P4 -> b1出力、以降順にB2,b3,P4を出力

ということも可能ですよね。バッファするフレームが増えてしまいますが。

ちなみにModのデコーダはPull型で、
デコーダ自身が必要な情報をソースに要求する形にしときました。

これなら並び替えもタイムコード書き換えもできますし。
(タイムコードは未実装)

乙
いつごろα版リリースできそうすか？

あるふぁ版ってどの程度できてればいいんでしょうか

あるふぁ未満ならあしたくらいに。
今日はもう寝ます、、、

http://www11.axfc.net/uploader/20/so/He_52457.zip.html
key:mod

お二方の会話が気になったので、ちょっとしたピラミッドの確認。

DirectShowで再生した場合
100.avi　　　 … 00001の表示が5フレームほど続き、00097まで再生。
100plus.avi　… 00001の表示が2フレームほど続き、00100まで再生。
100raw.avi　… 00001の表示が2フレームほど続き、00100まで再生。
100.mp4　　 … 正常に00100まで再生。

AviUtlで開いた場合
100.avi　　　 … 5フレーム分映像無し。00001が3枚重複。00093まで表示。
100plus.avi　… 00001が3枚重複。00099まで表示。（総フレーム数が101枚）
100raw.avi　… 00001が3枚重複。00098まで表示。
100.mp4　　 … 正常に00100まで表示。

AviUtlで使用された入力プラグインは、ファイル情報から
avi…AVI File Reader ( Video For Windows )
mp4…MP4 File Reader

aviで次世代コーデックを扱うのは難しい、ではなく絶望的になってしまった気がする…orz

検証乙です。
ファイルの中身までは調べてないけど、なんか予想どおりの素直な動きですね。
plusだけファイルサイズが大きいのが気になりますが。
まだ絶望する必要はないんじゃないかな？

modは今晩〜明朝。

MS/MSでなぜ蛋白が同定できるかやっとわかった。
ttp://www.jstage.jst.go.jp/article/nl2001jsce/2002/107/2002_107_29/_article/-char/ja
最後のデータ解析の実例がわかりやすい。技術の進歩ってすごいね。

帰宅。ちょっと書いてうｐした。おやすみ。

乙
作りかけ版のバイナリ起動してみたお
流石Modと冠してるだけあってGUIがそっくりだったな
個人的にはもっと遊んでくれるのを期待してたけど

Modのお部屋の掲示板のカウンターがすごい勢いで廻っていることだけ確認した

>280
いったいModに何を求めてるのかと小一時k(ry

さて、ここも知れ渡ってしまったし、何度も揚げられたし、そろそろ移転しようかしら。

追うのめんどいからやめてよ
いいじゃんここで

>>235 辺りでwikipediaの話がでていますが、コンテナスレでリンクされている
ノートはMakKi氏が書いたものですか？
むこうでダウソ厨扱いされているようです…
http://pc11.2ch.net/test/read.cgi/avi/1191848971/69-70

ノートからリンクされているavi.pdfには、「追加分（つまりハック）だけではなく、
OpenDMLのフォーマット機能を〜」と筆者自身が書いていますので、逆に
後半の追加機能分はハックなのではないかとちょっと心配になりました。
「This document describes the subset of Open-DML 1.02 le format features,
as well as some additions ('hacks').」

ただいま。
帰りがけに買ったすき屋の牛丼が並盛なのになぜか肉3倍くらいでちょっと幸せです。

>>284
ありがと。うん、202.152.108.232 2007は折れ。
2chで吠えてるだけなら実害ないからいいかとも思ったけど、
なんかミカタになってくれそうだから弁解しに逝くよ。

VBR音声に関しては、ハックというほどのことではないんじゃないかって思ってます。
スプリッタのタイムコードの割り当てかたを見ててそう結論付けました。
それを悪用したハックが例の新方式。

実験の合間メモ

IBBPBBPBBP でコーディングされた場合、

ファイル中: I0 P3 B1 B2 P6 B4 B5 P9 B7 B8
MP4のタイムコード順: I0 B1 B2 P3 B4 B5 P6 B7 B8 P9
AVIのタイムコード順: I0 P3 B1 B2 P6 B4 B5 P9 B7 B8
デコード画像: I0 B1 B2 P3 B4 B5 P6 B7 B8 P9

さて、AviUtlMod内部でデコード画像へアクセスする場合、当然ながら一番下の順序でないと困る。
じゃソースデータへアクセスする場合はどうしたらいいだろう。
1フレーム目のデータはB1なのかP3なのか。
タイムコードを基準にするとAVIとMP4で食い違ってしまうし、ファイルそのままにするとタイムコードが食い違う。
再圧縮無しでAVI(タイムコード無)<->MP4(有)をするためには何か仕掛けが必要。

さて、どうしたものか。。。

>>286
ソースにアクセスしたい場合として想像するのはカット編集等の
場合かなぁと思うのですが

・カット後に先頭フレームになれるフレーム - I
・カット後に末尾フレームになれるフレーム - I/P

をアプリケーションが意識して扱ってあげるしかないように思います。

I0 〜 P3 までを切り出す場合だと、ファイル内の順番での frm[0] 〜
frm[3] までを切り出すという形になるので、矛盾はあるけれども、
実害は出ないという形になるはずです。

で、AVI ファイルでは I か P/B かのフラグしかなくて、P/B の判別は
できないのはご存知の通りなのですが、MP4 でもこの制限は同様だった
ような気がするので…… アプリケーションあるいは入力プラグインで
P なのか、B なのかをビットストリームをパースして判別する以外に
方法はないかと。

また、MP4 のタイムコード (DTS/CTS) を設定する場合はどのみち
フレームタイプ判定が必要になります。

そうですね、カット編集とあとはコンテナの詰め換えです。
それらをやり易くするにはどんな内部形式にすべきか迷いちうです。

IPBのフレームタイプよりもっと一般化して、
依存フレームをデコーダに問い合わせるなんてどうかなと考えてます。
それらの受け渡し方法も悩みどころ。
当然、3フレーム以上に依存するフレームも今後出てくるでしょうし。
（ピラミッドのような間接的な依存でなく直接の。既にあったりして。）

タイムコードつけ直しはやっぱりストリームの中身を判別しないとだめですか。
そのへんのトリックも悩みどころですね。

はぁ、先は長い・・・
透過性ロゴ＆解析も更新したいな。

あげ

疲れた。デバッグは人任せ。み。

99bだってさ。
pluginsdkにも手が入ってるみたいだし、結構楽しみ。
さてさて、今夜は眠れなさそうだ。

今夜は寝かさないﾖ

ﾔｻｼｸｼﾃﾈ…♥

よし、次はションベンだ

一日約3本ペースでエンコしてたら
去年一年で800本以上エンコしてたお　（；＾ω＾）

800/3 =~ 267

貴様100日近くサボってやがったな？ｗｗｗ

見る時間くらいは与えてやれよ

普通はｴﾝｺして終了だろ

オレはエンコして、見たら消すけどな
保存するヤツはエンコしないし

こ・・こんな餌には釣られないクマー！

295だけど、エンコしたらソースを、見終わったらエンコしたのも後腐れなく消し去るお　（　＾ω＾）

今まで保存に頭を悩ませてたけど、棒茄子でBDドライブ買ったから
デカいファイルも余裕になったお…もうDVDには戻れないお！

消すならBDドライブもいらないじゃん

残すヤツはエンコして画質劣化させたりしないお…　（　＾ω＾）

磯で十分。

やっとその気に(;´Д｀)ﾊｧﾊｧ

ってｽﾚ違いだorz

99cか・・・
99b弄くりまわす前に来ちゃったよ。KENくん頑張りすぎ

とりあえず99b,cの変更点まとめておきますか。
どちらもfilter.hの変更のみ。コメントがそこそこ増えたようで。

*FILTER::check_default[] の初期値が負だとボタンに
　　設定ウィンドウでボタン作る人が多いので、便利といえば便利なんだけど…
　　位置の指定が出来ないぽいのでちょっと微妙。
　　99cのスライダとかのサイズ変更はこれを使えという圧力？とか邪推してみたり。

*WM_FILTER_MAIN_MOUSE_DBLCLK
　　読んで字のごとく。うん、便利かもね。

*FILTER::func_project_load(), FILTER::func_project_save()
　　プロジェクトファイルへのデータ保存方法が増えた。
　　FILTER::ex_data_ptr/size/defaがプロファイル単位に保持されるのに対し、
　　こっちはプロジェクト単位。プロファイルが複数あっても一つ。
　　字幕とかチャプタとかに使えるかも。

*FILTER::func_modify_title()
　　自動24fps(98d)のためといっても過言じゃなさそうな…
　　手動24fpsをプラグイン化した時に作っても良さそうだったのに。
　　とりあえず、内蔵プラグインでしか弄れなかった部分が公開されましたってことで。
　　どちらかというとEXFUNCに入ってた方が使いやすかった気もする。

*FILTER::dll_path
　　サブディレクトリ名が取得できるように。
　　独自設定ファイルを持つプラグインなんかにはいいんじゃないかな。
　　他にもいろいろ使えそう。

予約領域があと2つだけど、EXFUNCと違って増やせないのでどうするのかな。

99bはここまで。

次99c。主にEXFUNCに関数追加。あと設定ウィンドウ絡み。

*FILTER_WINDOW_SIZE_CLIENT, FILTER_WINDOW_SIZE_ADD
　　卯スレにも書いたけど、設定ウィンドウサイズの指定方法が増えた。
　　fp->x = 50|FILTER_WINDOW_SIZE_ADD; みたいにして使う。
　　ただし、これを使ったプラグインを99b以前で使うと酷いことにｗ

*EXFUNC::create_yc(), EXFUNC::delete_yc()
　　作業領域の確保/開放。システムの設定の最大画像サイズかな？
　　呼び出すたびにmalloc/freeされる模様。
　　当然だけど、func_proc()の中で確保,開放するのは非効率。

*EXFUNC::load_image()
　　…これって意味あるの？どう考えてもEXFUNCとして提供する機能じゃない希ガス

*EXFUNC::resize_yc()
　　…これも意味不明。本体が提供する意味はないでしょ。
　　アルゴリズムも選べないわけだし。

*EXFUNC::copy_yc()
　　…これこそもっと意味がわからない。
　　こういうのはプラグインが実装すべきじゃないかな。
　　実際「３次元領域平行複写」なんてのもあるし。アルファ処理加えるだけでしょ。
　　サンプルのvideo_filter.aufのためだけにあるんじゃないだろうか。

　　これら3つははっきり言って使い道が無い。あったとしても超限定的。
　　KENくんにはなにか思惑があるのだろうか・・・

*EXFUNC::draw_text()
　　そういえば昔、茂木さんがprintf形式のを公開してましたね。
　　デバッグにも有用ですが、99bの時のprojectデータと組み合わせれば
　　あっという間に字幕フィルタが作れてしまう代物。
　　そのうち誰か作るんじゃないかな。

99cはプラグインの強化よりむしろ、本体に手が加わっている模様。
内蔵フィルタとかパラメタが多少変わったけど大筋は変化ないようで。
内部処理までは知らないけど。

あとはUIが細かく変わりましたね。
フォントや設定ウィンドウのアイテムのサイズが変わったりした所為で
プラグインの作るボタンが不味い位置になってしまっているようで。透過性ロゴとかも煽り受けてるし。

99dあたりで戻ってそうな気もするので、放置していいですか？
対処面倒なんですよ。バージョン判定が必要なので、新バージョン出るたびに更新しないといけないし。

もう一つ、WAVファイルを動画として読めるようになった模様。
実際やってみると、640x480,30fps,YUY2の真っ黒画面＋音声として読み込まれます。
ただし、D&D不可。ファイルを開くダイアログからで。
あと音声用auiでは適用されません。WAVのみ特別扱いですね。前からそうでしたが。

ふう、もうこんな時間。
やろうと思ってた作業あったけど、またでいいや。

>>311
予想通り速攻修正されましたね。
まあ戻ったんではなくサイズ計算が正しくなった感じですが。

それはそうとfunc_WndProcでWM_FILTER_MAIN_KEY_DOWNだと
return TRUEしても再描画されないんだが、なんか条件あるのかな？
編集の補助にピラーボックス境界に飛ぶの作ったら変なとこで嵌った。

>314
対応早かったですね。KENくん頑張りすぎｗ
戻ったであってますよ。ボタンとかの配置には結局正解なんて無いので。

WndProcはあんまり調べて無かったです。というか、入力以外手付かずで…
なんでしょうね。他メッセージも一通り調べてみようかしら。

まぁそんなことより、313で言ってた作業だけど…

うん、わかってるよ、自分でも血迷ってると思ってる。
ただでさえ調子付いてる奴等をさらに増長させるだけだって。

でも仕方なかったんだ。
某tubeから落としたブツから音声を抜き出(ry
おっと、これは本音だ

そう、タイムコード。Modをタイムコードに対応させるべく、
タイムコードを持つコンテナを使いたかったんだ。
それでサンプルの入手しやすさからコイツが選ばれたというわけさ。

仕様書は例のライセンスの所為で参照できないので、
とりあえずここ ttp://osflash.org/flv が主な情報源。

うん、基本はわかった。
問題はonMetaData。某hito氏も言うように、カオスだ。
困った時の茂木さん頼み。出力プラグインのソースを読む。
うーん、文字列、配列、浮動小数は分かった。
某tubeからのサンプルだと他のタイプも使われてるし、難しいな。
しょうがない、ffmpegのソースを読もう。
なるほど、これで必要最低限の情報くらいは拾えるかな。

さて、某tubeのサンプルを見ると…
あっれー？フレームレートどころかwidth,heightすら無いんですが…
結論：Metaは無視。

じゃぁFLV→AVIなソフトはどうやってるのかってことで
FLV Extractのソースを読む。
VP6やH263のビットストリームからwidht,heightを取得するのね。
それだけ分かればあとは自力で。

ということを先週、本業の実験の合間を縫ってやっていたのですよ。
そして昨日今日、合間に実験を進めつつ組み上げました。

色々不完全ですが、仕様が分からないのでどうにも…
不味い点だらけだと思うので指摘していただけると助かりますです。


追伸
ニコ厨、ようつべ厨の要求には屈しない。

ニコ厨甘くみると痛い目みるぞｗ

もちろん、真っ当なバグ報告してくれる人を厨呼ばわりしたりはしないよ。
ただ、モノがモノだけにFAQが繰り返されそうで・・・
予想できるのをあらかじめ書いておこうか。

Q 対応してるって書いてあるVP6|H263＋MP3のFLVなのにAviUtlで読めません
A flvinput.auiはデコードは行いません。
　AviUtlが利用可能なvfw(vcm/acm)デコーダをインストールしてください。

Q AviUtl上または再圧縮なし出力したAVIで画像が上下逆になります
A デコーダの仕様です。

Q フレームレートが中途半端な値になってしまいます
A flvにフレームレートという概念は存在しません。
　タイムコードとフレーム数から平均レートを算出しているので中途半端になることもあります。

Q 出力すると音ズレするのですが
A AviUtlがVFRに対応していないためです。
　FLVの各データはタイムコードによって管理されているのでVFRとなる場合がほとんどです。

トリップ間違えたorz

Q PCM音声のflvで音声が壊れます
A バグです。原因に心当たりがあるので近日中に直せると思います。

Q 他の圧縮形式にも対応してください
A 仕様がわからないので無理です。詳しい仕様を教えてください。

Q ffmpegやFLV Extractを参照したとあるのですが、GPLにならないのですか
A あくまでFLVの構造を調べるために参照しました。
　ソースを比較すればわかる通り、コードの流用は行っていません。
　それでもGPLに抵触するのであれば、どの条文に引っかかるか教えていただけると助かります。

他にもネタあったらお願いします。
帰ったらアーカイブにも同梱しとこ。

(･∀･)ﾆﾔﾆﾔ
乙です

>>315
原因はスライダのサイズを変えたのに
サイズ計算に使うサイズが変わってなかったっぽいですが
スライダのサイズを戻すのではなくて計算の数値を正常化したと。

後半は気にしないでください。ほぼ愚痴です。
結局メインからのキーメッセージにset_frameしてTRUEだと更新されないっぽいです。
返り値のチェックにミスがあるのかとは思いますが確認とってみようかと。

ちょっと大人げなかったかしら。

>323
スライダのサイズだけじゃなくて、チェックボックスの間隔も変わってたりしましたね。
全体的なリニューアルを目指してたんでしょうか？
（単純に開発環境が変わっただけな気もする。対応OSがXP,Vistaに書き換えられてるし）

大きいスライダ、最初見た目に違和感あったけどつまみやすくて使いやすいかもｗ

なんかお部屋のインフォメーション日付おかしいけど
わざと？

ぅぁ、普通にミスです。帰宅したら直します。

直しました。
ついでにflv_inputのPCMのバグも直しました。アーカイブ差し替え済みです。

AdobeのSWF and FLV File Format Specification License Agreementを読み直してみた。
http://www.adobe.com/licensing/developer/fileformat/license/

3. Restrictions (制限)

a. You may not use the Specification in any way to create or develop a runtime,
　　client, player, executable or other program that reads or renders SWF files.

禁止されてるのは「SWF]のプレイヤ等の作成であって、FLVについては言及してない。
(他の部分ではSWF or FLVと書いてるし)
もしかして、FLVのパーサ作る分には読んでもいいのか？

FAQ見たら、
http://www.adobe.com/licensing/developer/fileformat/faq/

What SWF and FLV File Format versions are currently supported?
　The most recent version of the specification covers up through version 9 of the SWF file format and
　version 1 of the FLV file format. Adobe updates the Specification as soon as possible after each release.

だそうで。
H.264/AAC格納の情報が欲しかったんだけど、うーん、意味無いかも。

なんとなくわかった。FLVにH.264/AACを入れるのは無理。
（はっきり不可能とは書いてないみたいだけど、仕様策定されてないみたい）
Flashではこれらを格納する時MPEG4-part12を使うのね。

VP6のビットストリームの詳細を見つけた。
ttp://wiki.multimedia.cx/index.php?title=On2_VP6
MultimediaWikiにあったか・・・一通り探したと思ったんだどな。

これでVP60/VP61/VP62の判別もできるし、VP60で正しいwidth,heightを取得できる。
その実装が終わったら今度はタイムコード対応かな。本体側も含め。

flv_input更新した。これで多分VP6は完全対応のはず。

Mod本体の予定
　テスト用のAVI出力
　入力のタイムコード関連
　編集ストリーム制御系

>>332
おちゅ＞＜

なんか卯スレで遠廻しに呼ばれてた気もするけど、いかないよ。安心して。
というか、折れが噛みつくのは中途半端に誤解してて、かつそれを吹聴するような人だけだったから。
色に限ってるわけでもないし。
前の卯スレのでは何度か読み直してみたけど、言葉たらずな点はあれど、間違ったことは言ってないと思ってる。
（K氏とのあれは折れの読み違いから始まったけど。）

今やそれ以前にどうでも良くなってるんだけどね。
いくら真実を叫んでも、人は見たい物しか見ないし、信じたい物しか信じない。
もちろん折れもそれに当てはまる。
劣化してると信じる人の目でみればバイナリが一致してても劣化してるし、逆もまた然り。
それにどうせ色なんて、自分の感じる赤と他人の感じる赤が同じ保証もないし。
好きにすればいいんだよ。結局のところ。

たまに気まぐれで「ちがうよ」の一言だけ書くことはあるかもね。

>>334
まあ、なんだ。たっぷり休息を取ったほうがいいぞ。

>>334
まぁ、なんだ。
あんたの書き込みは、中途半端に誤解してて、かつそれを吹聴するような人にしか見えないんだがな。
言葉たらずな点があるせいで。

あっれ、折れいまMakKiと同じ事いってるよｗ

>335
ありがと。でも今は逆に休み過ぎで無気力な感じ。気合い入れんと。

>336
気があうね。
折れだって人だもん。全知全能なはずないよ。
できるだけ裏とって書くようにしてるけど、間違うこともあるさ。気づいたらちゃんと認めるし。
それに言葉たらずになるのも当然だよね。バックグラウンドまで全部書くなんて無理だし。
まぁ、なんだ。
本当に知りたい人なら自分で調べるでしょ。いらん世話焼く必要もないかなって。

MakKiの優しさに惚れたｗ

ハッテン場スレになりました。

ffmpegのソースで確認したんだけど、flvのSorensen H.263って普通のH.263とは違うんだね。
flvinputでFourCC='H263'使ってたけど駄目じゃん。てことで'FLV1'を使うことに。

ついでにScreen VideoとADPCMの仕様も分かってきたから実装してみる。只今コーディング中
あと、音声のSoundformat=0(Uncompressed)はBigEndianのPCMだったのね。
謎だったSoundformat=3はLittleEndianの普通のPCMですか。この辺も対応中。

問題は、ScreenVideo,ADPCM,PCM-BEはサンプルが無いからテストできないってことか。
利用できそうなデコーダも無さそうだし。

とりあえず完成。
ScreenVideo, ADPCM, PCM-BEは未テスト。多分動くさ。

残るはScreenVideo2とNelly moserだけど、
こいつらはFourCC,FormatTagが決められてなさそうなので不可能。
(FLV1,FSV1,0x5346あたりも凄くぁゃιぃけど、長い物(ffmpeg)に巻かれてみた)

FourCC='FLV1'のテスト中にMod用VCMデコーダの不具合に遭遇。
どうやらffdshowのvfwインターフェイスが呼べないみたい。
Utlではデコードできてるんで方法はあるはずだけど。
原因に心当たりある人いたら教えてくださると助かります。

おつ＞＜

DivXにエンコするときって、やっぱり皆さん、２Passは基本？
１Pass画質指定じゃだめなのかなぁ・・・・

DivXは長いこと使ってないので、よくわからんのだが、
Q指定のマルチパスって、そんなに効果あるの？

サイズ指定のマルチパスは、あくまでもサイズを
調整したい時にしか使わないけど。

当たり前っちゃ当たり前だが。

2passはターゲットサイズにしたいときだけ使ってる
画質重視ならQ1passでいいと思うよ

>>344>>345
�dです。
ＡＴ−Ｘの放送分をＰＶ４でキャプって、ＤｉｖＸ（Ｑ１０）でエンコしてるんですが、
大阪人から貰った、地アナをエンコしたのより、画質が悪い気がして。
単に元が悪いのかな？

Q指定なら3〜4じゃね？
10はないわ・・・画質上げるなら小さくすれ

あと軽くでいいから時間軸系のノイズ除去もした方がいいよ

>>347
え？画面見ると、数値が大きい方がクオリティ優先。小さい方がスピード優先になってんだけど。
実際、数値を大きくした方が、エンコ時間も掛かってるし。

>>347
ﾓﾚはQ指定の時は２〜３だったな。ソースによるけど、時間軸NRを
限界までかけて細部潰して（ｗ

最近のを見てない人間が言うのもなんだが、Q指定と、パフォーマンスみたいに
別のパラメータがないかい？

>>348
それはQじゃなくてエンコーディングプリセットじゃないか？

>>350
ｏｒｚ
今の今まで、設定の意味を誤解してた。

折れも折れちゃおうかな・・・

断る！

4/1に折れも折れてみようかと思ってたのに、もうメンテ終わっちゃったのね。残念。

ただいま。徹夜は辛い。もう年だね。

おつかれ

恒例の…

>>357
ページ乙ｗ

ttp://www.adobe.com/aboutadobe/pressroom/pressreleases/200804/050108AdobeOSP.html

Flashのオープン化に伴い、
Removing restrictions on use of the SWF and FLV/F4V specifications
だそうです。今更ですが。

掲示板スパムだらけじゃないかｗ

ただいま。

>360
誰も見てないと思って放置してたんだけど、見ててくれたんだ。
とりあえず対処方法考えときます。

おやすみ。

設定ウインドウ拡張向けフォントめも

1.GetStockObject(DEFAULT_GUI_FONT);
XP: OK
Vista: NG(メイリオフォントにならない)

2.SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &nm, 0);
XP: 取得できず
Vista: OK

3.SystemParametersInfo(SPI_GETICONTITLELOGFONT, sizeof(LOGFONT), &lgf, 0);
XP: OK
Vista: OK

4.WM_GETFONT
他のコントロールのフォントをぱくる

vistaのGUIはちょっとばかり勝手が違うんですね。

aviutl0.99cから設定ウインドウがメイリオフォントに対応したようです。

お前が一番危険だけどなｗ

祭りに乗り遅れたー
とりあえず入手。いろいろ変わってそうだ。
でも今日はおやすみ。

>364
なるほど、スライダとかのサイズが変わってたのもそれ関係ぽいですね。
vista導入予定もないしどうしようかな。

0.99d2でsdkに設定ウインドウのフォントハンドル追加された。(^^;)

確認しました。

314の書き込みと99c3の修正からまさかとは思ったけど
もしかしてここKENくんに見られてる？(((;ﾟдﾟ)))

みーてーるーだーけー

>>368
いや、どうかな。
>>314 の件は再現パターン書いて問い合わせしたんで関係ないかも。

入出力プラグインのPIXEL_YC形式対応を記念して
連番JPEG入力するプラグインを作ってみた
あんまり一般的な使い道は思いつかないけど
IndependentJPEG使用
今更感があるけれど特徴として
・PIXEL_YC形式で受け渡しするのでsYCC対応している
（sYCCはRGB変換したときにクリップされるような色でもOKという規格)
・YUY2で渡すより精度が上がってる
99d以降専用
入力プラグイン側ではバージョンチェックできないようなので
以前のやつで使うと落ちます

ttp://kissho.xii.jp/1/src/1jyou36108.zip.html

>370
そだったんだ。俺の考え杉かもね。まあ見られて困る物も無いけど。

>371
ちょお乙
INPUT_INFO::handler=0 にしてるみたいだけど、ここもYC48にしたほうがいいと思うよ。
そうすれば99c3以前ではコーデック見つからなくて読み込み失敗するだけだから。

99c系での例外発生の原因の予想だけど、handler=0なのでRGBとしてバッファ用意してくれてて、
でも当然YC48のほうがデータ多いから、バッファオーバーフローしてるんじゃないかな。
その他→ファイルの情報のビデオ展開形式がRGBになってるし。
99b以前だとなぜか例外出ないけど。すごく広めにバッファ取ってるのかな。

さて、ModもYC48に対応せねば。
またデコーダ周辺仕様変更だー

H.264の規格を見るとHigh 4:4:4 ProfileというのがあってYCbCr12bit使えるみたい。
デコーダはCoreAVC EnterpriseやAadobe Flashとか対応してるみたいだけどエンコーダは何があるんだろ。

12bitは色深度なのでYC48のオーバーフロー分を削ればそのまま通りますね。

今更だが>>1は、犯罪してる時が幸せってことですね。分かります。

>>372
そっか、handlerを設定しとけば良かったんだ

ttp://kissho.xii.jp/1/src/1jyou36301.zip.html

乙
readmeも欲しい

>>377
大して書くこともないんだけど一応つけてみた
でもそもそもこのプラグイン、ニーズあるのだろうか？

ttp://kissho.xii.jp/1/src/1jyou36423.zip.html

>>374
ただ問題は、UtlのYC48は正確には12bitじゃないんですよね。符号なし4096と符号付き2048のために。
微々たる差でしかないですが。

>>378
ニーズと言えるか微妙だけど、ModのYC48対応のテストに重宝する予定ですよ

作りたいから、作れそうだから作った、でいいんじゃないかな。楽しめればそれで。
ユーザとしても選択肢が増えるのは悪くないですし。

掲示板のカキコでVC++2008で作ったバイナリはWin9xでは動かないことに気づいた。
Win9x使ってる人も居たんだな…。

PC壊れた。どうも母板が逝ってたみたい・・・
おかげで一式新調する羽目に・・・
さよならAthlonXP

>380
DLL足りないってわけでもないですかね。LoadLibrary failedってどの段階でしょう？
さすがに9x系をメインで使ってる人は稀でしょうね。
//自分のMeノートも今やxubuntu機。そして現役ｗ

メインPCは少し前にVista 32bitにした。
サブPCはMonXキャプチャ専用機になってる。サブＰＣじゃないとPCI Expressないからー。
HDDは別HDDにファイル同期してるけどバックアップがこれで十分かどうか微妙かな。

>>381
VisualStudioは公式にサポートやめてるので、これで作ると自動的にWin9xでは動かなくなりますー。

http://msdn.microsoft.com/ja-jp/library/bb531344.aspx
＞ Windows 95、Windows 98、Windows ME、および Windows NT の各プラットフォームはサポートされなくなりました。
＞これらのオペレーティング システムは対象プラットフォームの一覧から削除されました。

＞LoadLibrary failedってどの段階でしょう？
STDAPI DllRegisterServer() { return AMovieDllRegisterServer2( TRUE ); }
このコードが動かないのですがAMovieDllRegisterServer2が入っているライブラリも自分でコンパイルするので
DirectShowのライブラリ内で失敗かな。

本当はフィルタ登録なしで動かしたかったけどよくわからなかったので
登録作業の簡略化で妥協。UACのボタンを押すだけで済むならいいかなと。

ドライバ導入ミスってひどいことになったりしたけど、やっとまともに動くようになりました。
久々のOS安装でWindowsって面倒だと痛感。ちなみに2kのまま。

>382
出てきたバイナリにも互換なくなってくるんですね。時代の流れなんでしょうけど。
2kはいつまでもつかなぁ。。

>383
お疲れ様。Vista普及でその手の質問激増してましたしね。
茂木さんの日記見る限りではそんなに難しくなさそうなんだけど・・・試してみよかな。

あ、その前にSDK入れなきゃ。

regsvr32でds_input.auiを登録してもデスクトップにおいた場合はレジストリに
C:\Documents and Settings\Administrator\デスクトップ\
というふうにファイル名にならずにパスの途中までしか記録されない。
コードは>>382なんだが。犯人はVC2008かSDKかどちらかかなぁ。('Ａ｀)

ダブルクォート使っても？

プラグイン内のコードは>>382の一行だけ。文字列は扱ってない。
トレースしてみるとコンパイラが怪しいかなぁ
strsafe.h: iRet = _vsnprintf(pszDest, cchMax, pszFormat, argList);
#pszFormat = "%ls"
#argList = unicodeのファイル名
ここで出力のpszDestに日本語だと壊れたファイル名が出力される。（'A`）

バグ回避コード
C:\Program Files\Microsoft SDKs\Windows\v6.1\Samples\Multimedia\DirectShow\BaseClasses\dllsetup.cpp
175行目あたり
// (void)StringCchPrintf( achTemp, NUMELMS(achTemp), TEXT("%ls"), szFileName );
char str[1024];
WideCharToMultiByte(CP_ACP, 0, szFileName, wcslen(szFileName)+1, str, 1024, NULL, NULL );
(void)StringCchPrintf( achTemp, NUMELMS(achTemp), TEXT("%s"), str );

するってーと、StringCchPrintf()がUnicodeをまともに扱えてないってことですか

もしかするとsetlocale(LC_CTYPE, "japanese")が必要なのかも。
プロジェクトはMBCSなのだが。
だとするとコンパイラじゃなくてSDK側がだめなのか。

String〜はstrsafe.libの中だそうで。SDK側かな？

話し変わって、どうやらVDがVBR-MP3に対応したそうですね。
nBlockAlignが1152のままなのは微妙に納得できないけど。

妖精さんの記事がとても興味深かった。いくつか気付いたので個人的めも。
MSのドキュメントでMPEG1WAVEFORMATのVBRへの言及をVBRサポートの根拠の一つにしてるけど、
AVIだとnBlockAlignは1じゃなくて大きい値にしないといけないのでドキュメントには従えないんだよね。
まぁMP3ならMPEGLAYER3WAVEFORMAT使うから別にいいんだとは思うけど。（こっちにはVBRについて何も書いてない）
オーバーヘッドが大きいって話も出てたけど、別に1frame/chunkにしなくてもいいので(Alexも書いてたはず)、
3frame/chunkくらいにすればビデオ1フレーム毎のインターリーブよりむしろ省オーバーヘッド。
もちろんこの方法はAVIMux-GUIのlow overhead modeとは違うから、互換性の問題もなし。
nBlockSizeに最大サイズでPADDING_ONは素直なのか微妙な気がする。
少なくとも、最大サイズになるchunkではフラグの"Always insert padding."に反するわけだし。
nBlockSize+=1すればいいかもｗ
最後に、MP3のフレームに含まれるサンプル数ってMPEG2/2.5だと1152じゃなくて576なんだよね。
パディング付きフレームが連続してるとフレームサイズを間違うのでちょっとまずい。

なんか長くなっちゃった。
さて、mp3input.auiのバグ直さなきゃ。(nAvgBytesPerSecの計算で1152固定になってやがるｗ)

ちょっと補足。

問題があるのはDirectShowのBaseClasses(stmrbase.lib)みたいです。
strmbase.libはマルチバイト(MBCS)版とUnicode版があります。（自分でコンパイルします）

関数にUnicode処理をさせるにはロケールの設定が必要らしいです。
マルチバイトしか使ったことがなかったのでUnicodeビルドのお約束を知らなかったのですが。
BaseClassesの中のdllsetup.cppの中では以下のようにファイル名を処理しています。

1. GetModuleFilenameAでdllのファイル名を取得。
2. MultibyteToWideCharでUnicodeに変換。
3 StringCchPrintfでUnicodeを処理。

マルチバイト版での問題は3では通常、ロケールが設定がされていないのでUnicode処理をさせてはいけないこと。
事前にWideCharToMultibyteでマルチバイトに変換する必要があります。
Unicode版での問題は条件コンパイルされていないためGetMuduleFilenameWを使ってくれないこと。
Unicode依存文字がファイル名に含まれているとフィルタ登録ができません。(マルチバイトも同じみたいですが…）

あー、そういうことか。
やっと事態が飲み込めました。ボケててすみません。
ロケールが不明なためString〜はコード変換できずにコケると。
勉強になりました。

にしても、この不完全なSDKでも他の人はうまく使いこなしてるんですかね・・・

warpsharpMT化に対抗して更新(嘘

いや、バグ見つけてくれたようだったのでこっちも修正のつもりだったんだ。
なんでだろ、見つけてもらったバグだけど、手元のソース見たらなんかもう直ってたんだ。
更新履歴みると2004年に手を加えてるっぽいんだ。

・・・公開するの忘れてました。ほんとごめん。


あとdepthとbumpの最大値だけど、見る限りオーバーフローし得ないので256のままです。一応書いとく。

なんというドジっ子。乙

>>394
元の処理ならオーバーフローしないです。
それで悩まされたんですけどｗ
SSE2化したコードの中で16ビットを一時的に超えることがあるのでそこですね。
メモリ使用は抑えられるはずなんですが、面倒だったのと速度優先でああなりましたｗ

そろそろﾎｼｭ。なんか忙しくてコードに触れてすらいなかった。ぷろぐらみんぐぶんがふそくしている

厄年だからか、今度はノートPCが壊れました。まあ7年半使ったから相当持ったほうかな。
思えば最初に手にした「自分のPC」だったわけで、感慨深いものも・・・あれ？あんまりないな。

Modの話。
ソースを適当にディレクトリ分けして、全体的にコード整理、
32bitRGBとYC48の入力(デコード)に対応、あと入力のキャッシュを作り中。公開はまだ。

実家に顔出してる間進めたかったんだけど、その初日でノート壊れたから全然すすまなかった。

おつ

拡張編集で気付いたけどSDKにこんなの追加されてたんだな。
2008/7/29(0.99e2)
　[auf]SYS_INFOにbuildの項目を追加。
　[auf]1つのaufファイルで複数のフィルタを登録できるようにした。

バージョンチェックが今まで出来なかったのはまあ注意書きだけで何とかしてたけど。
複数フィルタは画像と音声の両方を扱えるフィルタが作れるということか。

おひさしぶりです

文書という名の駄文書きましたよ。無駄に長いだけで見る価値はほとんど無いです。
語り尽くされた内容ですし。
しいて言えば3.2のRGB-YC48の変換式くらいかな、使えそうなのは。
で、いざうｐ！と思ったらなんか垂れ幕下がってて、0.99g4とか書いてあるんです。
もうね、(俺は)アホかと、(俺は)馬鹿かと。(ry

Modのページにも手を入れたかったんだけど、99g4でも計算式確認してたらやる気なくなっちゃった。
また今度。

>399
int型で宣言されているということは、この先2147483647回しか更新しないつもりなのだな！
バージョンチェックはauiやauoにも欲しいところですね。
サンプル見る限り、画像+音声に限らず画像+画像+画像とかでも良さそうですね。
フィールド分離・結合はくっつけてしまおうかな。
aufのみじゃなく、auf+auoとか別種の組み合わせもできたら面白いんですけどね。

o(^o^)oドキドキ

なんか見つけためも
ttp://resic.laburec.net/log/2008_12.html#20081228

これはプラグインの仕様が決まるまで待ちか？

Modで考えてたのは、各行ごとに分けて呼び出す形。
奇数幅からyuy2とか考えると、二次元をどう扱うか面倒だし。
あと、入力映像の高さが負の時の上下逆転もやりやすい。

×二次元をどう扱うか面倒だし。
○二次元だと端をどう扱うか面倒だし。

すいみんがひつようだ

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。