- 1 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/06/05(木) 21:41:16 ID:i6fbwhna0]
- ようつべ、ニコニコ動画はyoutube板
pc11.2ch.net/streaming/
ダウンロードした動画はダウンロード板
tmp7.2ch.net/download/
x264関係はDTV板x264 VFW 専用スレへ
find.2ch.net/?STR=x264+VFW
AviUtlのお部屋
spring-fragrance.mints.ne.jp/aviutl/
プラグイン解説
cwaweb.bai.ne.jp/~icchan/moviefile/AviUtl_P.htm
AviUtl総合スレッド45
pc11.2ch.net/test/read.cgi/software/1209992239/
- 876 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 05:46:53 ID:rU3tuL6Q0]
- 今気がついたんだが、99d3になってまた（まだ？）rgb2yc()の処理がおかしい気がするな。
pixelpに投げたポインタから少なくとも8バイト分は一気に読みに行くようで
確保したメモリ領域が8バイトの倍数でないと、確保されていないところまで読みに行って
0xc00000005の例外が出る。オフセットアドレスは0x00037e1aだそうだ。
てっきり作りかけの自作プラグインが悪いのかと思っちまった・・・
- 877 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:14:37 ID:rU3tuL6Q0]
- ごめん、分かりにくいかもしれないので補足。
検証のためにやったことは、
1. バッファの末尾(BMP的には先頭)の1ラインを一気に処理→画像によってOKだったりNGだったり
2. 1.でNGな画像のバッファの中間の1ラインを一気に処理→OK
3. 1.でNGな画像のバッファの末尾のラインの左端1ピクセル目だけ処理→OK
・・・（中略）・・・
4. 1.でNGな画像のバッファの末尾のラインの右端から3ピクセル目だけを処理→OK
5. 1.でNGな画像のバッファの末尾のラインの右端から2ピクセル目だけを処理→NG
24bit BMPを扱っているので、右端から3ピクセル目だと
確保されているバッファは残り9バイトだが
2ピクセル目では残り6バイトになる。
あれ、よく考えたら>>876説では1.でNGになった画像が横512ピクセルなのと矛盾するな。
徹夜で頭がボケてら・・・
ちなみに横が4096ピクセルとか848ピクセルとか378ピクセルとか22ピクセルのは大丈夫だった。
- 878 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:20:36 ID:z1borOEQ0]
- >>877
そのバッファはどうやって確保してる?
メモリは4KBのページ単位で確保されているので、
うまい具合にバッファの末尾がページの最終バイトになるようにしないと、
ちゃんと再現しないよ?
- 879 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:22:53 ID:z1borOEQ0]
- まさかとは思うけど、
BMPは1ラインが4バイトの倍数になるようにパディングが必要
ってことを忘れていて、あなたが確保したメモリが足りない・・・だったりする?
- 880 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:24:48 ID:r2l78CL70]
- >>824
マジできてる━━━━(Дﾟ(○=(ﾟ∀ﾟ)=○)Дﾟ)━━━━!!!!
プラグインの作者様達乙なのです。
- 881 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:28:47 ID:z1borOEQ0]
- ごめん、自分も眠くてボケてた。
>>878と>>879は、なかったことにして。
- 882 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:31:01 ID:rU3tuL6Q0]
- >>878-879
朝早くからレスありがとう。
バッファは原始的にmalloc()してる。
ただ、rgb2yc()は元のデータがBMPだったかどうかは全然関係ないわけで、
BMPの読み込みが正常に完了してる以上はメモリが足りないことはないと思うんだな。
もうちょっと追試してみたが横じゃなくて縦も関係あるようだ・・・
512x47→OK
512x48→NG
いったい何が悪いんだ・・・orz
- 883 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:35:18 ID:z1borOEQ0]
- >>882
NGなのは確実にNGとしても、
OKなのは、偶然そのアドレスが有効だったので、たまたま動いているだけ、だと思う。
- 884 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:36:42 ID:rU3tuL6Q0]
- ポインタをよーく観察したら、やっぱりページ境界が関わっているようだ。
バッファの先頭がページの先頭になるとして、
512x47の画像を読み込んだ時にはバッファの末尾がページ境界に来ないが、
512x48の画像だとバッファの末尾がちょうどページ境界になる。
- 885 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:39:39 ID:rU3tuL6Q0]
- 書き込むとレスが付いてる法則・・・
>>883
自分もそういう結論に達した。
やっぱり原因はrgb2yc()の中にあるようだ。とりあえず修正されるまでの間は
バッファがページ境界ぴったりに収まってしまう場合もう1ページ余分に確保するしかないか・・・
- 886 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 06:41:46 ID:z1borOEQ0]
- あーうまく1レスにまとめて書けなくて連投でゴメン
OKなのは、本当にOKなのと、たまたま動いているだけの2つ。
たまたま動いているのがNGになるようにするためには、
Win32APIのVirtualAllocを使って、
1バイトでもオーバーランしたらページアクセス違反になるようにする。
具体的には、
VirtualAllocにMEM_RESERVEを付けてアドレス空間を予約する
VirtualAllocにMEM_COMMITを付けてメモリを確保する
メモリを確保している範囲と予約しただけの範囲の境目が、
バッファの終わりになるようにRGBデータをメモリに書き込み、
rgb2ycを呼び出す。
- 887 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 07:21:57 ID:rU3tuL6Q0]
- >>886
それの確実なやり方なんだけど、1回目ではわざと大きめに予約しておいて、
2回目で1回目に返ってきたアドレスをぶち込んでサイズは画像ぴったりに確保、でおk？
一応上のやり方で確保してテストしてみた。
だけど・・・不思議なことに挙動に変化はなかった。
そして予想通り、確保する領域を1ページだけ増やしたら動いた。
- 888 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 07:44:10 ID:z1borOEQ0]
- >>887
2回目のときのサイズは画像ピッタリでOK (OS側がページサイズに切り上げてくれる)
ただし、画像の末尾がページ境界になるように、画像を配置する。
たとえば画像が100バイトだとしたら、
100バイト+4Kバイトを予約 → 8Kバイトが予約される
そのアドレスで100バイトをコミット → 4Kバイトがコミットされる
そのアドレスから、4096 - (100 % 4096) バイト 進んだ位置に、
画像100バイトの画像をコピー。その100バイトの先頭をrgb2ycに渡す
こんな感じです。
- 889 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 08:05:22 ID:rU3tuL6Q0]
- >>888
おk
再現できた。
アクセス違反の起こったアドレスはすべて4kページ境界。
- 890 名前：名無しさん＠お腹いっぱい。 mailto:sage [2008/07/01(火) 08:28:24 ID:z1borOEQ0]
- 乙
あとは作者に連絡するだけですね。
|
 |
