08/07/21 00:46:56 sGPc9KSe
気になるならクロップしなきゃいいじゃないか
90:名無しさん＠編集中
08/07/21 00:50:08 Ei0ANto/
NTSCならSAR 40:33(DAR 16:9)かSAR 10:11(DAR 10:11)のどちらか
91:名無しさん＠編集中
08/07/21 00:50:47 Ei0ANto/
SAR 10:11(DAR 4:3)
92:名無しさん＠編集中
08/07/21 01:36:56 CErfmXsY
>>89 >90 >>91
レスありがとうございます。
SARというのはスクリーンアスペクト比ですよね。
SARの設定というのはどの状態（再生ソフト側もしくはエンコード時）
で行うのでしょうか。
現在aviutl用いてdivxでエンコードしています。
再生ソフトはMedia Player ClassicとGOMplayerあたりをを主に使用しています。
93:名無しさん＠編集中
08/07/21 05:28:42 4uWlY1QP
いや普通に考えてエンコ時だろ
いちいち再生するたびに設定しろとでもいうのか
DivXってエンコの設定でSARの設定できなかったっけ？
確か入力と出力の両方に設定項目があってなんだこりゃと思った記憶がある
てかAVIなら素直にリサイズしてSAR 1:1の状態にした方がいいと思うよ
94:名無しさん＠編集中
08/07/21 08:45:52 XlGRgOQ2
＞SARというのはスクリーンアスペクト比ですよね。
わざわざDAR4:3って併記してあるのになんでそうなるんだ？
この場合サンプルアスペクトレシオと解釈するべきだろつまりPARと同じ
95:名無しさん＠編集中
08/07/21 23:35:46 CErfmXsY
>>93
レスありがとうございます。
>てかAVIなら素直にリサイズしてSAR 1:1の状態にした方がいいと思うよ
ということはクロップせずに直接720x480から640x480にした方が良いということでしょうか。
何回も質問してすいません。
>>94
すいませんちょっと勘違いしていました。
divxにはSAR項目が無かったので今まで知りませんでした。
x264にはちゃんとありますね。
今まで特に何も考えずにエンコードしていたので勉強になります。
96:名無しさん＠編集中
08/07/21 23:57:29 Ei0ANto/
640x480にリサイズするなら、一端704x480にクロップしてからでないと歪む。
DivXでもPARは設定できる。自分の使っているプレーヤーが対応するならこれでもいい。
URLﾘﾝｸ(img169.imageshack.us)
97:名無しさん＠編集中
08/07/21 23:59:05 XlGRgOQ2
>>95
>>2
98:名無しさん＠編集中
08/07/22 00:01:09 2Ha20gYm
AVIって基本的にアス比情報持ってないんじゃないか？
クロップするかしないかは好みだろうがリサイズしとけばいいんじゃねーの。
99:名無しさん＠編集中
08/07/22 00:04:20 ysAev21s
VP6等他のVfW用のCODECは非対応でも、DivXやXvidと言ったMPEG-4 ASPなら
ビットストリームでPARを持っているから、この場合コンテナは関係ないと私は思う。
100:名無しさん＠編集中
08/07/22 00:20:56 2Ha20gYm
まぁ対応してるプレーヤー使ってるならそれでいいか。
101:名無しさん＠編集中
08/07/22 00:41:59 yr6rERPq
俺用メモ
720x480 → (4:3) 720x540
720x480 → (16:9) 852x480
704x480 → (4:3) 704x528
704x480 → (16:9) 852x480
102:名無しさん＠編集中
08/07/22 00:56:04 g42/LmeL
>>96
ありがとうございます。
どうやら自分の使っているDivxPROの5.0.5とは
設定項目欄が違っていたようです。GUI部分にはありませんでした。
CLIで出来なければ違うコーデックで実験してみたいと思います。
103:名無しさん＠編集中
08/07/22 01:08:04 jSa1fueb
俺メモ
1440x1080→1440x1080(16:9)
1440x1080額縁→1080x1080(左右180(合計360)クロップ)→リサイズ640x480(1:1)
1440x1080超額縁→1080x810(左右180(合計360)、上下135(合計270)クロップ)→リサイズ1024x576
720x480額縁→528x480(左右96(合計192)クロップ)→528x480(40:33)
・・・大丈夫だよな。不安なんだ
104:名無しさん＠編集中
08/07/22 04:14:15 iAX/pB16
>>103
2番目は計算上はそれで正しいはずだけど、
実際には1080x1080の時点でまだ額縁が残ってしまうのが多い。
SDでいう720x480相当になっているように見える。
その場合はさらに左右合計24削ってからリサイズ。
でもこれって普通のワイドテレビで見た場合もアスペクト比狂ってるはずだよな。
105:名無しさん＠編集中
08/07/22 07:34:09 le0rGrbn
たまには計算機のことも思い出してあげて！
106:名無しさん＠編集中
08/07/22 21:03:06 jSa1fueb
>>104
定型でリサイズとかクロップしても、ちょっと残る場合があるよね
あれって放送局が間違って送出してるのか、オリジナルもそうなのか
わからないからいただけない
ほんのちょっとだけ残るような場合は上下左右2～4ピクセルくらいを
適当に削ってからリサイズしちゃうけど問題ありかな
107:名無しさん＠編集中
08/07/22 21:23:15 PVfBtmXK
＞1440x1080額縁→1080x1080(左右180(合計360)クロップ)→リサイズ640x480(1:1)
960x720じゃないのか
108:名無しさん＠編集中
08/07/24 00:49:02 9IWtHoEi
>>106
ないよないない。
仕様を知ってたら気持ち悪いけど
左右２ピクセルくらいの歪みを「見て」指摘できる人間なんていない。
絶対いない。
109:名無しさん＠編集中
08/07/27 14:47:21 IAXLo7X0
>>106
クロップ後のサイズが16の倍数でないとエンコ効率が悪くならない？
リサイズ→クロップ→リサイズなら完璧そうだけどやってる人いるのかな
110:名無しさん＠編集中
08/07/27 14:52:28 FGqZjN0v
>>109
>>106は縁が余った時そこを削るために余分にクロップするって言ってるだけでリサイズしてることに変わらんよ。
というかリサイズ＞クロップ＞リサイズってなんか意味あるか…？
111:名無しさん＠編集中
08/07/27 15:02:35 aHH3GJki
方式にもよるが，今は4の倍数か，せいぜい8の倍数でよいと思われる。
112:名無しさん＠編集中
08/07/27 15:39:51 dl/AJpbc
すみません質問させてください
セルDVDのスクイーズ収録などでは両端の黒帯がなく720×480目いっぱいに映像が記録されてますが
NTSCの規格から考えるとPAR40：33で市販の家電プレーヤーなどは再生するハズですので
結果的に表示される映像の画面アスペクト比は「16.363636・・・：9」 （1）
となり、16:9の元ソースより横方向に若干伸びてる（歪んでる）と考えていいのでしょうか？
それとも、それも計算に入れて（1）のような元ソースを横方向に圧縮してるだけなのでしょうか？
また、704×480（16:9 PAR40：33）で収録しない理由は画質的に有利とかそんな理由なのでしょうか？
意味不明な質問でしたらスミマセン
113:名無しさん＠編集中
08/07/27 15:45:51 pwETJipq
プロでも左右の無効領域をよく分からないで制作しているんじゃないかと思うことがよくある。
TMPGみたいにちゃんと無効領域有りの720x480でやってくれるMPEG-2エンコーダばかりじゃないから。
114:名無しさん＠編集中
08/07/27 15:52:41 IKr0BriS
目一杯入ってる≠無効領域無し
黒帯があるのはどうせ家電だとオーバースキャンされて上下左右カットされる
から。んで残りの写ってる部分は40：33で写る。黒帯がないのは最近PCとか
でオーバースキャンとか関係なく端っこまで写るような環境に合わせてってだけ。
115:名無しさん＠編集中
08/07/27 17:14:41 CGfLc/CH
>>112
上の答え：家電を信じろ。歪んでない。(PC再生では心配してるように歪む場合もある)
下の答え：NTSCは720*480が標準規格と決まっているため
116:名無しさん＠編集中
08/07/27 17:49:10 RbjDyci1
液晶テレビも無効領域ってあるの？
ピクセル比は正方？
117:名無しさん＠編集中
08/07/27 18:29:54 SiifyFR2
>>112
すべての答えは>>3に書いてあるよ
118:名無しさん＠編集中
08/07/27 21:42:31 w/DwtGAw
レスありがとうございました
それをふまえてもう一つ質問させてもらいたいんですが
地デジで1440×1080（キッチリ16:9）で放送されてるものをSDサイズにエンコする場合
黒帯ありの720×480と黒帯なしの704×480で正しいアスペクト比が保持されるという認識でいいでしょうか？
入力のアスペクト比保持を解除して720×480（16:9、PAR40:33）で目一杯にエンコした場合、
エンコーダーや再生ソフトによっては歪むこともあるから上記の二つでやるのが無難なのでしょうか？
119:名無しさん＠編集中
08/07/27 23:29:21 qVZDe7jU
俺の場合は地デジ
SAR1:1で1280*720にリサイズ
保存はSDでいいやって場合は
解像度は720*480に統一。
ソースによって9:8と32:27で使い分けしてる。
こんなもん正解はないと思うけど。
120:名無しさん＠編集中
08/08/07 00:10:57 CLK358hZ
DVD4:3スタンダードをMedia Player Classicなどのソフトで見るとき、
左右の無効領域も含んで4:3表示されますが、ということはオリジナルの
ピクセル比率より縦長に表示されているってことですか？
（無効領域を含んでいる分、横方向の圧縮が大きいので）
それとも横16ピクセルのぞいた704x480のピクセルで4:3に合わせてるのですか？
121:名無しさん＠編集中
08/08/07 01:12:33 aa91g5NK
うちのMPCも無効領域含んで表示するよ
122:名無しさん＠編集中
08/08/07 01:25:42 Ww7wUHG5
PDVD8のスプリッタとデコーダでオーバーレイ表示したらNTSCのソースは無効領域カットしてた
123:名無しさん＠編集中
08/08/07 01:53:50 t3wTRW0J
>>120
無効領域含んでるから縦長
124:名無しさん＠編集中
08/08/07 08:18:47 dfyrUPq/
でもそれを気にしてる人はそれを知ってる人だけ。
知らなかったのに縦長だと気づいた人は
デリケートな目の持ち主なので是非クリップするべきでしょう。
125:名無しさん＠編集中
08/08/07 08:25:08 f5wSgOw5
4:3のソースを無理矢理16:9に広げて喜んでいる人が多い世の中だから。
126:名無しさん＠編集中
08/08/07 10:49:49 CLK358hZ
やっぱそうだったんですか・・・
ずっと再生ソフト標準設定のまま見てたので、
クロップしてた方がむしろ違和感があった。
720x480のMEPG2を再エンコせずに正しいアスペクト比
で見ることって出来るのですか？
127:名無しさん＠編集中
08/08/07 11:06:55 3IZyYGXw
素直にテレビで見ればいいんじゃないの
128:名無しさん＠編集中
08/08/07 11:37:35 CLK358hZ
>>127
それはそうですが、PCで見た方が使い勝手が良かったり。
アナログキャプチャしたMPEG2ソースとかもあるので・・・
129:名無しさん＠編集中
08/08/07 11:52:46 f5wSgOw5
>>122の言うPowerDVD 8で再生するか、リップしてクロップ・リサイズをしたavsを再生するかどちらか。
130:名無しさん＠編集中
08/08/07 17:40:40 +tVcfzsz
>>125
うちのテレビのことかｗｗｗｗｗ
131:名無しさん＠編集中
08/08/07 17:46:44 WADtckcl
結局アナログ時代のワイドテレビ全盛の時にワイド放送って殆ど無かったよね。
全然かもしれん。見た覚えないし。
132:名無しさん＠編集中
08/08/07 19:04:52 ucXMDzc3
出始めの頃にサッカーとかであった。すぐに普通の4：3に戻ったけどね。
133:名無しさん＠編集中
08/08/07 20:59:12 VJYCR/dq
質問なんですが
1440x1080(16:9もの)の地デジTSファイルならx264を使う場合どうやるのがベターなんでしょうか。
１．sar1:1で1440x810にリサイズ
２．sar1:1で1280x720にリサイズ
３．sar4:3で1440x1080
４．どれでも好きにしろ
134:名無しさん＠編集中
08/08/07 23:05:30 CRGKeuIp
4
135:名無しさん＠編集中
08/08/07 23:06:05 t3wTRW0J
x264だからどうという質問でもないな
元ソースがスポーツなんかだと縦はそのままでインタレ保持した場合が良い事もあるし
容量気にせずに画質重視ならリサイズする必要も無い
要するに4番
136:名無しさん＠編集中
08/08/08 00:18:51 gV+PGdI8
>>133
正直４だよ。そんなもん人によって違うもん。
俺は２でやってる。８の倍数派に１のウケは悪いけど
別に変てことはない。
ソースがアニメの場合はそもそも1280*720以上の解像度で
作ってないケースがほとんどだと思う。
137:名無しさん＠編集中
08/08/08 00:57:28 vvgxBtXK
2011年の完全デジタル化以降は、
番組・CMともに、テレビ向けコンテンツのほぼすべてが
16:9になると思っていていいのでしょうか？
138:名無しさん＠編集中
08/08/08 05:28:32 UiSC5Ez4
昔っぽい演出のためにわざと4:3で撮って黒べた追加してくるかもよ
これも結果的に16:9として手元に届くがな
139:名無しさん＠編集中
08/08/08 05:40:25 1VBWcR9v
今の放送はどうせ1440x1080にはビットレートが足りないのだから、SAR1:1の1280x720だけにしてくれたら
このスレにもどうでもいい質問が減るのに。
140:名無しさん＠編集中
08/08/08 07:02:00 PqsLYvS8
>>133
４
エンコード＝必ず品質が劣化する
ということで、エンコードするのは品質より容量問題が優先だろうからね
141:名無しさん＠編集中
08/08/08 07:05:06 PqsLYvS8
>>139
地デジのほとんどの1440x
衛星の1920x
のどちらもビットレートが全く足りないよね
衛星デジ始まったときからさんざん文句言いすぎてもうどうでも良くなった
142:133
08/08/08 21:38:31 0Clqwz5n
みなさま回答ありがとうございました。
４の通りに好きにしてみることにします。
143:名無しさん＠編集中
08/08/15 14:59:11 MIxmiTgF
Width : 720 pixels
Height : 480 pixels
Display Aspect ratio : 16/9
Frame rate : 29.970 fps
Standard : NTSC
上記のソースを無効領域を削除して正しい縦横比にしたい場合、
>>2の「Q.720x480,スクイーズ」の方法でよろしいのでしょうか
144:名無しさん＠編集中
08/08/15 15:13:01 UzzGSv0Y
>>143
それでいいです
145:名無しさん＠編集中
08/08/15 15:14:47 MIxmiTgF
>>144
ありがとうございました
146:名無しさん＠編集中
08/08/16 13:40:41 sAZg+hCO
質問なんですが、>>2に
>A.左右合計16ドット削り、704x480に画面比4:3もしくはピクセル比10:11指定
> リサイズするなら704x480→640x480
> 何も削らずに720x480にピクセル比10:11でもOK
とありますが、720x480（DVD、4:3、アニメ）をエンコードする時に
720x480のままリサイズで、640x480にリサイズした場合は
アス比が崩れてるっていうことでしょうか？
4:3アニメでも左右8ずつ削るか、ピクセル比を指定しないと
アス比は崩れるっていう認識でOKってこと・・・？
147:名無しさん＠編集中
08/08/16 13:48:10 g4tgYs4L
720から削らないのなら、720*10/11で横は656(mod16)とかにしないと歪む。
148:名無しさん＠編集中
08/08/16 14:12:16 sAZg+hCO
>>147
やはりそうなるんですか・・・。
今まで720x480からリサイズで640x480を作っていたのは、間違っていたってことか
何で早く気づかなかったんだ
149:名無しさん＠編集中
08/08/16 14:39:34 sAZg+hCO
ちょっと思ったんですが、720x480をx264でエンコするときに
--sar 8:9 を記述してやるってのは微妙に違いますか？
704x480（左右8ずつ削る）場合は、--sar 10:11 ってことなのか。
150:名無しさん＠編集中
08/08/16 14:48:30 g4tgYs4L
NTSCのSARは10:11か40:33のどちらかだから、720から削らなくても--sar 10:11でいい。
DARを4:3や16:9にしたいのなら、横は704にする必要がある。
151:名無しさん＠編集中
08/08/16 15:05:10 sAZg+hCO
>>150
あーなるほど。SARとDNRか
なかなか難しいですねｗ ありがとうございました！
152:名無しさん＠編集中
08/08/16 22:36:19 UZVZiHQ7
ノイズリダクションになってる
153:名無しさん＠編集中
08/08/17 00:01:02 3YHu+Rpq
じゃあぼくは3DNRちゃん
154:名無しさん＠編集中
08/08/17 11:39:32 KBnLISGG
>>150
なんか自信満々だけど、根拠をお伺いしてもよろしいでしょうか？
155:名無しさん＠編集中
08/08/17 11:58:36 Rzgt7tcn
>>154
これのE.2.1
URLﾘﾝｸ(www.itu.int)
156:名無しさん＠編集中
08/08/17 12:00:00 9st1YNkr
根拠はNTSCだからじゃない？
NTSCに準拠してない映像なら意味ないけど
157:名無しさん＠編集中
08/08/17 19:13:36 IH8zrBZE
自分で見てわからないことを理解する必要はないよ。
つーか左右8ドットのアスペクトが狂ってることを見抜ける奴はいない。
158:名無しさん＠編集中
08/08/18 18:51:08 7pVMFQlw
こうやって自分の無知を正当化しようとする書き込みがくるのがいつものアスペクト比スレだねw
平和だw
159:名無しさん＠編集中
08/08/18 18:55:22 s+wGikQ4
>>158
だからナニ？
ま、こんな奴に限って目腐ってるんだろうけどね。
160:名無しさん＠編集中
08/08/18 19:02:42 ryzjZIph
>>2とこの表だけあればいいか。
URLﾘﾝｸ(img208.imageshack.us)
161:名無しさん＠編集中
08/08/18 19:20:35 ocXLkFRs
実際のところ知ってるか知らないかだけの話だしな。
>>157の言う通りで、また得意満面な>>158みたいな奴に限って見てそれがわかったりはしないと思う。
162:名無しさん＠編集中
08/08/18 19:26:08 pS/dHA4e
720*480（これは画面解像度）
16:9、4:3（これはスクリーンアスペクト比）
40:33、10:11（これはピクセルアスペクト比）
同じ720*480でもスクリーンアスペクト比が違うのはピクセルアスペクト比が違うから
ピクセルアスペクト比は１ピクセルの縦横の比率で正方形ピクセルなら1:1
リサイズとは解像度の変換
左右合計16ドット削りとは無効領域を削除の意味
無効領域を削除した後、スクリーンアスペクト比を指定で正しいアスペクト比になる
色々読んでみて自分での解釈が上記のようになったのですが正しいのでしょうか・・・
こう考えるとたまに他スレなどで見る704*396というのはなんのためにしているのかよくわかりません
解像度を16:9にしているってことでしょうか？
163:名無しさん＠編集中
08/08/18 19:30:28 ryzjZIph
720x480から>>160にあるhorizontal overscanを除けば704x480になる。
704x9/16で横はそのままで、縦は396と言う計算だろう。
164:名無しさん＠編集中
08/08/18 19:53:28 pS/dHA4e
horizontal overscan=水平方向に画面サイズの領域をはみ出たテレビ映像=横方向の無効領域ってことであってますか？
＞704x9/16で横はそのままで、縦は396と言う計算だろう。
これは解像度を16:9にすることによってスクリーンアスペクト比が16:9になるって意味なんでしょうか？
アスペクト比を確実に16:9にするための手段とかでしょうか？
165:名無しさん＠編集中
08/08/18 19:57:57 ryzjZIph
>horizontal overscan=水平方向に画面サイズの領域をはみ出たテレビ映像=横方向の無効領域ってことであってますか？
そう
>これは解像度を16:9にすることによってスクリーンアスペクト比が16:9になるって意味なんでしょうか？
>アスペクト比を確実に16:9にするための手段とかでしょうか？
704x396はSAR 1:1にしか対応しない環境でDAR 16:9を実現する苦肉の策だと思う。
できる限り704x480にSAR 40:33を指定してDAR 16:9にした方が良い。
166:名無しさん＠編集中
08/08/18 20:10:21 pS/dHA4e
ご丁寧なご説明ありがとうございました
これでやっとアスペクト比の事が完全ではないかもしれませんが理解出来たように思います
167:名無しさん＠編集中
08/08/18 20:33:49 xySFCLmt
どなたか地デジ（BSデジ）の場合も解説してくれんかの～
1440x1080（下8ドットの無効領域除外）:
16:9
Full -> そのまま16:9（1280x720等）へリサイズ
Letterbox -> 上下135、左右180削って16:9へリサイズ
4:3
左右180削って4:3（1280x960等）へリサイズ
って感じでええかの？
168:名無しさん＠編集中
08/08/18 20:47:06 ryzjZIph
1920x1080や1280x720はSAR 1:1のままで1440x1080はSAR 4:3
クロップは画面を見ないと分からない。
169:名無しさん＠編集中
08/08/18 21:00:24 ItBdLB/j
720*480をアスペクト比無効で再生すれば画面いっぱいで見れおかしな劣化もない
170:167
08/08/18 21:08:42 xySFCLmt
補足
16:9とか4:3はDAR表記です。
（リサイズする場合なんで）
>168
>クロップは画面を見ないと分からない。
額縁かそうでないかの２種類しかないのかな、と。
171:名無しさん＠編集中
08/08/18 21:40:53 gSSzD8Xj
720x480を4:3の動画にするなら
１、720x480を704x480にして、リサイズ（640x480）
２、720x480のままsar10:11を指定
３、720x480を704x480にして、リサイズ+sar10:11を指定
ってことになるのかな？３はおかしい・・・？
172:名無しさん＠編集中
08/08/18 21:50:07 ryzjZIph
704*10/11=640だから、3にはクロップだけすればリサイズは必要ない。
173:名無しさん＠編集中
08/08/18 21:50:22 pS/dHA4e
>>171
先ほど質問する側だった者ですが、それは>>2なんだとおもいます
174:名無しさん＠編集中
08/08/18 23:22:20 gSSzD8Xj
なるほど。やはり3の場合はリサイズ不要ってことか！
１、720x480のままsar10:11
２、704x480にしてsar10:11
３、704x480にして640x480にリサイズ
ということになるみたいだけど、１は間違いって認識でOK？
175:名無しさん＠編集中
08/08/18 23:30:19 t1G/nmTd
>>174
いや1.もあってる。単に黒い縁が残るだけ。それでもいいなら
176:名無しさん＠編集中
08/08/18 23:34:59 7pVMFQlw
なんでや
１でも２でも同じだろうたんに表示エリアが違うだけ
その前にsarという表記はｘ264だけだしscreen aspect ratioと混同するので
通常はparと表記するべきだよ
177:名無しさん＠編集中
08/08/18 23:57:28 gSSzD8Xj
>>175
>>176
レスありがとうございます。
確かに--sarというのはx264での表記なので紛らわしいですね・・・
助かりました。
178:名無しさん＠編集中
08/08/19 00:30:55 /x3ML140
h.264はテロップとかの時ブロックノイズ見たくなる
ブロックノイズはDivxの方が多いと思ったけど、Divxの2-Passだとブロックノイズなんて入らない
Divxのほうが綺麗に見えるんだけどみんなh.264使ってるの？
179:名無しさん＠編集中
08/08/19 00:35:19 IE2RLl2Y
すさまじくスレ違いな質問だな。
180:名無しさん＠編集中
08/08/19 09:38:05 wSLzlgOu
sample aspect ratioはITU-Tで使われる用語で別にx264独自ではない。
181:名無しさん＠編集中
08/08/19 09:51:56 jwbLRiJ9
>>178
【DivX/XviD】最強コーデック決定戦【H.264/WMV9】
ｽﾚﾘﾝｸ(avi板)
あんたはこっち
182:名無しさん＠編集中
08/08/19 14:52:06 JIc/RxE8
リサイズによる劣化を聞きたかったんだろ
答えてやればいいのにコーデックスレに誘導とかｗ
h.264はオリジナルじゃないと変な歪みが出る
183:名無しさん＠編集中
08/08/19 15:19:10 KunqYt5w
は？
おまえはなんでもいいから煽りたいだけだろ。
出直してこいトンチンカン。
>>178を読んで本当にそう思うなら相当国語力に問題あるぞ。
184:名無しさん＠編集中
08/08/19 15:30:59 G7GCo/7J
どうもここのところ自分だけ特別な存在の上から目線君が住み着いてるな。
おおかた>>158=>>183てところだろ。
違ってたって知ったこっちゃないけど。
185:名無しさん＠編集中
08/08/19 15:33:36 KunqYt5w
俺は>>158じゃないｗ
まあいいけどさｗ
186:名無しさん＠編集中
08/08/19 16:35:02 JIc/RxE8
>>183
>>178の文章だけ読んだらコーデックの優劣を聞いてるようだけど、>>177の人がx264とだして自分はDivxを使ってる
疑問に思って
>Divxのほうが綺麗に見えるんだけどみんなh.264使ってるの？
と書いているんだろ
単純に使ってるコーデック答えればいいだけの質問
187:158
08/08/19 22:59:57 qZUbvUEo
>>184
上から目線も何も
過去スレやテンプレに書いてあるURLを参照すれば誰でも理解できることを
堂々巡りで繰り返す馬鹿が巣くっているのがこのスレでしょ？
頭わりーなぁって思わないほうがおかしいだろw
188:名無しさん＠編集中
08/08/19 23:57:18 vhRzmmFF
すいません便乗になるんですが
>>174さんの
１、720x480のままsar10:11
２、704x480にしてsar10:11
３、704x480にして640x480にリサイズ
１については
>>2
Q.左右に映像があるのに16ドット削っちゃうの？
A.別に嫌ならそのまま削らずにピクセル比指定すればいい
にあるように削る部分に映像あるなら720x480のままsar10:11にすればいいんじゃねってことでおｋ？
189:名無しさん＠編集中
08/08/20 00:00:38 jwbLRiJ9
>>187
それを言ったら>>160だけでいいんだよ。
質問も回答もいらない。
でもそうはならないだろ？
キミの思い通りのスレにならなくて悪いけどさｗ
190:名無しさん＠編集中
08/08/20 00:01:27 sRsv5QWM
>>186
で、誘導したら馬鹿なんだｗ
面白いね。キミｗ
191:名無しさん＠編集中
08/08/20 00:13:10 2t24cBNW
>>188
そう。画面を4:3にしたいのなら、オーバースキャンの分横を合計16ピクセル削る必要があると言うだけ。
192:名無しさん＠編集中
08/08/20 00:24:53 5leHr/0y
つまり、16ドット削っても削らなくても大差ないから好きな方でOKってことだろ
ソースと並べて比較しても見抜くのは難しいはずｗ
193:anonymous
08/08/20 00:26:34 +iFYzkEr
>>188
多分それでいいんじゃない？ 結局何が目的かによるんだよ。
DVDリップやテレビ放送をアナログキャプチャしたのを、
後でPCで見る用途のために H.264とかにエンコしなおすとき
の処置を聞いてるなら多分それでいいし、もちろん２でも３でもいい。
(映像あるところを削るのもいとわなければ)
PC上のプレイヤーは大体どんな画素数・アスペクト比でも指定されたとおり
表示できることが多いから。
4:3の DV ソースから、SDTV な BD-Video を作るなら１しか
ありえない BD の規格がそうなってるから。
194:名無しさん＠編集中
08/08/20 00:28:22 u5HhlBES
720x480を4:3で表示させる場合のピクセル比10:11
1.クロップ無しの場合
720x10=7200
480x11=5280
7200:5280=4:2.93
2.左右合計16ドットクロップした場合
704x10=7040
480x11=5280
7040:5280=4:3
なぜクロップ無しの方(1)も4:3で表示されるの？
少し縦長にならないの？
195:158
08/08/20 00:31:12 euHFVYha
>>189
はぁ？
>>160なんて何の参考にもならん
NTSCなら
URLﾘﾝｸ(tmpgenc.pegasys-inc.com)
読めば簡単に理解できるし
地デジやらのHV放送はアス比計算機でも使えば簡単に答えが出る
もちろん手計算でもなんら問題波ないけどね
このスレはテンプレだけ存在して後は保守だけでいいんだよ
あ、PAL関係はまだ出てなかったはずだからPALのアス比に関しては
いろいろ話が出ても良いとは思うけどね
196:名無しさん＠編集中
08/08/20 00:38:18 2t24cBNW
PALは>>160の表にある12:11(DAR 4:3)か16:11(DAR 16:9)で十分だろう。
197:名無しさん＠編集中
08/08/20 00:42:06 xm5vHZhF
>>194
お前の計算は合っている
1.で4:3表示したらおかしい比率ってことだ
198:名無しさん＠編集中
08/08/20 00:45:51 5leHr/0y
>>194
でも、その崩れてるのを目で見て分かるなら左右8ずつ削ればOK
199:158
08/08/20 00:46:02 euHFVYha
質問のレベルもあまりにも低すぎるが・・・答えるほうもバカばっかになってるのか？
>>191
オーバースキャンなんて関係ない、横16ピクセル削るのは別の理由だよ
>>192
大差があるかないかは個人の価値観、自分の価値感を基準にするな
>>193
「4:3の DV ソースから」なんて書くから>>194が間違う。「スタンダードサイズ」とかほかの言い方をするべき
>>194
もちろん4:3で表示されないが画面のアスペクト比は維持される（真円が真円として表示される）
>>195
そんなことはどこでも書いてるし計算すりゃ簡単に出る。
俺が言ってるのはPALのピクセル周波数とかそっち方面のことだよ・・・
とにかく半端な知識を広めるのはやめたほうが良いよ
200:名無しさん＠編集中
08/08/20 00:47:56 5leHr/0y
ちょっと日本語変だなｗ
201:名無しさん＠編集中
08/08/20 00:52:57 F/ZLT82b
>>190
このスレの人が使ってるコーデックを知りたかったんだろ！
ホント読解力ないな
2ちゃんねるは1から10まで懇切丁寧に書き込む奴なんて少ないんだから、わからんならスルーしろよ
202:193
08/08/20 00:56:14 +iFYzkEr
>>199
うーん、一応曖昧な話にならないように、規格上の言葉を使っただけだけどね。
DVストリームには4:3か16:9のどちらかを示すフラグがあるので
それを指したつもりだが
ちなみに、DV絡みの文脈で「スタンダードサイズ」というとカセットの
大きさのことを想像しちゃうけどね
203:名無しさん＠編集中
08/08/20 00:59:35 5leHr/0y
>>174のsarはx264のコマンドだから実際はparのことか
204:名無しさん＠編集中
08/08/20 01:19:35 2t24cBNW
PALについては一度ITU-R BT.601をしっかり読まないといけないな。
ただヨーロッパのDVDをリッピングするだけならSARの丸暗記で十分だと思うが。
205:名無しさん＠編集中
08/08/20 01:26:18 2t24cBNW
もし他に興味のある人がいるのなら。
URLﾘﾝｸ(inst.eecs.berkeley.edu)
206:名無しさん＠編集中
08/08/20 03:24:40 SaYKtUAO
>>194
同じピクセル比だから、縦長にはならない。
207:名無しさん＠編集中
08/08/20 10:26:49 otfmDK9d
＞自分の価値感を基準にするな
こいつ絶対アスペクトなんて見抜けないよｗｗｗ
208:名無しさん＠編集中
08/08/20 10:28:05 otfmDK9d
>>201
おまえはホントに馬鹿だなあｗｗｗ
209:名無しさん＠編集中
08/08/20 10:36:11 vLaeHYgh
てめえの自尊心満たすだ煽りくれてるやつはそろそろ黙れよ。
おまえがぼくはすごいんだじょ～ってだけの話が誰の役に立つんだ。
210:名無しさん＠編集中
08/08/20 12:50:09 TqLxvDQH
おまえらいい加減別なところ行ってやってくれ、無駄にスレ消費するな
211:名無しさん＠編集中
08/08/20 13:26:35 lNiXqOu9
>>194
1を再生した場合4:3じゃなくて少し横長に表示される
2を再生した場合4:3で表示される
ピクセル比は同じだから両方正常
212:名無しさん＠編集中
08/08/20 16:46:52 wGh4kSry
720*480 SAR4:3
これを見た目のアスペクト比が正しくなるようにする場合、PAR10:11の指定をすれば正しくなる
そのかわり720*480の解像度のままでは見た目は正しいアスペクト比になるけど無効領域が含まれたままなので、表示される範囲は正確なSAR4:3にはならない
表示される範囲も正確なSAR4:3にしたいのであれば横合計16ドット削って704:480にする
SAR4:3 PAR10:11どちらも正確な数値にしたいなら704:480に
見た目のアスペクト比が正確になるだけでよければそのままPAR10:11を設定してやればいい
どちらにするかは個人の拘り具合
こういう事なんじゃないの？
再生する時、表示サイズ100%だったら気にするほどのことではない
全画面表示する時左右に無効領域が表示されて気になるって人は削ればいい
こんなところなのでは？
213:名無しさん＠編集中
08/08/20 17:23:20 hSSQUH+t
▲▃ ▅▂▃▅ ▂▄▃▅▆▃
█▀▲ ▆█▀█▀ ▀■▀▀ ▃▆▀
▅█▃█▀▅▀▅▃▉ ▀▆▀
▆▀▲ ▅▀▆▃ █
▅■▀▃▀▅▀▃▂ ▀█▆▅▃ █
▲▐▅ ▼ ▃ ▀▀ █
▀ ▀█▅ ▀▆▅█
214:名無しさん＠編集中
08/08/20 19:43:23 u5HhlBES
4:3ソースで
704x480 par=10:11 と 720x480 par=10:11 が同じピクセル比で表示されるのはわかった
par=10:11で表示させた後にcropして横幅を同じに揃えて重ねたら画像がピッタリ一致したので
では、
16:9ソースで
1. 720x480 par=40:33 をプレイヤーで1280x720に拡大したもの
2. 左右合計16ドットクロップして 704x480 から 1280x720にリサイズしたもの(par=1:1)
これは2の方が1よりも横長に表示される
1と2、どちらが正しいの？
215:名無しさん＠編集中
08/08/20 19:52:44 lNXJPoZv
どちらが…ってどちらも正しいだろ
PARが違うのに、同じになると思う理由が全く分からない
216:名無しさん＠編集中
08/08/20 20:02:19 u5HhlBES
うーん、質問をうまく説明できない・・
真円をビデオカメラで撮影してNTSC規格のDVDを作りました
それが真円で表示されるのはどっち？
もし1の方法で真円に表示されるのなら2の方法では横長の楕円で表示されると思うんだけど
217:名無しさん＠編集中
08/08/20 20:06:37 2t24cBNW
1280x720は853(704*40/33)x480と同じくDAR 16:9だから、この場合正しいのは2に決まっている。
218:名無しさん＠編集中
08/08/20 20:14:42 lNiXqOu9
>>214
質問がすでに間違ってる
720ｘ480の10:11は1280x720にはならない
1309x720になる
219:名無しさん＠編集中
08/08/20 20:15:50 lNiXqOu9
縦解像度を720に合わせればって事ね
220:名無しさん＠編集中
08/08/20 20:18:45 u5HhlBES
>>218
いやいや、720x480 par=40:33 → 1280x720 dar=16:9 という意味で、
３行目までは>>194のことです
221:名無しさん＠編集中
08/08/20 20:22:03 2t24cBNW
720*40/33:480 = 20:11
704*40/33:480 = 16:9
1280:720 = 16:9
222:名無しさん＠編集中
08/08/20 20:23:02 lNiXqOu9
>>220
すまん書き間違った
720ｘ480の40:33は1280x720にはならない
1309x720になるの間違い
1も2も正しい比率だけど、1は16:9表示にはならない
223:名無しさん＠編集中
08/08/20 20:26:19 u5HhlBES
ごめんなさい
なんだか壮大な勘違いをしていたようで・・・
ようやく理解できたような気がします
224:名無しさん＠編集中
08/08/21 14:59:39 y1J1iedh
>>223
ピクセルアスペクト比と画面アスペクト比
URLﾘﾝｸ(tmpgenc.pegasys-inc.com)
225:名無しさん＠編集中
08/08/25 11:59:51 aUlqITWM
1440x1080額縁を720x480のDVDにしたいんだけどこれで合ってる？分からなくなってきた…。
左右344クロップ(360-無効領域分16ドット=344)、リサイズ720x480
226:名無しさん＠編集中
08/08/25 18:42:04 Wjj/txCn
映像が入ってる有効な部分は結局どれくらいなのさ
何にせよ最終的に解像度が720x480でPAR 10:11か40:33なら何でもいい
227:名無しさん＠編集中
08/08/25 18:46:34 vIoGy7k9
NTSCのDVD Videoなら無効領域無しの704x480でもいい。
228:名無しさん＠編集中
08/08/27 19:27:45 L8fXY4g7
PS3で再生するんだけど、微妙にアップスキャン気味に映るから、
外に出すときは無効領域入りでアス比指定かな。
下手に考えるより、ソースはそのままでアス比指定したほうが鉄板だよね。
229:名無しさん＠編集中
08/08/30 10:44:57 5PQxm4RT
HDのビスタサイズを640x480にリサイズしてPAR４：３で出力してみた、おもすれーｗｗｗ
230:名無しさん＠編集中
08/08/30 12:10:26 cnJAcD7h
>>226
実際に映ってる領域がすべて。
231:名無しさん＠編集中
08/09/02 22:58:03 st6LDP5F
すいません。
どなたか過去スレくださいませ。。。
232:名無しさん＠編集中
08/09/02 23:22:10 O4QaAgtd
ほれ
URLﾘﾝｸ(www1.axfc.net)
初代スレが>992までしか取れなかったけどまあ問題ないっしょ
移転だかあぼーんだかのせいか知らんけど
pc11鯖には初代スレのdat置いてないみたいだから
次スレからテンプレの初代スレはpc8に書き換えよろしく
233:名無しさん＠編集中
08/09/03 02:01:42 oYuuY40E
テンプレに解像度は16の倍数がいいって書いてあるけど
16の倍数にしなかった場合どういう弊害があるんだ？
処理速度とか画質が落ちるの？
PSP用のH.264を480x270でエンコしてるんだが何かまずいのか？
234:名無しさん＠編集中
08/09/03 04:23:54 w0todzl6
MPEGの場合16の倍数じゃないとエンコできない
その関係でTV放送もTS抜けば分かるけど縦は無効領域含んで1088
H.264なんかは基本気にしなくていいが、再生ソフトによって不具合が出る場合があるらしい
何のソフトでダメなのかは知らんけど。
PSPでちゃんと再生出来てるなら問題ない、気持ち悪いなら縦272にして下2ピクセル無効領域にすれば良い。
一般的な704ｘ396だって、396は8の倍数ですらない。
235:名無しさん＠編集中
08/09/03 07:04:46 kFCBs0s+
H.264なら4の倍数でおk。
よって396はおk。
236:名無しさん＠編集中
08/09/03 12:35:30 o6Z5NKa/
スコープサイズの2.35:1というのは本当に2.35:1ですか？
というのも4:3を1.3:1と表現しているケースがあるので念のため。
237:名無しさん＠編集中
08/09/03 13:44:00 oYuuY40E
>>234-235
480x270のままで行くことにします
>>236
4:3
4^2:3^2=16:9
と来てるから
4^3:3^3=64:27
かなと思ったけどそれだと2.37:1だな・・・
238:名無しさん＠編集中
08/09/03 17:02:47 z/PaGmj9
シネスコサイズの動画に上下黒帯がついているビスタサイズのソースの場合
自分は720x368にクロップしています。
720x40:368x33
だから
2.3715:1
となりますから、だいたいそんな感じですね
ところで、ある動画のPARやDARを調べるにはどうすればいいのでしょうか？
239:名無しさん＠編集中
08/09/03 17:05:30 o6Z5NKa/
>>237
そういう発送好きです。
私も思い着きましたが残念でした。
240:名無しさん＠編集中
08/09/03 22:46:08 AccV/YP7
テンプレ様にしたのですがこれ正解ですか？
Q.720x480,スコープ
A.左右合計16ドット削り、704x480に画面比2.35:1もしくはピクセル比141:88指定
何も削らずに720x480にピクセル比141:88でもOK
>>232 ありがとうございます。
241:名無しさん＠編集中
08/09/04 04:14:41 fFTUl2nf
2chって意外と狭いんだな…同じ板にあるとは
シネマスコープに注目するスレ
ｽﾚﾘﾝｸ(avi板)
wikipediaの画面アスペクト比のページには
2.35もあるけど2.40もあるよ、みたいなことが書いてあるな
＞左右合計16ドット削り、704x480に画面比2.35:1もしくはピクセル比141:88指定
よく知らんけど、全てのDVDって無効領域を考慮して収録してんのかな
もしそうならこれは合ってるんじゃないか？704*141：480*88 = 2.35：1 だし
レタボじゃないシネスコが手元にないから白黒はっきりできないが
レタボってるスクイーズ収録なら普通にPAR 40:33 でいいよな
242:名無しさん＠編集中
08/09/04 22:43:30 0nMIzryQ
>>241
スクイーズ収録のものをPAR141:88にしてみましたが
私の眼も馬鹿になったみたいで本当に2.35:1になっているのか･･･
>>238さんと同じくPARを調べるツールありませんか？
243:名無しさん＠編集中
08/09/05 02:32:31 yyzzoZaw
DVDソースならPAR 10:11か40:33の2択じゃないのか？
244:名無しさん＠編集中
08/09/05 02:53:43 2cAf58Br
というか、シネスコサイズのものがスクイーズではなく720x480で収録されていることを
前提としている話では？
自分はそんなDVDを見たことないですけど。
DAR2.35:1というのはだいたいの値ではないでしょうか？
ソースによっては2.35±0.05くらいの誤差が生じているように思います。
フランス映画などではもっと変な値になっているようです。
結局NTSCスクイーズならどうクロップしようがPAR40：33でおkだと思います。
245:名無しさん＠編集中
08/09/05 15:57:09 PMywPCld
16:9と4:3の動画を
720x480の横方向だけの伸縮により実現している。
2.35:1に関しても
720x480の上下それぞれ720x約58（58*2+364=480）を黒領域にすることで
720x480の横方向だけの引き伸ばしにより
実現している（704*40:364*33=約2.35:1）。
そのためワイドテレビにおいても全てがレターボックスになる。
以上が私の脳内です。
>上下それぞれ720x約58を黒領域にする
の黒領域には黒ピクセル達が必ず実在するのでしょうか？
それともピクセルがあるように振る舞う擬似ピクセル達がある場合もあるのでしょうか？
というのもNTSCスクイーズは720x480のpar40:33だけみたいなので。
246:名無しさん＠編集中
08/09/06 16:05:15 tDKdluPU
>>黒領域には黒ピクセル達が必ず実在するのでしょうか？
黒ピクセルたん擬人化希望。
247:名無しさん＠編集中
08/09/07 02:36:12 FD5hko/0
ヽ■ﾉ ﾍﾞ, ﾍﾞﾂﾆ ｱﾝﾀﾆ ｱｲﾆ ｷﾀﾜｹｼﾞｬ ﾅｲﾝﾀﾞｶﾗﾈｯ
ハ
248:名無しさん＠編集中
08/09/07 02:44:08 r0tiXVu/
全く発想が同じだったのでウケタ
249:名無しさん＠編集中
08/09/13 18:59:21 dR+8xmEc
>>242
>>238
GSpotで SAR PAR DAR 三つとも出るよ
AVIならMMname2でVideo Object Layer Header覗けばaspect_ratio_infoの所に記述されてる。
XviDとDivXはMPEG4 Modifierで変更も出来る。
250:名無しさん＠編集中
08/09/13 21:50:40 kTsqJa6X
GSpot2.70aだけどSARが違くね？PARとDARは合ってるっぽいが
SARのとこは単純に解像度の縦横比が表示されてるっぽい
それともSARの定義が実はそうなのであって俺の今までの認識が違うのかな
251:名無しさん＠編集中
08/09/13 22:44:09 Tk+Ns+rl
SAR：Screen Aspect Ratio＝DAR
SAR：Smples Aspect Ratio＝PAR
どちらにも使う事がある紛らわしい用語
252:238
08/09/13 23:07:22 ovRFFATO
>>249 ありがとう！！これでいろいろ調べられる！
でもmkvに対応してないみたいだし、
x264でSAR40:33で出力したmp4のPARが出なかったりする。
まあDARから逆算すればいいのだけど。
253:名無しさん＠編集中
08/09/13 23:23:43 3/oNsx3F
x264のSARはPARにおなじだろ
254:名無しさん＠編集中
08/09/13 23:39:37 dR+8xmEc
>>252
ほんとだ・・・GSpotはmkvとOgmは情報見れないね。
ずいぶん更新してないからもう開発してないのかな。
さすがにOgmはもう使わないけど、mkvは使い勝手が良いからたまに使うんだよな・・・
255:名無しさん＠編集中
08/09/14 01:46:31 /dEIHX1s
>>253 舌足らずだった。
x264でいうSARがGSPOTでPARとして判別されないということ。
自エンコしたやつと拾ったやつで確認しました。
これはmp4コンテナの場合だったがx264によるエンコードでaviコンテナの場合は不明。
その他のaviコンテナの場合は見た限りPAR1：1だった。
あたりまえっちゃああたりまえか。
256:名無しさん＠編集中
08/09/14 23:22:07 zoSUpEE7
>>255
おまえ何言ってるの？
GSPOTにmp4のAVCをつっこむとSampleAspectRatioで正しく表示するじゃないか
この場合PARはSARと同義語なのだから表示する必要ないだろ
257:名無しさん＠編集中
08/09/14 23:58:08 QzTpWce3
>>249
MP4BOXだろ
258:名無しさん＠編集中
08/09/15 20:59:38 J4VSpKkP
ソース スカパー 720*480 4：3（上下に黒帯あり）を704*396で保存する場合
左右を8ずつクロップし、上下も42ずつクロップするのでしょうか？
それとも上下は704*480から704*396にリサイズするのでしょうか？
知人は一旦704*360までクロップし、704*396にリサイズすれば16:9に近い比率になる。
モニターごとに若干の比率の違いがでるので、見た目は大して変わらない。
と教えてくれましたが、この知人の方法で間違いないでしょうか。
259:名無しさん＠編集中
08/09/15 21:03:01 MCwU1/uz
NTSCのソースなら、好きなようにクロップして--sar 10:11か40:33でいい。
260:名無しさん＠編集中
08/09/15 21:51:45 J4VSpKkP
aviutlでDivxで出力する場合はコーデックの設定で
ビデオ解像度の出力形式をNTSC 16：9にすれば良いという事でしょうか。
MP4での出力の場合は--sar 10:11か40:33をコマンドラインに追記するようにします。
261:名無しさん＠編集中
08/09/15 21:54:32 MCwU1/uz
DivXのPARは正しい数字だから、それで問題ない。
262:名無しさん＠編集中
08/09/16 10:21:55 h1KHWzrk
地デジを1440x1080でキャプチャしたものを
16:9ソースなら960x720にリサイズ、4:3ソースなら左右削った後720x720にリサイズして
SAR4:3で出力してるんだけど、ピクセル比指定するならリサイズはやめた方がいいのかな？
>>2に「リサイズはやめておけ」ってあるの見て気になり始めてしまった。
263:名無しさん＠編集中
08/09/16 11:39:56 8ExXyEhZ
1440x1080なら、好きに削って--sar 4:3を指定すれば余計なリサイズをせずに済む。
264:名無しさん＠編集中
08/09/16 12:35:57 5j2dHyDO
リサイズ
拡大…再生時に拡大すればいいじゃん？わざわざ情報量増やして保存するのって容量の無駄
縮小…再生時に縮小すればいいじゃん？わざわざ情報量減らすのって勿体無い
265:名無しさん＠編集中
08/09/16 16:02:35 h1KHWzrk
助言ｻﾝｸｽ。
モニタが22インチの1680x1050なもんで、キャプチャサイズのままだとパンパンでさ。
再生時に縮小すればいいか。そうしようかの。
266:名無しさん＠編集中
08/09/19 20:46:48 m/AYLqef
久しぶりのエンコで忘れちまってて、ざっと読んだんだけど
DVD→avi
720x480のDVD動画を左右8ずつ削って704x480にする。→エンコ
DV→avi
720x480のDV動画を左右8ずつ削って704x480にする。
エンコードするときに640x480にリサイズする。→エンコ
これでおｋ？
267:名無しさん＠編集中
08/09/19 21:54:35 1W2F16RU
シネスコサイズから16:9にしたい場合、左右を大幅に削るしか方法ないの？
268:名無しさん＠編集中
08/09/19 21:58:03 LJnmIPVj
黒ベタ
269:名無しさん＠編集中
08/09/19 22:22:42 1W2F16RU
方法をkwsk頼む
ちなみに640:272の動画だ
270:名無しさん＠編集中
08/09/20 04:10:57 0VRP/GxB
まず服を脱ぎます
271:名無しさん＠編集中
08/09/20 04:38:21 KdIUR9Yl
AddBorders(0, 44, 0, 44, $000000)
272:名無しさん＠編集中
08/09/22 17:03:21 3GV2jbdF
1980x1080のソースで、2.35:1に変換しようとテンプレのアプリケーションで計算してみましたが、1980x843という中途半端な数字が出ました。
みなさんは1980x850や1980x840とかにしてるのでしょうか？
273:名無しさん＠編集中
08/09/22 17:14:36 vL6DAe5x
1920 * 1/2.35 = 817
1920x1080はSAR 1:1なので、816か818にクロップだけすれば問題なし。
274:名無しさん＠編集中
08/09/22 17:16:37 vL6DAe5x
どちらかと言えば、16で割り切れる816の方がいいか。
275:名無しさん＠編集中
08/09/22 17:19:37 3GV2jbdF
>>273-274
やはり中途半端な数字ですか、しかしこれが適正のようですね、thx
276:名無しさん＠編集中
08/09/22 20:50:04 ARySuTFW
>>272
アス比計算機 の作者ですが
どのような計算させたらそんな数字が出てきたのでしょうか
バグがあれば修正しますので教えてください
277:名無しさん＠編集中
08/09/22 20:53:12 /VyuUluT
1980
278:名無しさん＠編集中
08/09/22 20:56:42 ARySuTFW
ああ、それでですか
見落としていました。失礼いたしました。
279:名無しさん＠編集中
08/09/22 21:49:29 qOLx2NWU
さすがは作者。IDがAR
280:名無しさん＠編集中
08/09/23 15:40:34 thWg/2qo
>>278
自分のポカミスでしたごめんなさいorz
281:名無しさん＠編集中
08/09/23 17:02:43 j4VxCnR8
x264でエンコしてます．
SAR設定とリサイズはどちらがお勧めですか？
理由も教えてください．
282:名無しさん＠編集中
08/09/23 17:10:33 9SZjt4Nj
クロップだけして--sarを指定すれば、リサイズは不要。
iPod等、解像度の決まった特定の環境に合わせたいのなら、リサイズも仕方ないが。
283:名無しさん＠編集中
08/09/23 18:23:34 7PtlPXhI
x264だけに>264に俺が言いたいことが書いてあった
リサイズはPSP用にエンコする時だけかなあ
284:名無しさん＠編集中
08/09/23 19:42:18 j4VxCnR8
>264
まあ確かに。
でも小さくする場合はファイルサイズも小さくできるよね。
あるいはビットレートを上げられる。
285:名無しさん＠編集中
08/09/24 14:35:00 CFt8mgLi
16:9SDをPC用の静止画にするには、縦横何ピクセルにすればいいの？
286:名無しさん＠編集中
08/09/24 15:06:08 YIBvU3Bu
ソースによる
287:名無しさん＠編集中
08/09/24 19:03:40 oa6iFyMX
用途にもよる
288:名無しさん＠編集中
08/09/25 21:31:28 gCJn+b5V
720x480(16:9)のMPEG2を無効領域をカット、704x480にした上で
H.264エンコして480x270にしたんですが、どうも上1～2ドットほど黒帯が入るようで気になります
そこで、704x480からさらに700x478にカットした上で480x270に変換して黒帯をなくしているんですが
この動画は16：9に近いものになっているのでしょうか？
289:288
08/09/25 21:46:52 gCJn+b5V
>この動画は16：9に近いものになっているのでしょうか？
この動画は製作者の意図したアスペクト比に近いものになっているのでしょうか？
の間違いです
290:名無しさん＠編集中
08/09/25 23:44:48 JNVvklm/
700x478に--sar 40:33でもプログレッシブのYV12としてはおかしな解像度ではないから、
x264でエンコードできる。
291:名無しさん＠編集中
08/09/27 18:47:47 8irO5Ida
>>288
クロップした画像の解像度に適正なアス比40：33かけて16：9になればいいのでは？
Xx40:478x33=16:9
X=701.067
横701はエンコに適さないから700にしたってわけですか。
あまり神経質になるのもどうかと思われ。
あとクロップは1回でよろし。
292:名無しさん＠編集中
08/09/28 23:03:07 rYHgb34d
>>291
ありがとうございます。
神経質なものでそれをきいて安心しました。
293:名無しさん＠編集中
08/09/30 21:12:44 3U01rLyC
synthのリサイズならfloatでクロップできるよ
crop(8,2,704,478)#リサイズ時のクロップはクロップしたはずのピクセルを補間に使うみたいなんで先にクロップ、奇数クロップ出来るならcrop(9,2,702,478)
lanczosresize(480,270,22./15.,0,10516,/15.,478)#奇数クロップしてたらlanczosresize(480,270,7./15.,0,10516,/15.,478)
どうせならこんな感じでやった方がいいと思う
294:名無しさん＠編集中
08/09/30 21:13:40 3U01rLyC
訂正
X 10516,
O 10516.
295:名無しさん＠編集中
08/10/04 06:01:44 juwONhte
>>2
> Q.720x480,スクイーズ
> A.左右合計16ドット削り、704x480に画面比16:9もしくはピクセル比40:33指定
> リサイズはやめておけ
> 何も削らずに720x480にピクセル比40:33でもOK
リサイズはやめとけとありますが、何か不具合があるんでしょうか？
理由を教えてもらえればありがたいです
296:名無しさん＠編集中
08/10/04 06:35:30 wCFokz2E
Lanczosで発生するリンギングとか、リサイズでも映像は劣化するから、
どうしても必要な再生時の一回だけにしておくのが無難。
1920x1080の1/6しかない、SDの解像度をさらに削るのももったいない。
297:名無しさん＠編集中
08/10/04 10:39:56 n5uXkAwk
短期間でループするような話題だし、リサイズの件をテンプレに入れるのはどうだろう
298:名無しさん＠編集中
08/10/05 11:08:08 +m4Xicgv
テンプレにいれればループしないとでも？
299:名無しさん＠編集中
08/10/05 11:12:53 241VbHRg
Why are people resizing 720x480 -> 848x480?
URLﾘﾝｸ(forum.doom9.org)
外国ではNTSCにある横のオーバースキャンも気にせず、皆おおらかにやっているなあ。
市販のDVDもこの調子で制作されているのかもしれない。
300:名無しさん＠編集中
08/10/05 16:04:58 acEWNuYv
数学的に求められる項目とは違い通常のリサイズは個人の価値観の問題
だいたいこれが正しいなんて答えはないんだし、ましてやアスペクト比スレのテンプレに入れるなんてw
301:名無しさん＠編集中
08/10/05 16:08:12 Otjb4+ex
なんで外人がおおざっぱな性格してるからDVDの制作側も適当に
やってるかもなんて結論になるのかわけわからんのだが…
302:名無しさん＠編集中
08/10/05 16:22:46 241VbHRg
プロ向けに書かれたガイドですらこれだから、後は推して知るべしだ。
URLﾘﾝｸ(lipas.uwasa.fi)
303:名無しさん＠編集中
08/10/06 03:37:05 9hVK1Z+q
んまぁ最近は俺もあまり深くかんがえないようにしてるなぁ
フーリオとか持ってないからいまだに地デジもSDエンコだけども
うちのﾚｺだと720x480めいっぱいに出力されるし
人それぞれなんじゃねーかなぁ
#ところで地デジのTSに無効領域なんて設定されてないよな？
304:名無しさん＠編集中
08/10/06 04:06:28 rZGbuWmj
あるよ、無効領域って言い方が変だけどオーバースキャンを考慮した
上下左右黒帯付きなんて珍しくも何ともないよ。
305:名無しさん＠編集中
08/10/06 15:01:21 VcEZlYy4
>>304の書き込みを見て今気がついたんだが
液晶TVを買うときにフルHV液晶でないとと思って当時無理して買ったけど
どうせ液晶表示するときにアップサンプリングされるんならD4解像度の低価格もの買っても
大して違って見えない気がしてきた・・・10万損した気分
306:名無しさん＠編集中
08/10/09 11:14:54 DuVC6/ZL
シネスコをそのままの画面比率で 黒帯クロップして出したいときは いくつがいいですか? 縦360だと単純に2.35倍でいいですか?
307:名無しさん＠編集中
08/10/09 11:31:23 ZQH0sNL2
>>306
黒帯が付いてるのは必ずしもシネスコ比率とは限らないよ。
その画面による。
308:名無しさん＠編集中
08/10/09 12:52:38 PY2ByK3q
レターボックス物でも縦のクロップだけしておいて、後は一般のプレーヤーと同じように、
10:11か40:33で引き延ばしておけば間違いない。
309:名無しさん＠編集中
08/10/09 16:59:46 7R1r37dI
初心者なんですが質問です。パソコンでアナログテレビ録画をすると左右がわずかですが黒帯になります。
これはクロップして引き延ばせばいいのでしょうか。それともそのままにしておいたほうが正しい比率なんでしょうか？
解像度は720x480の4：3です。
310:名無しさん＠編集中
08/10/09 17:38:45 7R1r37dI
309ですが。自己解決しました。すいません・・・
311:名無しさん＠編集中
08/10/17 09:05:04 faa2FYf2
TMPEGで、入力ソースがwmvの720×480です。
640×480にリサイズしたいのですが、うまく行きません。
クリップ枠で、
出力フォーマットがどうやっても720×480(4:3)になります。
画像の配置（任意）で640×480にしても、
両側の４０×２pixが残ります。これを削除するにはどうすればいいですか。
312:名無しさん＠編集中
08/10/17 09:08:34 xMb2oRTj
AviSynthなら、Spline36Resize(640, 480, 8, 0, -8, 0) とでもすればすぐだが、
TMPGは面倒そうだな。
313:名無しさん＠編集中
08/10/17 19:50:18 aG8fjOZP
NTSCソースでいいんだな
だったら、ソースアスペクト比は4:3NTSCを選ぶこと
たぶんピクセル比1:1とかになってないかな
314:名無しさん＠編集中
08/10/18 01:38:58 aD/xMNp9
>>311
①クリップの情報画面でアスペクト比を10:11(NTSC4:3)を選択するかフィルター画面で映像リサイズ
②フィルターを選択し、画面中心に表示(指定したサイズ)で任意のサイズを指定。
315:314
08/10/18 01:51:37 aD/xMNp9
訂正
>>311
①クリップの情報画面でアスペクト比を10:11(NTSC4:3)を選択する
②フィルター画面で映像リサイズフィルターを選択し、画面中心に表示(指定したサイズ)で任意のサイズを指定。
316:名無しさん＠編集中
08/10/22 18:32:46 shiYXx2A
>>2
＞何も削らずに720x480にピクセル比40:33でもOK
明らかにこっちのほうがいいのに704でわざわざ領域を削る人が多いのはなぜですか？
317:名無しさん＠編集中
08/10/22 18:45:50 eHPlNcN4
そっちが明らかにいい。という前提が間違っているから。
318:名無しさん＠編集中
08/10/23 00:03:31 018mxoVe
PCじゃなくて小さい画面で見る用はリサイズした方がいい
319:名無しさん＠編集中
08/10/23 00:22:44 EmEPZvlh
704に削らないと、SAR 40:33でDAR 16:9にはならない。
320:名無しさん＠編集中
08/10/23 00:27:49 onScGlQs
実際に704に切っちゃってもそんなに気にならないよな
たまに画面の端っこが歪んでいたりする物もあるからなー
321:名無しさん＠編集中
08/10/24 14:49:28 ZZZ9SjwP
PC上の再生ならSAR40:33DAR16:9にしたいけど
PS3なんかを介して液晶に映すのが前提なら
何もしなくていいんだよね？
322:名無しさん＠編集中
08/10/24 15:30:19 LBOywvKH
SARじゃなくてPARだろ
323:名無しさん＠編集中
08/10/24 15:31:28 berSLcgd
ITUの用語としてはSARが正しい。
324:名無しさん＠編集中
08/10/24 17:39:49 LBOywvKH
>>323
はあ？
本当にそんなことが定義されてのか？
実は「このスレの誰かがもっともらしくこう言ったからこうに違いない」で思考停止した挙げ句、
通ぶったやつらのためのジャーゴンになってしまいました、とかじゃないの？
少なくともDoom9やWikipediaを見た限り、一般的な認識としてはPARであり、
ググったところで"SARは国際規格による正式名称"なんてのは日本方言っぽいんだが。
とりあえず規格書(ITU-R BT.601)を持ってる人の正しい意見が聞きたいな。
325:名無しさん＠編集中
08/10/24 17:44:01 ZZZ9SjwP
その話はその話で興味深いけど
そんなに偉そうなら俺の質問にも答えてくれませんかｗ
326:名無しさん＠編集中
08/10/24 17:53:26 LBOywvKH
ゲハでも行けば？
君と似たようなのがあふれかえってるだろ？>>325
327:名無しさん＠編集中
08/10/24 18:01:08 berSLcgd
>>324
これのE.2.1やITU-T Rec. H.262だとSample Aspect Ratio(SAR)となっている。
URLﾘﾝｸ(www.itu.int)
328:名無しさん＠編集中
08/10/24 18:02:33 yPP/eFrH
>>324
ITU-R BT.601だったか、mp4だったか忘れたがsample aspect ratioって用語は見かけた覚えがある
DoomとかでSARが敬遠されるのはscreen aspect ratioと混同される可能性があるからだろ
動画のfpsをHzと表記していることに噛みついた馬鹿がいたが、だいたい用語なんぞは意味がわかりゃ何でもいいんだよ
>>325
質問自体の意味がわからん
何もしないってのは、コンテナにもアスペクトレシオを設定しないってことか？
329:名無しさん＠編集中
08/10/24 18:09:45 ZZZ9SjwP
>>328
その通りですね。言葉足らずでゴメン。
いやNTSC無効領域を意識して左右8pixずつクロップするのは
正しいアスペクト比で再生するためじゃない？
4：3再生ならピクセル比10：11だし16：9なら40：33でしょ。
そこまではいいけどPS3を引き合いに出したのはやっぱNTSC再生（出力）で
あるふつーのテレビに映すときはやっぱNTSC無効領域があるんだから
クロップせずに720*480のSAR8：9や32：27でいいんだよね？
って意味です。すません。
330:名無しさん＠編集中
08/10/24 18:16:20 LBOywvKH
>>327
それは俺も確認済み。
だからBT.601を例に挙げてるわけで、H264だのMPEGだの、特定のコーデックの規格書については問うていないわけ。
>>328
そそ。外人もScreenと混同してる。
一般的な表記と書いた理由は、怪しげな根拠を元に無駄な混同が広まるのはどうかと思ったわけだから。
昔のネットニュースのように「Chain Mailというならチェーンメールではなくチェインメイルが正しい！」と
無駄なこだわりを力説されたところで、普通のやつからすれば「鎖かたびらがどうかしたの？」と
言われるみたいなもん。
331:名無しさん＠編集中
08/10/24 18:20:35 yPP/eFrH
>>329
一般論としてNTSC出力なら出力側でアスペクトレシオの設定はするべきでない
それはTV側がするというか、TVの構造がそうなっている
332:名無しさん＠編集中
08/10/24 18:21:28 ZZZ9SjwP
>>331
ありがとう。すっきりしました！
333:名無しさん＠編集中
08/10/24 18:24:10 berSLcgd
>>330
H.262やH.264は実際に広く使われているITU-Tの規格だから、ITUでの使用例としては至極適当だと思うが。
URLﾘﾝｸ(inst.eecs.berkeley.edu)
BT.601に関しては、これだとアスペクト比については書かれていないな。
H.262だと6.3.3にsample aspect ratioとある。
URLﾘﾝｸ(www.esnips.com)
334:名無しさん＠編集中
08/10/24 18:33:26 LBOywvKH
>>333
そらないだろうね
書いてあるセクションは601-6らしいから。
H.262については前述通りなんでコメントなしで。
つーか無駄なコーデック四方山話とかどうでもいいんで、本当に規格書持ってる人が出るまで隠れるとするわ。
335:名無しさん＠編集中
08/10/24 19:59:52 NTWgfcea
ID:LBOywvKHの支離滅裂さ加減に吹いたわ
今でもこんなやつがいるんだなぁ・・・
336:名無しさん＠編集中
08/10/24 21:27:51 0sFI5UuC
SAR論争はもう決着ついた感あるけど俺からも言わせて。
H.264 は ITU が策定した正式な規格であり、その規格書でSARの用語が
定義されているんだから
SAR は国際規格で定められた正式な用語である。
あと doom9 はジャーゴンの固まりの印象を持っているんだけどな。
337:336
08/10/24 21:38:52 0sFI5UuC
ITUは年間三本まで規格書を無料でDLできるので、BT.601-6 を
落としてみたが PAR も SAR も使われていなかったぞ。
338:名無しさん＠編集中
08/10/24 21:57:51 LBOywvKH
>>336
> SAR は国際規格で定められた正式な用語である。
URLﾘﾝｸ(www.google.co.jp) PAR:63件
URLﾘﾝｸ(www.google.co.jp) SAR:29件
あなたの言い分に照らすならPARも正式な用語ですね。しかも世界で一般的に使われるのはこっち。
何をもって決着と考えたのかが知りたいところですね。
>>337
thx!記載がなかったのは残念。
Square Pixelとかその手の言い回しなのかな。
まあそれはいいとして、いずれにせよPARも正式な用語である以上は
＿＿＿
／ ＼ ／＼ ｷﾘｯ
. ／ <●>::::<●>＼
／ ⌒（__人__）⌒ ＼ ＜ITUの用語としてはSARが正しい。
| |r┬-| |
＼ `ー'´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
などと得意気に断言した輩の根拠が希薄であったのは事実みたいですね。
それに乗っかって得意気に「SARが正しい」と抜かしたのも同類。
339:名無しさん＠編集中
08/10/24 22:08:44 berSLcgd
ITUではSAR、MPEGではPARが使われると言うだけの話だろう。
340:名無しさん＠編集中
08/10/24 22:15:27 LBOywvKH
>>339
そっかー。
ITU-T RECOMMENDATIONってのはITUじゃないんだー。
こらまた珍説のご披露、本当にありがとうございましたｍ（_ _）ｍ
URLﾘﾝｸ(www.google.co.jp)
それと>>338のコピペミスを修正
URLﾘﾝｸ(www.google.co.jp) PAR:63件
URLﾘﾝｸ(www.google.co.jp) SAR:29件
341:名無しさん＠編集中
08/10/24 22:17:56 ddypA+ps
いい加減うざいな。
342:名無しさん＠編集中
08/10/24 23:13:31 AhZcvrxR
さぁぱぁっと別の話題に移ろうぜ
343:名無しさん＠編集中
08/10/24 23:14:01 LBOywvKH
まあそう言うなよｗ
あくまでもPAR(also known as SAR)であって、SAR(authoritative word in ITU)じゃないってことなんでね。
見立て通りの一方言だという自覚もなしに、ITU教条主義に走る池沼の増殖を防げたわけだし。
2ちゃんでもっともらしいこと抜かしてるやつこそ疑わなくちゃいけないってわけだ。
／￣￣￣￣＼
(ヽ,,,／ /・ヽ /・ヽ ＼ /) ＜DTV板が誇る情報強者の皆さん乙であります！
(((i ) ￣ ￣ ( i))) これからは何事も良く噛んでから消化してくださいね～
,／∠| (_人_) |ゝ ＼
(＿＿＼ ＼＿| ／,＿＿）
344:名無しさん＠編集中
08/10/24 23:14:19 iAbVPUyD
うっぜ。
しかも基本的に自分で調べることはせず他力本願なのに
すべてにおいて上からコメント。
アス比のスレなのに質問なのに他板にいけとか言ってるしｗ
345:名無しさん＠編集中
08/10/24 23:25:59 9couaV1C
>>ID:LBOywvKH
あなたの言わんとすることがイマイチ理解できないんだが
簡潔にまとめてもらえないかな？
ざっと見た限りでは
・Doom9やWikipediaとかでもPARという用語を使っているからSARという用語は使うべきでない
・SARの出典と言われるITU-R BT.601にその記述を見つけられないのだからSARを使うべきでない
と言っているように見えるがあっている？？
346:名無しさん＠編集中
08/10/24 23:48:50 LBOywvKH
>>345
正直ウンザリだが、まあサービスだ。
> 簡潔にまとめてもらえないかな？
あくまでもPAR(also known as SAR)であって、SAR(authoritative word in ITU)じゃない
1.SARを使うのは自由だけど、一般的な用語はPARである。
2.ITU勧告からの唯一にして正式に定義された用語であるかのように語るのは、
ごく一部の通気取りの情報強者(笑)
3.PARなら誤解なく疎通できるが、SARだと混乱を招く。
※.ITU勧告ではないが、ITUですらSARの使い方が一定していない以上、仕方がない
URLﾘﾝｸ(www.google.co.jp)
以上、積極的にSARを使う理由が見当たらない。
こんだけ書けば、いーかげん理解できんでしょ？
まあ理解できなくても知ったことじゃないけど。
ということで終了。
もう疲れたし、ID変えて粘着してくるゲハ厨が増えるだけだから。
347:名無しさん＠編集中
08/10/24 23:51:27 berSLcgd
>>321の様に、SARとDARが併記してあるなら、別に問題ないな。
348:名無しさん＠編集中
08/10/25 00:01:49 iAbVPUyD
おめえが仕事のできそうにない人間だってことは十分わかったよ。
頼むから自分で書いた>>334の通り、
規格書持ってる人間が出てくるまで黙っててくんないか。
ご大層な書き込みも誰の役にもたってないからさ。
349:345
08/10/25 01:08:36 OGPAHr0E
>>346
なるほど
＞1.SARを使うのは自由だけど、一般的な用語はPARである。
では一般的な検索エンジンでSample Aspect Ratioで検索すると多数ヒットしますし、同じくSARで検索しても多数ヒットします
これはこれだけヒットするのに一般的な用語ではないのでしょうか？
さらに使用が自由であるならば、ここまで強引に主張することはないかと思われますが？
＞2.ITU勧告からの唯一にして正式に定義された用語であるかのように語るのは、
ごく一部の通気取りの情報強者(笑)
これに関してはまだ結論が出てないのでは？
＞3.PARなら誤解なく疎通できるが、SARだと混乱を招く。
言わんとすることは理解はできますが、x264がこれほど流行った現在ではSARはPARと同義という認識は多数の方がお持ちなのでは？
あなたもこの論議のはじめでそう理解したから問題提起されたのでは？なので基本的に紛らわしいと考えなくて良いかと思いますが・・・
だいたい、YpbPrとYCｂCrのように似たようなことはよくありますし、あなたを含めて大多数の人に意味が通じるのであれば
出典にかかわらずその用語は「一般的」であると思われませんか？
350:名無しさん＠編集中
08/10/25 01:49:34 rrH18OIR
彼にとっちゃ持論に異を唱える人は全部ゲハ板住人、
もしくは>>321の自演らしいから相手するだけ無駄だよ。
x264だけでなくDivXもオプションでSARと表記してるんだけど
各コーデックの事情なんか知ったこっちゃないし、
彼がこだわってるのはあくまで「一般的」という部分で
しかもそのソースを他人にた頼ってる有様。
351:名無しさん＠編集中
08/10/25 01:50:14 pAzguWHK
>>349
あんたさ、マジでキモいんだけど。
BT.601には記載はなかったという報告もいただいた上で、このスレで主張された根拠ってのは、
「H.264の規格書にあったからITUの御心である」って、その程度でしかないわけじゃない。
で、俺は「PARもITUで使われている神聖なる御言葉である」と返したわけさ。
なんで、この程度のログぐらい読めないわけ？
しかも「検索したらいっぱい出たから一般的なんだよね」って小学生か？
じゃあ「汚名挽回」も検索したらいっぱい出てきたから一般的なのか、とかその程度の屁理屈だろ。
あんた、どうせ日本語のページしか見てないんだろ？
その日本語のページですらSARの混乱が起きているのも、見てないよな。その調子じゃ。
大体理解できないなら、これからも永遠に「SARは絶対にして神聖たるITUによる神の言葉である」とか主張してればいいじゃん。
ウンザリするだけで無為だし、俺は止めないからさ。
あとYPbPrとYCbCrは明らかに違うから。
こんな間違いを犯したらハード板のトラスコスレあたりじゃボコボコにされるぞ。
知ったかぶりもほどほどにね。
つーことで、このレスで最後にするから、二度とレスすんのやめてくださいね。
もう主張するべき事は主張してるわけだから、新たな事実が出るまで時間の無駄でしかない議論なんかするつもりは毛頭無いし、
それ以上に生理的に受け付けないもんでね。
352:345
08/10/25 02:11:11 OGPAHr0E
>>351
キモさかげんはあなたと同レベルというのは百も承知の上ですので、ご心配なく。
なぜ「一般的」と言われる論拠にBT.601での記載の有無が必要なのですか？
と問うているわけですが、それに対してお答えいただいてないようです。
それに動画の知識についてはそれを生業としておりますのであなた以上ですのでご心配なくw
日本語ページだけを検索したわけではないですが、よしんば日本だけでその用語が使われていても何ら問題ないかと思われますが
言葉というのはその文化圏でその意味するものがわかれば良いだけではないのですか？だいたいあなたは使用は自由だ主張していらっしゃるのにw
それにあなたがBT.601という規格書を論拠にするのならあなた自身が記載されてないと証明するべきでしょう。
でもそのことと「一般的」とは何ら関係はないですけどね。
まぁもう現れないと思いますので、ご自分のレスをもう一度読み返してみられることをお勧めして、私も消えます
アスペクト比スレの皆様スレ汚しどうも失礼いたしました。
353:名無しさん＠編集中
08/10/25 06:10:53 fQk4j89F
このレスで終わりって書いた人はまたすぐ出てくる
これ豆知識な
354:名無しさん＠編集中
08/10/25 15:37:38 NJ4BN14i
なんつうか、広告代理店にいるよなあ、こういう人
355:名無しさん＠編集中
08/10/25 19:41:24 rrH18OIR
いやいやないない。
知識だけのエンコマニアニートｗ
もしくはポスプロの消費されるだけのオペレーターってところ。
356:名無しさん＠編集中
08/10/25 19:48:11 OtHC51tb
うわぁ、また出た
357:名無しさん＠編集中
08/10/27 14:59:36 7JfwUf5o
エラいヒゲ生やしたタヌキオヤジが「ジャグァ」って言ったらジャグァなんだよ！
「メルツェデス」って言ったらメルツェデスなんだよ！
いいかわかったかおまえら！！
こういう言い争いをしてるわけだ。
358:名無しさん＠編集中
08/10/27 16:05:29 41p8KDNW
そう記述された権威ある論文を示せ。
それができないならお前はバカだ。
こう言ってるわけです。
実にどうでもいい言い争いです。
359:名無しさん＠編集中
08/10/27 16:41:53 FD10Y7M0
うわぁ、また出た
360:名無しさん＠編集中
08/10/27 17:04:16 41p8KDNW
毎日毎日粘着してるんだね・・・ｗ
361:名無しさん＠編集中
08/10/27 17:06:05 YYombJpK
やれやれ・・・
∧∧ ミ ＿ ドスッ
( ,,)┌─┴┴─┐
/ つ. 終 了 │
～′ /´ └─┬┬─┘
∪ ∪ ││ _ε３
゛゛'゛'゛
362:名無しさん＠編集中
08/10/27 17:11:27 qzoDtPD8
スルーできずにどうしても反応してしまい、
何か言わずにおれないところを見るとよほど皆に馬鹿にされたのが悔しかったのだろう。毎日スレを監視に来てるようだし。
はやく金科玉条の書かれた規格書持った人が現れるといいね。
↓
我慢しきれずうわあまた出たなどの書き逃げレス
363:名無しさん＠編集中
08/10/27 20:56:32 sdzhtUwo
はいはい、自称動画プロの高卒派遣社員乙
364:名無しさん＠編集中
08/10/27 21:47:54 7Fr0CCu8
どんだけ煽られてんだｗ
まあ話題なんかないからいいけどｗ
365:名無しさん＠編集中
08/10/28 01:20:49 K0h5xgTT
>>363
ちなみに俺は自称ではなく本当に動画のプロ。
動画というか映像か。で、正社員。
でも知識は全然おまえらのほうがあると思う。
いやまじで。
366:名無しさん＠編集中
08/10/28 07:06:41 JqL+iUM8
やれやれ、高卒の自己紹介なんて誰も聞いてないから
∧∧ ミ ＿ ドスッ
( ,,)┌─┴┴─┐
/ つ. 終 了 │
～′ /´ └─┬┬─┘
∪ ∪ ││ _ε３
367:名無しさん＠編集中
08/10/28 09:23:25 K0h5xgTT
高卒じゃないよｗ なんで話すこともないのに仕切りたがるん？
自意識過剰なのはわかったから君も自己紹介でもしてみたら？
368:名無しさん＠編集中
08/10/28 09:24:26 K0h5xgTT
ま、反応してくれただけで満足だ。終わろうｗ
∧∧ ミ ＿ ドスッ
( ,,)┌─┴┴─┐
/ つ. 終 了 │
～′ /´ └─┬┬─┘
∪ ∪ ││ _ε３
369:名無しさん＠編集中
08/10/28 13:30:59 LYkLYJM/
そんな劣化がどうのとか考えないで好きなように切とりゃいいんだよ
昔、散々画質がどうの色味がどうのと思考錯誤した十年前の動画は
どれも笑っちゃうぐらいの糞画像
今、最高にエンコしたと思った動画も20年ぐらいすれば
どれも糞画質なんだから見れればいいんだよ
370:名無しさん＠編集中
08/10/28 14:08:26 CKLJD4L0
エンコーダ(x264)ではsarでデコーダ(ffdshow)ではparだから、なんとなくエンコードの時はsarでデコードの時がparだと思って使ってたけど？？
x:yでサンプリングしました（して下さい）とかピクセル比a:bで表示して下さいみたいな
371:名無しさん＠編集中
08/10/28 20:33:11 nzqBLlaw
よっぽどショックだったのか、同士討ちまでしてるのがなんとも。
それは置いて追加情報だ。
Recommendation H.264 (11/07) から抜粋。
sample aspect ratio: Specifies, for assisting the display process, which is not specified
in this Recommendation | International Standard, the ratio between the intended horizontal distance
between thecolumns and the intended vertical distance between the rows of the luma sample array in a frame.
Sample aspect ratio is expressed as h:v, where h is horizontal width and v is vertical height
(in arbitrary units of spatial distance).
英語どころか日本語もマトモに読めない、キモいだけの自称映像プロ除けに、
あえて意訳はしないでおくけどね。
要するに画面をブロック単位で処理していて、その縦横比を表すのがSARであって、
そもそも定義的にSAR(=PAR)って主張自体がデタラメ。
要するに、ここで「PARではなくSARがITUの正式な用語であるから正しい！」とか、
もっともらしいことを抜かした挙げ句に珍説を並び立ててまで頑張っていた連中は、
全員ただの通ぶりたかっただけの半可通、、いや情報強者(笑)って事で全く問題ない。
とは言え、まさかあんな自信満々に主張していた前提条件すらデタラメだったとは思いもしなかった。
それを疑わなかったことについては俺も反省したい。
372:名無しさん＠編集中
08/10/28 21:08:56 1L/GRjrt
>>371
素人が知ったかぶりすんなよ…
ここに書かれているのはピクセルの縦横比の定義そのものだよ。
373:名無しさん＠編集中
08/10/28 21:12:41 coktjeOA
まだやってたのかｗ
374:名無しさん＠編集中
08/10/28 21:53:00 0h7BptPq
>>371
よくわからんど素人なんですが、ブロック単位のブロックってMBのこと？
もしそうなら、PスライスやBスライスで8ｘ16とかいったものは使えないような気がするんだが…
まったく的外れなことだったらごめんなさい
375:名無しさん＠編集中
08/10/28 21:54:22 676lvDfa
孤軍奮闘というか必死というか・・・
周囲に評価されないから自分で自分は賢いとPRしてんのか？
大変みっともないな。
376:名無しさん＠編集中
08/10/28 22:11:26 K0h5xgTT
>>371
なんだ俺に嫉妬してんのか？
別に俺はSARPAR論争には参加してねーぞ。勝手に敵視すんな。
おまえらすごい知識だねって言ってるだけなのに見えない敵と戦うなよ。
377:名無しさん＠編集中
08/10/28 22:30:07 nzqBLlaw
>>372
釣り乙
>>374
矩形じゃないのはサブブロックに分けてるだけなんじゃね？
気になるならH.264の技術資料でもあたったらいいんでは。
>>375
だよな。
得意気にデマ飛ばした挙げ句、反論も出来ず居直ってる低偏差値が一番みっともないよな。
>>376
そうか、勘違いしたか。すまんな。
「キモい」で検索すれば、俺が言ってる自称映像プロがどの生物なのか分かるぞ(´ω`)
まず、日本語が読めない。簡単な英語も読めない。ただひたすらキモい。
こういう生物だ。
378:名無しさん＠編集中
08/10/28 23:12:03 1L/GRjrt
>>377
やはりキミは素人だから反論できないんだね。
＞要するに画面をブロック単位で処理していて、その縦横比を表すのがSARであって、
素人ではないと言うのなら「ブロック」の簡単な説明をしてくれ。
自分で >>371 を書いているんだから説明出来るよね？
379:名無しさん＠編集中
08/10/28 23:16:52 nzqBLlaw
>>378
sample aspect ratio between the intended horizontal distance between thecolumns and
the intended vertical distance between the rows of the luma sample array in a frame.
(･∀･)ﾆﾔﾆﾔ
380:名無しさん＠編集中
08/10/28 23:20:39 1L/GRjrt
>>379
まさかとは思うけど「luma sample」の意味を分かっていない？
381:名無しさん＠編集中
08/10/28 23:22:22 nzqBLlaw
>>380
まさかとは思うけどarrayの意味を分かってない？
(･∀･)ﾆﾔﾆﾔ
382:名無しさん＠編集中
08/10/28 23:25:59 coktjeOA
いいぞもっとやれーｗ
383:名無しさん＠編集中
08/10/28 23:31:14 1L/GRjrt
>>381
キミに付き合うのも面倒になってきたわ。
まずフレームの luma sample 配列を二次元の表としてみたときに列と列の間の距離と
行と行の間の距離の比率が sample aspect ratio。
ここで重要になってくるのが「luma sample」だけど、これまでの返答見ていると
「luma sample」の意味を理解していないね。
384:名無しさん＠編集中
08/10/28 23:34:58 nzqBLlaw
>>383
やっぱりPixel縦横比の定義じゃないってことは認めざるを得ないんだね。
(･∀･)ﾆﾔﾆﾔ
385:名無しさん＠編集中
08/10/28 23:39:12 SMv/72bm
平行線ですな。
さてどっちが勝つやら。
386:名無しさん＠編集中
08/10/28 23:47:46 1L/GRjrt
>>384
H.264 は基本的に映像を YUV 4:2:0 で扱います。
YUV 4:2:0 の説明はググってくれ。
「luma sample」は輝度サンプル。つまり YUV 映像の Y プレーンの各画素を指します。
U・V はどうなっているんだと思われるかもしれませんが、Y と U・Ｖの関連付けは
H.264 規格の別章で規定されています。
つまり下の英文は、結局のところピクセルアスペクト比を定義しているんだな。
sample aspect ratio: Specifies, for assisting the display process, which is not specified
in this Recommendation | International Standard, the ratio between the intended horizontal distance
between thecolumns and the intended vertical distance between the rows of the luma sample array in a frame.
Sample aspect ratio is expressed as h:v, where h is horizontal width and v is vertical height
(in arbitrary units of spatial distance).
387:名無しさん＠編集中
08/10/28 23:48:40 nzqBLlaw
単純にこういうこと。
輝度サンプルの縦横比
■■■■↑
■■■■ 4
■■■■
■■■■↓
← 4 →
4:4 -> 1:1
正方ピクセル
■1
1
1:1
つまりこの場合、最終的な結果が同じになるので、実使用上の相違点はないけど、定義としては厳密には違う。
SAR(≒PAR)ではあるけど、SAR=PARではない。
そして繰り返すけど、PARが一般的な用語であり、混乱もまたない。
ちなみに264でSARって使うのは問題ないけど、WMVでもSARとか主張しないように。
388:名無しさん＠編集中
08/10/28 23:59:52 nzqBLlaw
さらに補足すると、輝度情報は色差情報と違って圧縮されない(=サンプルの欠落がない)から、
輝度をサンプルにしてるんだろうね。
だから「つまり下の英文は、結局のところピクセルアスペクト比を定義しているんだな。」なんてのは
まったくもって意味不明な帰結としか言いようがないわけだ。
389:名無しさん＠編集中
08/10/29 00:00:39 vDD0Zf0d
>>ID:nzqBLlaw
なんだか君の言葉は理想国家を求めてやまないあげあし取りだけの共産党や社会党の演説聞いているようだわ
たかだか呼称でここまで常駐して無駄な議論を推し進めるパワーがあるならもっと別のところで発揮すると良いいのに
一字一句を大切に扱う憲法学者にでもなったら君は大成すると思うよw
390:名無しさん＠編集中
08/10/29 00:06:56 5+5BR+d+
>>388
全然違う。輝度サンプルの意味を理解していないね。
なぜ輝度サンプルが 4x4 になっているの？
キミの図を借りるなら正しくはこう。
輝度サンプルの縦横比。
■□□□■□□□↑
□□□□□□□□ 3
□□□□□□□□↓
■□□□■□□□
□□□□□□□□
← 4 →
4:3
黒い点が輝度サンプル。白い点は輝度サンプルと輝度サンプルの間を距離を
表すための目安です。
391:名無しさん＠編集中
08/10/29 00:08:25 5+5BR+d+
＞← 4 →
肝心なところでずれちゃったわ。まあ意味は通じると思います。
392:名無しさん＠編集中
08/10/29 00:25:17 +A4X18i6
いま必至にググり中なのでしばらくお待ち下さい
(･∀･)ﾆﾔﾆﾔ
393:名無しさん＠編集中
08/10/29 02:06:04 XckKnmoo
まーた始まった（AA略
394:名無しさん＠編集中
08/10/29 20:58:06 0+hlmjAa
>>390
すいません、皆目意味が分からんです。
なんで、わざわざアスペクトを指定するためだけに「サンプルとサンプルの間の空間」なんて概念が必要になるの？
なんでデジタルなのに謎の空間を使ってまで、面倒な実装をしなくちゃいけないの？
例えば999:550とか指定したら、わざわざそんだけ配列つくりますとか言うの？
それとも実はアナログ信号だとでも主張してるの？
まったくもって意味不明としか言いようがないっすｗ
さらには、結局その例では1ピクセルの定義をするために4サンプル使ってるし、結局俺と変わらんやん。
要するにこれはPARとは違う定義である、と認めたと受け取って良いのかな？
395:名無しさん＠編集中
08/10/29 21:21:40 +LU0ABoY
必至にググっても意味が分からんのですね
(･∀･)ﾆﾔﾆﾔ
396:名無しさん＠編集中
08/10/29 21:39:51 5+5BR+d+
>>394
>なんで、わざわざアスペクトを指定するためだけに「サンプルとサンプルの間の空間」なんて概念が必要になるの？
>>371 の英文が「サンプルとサンプルの間の距離」の概念を導入して
ピクセル(サンプル)の縦横比を定義しているからです。そんな概念イラネと
私に言われても困っちゃうＹＯ！
今までサンプルサンプルと言っていますが、これは SAR 定義の文脈においては
いわゆるピクセルと完全に同義です。念のため。
>なんでデジタルなのに謎の空間を使ってまで、面倒な実装をしなくちゃいけないの？
>例えば999:550とか指定したら、わざわざそんだけ配列つくりますとか言うの？
>>371 に「for assisting the display process」とある通り、H.264 の
サンプルアスペクト比はエンコード・デコード処理に全く影響しませんので
ご心配なく。
>さらには、結局その例では1ピクセルの定義をするために4サンプル使ってるし、結局俺と変わらんやん。
H.264 での概念に従って SAR(PARとも言う) 4:3 を図にしたのが >>390 です。
サンプルとサンプルの左右方向の距離が四マス、上下方向の距離が
三マスとなっていますよね。
397:名無しさん＠編集中
08/10/29 22:04:58 85ym0eFu
>なんで、わざわざアスペクトを指定するためだけに「サンプルとサンプルの間の空間」なんて概念が必要になるの？
例えば、正方形のピクセルが規則的に隙間を空けて並んでいる場合は、一つのピクセルの縦横比では
アスペクト比は定義出来ないのでは？
ピクセルが正方形や長方形ではなく三角形だったら？
などと考えると、サンプル間の距離で定義しないとまずいような気がするね
んなことありえないのかな？
398:名無しさん＠編集中
08/10/29 22:33:54 0+hlmjAa
>>396
> >>371 の英文が「サンプルとサンプルの間の距離」の概念を導入して
> ピクセル(サンプル)の縦横比を定義しているからです。
ええと、そういうことを聞いてるわけではなく、そもそも、その概念ってのが
あなたの解釈でしかないわけでしょ。で、その論拠が「俺はプロだから」ってだけ。
俺はサンプル間の距離？なんで配列の要素間に距離が？はあ？
じゃあ1st sample to Last sampleの長さかな、と捉えたわけ。
解釈が別れた以上は、その概念の根拠がないとおかしいって話。
>>>371 に「for assisting the display process」とある通り、H.264 の
>サンプルアスペクト比はエンコード・デコード処理に全く影響しませんので
>ご心配なく。
これも噛み合ってないですね。
264の規格外の話であれば、その論拠があるはずだし、264規格内の話であれば、
そういう処理(オーバサンプリングして輝度サンプル間の距離を測定みたいなの)をしている記述が必ずあるはず。
見た感じRec.264にそういう記述はないようですね。not specifiedだから当然だけど。
だから、ここで必要になるのはH.264のSARの概念を補強する根拠。それだけなんですわ。
>>397
ストリームでそんなことまで定義も処理もしているとは正直思えないから、だから疑問なわけですわ。
399:名無しさん＠編集中
08/10/29 22:51:42 5+5BR+d+
>>398
私は「俺はプロだから」の人じゃないよ？ 他の人と勘違いしているようだけど
はっきりさせるためにこのスレに書き込んだ時の ID を並べとく。
ID:0sFI5UuC ID:1L/GRjrt ID:5+5BR+d+
>ええと、そういうことを聞いてるわけではなく、そもそも、その概念ってのが
>あなたの解釈でしかないわけでしょ。で、その論拠が「俺はプロだから」ってだけ。
>俺はサンプル間の距離？なんで配列の要素間に距離が？はあ？
>>371 の英文をよ～く隅から隅までお読み下さいとしか言いようがありませんね。
サンプル間の距離、正確に言うと列と列の距離、行と行の距離があるものとして
列の距離と行の距離の比率を sample aspect ratio と定義している。
距離というものはあくまでも概念的なもの。
400:名無しさん＠編集中
08/10/29 23:10:43 0+hlmjAa
>>399
プロの人じゃない?
そういや素人、素人と連呼していたけど、考えてみたら対義語は玄人だもんね。
ってことで、以降から玄人さんとでもお呼びしましょうか。
で、玄人さんも、あくまでそういう解釈という主張でしかないわけですね。
明確な根拠(Secified)な文献は特になし、と。
まあ、本当のことを言うとそれはどうでもいいんですわ。
・H.264にSARの呼称は問題ない
・PAR(also known as SAR)に問題はない
・「ITUお墨付きによりPARではなくSARが正しい」という事実はない
・その他のCODECの用語までがSARかどうかは別の話
この認識に齟齬はないですよね？
401:名無しさん＠編集中
08/10/29 23:14:39 5+5BR+d+
>>400
>・H.264にSARの呼称は問題ない
>・PAR(also known as SAR)に問題はない
>・「ITUお墨付きによりPARではなくSARが正しい」という事実はない
>・その他のCODECの用語までがSARかどうかは別の話
以上で問題ない。で >>371 で「そもそも定義的にSAR(=PAR)って主張自体がデタラメ」と
今まで騒いでいたのは何だったの？
402:名無しさん＠編集中
08/10/29 23:40:02 0+hlmjAa
>>401
ああ、撤回しますわ。
あれは、同意してもらった齟齬について認めず、しつこく騒いでるのがいたから煽り大半なんで。
ごめんねｗ
今回、玄人さんに同意してもらったんで、さすがにこれ以上もう騒げないでしょ。
まあついでに書いてみるとITUのサイトで見つけた文書に
>[Editor: Clarify here that “sample” means “pixel” ? sort of. Readers unfamiliar with H.264 terminology have been confused.]
「聞き慣れないH264用語には混乱させられるぜ」なんて書かれてるぐらいだし、
まあその程度の認識でしかないんだな、ってのが正直なところ。
403:名無しさん＠編集中
08/10/29 23:54:56 5+5BR+d+
>>402
どう言いつくろうが >>371 の書き込みは真性。
決着は付いたようですのでこれで消えます。
404:名無しさん＠編集中
08/10/30 01:00:16 8h/LzYgp
これで終わりにするって書いた人はまたすぐ出てくる
これ豆知識な
405:名無しさん＠編集中
08/10/30 03:26:02 5+Bv0+tC
ISO/IECとITU-TではMPEG-2 Video/H.262, MPEG-4 AVC/H.264と同じ規格に違う名前を使うし、
画素の呼称がpixel, pel/sampleとなるのも、別に不思議ではない。
406:名無しさん＠編集中
08/11/10 15:16:21 OF8fSZjf
ループかも知れないが、テンプレの720x480スクイーズってNTSCのDVDや
アナログ放送のキャプチャの場合は40:33でいいけど、デジタル放送を
SDでキャプチャしたときは32:27の方が正しい場合もあるんじゃ。
例えば1920x1080/無効領域なし/ピクセル比1:1の画面全体を720x480に
縮めてキャプチャした場合はこの720x480内にも無効領域はないはずから、
全体を16:9で表示する32:27の方が正しい気がするんだけど。
407:名無しさん＠編集中
08/11/10 15:27:09 gn+SX3fI
そういう事は当然あるだろう。
私がHD->SDをする場合には、NTSCとの互換性を考えて704x480にするけれど。
408:名無しさん＠編集中
08/11/10 16:14:25 OF8fSZjf
>>406 訂正。
アナログでスクイーズとかありえないよな。すんません。
409:名無しさん＠編集中
08/11/11 04:33:53 HpmSL+yG
画像サイズの縦横比と、表示上の縦横比が一致しない映像の場合、ストリーム側でアス比を指定するのと
コンテナ側でアス比指定するのと、どっちが互換性高いですか？
410:名無しさん＠編集中
08/11/11 04:45:56 okDEJche
再生環境依存。
411:名無しさん＠編集中
08/11/11 22:02:20 uERPYf8q
>>409
つまり両方やっておけってこった
412:名無しさん＠編集中
08/11/12 04:22:46 3I/vRb7A
なるほど。どうもでした
413:名無しさん＠編集中
08/11/13 14:47:38 Ic8OlpI1
ＡｖｉＳｙｎｔｈでautocropしたら、720×480のうち716×338ピクセルに
画があることがわかりました。
で、ＡｖｉＳｙｎｔｈでCrop(8,72,704,336)により704×336にcropしてから、
TMPGencでエンコードする際に、クリップををピクセル比10：11に指定して
さらに512：288(16:9)にリサイズして、Aviファイル作ってました。
ここで疑問がわきました。元の画のサイズアスペクト比って
716/338*10/11＝1.93でよいのでしょうか？
だとすると16：9の1.78とはかなり違いアスペクトを狂わしてる
気がするのですが、どうなのでしょうか？
ご教授お願いいたします。
414:名無しさん＠編集中
08/11/13 15:09:25 Ic8OlpI1
違う素材で、autocropしたらcrop(0,60,720,364)でした。
この場合だと、サイズアスペクト比は、720/364*10/11＝1.80となり
16：9の1.78にかなり近いです。
ということで、4：3の上下黒タイプのサイズアスペクト比は、1.93とかの
変則的な数値もありうるということでいいのかな？
415:名無しさん＠編集中
08/11/13 15:10:23 xmdLfAiQ
どうせ大した違いは無いから、704x336にクロップ->640x336(1.905)にリサイズでもすれば。
416:名無しさん＠編集中
08/11/13 15:48:17 NEJPU7hv
>>414
縦364なのは、普通の SD 720x486 に 16:9 素材を LB 収録したのを
垂直方向6ライン削ったんだと思えばいいんじゃないの?
> 4：3の上下黒タイプのサイズアスペクト比は、
> 1.93とかの変則的な数値もありうるということでいいのかな？
変則的も何も映像を制作するときの画面サイズの縦横比に
制限とかないじゃん。そんなの作る側の自由。
417:名無しさん＠編集中
08/11/13 16:01:29 Ic8OlpI1
>>415
モバイル機器で再生しようとしてるので、サイズ大きいと
ＣＰＵ弱いので、画固まってしまうんです(512×288 q5でも２フレ/秒位再生レート落ちます)
432×224(1.93)あたりのサイズで考察してみます。
>>416
そうだったんですか。てっきり16:9ばっかりだと思い込んでいました。
もしくは、あっても映画とかの比だけかなとばっかり。
415さん、416さん ありがとうございました。
418:名無しさん＠編集中
08/11/18 12:54:37 WQM2eEGn
今まで720×480と704×480が同じアスペクト比3:4として扱ってよいと聞いてから
調べてやっと分かってきた。
つまりPARが同じ(ピクセルの形が同じ)ということで同じ比率の映像に見えるということね。
で、ピクセルの形が同じならば映像自体の大きさが違ってくるが、
720pxのままでも704px以上の16pxは無効領域としてTVには表示されない。
ただしPCでは無効領域も含め表示されるのでDARは3:4にはならないが歪んでいないのでOKなんじゃね？ということでいい？
しかし、ここで問題が…
PARが設定できないTMPGEncやPremirerは無効領域も含めてDARを3:4にしてしまうのではないか？
ちょっと試してみたところ、X.264で作成した720×480[PAR(SAR)10:11]のMP4に比べて
Premirerは変わらないがTMPGEncは縮んだ。
ペガシスさん、どーすりゃいいの？
419:名無しさん＠編集中
08/11/18 15:49:07 LmUijkKV
それはあんたがTMPGEncの設定を良く知らないため起きたことだ
入力ソースのアス比指定が正しくて、「アスペクト比保持」にチェックを入れておけば
どんなリサイズを指定しようと出力ピクセル比が歪むことはないようになってるんだよ
420:名無しさん＠編集中
08/11/18 16:37:13 BSx9t9cn
アドベはどうかしらんが、あの堀さんがアス比設定まともに出来ないようなシロモンつくるわけないわな
421:名無しさん＠編集中
08/11/18 20:02:22 WQM2eEGn
720×480をリサイズせず、入力設定でピクセル比10:11を選んで、
アスペクト比保持にチェック付けて、出力設定でアスペクト比3:4を選んで書き出したらこうなった。
(アスペクト比保持ってPARかDARのどっちのことをいっているのか分からないので両方試してみたが、結果は同じだった。)
サポセンに聞いてみてもあまり要領を得た返事は返ってこなかった。
大体、ピクセル比10:11で画面アスペクト比3:4にするというのは矛盾するので、
どっちかの情報を優先して入れるしかないとおもうのだが、
どうも画面アスペクト比の方っぽい…
それとも両方の情報が入っているがプレイヤーが画面アスペクト比を優先しているのか？
素人考えなので自分が間違っていると思うんだけどね。何が間違ってんだか…
これ以上特定のソフトの話はスレ違いのような気がするので、逝ってくる。
422:名無しさん＠編集中
08/11/18 20:15:44 T1YamXXj
>>421
普通に正常な動作だろ。何が疑問なのかがわからないんだが・・・
423:名無しさん＠編集中
08/11/19 00:42:40 530HUXEP
色々トライ・エンド・エラーして、直感で掴んだ方がわかりやすかも。
あまり、頭でっかちに考えないほうが、設定メニューの仕組みや動きを大局的に掴めるかと。
424:名無しさん＠編集中
08/11/19 13:57:44 LjhBi4sp
>>421
大体、ピクセル比10:11で画面アスペクト比3:4にするというのは矛盾するので、
なぜ？
425:名無しさん＠編集中
08/11/20 22:44:43 2c8wR41U
スクイーズだった720x480の映像にMP4BOXでアスペクト比いろいろ変えてみたけど、
PS3でスクイーズ表示されない。（変えないでそのままフル表示すればなんとか可）
例：mp4box -add "test.mp4":par=100000:84375 -new "test2.mp4
16:9 QTプレイヤで32:9のような超横長表示されしまう。PS3でも32:9。
8:9 じゃあってんで横を半分にしてみたら元の4:3映像（アスペクト的に縦長絵）になる。
100000:84375 QTプレイヤで正常比。ただしリサイズで映像ガクガク。PS3では32:9
・・・
で、書いてるうちに自己解決したので答え
32:27指定することで、PS3でもノーマル判断で正常比表示されました。
結構みんな引っかかってたらしい。
URLﾘﾝｸ(209.85.175.132)
このキャッシュの554～
426:名無しさん＠編集中
08/11/20 23:50:53 5tIZ/6aD
そんなPAR指定するのが悪い
427:名無しさん＠編集中
08/11/21 00:06:27 JJvGAGOI
>>425
正常PARは40:33だって・・・まぁフル画面取るか正常アスペクト比取るかは自由だけどね
428:名無しさん＠編集中
08/11/22 02:08:05 +541hLtv
>>425
そうゆうことだったのか
俺も微妙に横長になってしまうので、どうしようかと思っていたところ参考になったわ
今までは704x480でクロップして、PAR10:11(40:33)でエンコしていれば正しいと思い
良しとしていたが、どうしてもソースに対して微妙に違和感が感じるので704x480で
クロップした後に左右8ドットプラスするか、735x490拡大してから720x480でクロップし
PAR10:11(40:33)でエンコするように変更したよ （KMPlayerとPowerDVD Vistaで再生）