【ニコニコ動画】FLV/MP4エンコードスレ 54【質問】

ニコニコ動画へ動画をUPするためのFLV/MP4ファイル作成に関する質問スレです。
テンプレやwikiをよく読んで、わからない時に質問するようにしましょう。

※ここは『作成済みの動画をニコニコ動画にアップ出来る制限内のFLV/MP4に変換する』ためのスレです※
　動画の作成方法、画質の追求については関連スレ等をどうぞ。
　ニコニコ動画からDLしたファイルの視聴・編集に関しても関連スレにどうぞ。

質問時は>>8あたりまでのテンプレをしっかり読み、
　　１．問題点（なるべく詳しく）
　　２．元ファイルの情報 （必ずmediainfo等にかけた結果を書いて下さい）
　　３．エンコードして出来上がったファイルの情報 （同上）
　　４．使用ソフト
　　５．MP4ならば必要に応じてx264のエンコードオプション
　　　　（Aviutlの拡張x264出力(GUI)を使っているなら設定画面の下のほうにある"--bitrate 〜"の部分）
　　６．PC環境
等を忘れずに書きましょう。ここにｴｽﾊﾟｰは居ません。

エラーが起きたというような場合は、
　　・エラーを起こすまでの操作手順
　　・エラー発生時のエラーメッセージ
などもしっかり書きましょう。

なお、mediainfoの動画情報等を貼る場合は、patebin等のサービスを利用すると便利です
http://privatepaste.com/
http://pastebin.com/

次スレを立てるのは970辺りの人が宣言して立てる事。
宣言した人間が立てられなかったら失敗報告後に次の有志が宣言後立てる事。

公式サイト
http://www.nicovideo.jp/


前スレ
【ニコニコ動画】FLV/MP4エンコードスレ 53【質問】
http://anago.2ch.net/test/read.cgi/streaming/1311877802/

■関連スレ

【全力】ニコニコ関連の質問に全力で答えるスレ19
http://anago.2ch.net/test/read.cgi/streaming/1323226208/

【YouTube】‐MAD制作初心者向けスレ117
http://anago.2ch.net/test/read.cgi/streaming/1333122392/

【ニコニコ動画】エンコード依頼スレ 13.2【FLV/MP4】
http://anago.2ch.net/test/read.cgi/streaming/1328135238/


■ FLV/MP4ファイル作成の具体的方法

・ニコニコ動画まとめwiki-エンコード設定
http://nicowiki.com/encode.html

■エンコード関連Q&A集（主にFLVに関して）

・ニコニコ動画まとめwiki内エンコード設定あるある質問箱
http://nicowiki.com/aruaru.html

・ニコニコ動画まとめwiki内エンコード系質問？を適当に集めた所（新）
http://nicowiki.com/EncodeQA.html

■ コーデック情報確認ツール（映像・音声ビットレート、フレームレート等の確認用）
・MediaInfo
http://mediainfo.sourceforge.net/ja

・AVInaptic2
http://fsinapsi.altervista.org/

■ FLV/MP4視聴用ツール（映像・音声の視聴確認用）
・Flavie（日本語ok）
http://yakkun.com/other/flavie.htm

・FLVP（日本語ok）
http://s470.web.fc2.com/software.html

・FLV Player（メニュー表示など全て英語）
http://www.martijndevisser.com/blog/flv-player/

・H.264 FLV Player（日本語ok）
http://audition.good-mind.com/soft/

■MP4/FLV作成用フリーソフト

・x264 - a free h264/avc encoder(英語)
http://www.videolan.org/developers/x264.html　　(本家)
http://x264.nl/　　(配布場所)

・AviUtl version0.99k2（推奨）
http://spring-fragrance.mints.ne.jp/aviutl/
・AviUtlプラグインWiki(仮、作成中)
http://www.wikihouse.com/aviutl/

・Avidemux2（英語）
http://www.avidemux.org/ (本家）
http://avidemux.berlios.de/download.html　　（配布場所）

・ffmpeg(英語)
http://ffmpeg.org/ (本家)
http://libav.org/ (分家）
http://win32.libav.org/　　(配布場所)

・VirtualDub（英語）
http://www.virtualdub.org/　（本家）
・VirtualDub用日本語化パッチ
http://tnetsixenon.xrea.jp/rnote/localization/virtualdub.html

・VP6vfwコーデック（ver6.4.2.0）(ファイルへの直接リンクになります)
http://www.webalice.it/f.corriga/vp6personal/VP6.4.2.rar

・FLV/MP4エンコードスレ 支援サイト（下記バッチファイルセットなど）
http://lapis.lazuli.biz/
　基本セット（flvenc.zip）、VP6 2パス用mencoderセット（mencoder_vp6set.zip）、変換君ファイルセット（3GP_Converter_flv.zip）
AAC音声対応のFLV_ffmpegmux_D&D.bat 、可逆圧縮コーデックへのリンクなど

■音声エンコード用ソフト
・Nero AAC コーデック（AAC用コーデック）
http://www.nero.com/ena/downloads-nerodigital-nero-aac-codec.php

・Simple NeroAACEnc GUI : NeroAAC用のフロントエンド（Doom9フォーラム内/英語）
http://forum.doom9.org/showthread.php?t=110970

・qtaacenc : QuickTime for WindowsのaacエンコーダーをCLIで使うためのツール
http://tmkk.pv.land.to/qtaacenc/

・qaac : qtaacencと同じくQuickTime for WindowsのaacエンコーダーをCLIから使えるツール
http://sites.google.com/site/qaacpage/

・Lame.exe(mp3エンコーダー）
http://www.rarewares.org/mp3-lame-bundle.php

・Lame Ivy Frontend Encoder : 通称LIFE（上記Lame.exe用フロントエンド）
http://kkkkk.net/

■その他
・Yamb　2.1.0.0 beta1　（MP4BoxのGUIフロントエンド、beta2はアンインストーラにバグ有で危険）
http://kurtnoise.free.fr/Yamb/installer/YambInstaller-2.1.0.0_beta1.exe
・Yamb日本語化
http://www1.axfc.net/uploader/Sc/so/129495.zip&key=yamb　　　CRC32： 9FB35D72
または、上記アップローダ(板=Scandium) ファイル検索 / 投稿コメント [ yamb ] / key=　yamb
・MP4Box　単体
http://www.mediafire.com/download.php?oacerwnbqbowiyz

■ビットレート制限関連

■アップロード時の上限ビットレート判定について

　ニコニコ動画での上限ビットレートは、現時点で以下のようになっています。
　このビットレートを超えてしまうと、アップロードに失敗します。
　判定には>>7の「実ビットレート」が使用されます。

　　●プレミア会員　　　制限なし

　　●一般会員　　　　　(640+1)×1024＝656384[bps]

■エコノミー回避判定について

　ニコニコ動画ではアップロード時にエコノミーモード用の動画を生成していますが、
　「実ビットレート」が以下に示すビットレート以下であればエコノミーモード用動画は生成されず、
　一般会員にもプレミアム会員にも、常に同じ画質で視聴してもらうことができます。

　　445[kbps] ＝ 455680[bps]

■「実ビットレート」の計算方法

　ニコニコ動画では、アップロードしたファイルを調べ、ビットレート違反のチェックや
　エコノミー判定を行なうようになっていますが、この判定には、コンテナのオーバーヘッドや
　映像、音声など全てをひっくるめた「実ビットレート」と呼ばれる数値が使用されます。
　また、これもあくまで計算なので、実際に通らなかったら潔くビットレートを下げてみましょう。

　＊注意＊
　　「エンコード時に設定した映像や音声のビットレート」は、ただの目安です。
　　設定した映像と音声のビットレートを単純に足すといった計算は無意味ですので、
　　必ず下記の実ビットレート計算式を用いて計算して下さい。

　実ビットレートの計算で使う数値の意味や計算式は以下の通りです。
　もしくはmediainfo等を使うのもよいでしょう。

　　◎ファイルサイズ[bytes]
　　　　作成したFLVやMP4のファイルを右クリック→「プロパティ」で、
　　　　「サイズ」のところの（）内の（〜バイト）と出る部分の数字。
　　　　（「ディスク上のサイズ」のほうではないので注意。）

　　◎再生時間[秒]
　　　　小数点以下は切り捨てます。

　　●実ビットレート[bps] = ファイルサイズ[Bytes] × 8 ÷ 再生時間[秒（小数点以下切捨て）]

尚、各単位換算は以下の通りです。

1Mbps = 1000kbps
1kbps = 1000bps

1GiB = 1024Mbytes
1MiB = 1024kbytes
1KiB = 1024bytes
1byte = 8bits

■注意
　このスレで次の質問をした者には、住人のうちの何名かは問答無用で罵声を浴びせます
　決してこの質問をしてはいけません！！　いいかげんにしてよね、ほんと…

　Ｑ．エコノミー回避の動画を作成してSmileVideoにアップロードしたのに
　　　　「エンコードしています・・・」って表示されるんだけど？？？
　　　　エコノミー回避なら再エンコはされないはずなのになんで？

　Ａ．仕様です。その表示はエコノミー回避してようがなにしてようが表示されます。
　　　条件さえ満たしてれば再エンコードはされないので落ち着け。

　Ｑ．ちゃんと範囲内でエンコードしたのにビットレートオーバーって怒られるんだけどなんで？

　Ａ．ちゃんと実ビットレートで確認しましたか？
　　　指定値を上回ることはよくあります。

　Ｑ．作ったMP4を自分の環境で再生確認すると問題ないのに、ニコニコにアップすると画質がおかしくなる

　Ａ１．まずは、自分の動画がサーバー側で再エンコードされていないか確認しましょう。
　　　　再エンコードの条件とかについてはテンプレやWikiを熟読すること。

　Ａ２．次に、自分の環境で再生確認に使ったソフトを確認しましょう。
　　　　ニコニコ動画で使われているFlashPlayerと、PCで使うWindowsMediaPlayerなどでは
　　　　再生の仕組みがまったく異なります。FlashPlayerは再生時の色補間などをしていないこともあり、
　　　　基本的にはWindowsMediaPlayerなどよりも汚く見えてしまいます。
　　　　例えば黒背景に赤い小さな文字とか描いてたら崩れ方がマジハンパねえっす。
　　　　ニコニコでの見え方を確認するなら、FlashPlayerを利用したFlavieなどのソフトを使いましょう。

テンプレここまで。
色々書き換えたけどこの辺はよくわかんないから入れなかった。


窓の杜 - 【NEWS】「Adobe Flash Player 11.2」「Adobe AIR 3.2」が正式公開
http://www.forest.impress.co.jp/docs/news/20120329_522113.html

FlashPlayer11.2で挙動がいくつか変わっているようです。検証した内容を報告。

　※GPU再生支援がないので、【HWアクセラレーションOFF】の時の検証しかできてません。
　　　【HWアクセラレーションON】の時の検証は、どなたかよろしくお願いします。

　●colormatrixやfullrangeが無視されるようになり、強制的にBT.601でデコードされるようになった。
　　 （11.1時点のHWアクセラレーションON時と同じ挙動）
　　　　　→テスト動画リスト： ttp://www.nicovideo.jp/mylist/27805122

　●10bit-depthの再生では、右側に出ていたマゼンタ線が出なくなった。
　　　ただし、色が微妙におかしくなる問題はそのまま。
　　　　　→テスト動画： ttp://www.nicovideo.jp/watch/sm16808896

　●>>915（deblock有効の動画をHWアクセラレーションOFFで見ると崩壊）の問題は従来と変わらず発生。
　　　>>936にある「GTX570でHWアクセラレーションONにすると緑線と色ずれが発生」という件が、
　　　正式版や他のGPU環境でどうなるのかは気になるところ。
　　　　　→テスト動画： ttp://www.nicovideo.jp/watch/sm17278404

　●初期ディレイ分の映像遅延が発生する件は従来と変わらず。
　　　　　→テスト動画リスト： ttp://www.nicovideo.jp/mylist/28386130

従来から、HWアクセラレーションが有効な場合はcolormatrixやfullrangeを無視して強制的にBT.601扱いでデコードされていた。
つまり、BT.709の動画は、わざわざHWアクセラレーションをOFFにしないと、正しく表示することはできなかった。

今回の変更で、BT.709の動画を正しく表示させる方法はなくなったということになるけど、実はこれは大して問題じゃなかったりする。

なぜなら、ニコニコ動画まとめWikiでは、HWアクセラレーションの挙動なども考慮したうえで

　　「HDだろうがなんだろうが関係なく、BT.601でエンコして--colormatrix smpte170mをつけておく」

という方法を推奨していたから。それに従ってエンコードしていたなら何も問題はない。
ニコエンコやつんでれんこもデフォルトではBT.601を指定するようになっている。

BT.709でアップしてしまったものについてはもうどうしようもないけど、
上に書いたように元から正しく表示されてなかった可能性が高い。

サーバーエンコードされたかどうか、エコノミー回避できたかどうかの判定方法

URLのsmxxxxxxの後に?eco=1を付けて、強制エコノミーモードにする
(非公開設定でも可能。自動再生はoffにすること)

混雑中のため、低画質モードでの再生となります との表示が出たら
サーバーエンコードはされていない
エコノミー回避をしようとしていた場合は、回避できていない

表示が出なかったら、
サーバーエンコードされている もしくは、エコノミー回避に成功している

ニコエンコを使用する場合の注意
ver0.77には、いくつか問題があるので
つんでれんこやAviUtl+x264guiExの使用を推奨する

もしも、ニコエンコを使いたい場合は、ニコニコ大百科の記事を参照のこと
http://dic.nicovideo.jp/id/4131469

mp4と音声ファイルを
別々に作って
あとで互いに無劣化で結合させる方法教えてください
aviutlで出来れば最高なんですけど

つんでれんこにその２つをドラッグ＆ドロップ。

mp4を無劣化でかつ
多少の破損があった場合でも強制的に結合できるソフトおしえて
aviutlでやると映像の破損がある場合がありますって警告がでてだめなの

ふむ

3月30日にリリースされたニコニコ動画iPhoneアプリ4.0では、ref=16の動画は再生できない
3.0や、ref=15以下なら再生可能
このスレで答えている人にはいないと思うが--preset veryslow (ニコエンコのデフォルとである最低速 設定)でエンコすると引っ掛かる

何個かを切り取ったmp4fileを
無劣化結合させたいんですけど
どうしても音ズレが発生してしまいます

何かいい方法がありましたらお教え下さい

音声の方のサンプリングレートをチェック

色々読んだりAviUtl導入したりあれこれやった上でこんがらがってしまったんだけど・・
70分とか80分クラスの作業用BGMなんかで音質192bpsとかの高音質で挙げてる人ってのは、
とどのつまりプレミアム会員で容量が大きいから出来てるってことなんかな！？

計算してみれ

70分　192bps　103KB
70分　192Kbps　98.4MB

oh... 　　“ｋ”が抜けとったorz

WMメーカー・LMメーカーやらで元動画(80分弱）作って当初256kbpsで高音質狙い、最初はニコエンコ使ってやってたんだけど、
どうしても気に入る音質からは落ちるんでwiki読んでAviutl導入してあれこれやってみたのだけども・・
設定がおかしいんだろなぁ、色々やってもｴﾝｺに失敗（ファイルサイズ超過）する('A`)
黙ってプレミアム登録すれって話になるのか・・orz

>>21
いい加減なことやってないで、ちゃんと読んで理解しといたほうがいいと思うよ。
　　エンコード設定 - ニコニコ動画まとめwiki
　　http://nicowiki.com/encode.html

>>22
ありがとー
そこも見てはいるんだけどね^^;
んで、色々試行錯誤の上何とかサイズ超過にならずにｴﾝｺ完了はしたけど、
ニコｴﾝｺで作った方がまだ音が良かったりしたw
もうちょい頑張ってやってみます

言っちゃ悪いけど
ニコエンコのほうが音がいいってことは
何もわかってないってことだな・・・

めんどくせーのと暇だから答え書いてしまうわ。
70分で音声192kbpsなら音声だけで
(192[kbps]*10^3[bps/kbps]*70[min]*60[sec/min])/(8[bits/byte]*2^20[bytes/MB])≒96.1[MB]
になるんだから40MBまでしかうｐ出来ない一般会員が敵うわけないだろが。
中学生でも計算できるぞ。時間掛ければ電卓すら要らんわ。

※ 1[kbps]=10^3[bps]
※ 1[min]=60[sec]
※ 1[byte]=8[bits]
※ 1[MB]=2^20[bytes]

>>20
どうも計算が合わんと思ったら何で"Kbps"で計算してるんだ？
"kbps"なら96.1MBだが。

面倒だからその辺のレート計算機にぶち込んだ結果だったり
どこもKibpsばっかりなんだけど何故だろう？
ややこしい

前スレで出たＦＬＶにＷＡＶ音源使える話、ニコＷＩＫＩにはそのへん
見当たらなかったけど、一般会員再エンコ回避規格でもＭＰ3の変わりに
そのままＷＡＶ使えるのかな？

>>27
まだwavつうかPCM乗せれるんだとしたら可能といえば可能だろうけど、
PCMのビットレートを考えてみれば使う価値がないことくらいわかる。

そうでなくてもニコニコにアップするのにPCM使うのはキ○ガイの所業だと思う。
特に権利関係をクリアしてない音源ならばなおさら。

【事前告知】新バージョンZeroに伴う変更‐ニコニコインフォ
ttp://blog.nicovideo.jp/niconews/2012/04/031597.html

Zeroでプレイヤーのネイティブ解像度が横864の縦486になるらしい。
4:3の動画だと648x486かな？

今まさに動画作成中ですが混乱しています
そもそも作った動画とこのネイティブ解像度が違うときって、
合わさるように拡大・縮小されるって理解でいいんですよね？

新バージョンのプレイヤーにあわせて、一般のビットレート制限も上げて欲しいわ。

4:3プレイヤーはどうなるの

iPhone,iPad,PlayStationVita等で
一部再生できない動画があることについて
ユーザーの皆さまから、改善の要望を多くいただいています。

ニコニコ動画では今後、PCに限らない様々なデバイスでの再生可能性向上のため
新規投稿分および、過去のすべてのユーザー投稿動画について、
サーバーエンコードされた動画が生成されるようになります。

これにより今後、今までiPhone,iPad,PlayStationVitaなどで
再生ができなかった動画も、徐々に再生が可能になっていきます。

4/19のメンテナンス以降、新規に投稿される動画について、
低ビットレートでアップロードされる動画に対しても
サーバーエンコードされた動画を生成するようになります。
※オリジナル動画が低ビットレートな動画に関しては、
混雑時間帯、一般会員であってもオリジナル動画が再生されます。

また、投稿日時が古く低画質動画が存在しなかった動画にも、
4/19より徐々に低画質動画を生成していきます。
これに伴い、そのような動画は
混雑時間帯・一般会員では低画質モードで再生されるようになります。

>>29
どうせ余白分も含んだサイズだろうから、
4:3はVGAでいいんじゃないの

>>33

これって、読みようによってはうｐした動画は全て再エンコされる（Youtubeみたいに)
ようにとれるんだけど・・・どうかな？

>>35
どんな動画も再エンコによって「低画質動画」が生成されるようになるけど、
あくまでも携帯機器等での再生を考えてのことであって、ＰＣで視聴する場合は従来と変わらんってことでしょ。

iPhoneとかだけなら、>>16 なのに、ご苦労なことで

容量とビットレートのが需要あると思うんだけどな・・・

サムネをでかくしてほしいわ
動画を選ぶ時の前情報が少なすぎる

エコノミー回避してても低画質動画(おそらく携帯機器向け)が生成されるようになった件の検証。
まだもろもろ調整中なのかもしれないけど、とりあえず昨日やってみたところまで。あとは誰か追加検証よろすく。

　　１．エコノミー回避している場合、低画質動画はすぐに生成されるとは限らない。
　　　　混雑度合い等によるかもしれないが数分〜１，２時間後になることも。
　　　　（エコ回避していない場合はすぐに生成される）

　　２．低画質動画が生成された後は、?eco=1をつければ低画質動画を再生することができる。

　　３．エコノミー回避している場合、低画質動画の解像度やビットレートが下げられることがある。

　　　　640x360（16:9）で投稿した場合
　　　　　エコ回避していない場合　→　映像640x360 29.97fps 約360kbps、音声44.1kHz 約64kbps
　　　　　エコ回避で312kbps以上？　→　映像640x360 29.97fps 約250kbps、音声44.1kHz 約64kbps
　　　　　エコ回避で312kbps以下？　→　映像352x200 29.97fps 約250kbps、音声44.1kHz 約64kbps

　　　　　よくわからないけど、実ビットレート190kbpsで投稿すると352x200で128kbpsとか140kbpsにされた。

　　　　　　実ビットレート314068bps → 640x360 約250kbps
　　　　　　http://www.nicovideo.jp/watch/sm17603005

　　　　　　実ビットレート310045bps → 352x200 約240kbps
　　　　　　http://www.nicovideo.jp/watch/sm17603017

　　　　　　実ビットレート約190kbps → 352x200 約128〜140kbps
　　　　　　http://www.nicovideo.jp/watch/sm17602228
　　　　　　http://www.nicovideo.jp/watch/sm17601841

4:3のエコノミー回避例だと、512x384の実ビットレート約224kbpsで投稿したものの低画質動画が
映像320x240 29.97fps 約156kbps、音声44.1kHz 約64kbpsになってるみたいですね。

つんでれんこの最終更新やったらまたツールの容量増えたんだけど
18GBって多過ぎないですかね？これがデフォ？
最新版使ってる人ってみんな同じくらいなんですかね？

それ変換したファイルも足してないか？
俺のは8Gくらいみたいだが

ツールが18Gやら8Gってなんなんだよ
その辺の3Dゲームより重いじゃねーか

ていうか調べたらただのバッチツールじゃん
5MiBもないだろこんなもん

そしてお前ID: mPCndjxxUbか
よかったなわかってる奴から回答来てたぞ
マルチ氏ね

>>44
おお返事来てたわ(´・ω・｀)ありがとう
後ニコニコ大百科と2ｃｈの併用くらいいいだろ
別サイト（掲示板）だぞ？
氏ねとかねーわ　大袈裟だよ(´・ω・｀)

>>43
今ツールフォルダ内のTEMPファイル消したらすっきりした
現状だと28.6MB位かな

うわークズいなー・・・

submeを10から11に変えたら
1時間30分のエンコが2時間5分になった
画質はわずかながらシャープになった・・・ 気がする
placeboなのか？

>>46
iPhone,iPad,PlayStationVita上での視聴"のみ"の適用ならいいんだけどね
もしPC上での視聴を含むすべての視聴に適用されるんなら、事実上の「低画質モード適用範囲の大幅拡大()」になるね
なんか本格的な一般会員締め出しのように思えて仕方が無い。

aviutで編集した動画lがやたら音ズレするんだけどどうすればいいんだろう

全体がずれてると言うより部分部分がずれてる
ずれてると思ったらズレが消えてて消えたと思ったらまたズレ始めてる感じ

前にも編集した動画を上げた事があるんだけどそれは殆どずれてなかった
けど今回はどうあがいても音ズレする、なんか解決法とか無いでしょうか

編集した動画はMP4でPCは7で32bit、多分コア2のノートパソコン
aviutlにはBGMの編集が出来るようにそのプラグインを入れただけ

aviutlのスレも板別に二つあったけどどっちも>>1の一行目に質問お断り的な事書いてあったからこっちに書いた

>>49
・「そのプラグイン」と言われてもなんのことかさっぱりわからない。
・MP4の読み込みに使っているプラグインがわからない。
・音ずれが怖いならMP4を直接編集しないほうがいいと思う。
・拡張編集プラグインを使って編集しているような気がするがわからない。
・再生確認をした環境（プレイヤー等）がわからない。
・AviUtlスレでは初心者スレに行くよう誘導があるので、そちらに行った方がいいと思う。
　　　【初心者歓迎・ダウソNG】総合質問スレッド-78-
　　　ttp://toro.2ch.net/test/read.cgi/avi/1317166834/l50

また、FlashPlayer11.2には、「低スペック環境だと映像処理が極端に遅くなる」といった問題があるので、
　　＞全体がずれてると言うより部分部分がずれてる
　　＞ずれてると思ったらズレが消えてて消えたと思ったらまたズレ始めてる感じ
というのがFlashPlayerで見た場合のことを言ってるなら、そのせいかもしれない。
他のプレイヤーで見た時には問題ないということであれば、FlashPlayerを10.3.183.18にすれば良いかもしれない。

　　FlashPlayer11.2.202.228で発生する問題と対処方法
　　ttp://goldenhige.cocolog-nifty.com/blog/2012/04/flashplayer1122.html

　　FlashPlayer11.2.202.228をアンインストールして10.3.183.18をインストールする方法
　　ttp://goldenhige.cocolog-nifty.com/blog/2012/04/flashplayer11-1.html

うおぉ、色々すいません

プラグインはAviutlのお部屋にある拡張編集プラグインを入れてます、それ以外は何も入れてないです

>音ずれが怖いならMP4を直接編集しないほうがいいと思う。
MP4だと問題があるのかな
一度aviにしてから編集した方が良いのでしょうか？

視聴に使ってるのはニコニコに非公開でアップしてニコニコで見てます
これなら他の人とほぼ同じに見えてると思うので・・・
・・・もしかしてFlashPlayer11.2＝ニコニコ？
ちなみにエンコに使うつんでれこに入ってるプレイヤーやWMPで見てもずれて聞こえます
けどなんかそれぞれズレが違う気が・・・

2年前に買ったとは言えまだそこまでスペック低くないと思います・・・が実際どうなんだろう
---
こっちの事情で動画をMP4でしか出力できないので
とりあえずMP4をaviに変換できるソフトを探してaviにして編集してみます

それでも駄目ならFlashPlayerのバージョンを変えてみまｓ

>>51
>>プラグインはAviutlのお部屋にある拡張編集プラグインを入れてます、それ以外は何も入れてないです
ここまで清々しい嘘、ど忘れ、勘違いのいずれかは久しぶりに見たな…。
嘘やいい加減を言って回答者を困らせるのは止めましょう。

え？って思ってもう一回調べたらMP4を読み込めるようにするプラグインは別でした、ド忘れです、いい加減言ってすいません

あとあの後MP4からaviに変換するソフトを使ってaviに変換してaviutlに読み込ませて編集してエンコして試しに上げたら
見事に音ズレが消えました、全くと言って良いほど無いです
MP4で読み込めるようにしたからMP4のままでも問題ないだろ〜って思ってましたが、それが大間違いだったんですね

AviutlでMP4読み込むならL-SMASH Worksがいいと思うけどどうよ。

Ivyでは再生支援映像崩壊問題が解決してるとかしてないとか

>>55
ソースはよ

>>56
価格.comの3770Kのレビュー
ソースと呼ぶにはちょっとあれかな、詳細なこと(再生環境やら)が書かれてないし

>>57
これか。ありがとう。

　　価格.com - インテル Core i7 3770K BOX レビュー・評価
　　ttp://review.kakaku.com/review/K0000368065/

　　個人的に満足したのはGPUの方でSandy Bridgeでの動画再生支援機能の不具合が
　　少なくともかなり改善しているようだからです。
　　うちにあるSandy Bridgeで同じ箇所でノイズ発生率100％の
　　x264でエンコしたMP4ファイルでも問題なく綺麗に再生できてます。
　　現時点では完全にどの動画ファイルでも問題ないというのは言い切れませんが、
　　動画サイトを利用される人にも薦められる状態にようやくなった、という感じですかね…？

新バージョンZeroに伴う変更
http://blog.nicovideo.jp/niconews/2012/04/031597.html

新動画視聴プレイヤーで画面サイズが大きくなる（通常モード：横：864　縦：486）ため、
一般会員が投稿できる動画解像度の上限を緩和いたします。
現在800x600が上限ですが、
5/1 Zeroリリース時点より、1280x720 が上限となります。



↑らしいが、ビットレートの上限は今までどおりなんだろか？

エンコ職人は工夫のしがいがあるなあ（棒

1280x720 ： 800x600　= 1.92 ： 1

解像度の画素数が2倍ぐらいになるので、今までの上限ビットレートだとつらいなー

というか864x486で656kbpsだと
素材によっては普通にブロックノイズ出るだろ
多少にじんでても今までどおりの解像度でエンコして
ユーザ側で引き伸ばしの方がまだ見れると思うんだけどなぁ

紙芝居系なんかは大丈夫だろうけど、MADとかゲームとか、そこそこ動きのある動画は厳しいかもね。

・・・末尾に黒映像つけてビットレート稼ぐ人が増えなければいいけど・・・。

>>63
すでにそこそこいるもんな

俺とか


まあでももしかしたら
＞※プレミアム会員は引き続きビットレート・解像度ともに投稿上限なしです。
ってことはこっそりビットレートもあがるかも

推奨形式：
mp4形式。
一般会員はファイルサイズ 40MB まで、最大ビットレート 600Kbps、解像度HD(1280x720)まで。
プレミアム会員はファイルサイズ 100MB まで、最大ビットレート・解像度制限なし。
動画再生プレイヤーの解像度：
▽最新バージョン(Zero)
通常モードでは最大864x486、中画面モードでは標準640x360・最大640x384です。
▽現行バージョン(原宿)
4:3モードでは最大512x384 、16:9モードでは標準640x360・最大640x384です。

解像度は良くなったけど容量は変わんなかったか...

あれ？ 動画の説明文が表示されないんだけど・・・
どこに表示されますかね。

Zeroの最大16:9は864x486だけど、4:3だと推奨サイズはいくつになるんだろ
それとも今まで通り512x384でエンコして、ユーザー側で引き伸ばしの方が画質いいのかな

648x486?

もしそうならえらく半端だなぁ
どういうつもりなんだろ

dot by dotのサイズがわからないと動画作れないよー

ニコニコはそろそろ動画が表示領域より小さい場合
引き伸ばして表示するか中央に配置するかの設定を付けるべきだと思うんだ

動画作ってみたけど648x486はDbDで表示されるっぽい
しかしZeroには慣れそうに無いな…

やっぱ新プレイヤーで864x486に引き延ばされるとちょっと荒く見えるなあ

新プレイヤー糞見辛いｗ　ゴチャゴチャし過ぎだろｗ

今後「中画面推奨」みたいなタグが出まわるんだろうか

Zeroマイナスしか見当たらない気がするんだけど
モニタサイズのフルスクリーンが関連動画と動画説明で全然フルじゃ無いし
後妙に重い気がする、俺のPCももう時代に追いつけないのか・・・？

4:3をVGAサイズで上げると微妙に拡大されて画質落ちるのかな？
もう運営何目指してるのかわからん

ていうか画面サイズ720pまで上げたのに上限ビットレートそのまま656kbpsってのがワケ分からんわ。
ようつべに上げてる動画でも（ようつべの再エンコはあるものの）映像：1020.55 + 音声：151.94 kbpsあるぞ
720pで合計ビットレ656kbpsってタダ画面サイズがデカいだけの糞画質動画じゃねぇかよ
せめて上限1000kbpsぐらいまではいるだろうに。

一応前のバージョンに戻せるのか、良かった・・・

>>77
そこで黒画面でビットレート稼ぎですよ

黒画面＋ニコスクリプトで目的の動画部分終わったら
即動画の最後に飛ばすってのが流行りそうだねーｗ

>>79
所謂エコノミー上限313kbps時代に流行ったインチキエコノミー回避のアレだな。

しかしまあそれで動画を作るとすると、（これは自分のサンプル動画なのだが）
3分10秒の動画で実質ビットレ：[映像：800＋音声：192kbps]が欲しいとなると
サイズが23.3MB（ニコエンコ出力前予想による）らしく、これを656kbps以内に
収めるとなると、粗算だが必要秒数が約290秒（＝4分50秒）。

つまり、たった3分10秒の動画に1分40秒の黒背景が必要っていう。
（＝実質動画66％に対してダミーが34％も含まれる！！）

只でさえ読み込みが糞遅くシークが意味を成さないニコ動で34％のダミー動画も
読み込むとなると、とても動画の視聴どころではないわ。

ニコの一般HDってのはまるで形だけのシステムだな。

つんでれんこで、多音声（コメンタリー付きとか）つける方法ある？

>>81
多分ないと思うが、そこまでするなら自分でバッチ組んでエンコしたほうがいいんじゃね？
それか１音声でエンコしてからMP4Boxで追加するとか。

>>81
そもそもニコニコが音声1トラックしか受け付けないよ

Macで簡単で落とすのにオススメのソフトありますか？

>>84
スレ違い。他へ行け。

>>71
されない。間違いなくされてない。もうプレイヤーサイズかわったみたいだが

>>86
Zeroバージョンの大画面モードでの4：3なら648×486であってると思うが・・・。
「プレイヤーサイズが変わった」って、なんのことを言ってるんだろう？

あれ…すまん勘違いだった。
ドットバイドットに関してはss撮るまでもなくボケてるし比較してもボケてる。640×480に無効領域付けても同じ
まだ640x480の方が綺麗な所をみると512×384を基本サイズで再生して無理矢理伸ばしてるんじゃないかと思う

マザーボードをギガバイト（その前はフォックスコン）に変えてから音ズレ発生
決まった間隔でズレるわけじゃなくて、だんだんズレていく
ウィルスソフトやその他常駐ソフトを切っても起きる
映像と音声を比較すると、映像に時々間延びのコマが入る
酷いと画像がノイズ状に
よくよく考えてみるとネット経由でUSB接続のドライブにアクセスした時によく発生
ソースをUSB接続のドライブに置いていたり、エンコ先にUSB接続のドライブを指定したり
ので、ソースとエンコ先をすべてPC内にドライブに指定して、USB接続は全部取り外したら
音ズレなく綺麗なエンコができた
音ズレに悩んでいる人はUSBドライブを全部外してみよう

>>88
いやそんなことないだろ
648x486はそのまま表示される
引き伸ばされてボケるってのならサンプル提示してくれないか？

うーん…されてるっぽい…初日に試してだめだこれって思って要望送ったんだがそれが反映されたにしては>>71の方がはやいし…
ssぐらい保存しとくんだった
ttp://hishou.ddo.jp/~bbs/up/img/up3439.png

されてるっぽいって何の事言ってるのか分かんないけど引き伸ばされてないですね

>>91
AviUtlのプレビューと比べるとボヤけてるように見えるというのはなんとなくわかるけど、
そもそもAviUtlのプレビュー画面とFlashPlayerの画面を見比べてはいけないんじゃないだろうか。
どのプラグインを使ってMP4をAviUtlに読み込んでるのかわからないけど、
AviUtl側では何らかの色差補間が入るはず。FlashPlayerは補間なしの単純再生らしいし。

比べるなら、Flavieでの再生画面と比べないと意味がないと思う。

>>93
こんなのあったのか｡ssも普通に撮れるしすごくいいね｡
aviutlはdirectshow+lavfiltersで開いてYV12→YC48に伸張してます｡
普通のffdshowやmpchcで読み込んで比べてみても明らかにボケててプレイヤがキャプチャできなかったからaviutlで読み込んだんよ
色空間的なボケじゃなくて解像度が合っていないボケかただったからさ…

flash player上で右クリメニュー出して
画質を低にしないと、aviutlと同じ画にはならんでしょ

>>94
LAV Filtersでのデコードで補間が入るはずだし、やっぱりFlashPlayerとは見え方が違うはずだと思う。
結局Flavieを試した結果はどうだったんだろう？
ZeroバージョンのプレーヤーとFlavieでの見え方は同じだったのかな？

>>95
FlashPlayerの画質設定は、swfファイルなら効くけどH.264やらVP6やらの動画には
効かないという認識だったけど、自分は詳しいことはよくわかってない。

　　低画質推奨とは - ニコニコ大百科
　　http://dic.nicovideo.jp/id/655736

しかし>>91の左の設定すごいな。エンコに半日もかけてんじゃねえよｗ

>>96
私がおかしいと思った箇所については全く問題ありませんでした｡というかniconicozeroの方でも現在は問題ないみたいです｡なんかいろいろすみません

右のほう一日以上かかったのか・・・

ニコニコに上げた時間なんかなこれは

ここでいいのかわかりませんが質問です
ニコニコに投稿する前提で
キャプチャーボードがAVケーブルかS端子、D端子、HDMI対応どれにするか悩んでます

画質はやはり全然違いますか？

>>101
スレ違いです。ソフトウェア板やDTV板にあるキャプチャ関連スレに行くなり、
「VIPで初心者」でググってそこをちゃんと読むなりしてください。
何をキャプチャしたいのかも書いてないし、ググってある程度知識をつけないと門前払いかもしれない。

そんな検索ワードでどんなサイトが出るのかと思ったらよく見てたところだった

>>102
親切にありがとうございます
そちらにいってみます

Aviutlにデジカメで撮った動画を取り込めないんだけど、どうしたらいいんだろう
Directなんたらは入れたんだけどできない

AVCHDに対応してないとか？

windowsメディアプレイヤーで再生できてaviutlにdirectshowで見られないなら読み込みの設定順位がおかしい｡
再生できないならスプリッタがちゃんと動いてない｡mpchcなりffdshowなり入れないと

>>105
デジカメの記録方式を書かないと正しい答えはもらえないってことに気付こう

その前にスレチ
【初心者歓迎】総合質問スレッド-79-【ダウソNG】
http://toro.2ch.net/test/read.cgi/avi/1335404660/l50
こっち池

flvで80MBくらいの動画を手っ取り早くうｐしたいんですが
ニコエンコにも対応していないって言われますし
つんでれんことか使い方意味不明だし
諦めるしかないですかね？

プレアカにするつもりはないんで
youtubeも15分以上の動画は携帯認証とかめんどくさいし
気軽に動画すらうｐできなくてわろたｗｗｗわろた・・・

>110
flvならblipにアップしてみれば

youtubeは10個動画上げれば長い動画でも上げられるようになる

つんでれんこの使い方なんて初心者でも余裕だし、それが意味不明って逆に凄いな。
つうかそのレベルでよくFLVファイルが作れたな・・・。
FLV出力できるソフトなら別形式での出力もできるだろうし、
kakoroku導入して生放送録画したものだって言うなら、kakoroku導入できるくらいなら
つんでれんこなんて余裕だろって話だし、残るはDL丸上げくらいか？

>>113
ここまで侮辱されたの生まれて初めてです・・・

正直このレス読みながらかなりピキピキきちゃいました

どういう神経してるんでしょうか？

いまどきflvとかないわwww

lsmashでavc+alacを上げられるようになったがブラッシュプレイヤーでギャップレス再生出来てないぽいからvp6+wavもまだ需要あるぞ

>>116
ギャップレス再生も何も、FlashPlayerはALACなんぞサポートしてないわけだが・・・。

してる

FLVの使用用途なんてwavだけだと思ってる

>>118
FlashPlayerはALACなんて対応してないよ。
FlashPlayerはMP4系コンテナでは映像H.264/AVC、音声AACだけしか扱えない。
Adobeが定義したF4Vコンテナの仕様書には一応MP3音声も規定されてるが、FlashPlayerはそれすら再生できない。

L-SMASHのおかげで「音声がALACのMP4を作れるようになった」のは確かだが、
そのことと、FlashPlayerがそれを再生できるかどうかということは全く関係ない。

H.264/AVC＋ALACのMP4をアップしたらどうなるのかは試してないし、試す気もないが、
少なくともそのままの形式では再生できないのは間違いない。

正直ニコニコに可逆音声やPCM音声でアップする人って不思議ちゃんとしか思えないけどね・・・。

禁断の果実だから手を出したい奴もいるだろ。
皆がやればどうなるかとか考えず

ぶらっしゅぷれいやー

秒間30フレームのような動画でも、ニコのプレイヤーだと
例えば背景がゆっくり動くような映像で微妙にカクカクして見えるのはどうして？

flash playerがPAL仕様で最高50fpsだからとか？

>>123

ニコ動のページで他の宣伝のflash＆マーキーが動いているから。

>>124-125
よく判らないけど、これに関しては回避不可能と思えばいいのかな？
自分がうpった訳じゃないが、日常ED2みたいな動画だともうガクガクだよね

>>124
知らなかった…どうりで60fpsで上げてもドロップフレームが出るわけだ…
ネトゲの動画とかは50fpsでキャプチャしようかのう

いや、上限50fpsなんて大嘘だから。
明確なソースは見つけられなかったけど、ありえない。

>>127

flash playerは60fpsどころか、120fps再生とかも問題ないよ。
カクカクするのは、コメントや他の宣伝のflash＆マーキーが同時に動いている負荷のため。
または、PCやグラボの性能が低いため。

corei7 [email protected]で再生支援は切ってる。コメント切っても変わらんし広告なのかぁ
なんだっけオミトロンとか入れればいいんかね?

flashplayerの再生支援はGPUなんだから、グラボ次第

OperaとかFirefoxとかのプラグイン版だとコマ落ちするけど、64bitのActiveX版だとコマ落ちしにくい

MAD動画をアップしようと思うのですが、
たて横の大きさはどのくらいがいいとかありますか？

幅1280ｐｘ　高さ720ｐｘ　なんですが、
この辺は特に気にする必要はないですか？

動くシーンは大体ティアリングが発生して
たまにノイズみたいのも載るんだがこれは何が原因？

>>133
そのままでもよかとですけど、16:9なら
　・Zeroの大画面相当の864x486
　・原宿やZeroの中画面相当の640x360
くらいにしてもいいかもしれねべっちゃ。
解像度が高いとビットレートも仰山必要になるさかい、
動画の長さ、一般かプレミアかなど、自分で考えて決めりゃええ。

>>134
環境もろくに書かず質問するとはいい度胸ですぅ
　・ティアリングとかノイズとか言ってるものがわかるSS
　・CPU
　・OSとビット数
　・使用ブラウザとバージョン
　・FlashPlayerのバージョン
　・ハードウェアアクセラレーションのON/OFF
　・GPU名やドライババージョン
　・問題が起きるサンプル動画
くらいの情報は出しやがれなのですぅ

以前niconicozeroで648x486がドットバイドットで再生できないと言ったID:zAq1Gbd+0 です｡
ttp://hishou.ddo.jp/~bbs/up/img/up3630.png
やはりこれは出来てないんじゃないかな… どうみても文字が潰れてると思います

すみませんプレイヤの設定で画質低にしたら普通に見られました｡変な補間が入ってるんすね

flash playerは画質低をデフォにしてほしいよな
毎回低に変えるのめんどい

ニコエンコが使えなくて困っています。

OS:Win7
録画ソフト:アマレココ
元動画の形式:AVI

ファイルを選択すると
「未対応の動画形式です。コーデックパック(CCCPなど)を入れると対応できます。」
と出ます。２ヶ月ほど前は普通に使えてたんですが急にこのようなエラーが出ました。
CCCPもインストールしましたが駄目でした。

よろしくおねがいします。

>>139
ニコエンコは古いままメンテナンスもされておらず、色々な問題があるので使うべきではありません。
「つんでれんこ」やその派生の「夏蓮根」、または「AviUtl」あたりを利用するほうがよいでしょう。

　　ニコエンコとは - ニコニコ大百科
　　ttp://dic.nicovideo.jp/id/4131469

　　ニコエンコ v0.77を使う場合の注意点
　　ttp://goldenhige.cocolog-nifty.com/blog/2011/11/v077-9371.html

　　動画がおかしくなる方は大百科をクリック→とは - ニコニコ大百科
　　ttp://dic.nicovideo.jp/id/4623324

　　つんでれんことは - ニコニコ大百科
　　ttp://dic.nicovideo.jp/id/4038249

動画がおかしくなる方は〜は全然違うだろwあれはDXVAの支援バグに関する記事だ
とりあえずamv2/amv3のアンインストールと再インストール、PC再起動してみれば?

>>141
>>139 の問題とは直接関係ないが

動画がおかしくなる方は大百科をクリック→とは - ニコニコ大百科
ttp://dic.nicovideo.jp/id/4623324
の記事を読めばわかるが、ニコエンコのデフォにもなっているref=16にした時に起こる問題についても書いてある

そのあたり、エンコ設定に関する注意をまとめた記事

ｘ264でのニコニコ動画用エンコードで注意すべき設定(AviUtl)
http://chround30.blog.fc2.com/blog-entry-24.html

記事にあるdeblockの問題とか、エンコ依頼受けている人がエンコした動画でも起こっていたりする

いやいや前の記事のベースはほとんど自分が書いてるし内容は把握してる
動画が読み込めないって質問に対してエンコ後どうとか言うのはあまりにお門違いだろうと
ニコエンコは使わないから詳しい事は分からんがdirectshowがおかしいんだろ。コーデックの優先度などが正常にならんとつんでれんこでも同様の問題が発生する可能性がある

今動画を投稿する場合解像度640×360で
ビットレートは1200、1400、1500のどれが良いと思いますか？
1500だと今のニコでは重過ぎて見れませんか？

今動画のエンコや投稿している人の現状でのアドバイスを聞きたいです

>>144
ギリギリ視聴に耐えられるラインで容量切り詰めてうpったりしたけど
結局高画質版をつべに貼り直した。
今のニコが不安定すぎるんで悩むだろうけど、
自分が納得できるサイズにするのが後悔しないと思う。俺なら1500にするね。

>>139
>>143
とりあえず以下を確認するといいかもね。
　　１．数秒でいいからもう一度何か録画してニコエンコにかけてみる。
　　　　そっちがちゃんと読めるなら、問題が起きたAVIだけがおかしいということになる。
　　２．とりあえず問題が起きたAVIが再生できるかどうかを確認。
　　３．再生できないなら修復ツールを試す。
　　　　　　ttp://www.amarectv.com/amarecco/manual/kakugamenn.htm#syuufukugamenn

だが、記事読めばわかるだろうけど、余程の理由がない限りニコエンコを使い続けるメリットはない。
使い続けるにしても設定ファイル等をいじらないといけない。
つんでれんこはDirectShowだけじゃなくAVISource()やFFMpegSource()での読み込みもできるので
ファイルを正常に読み込める可能性は高い。

>>144
とりあえず自動マルチパスじゃなく、品質基準VBRの --crf 23 でエンコしてみる。
できあがったもののビットレートが1500以上なら自動マルチパスでビットレート1500に。
それ以下ならそのまま投稿すればいい。

>>145
>>147
自分は今プレミアム会員だけど
7分の640のビットレート1500で上げて一般会員はまともに見れるのか心配です。
妥協して1200や1300に下げるかどうか。
一般が見れないと再生数は伸びないし、でもこの1200〜1500で画質は全然違うし・・・。

ビットレートとランキングの関連性についてのデータないかな？

>>148
何を言っても無駄みたいだし、依頼スレに続いてこんなとこでグダグダ言ってないで自分で考えて好きにしなよ。
個人的には1200か1500かで変わる再生数なんて誤差レベルだと思うがね。

今640×360のビットレート1600の動画MADを作ってみたのですが
一般では重くてシークバーが止まりまともに見れないようです。
ちなみに容量は8分で90MB程度。

こちらでMADのエンコードをする場合、
640の解像度のものを普段どの程度のビットレートにしていますか？

そもそもニコニコの読み込み速度なんて全く信用してないわ
動画見るときは基本全ロード最低でも半分はロードしてから見てる
正直ビットレートあまり関係ない気がする
超時間耐久動画と超高画質ベンチ動画で明らかに耐久のほうがロード遅いし

>>151
動画投稿してる俺の個人的な感覚でよければだけど
ビットレート1200超えた辺りから「動画重い」ってコメが付き始める感じ。

>>151
動画の読み込み時にシークバーが止まるのなら、ビットレートというより
通信速度と容量の問題だろ？

だから、90MBあるんなら、1600kpbsで8分だろうと、3200kbpsで4分だろうと同じ

動画を読み込んだ後に、再生がスムーズに行くかどうかなら、ビットレートとか
エンコ設定が効いてくる

ニコニコ動画のsmile-psuサーバーの仕様について
http://togetter.com/li/302424

の話まで考えるなら、容量だけじゃなくて、ビットレートも効いてくるだろうけど、それはまた別の話

psuってZeroの話みたいだから一般には関係なさそうね
しかしシークバーで判断できないとか・・・

>>156
smile-psuはZeroとは何も関係ない。原宿でも発生する。
プレミアムだけの問題だから一般会員には関係ないというのは合ってるけどね。

>>153
>>154
2、3分の動画だと2、30MBに収まりますけど
7分や8分でそこそこの画質にすると
どうしても70MBとか80MBになってしまいます。

現状のニコニコでMADの解像度640の1500や1600ビットレートでは
重くて敬遠されるレベルなのでしょうか？
通常のゲームプレイ動画と違いMADの場合やはり画質を無視できませんから
その辺の一般的な視聴者側の体感や認識が凄く気になります。

>>152
>動画見るときは基本全ロード最低でも半分はロードしてから見てる
以前はどうだったかわかりませんが
今はプレミアムの方が読み込み＋再生でカクカクしますね。
一般はカクツキが無い代わりに読み込みが遅いという感じで
結局ニコニコ側の問題なので投稿者はどうする事もできない気がします。

>>158
はっきりいって、重いかどうかが気になるレベルのMADなら、７分や8分あること自体が敬遠される
内容が十分面白いのなら、どんなに重かろうが、視聴者は見てくれる

映像部分に関して、エンコしても崩れにくいものって何？
例えば紙芝居動画を作るとして、元の画像はどういう状態に準備する？

もやっとしてエッジがない絵は圧縮しやすい
しかし、紙芝居なんてエンコ楽勝だからそこまで気にする必要はない

ttp://www.nicovideo.jp/search/%E3%83%95%E3%83%AD%E3%83%83%E3%83%94%E3%83%BC%E3%81%AB%E5%85%A5%E3%82%8B%E5%8B%95%E7%94%BB%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA?sort=n&order=d
こういう縛りプレイ楽しそうなんだけどなんで流行らないんだろう

FDサイズにエンコし直しただけで自作動画になるなんてお得ですね

割とこだわってエンコしてる身としてすごい面白そうだと思ったんだけどな｡
そういう人は1度は○○を何人かでエンコして一番綺麗な奴優勝なみたいな事考えたことあると思うしバイト単位で条件作れる訳やん

>>163
URL張る時は短縮位しろ
http://goo.gl/I5UUP

短縮URLも怪しくてあまり踏む気になれないし、大百科示せばよかったんちゃうかと。

　　フロッピーに入る動画シリーズとは - ニコニコ大百科
　　http://dic.nicovideo.jp/id/4417245

フィルタやエンコ設定を細かく考えていく人なら楽しいのかもしれないけど、
正直なところ低解像度で異常な設定をした挙句、出来上がるのはサイズが小さいだけで
ただの画質の悪い動画なんで、個人的にはまったく魅力を感じない。

twitterじゃあるまいし短縮にする必要なし

自分ルール
1. amazonのURLからは不要な部分を削る
http://www.amazon.co.jp/dp/4777512258/
2. ニコニコ大百科は、>>167のように記事番号のURLを使う　（記事名が英数字のみの場合は除く）
3.他は、リンク先が踏まないとわからないから、短縮URLは使わない、

短縮じゃないとスマホで見づらいから、短縮で頼むわ

ｍｍｄ作成でAVIで出力してからaviUTLで編集して、H,264でMP4にエンコして再生したら、MMDで作成した画面のほとんどが白くなったり字幕に影がかかって読みづらくなりました

エンコードオプションは--bitrate 390 --pass 3 --stats "%{savfile}.stats" --keyint 300 --b-adapt 2 --me umh --subme 8 --direct auto --ref 5 --log-level noneです
PCはLC900KGでVistaのノートPCです

MMDやAVI形式の動画以外では問題なくMP4で再生されました
３時間くらい調べても原因がまったくわからなかったので、わかる方回答してくださるとすごく助かります

プレイヤーがquicktimeだったとかじゃあるまいな

AVIがまともに読めてないんかな？
試しに他の形式にしてみれ

>>172、>173
レスありがとうございます
早速試させてもらいます

問題解決できました、ありがとうございます
原因は>>173さんの言う通りquicktimeが原因でした
やっくん氏の配信しているフリーソフトのFlavieでMP4を再生することで通常通り再生できました
Yahooの知恵袋では回答が来なかったのですごく助かりました、ありがとうございます

とりあえず最後の1行はやめとけ。
回答者になればよく分かるがマルチポストは馬鹿にされてる印象しか受けない

>>175　の問題点
1. テンプレを読んでいない　(>>8 の逆パターン)
2. （>>176) マルチポスト
3. 知恵袋という名だが、なんの知恵の集積もしていないサイトをアテにしたこと

いや割と知恵袋でも質問点を的確にして質問すればちゃんと事細かに答えてくれる人はいるよ
DTV板住民でもまず誰も知らないような重箱の隅を突つくような質問でも懇切丁寧に教えてくれたり検証してくれたりする事は多いし自分も自己満足で答えたりはしてる
専門的な分野になればなるほど人は少ないけど教えたがりな人の割合は高かったりするからね
ただそうはいっても動画共有やらネット一般のカテゴリとかPC初心者、その他一般的なカテゴリでは質問の意図にそぐわないあまりにも酷い受け答えが大半のようには感じる

YES,NOで完結する質問にそれは分からないですがこれ(全く関係の無い酷いもの)はどうですか?とか勧められてベストアンサーになった時は唖然としたわ

>.178
ちゃんと答えてくれる人がいることは認める
問題なのは、「なんの知恵の集積もしていない」こと
知っている人が質問した人に教えるだけで、それ以外の人がその情報を探そうとして
知恵袋内で検索しても、往々にして、的確な答えはノイズの山に埋もれてしまっていて
その時答えた人を運良く捕まえる以外に方法がない点

おｋ

[movie.avi]
720x480 12Bit Intel Indeo iYUV R2.0 29.97fps 124291.59kb/s
PCM 44.10kHz 16Bit 2ch 1411.20kb/s
[WindowsMedia] 00:01:04.000 (64.000sec) / 1,012,806,034Bytes

真空波動研SuperLite 090503 / DLL 090503

このファイルをAviutlで読み込むと、音声だけで画面が真っ黒になってしまいます。
FFDshow関連かとも思いそちらも試しましたが、WMPでの再生時にはFFDshowは出
てこないのでどうやら違うようです。
AMV3の未圧縮で出力したものをWMMで編集し、WMEの未圧縮コーデックで出力しま
した。
どなたか原因がお分かりの方はいらっしゃいませんでしょうか？
当方OSはVistaです。

>>181
・まとめWikiで非推奨とされている無圧縮WMVで出力している。( http://nicowiki.com/howtomovie.html#r8e34852 )
・そのファイルはWMVファイルであってAVIではないのに拡張子をaviにしている。
・ついでに言うがそんな解像度で大丈夫なのか？アスペクト比とかおかしいんじゃね？
・さらについでに言うと真空波動研が古すぎる。

たぶんかなり古い間違った解説動画を見たんだと思うけど、とりあえず無圧縮WMVを使うのはやめたほうがいい。
あとDirectShow File Readerでの読み込みもトラブルの原因だからL-SMASH Worksを入れて読み込んだほうがいい。

解説動画って正直害悪だよなぁ。
うｐした瞬間から情報は古くなっていくし、そもそもその内容がうｐ主独自の頓珍漢なやり方だったりする。
複数人の目に晒されて中身が練られてるまとめｗｉｋｉのほうがいいわ。

3年前の波動研か・・・

まとめwikiも編集しなけりゃダメだけどな

http://nicowiki.com/aviutl_h264.html
ビットレート計算機が付いたこととか、拡張x264出力(GUI)Ex)1.43から、キーフレーム間隔の上限で -1にすると自動でfpsx10になるとか

http://nicowiki.com/encode.html
48kHz制限は撤廃されたとか

あちこち古くなっている

#海外規制で自分では直せなかった

>>182
sar par darって知ってるか

>>186
知ってるけど、>>181の流れで720x480のまま扱ってるのは疑問に思わないのか？
ソース等が明記されてないから詳細はわからんけど、注意喚起くらいしといがほうがいいかと思っただけだ。

>>185
とりあえずaviutl_h264のページだけ更新しておきました。
　　http://nicowiki.com/?aviutl_h264

●ツール一覧表からMP4PluginとDirectShowFileReaderを削除。
　代わりにL-SMASH Worksを追加。DLはPOP氏のサイトから。
●FlashPlayer11.2からはマゼンタ線が出なくなったため、
　10bit非推奨の理由を「GPU再生支援が効かない」に修正。
　視聴にはほぼ影響ないけど微妙に色もおかしいという問題もある。
●一般会員の解像度上限は5/1から1280x720になったことを追記。
●ZeroWatch大画面モードでの基本解像度を追記。（原宿バージョンの記述も残した）
●プラグインにL-SMASH Worksの記述を追加。
　DirectShow File ReaderとMP4Pluginは記述は残しているが非推奨に。
●x264guiExのビットレート計算機の説明とスクショを追加
●x264guiExの設定とスクショをv1.43対応に更新。
●H.264 Levelの指定は冗長なので削除。
●参照距離(--ref)に関して、大百科記事「動画がおかしくなる方は大百科をクリック→」への参考リンクを追加。
●「キーフレーム間隔の上限」はv1.43で追加された
　　　「-1を指定するとフレームレートの10倍を自動設定する」
　という機能を推奨。
●シングルパスの設定方法を表から削除。

結局Zeroがどうなるのかはっきりと分からないから今どうするかって結構微妙なのよね
そもそも容量とかビットレート上げてくれないと・・・

>>188
乙乙！

容量ビットレート上げるなら投稿容量が月1GBじゃ少な過ぎる

100MB/fileの方がきつい
せめて、300MBまで上げてくれ

たしかに他の動画サイトもどんどん高解像度・大容量化してるしニコニコもそのぐらいまで上げてほしい所

macはスレチかもしれませんが、h264でエンコードした動画ファイルが汚すぎて視聴に耐えうる物にならないんです

　　１．問題点:対戦格闘ゲームの動画なので動くと荒れて見れた物じゃない
　　２．元ファイルの情報 :すみません出先の為情報がないのですが、25分近い動画です
　　３．エンコードして出来上がったファイルの情報 :これも出先の為詳細がないです。
　　４．ソフト:FinalCutProX + Compressor4
　　５．MP4ならば必要に応じてx264のエンコードオプション:これも不明です、すみません
　　６．PC環境:MacBookPro15.4inch,2011early
VRAMは1GBです

どなたか解決策をご存知の方いらしましたらよろしくお願い致します。

いや・・・うん・・・

画質をよくするだけならビットレートでも上げておけばいいと思うよ

>>194
ファイルサイズ100MBになるようにビットレート限界まで上げたのですがダメなんです
止まってる時は綺麗なのですが、動くと崩れるので設定でもう少し改善出来るのかなと思ったのですが・・・
compressorの設定でフレームコントロールをオンにして、デインターレースを高品に、レート変換を動き補正にして試してみましたがあまり変わらず・・・

情報が少な過ぎてなんとも言えないけどリサイズはしてある？
25分もあると500kbpsも振れないだろうから512x384（16:9なら640x360）に縮小して
それでも不満があるなら動画を2か3分割ぐらいにした方がいいんじゃないかな

>>196
ビットレートが1Mbpsはないときついかと
分割するか、画面サイズを縮小しろ

>>197
リサイズは640×360でしてます

>>198
ビットレート1Mは必要なんですね・・・

もしかしてリサイズ前の画面サイズも640×360にした方が綺麗になるものなんですかね？

それなら8分刻みぐらいで分割して100MBのファイルを3つ作るのがよさそう
撮影する時は原寸のままがきれいに仕上がると思う

>>194
>>172

ここでは常識かもしれないけど、ずっと困ってた問題が解決したので一応書いておきます。

1080P/60fpsでエンコした動画を、ニコ動でGPU支援オンで見るとガクガク。
支援オフなら50-55fpsくらいは出てるけど、VLCプレイヤーで見るよりfpsが落ちてる状態だった。
それで仕方なく説明文にGPU支援オフ推奨と書いてたんだけど、試しに2048x1152/60fpsで
エンコしてみたら、支援オンでもプレイヤーで見るのと全く同じヌルヌル感になった。

解像度が上がってるから再生負荷も上がってるはずなのに、どうしてこうなったのかな？
経験上、どうも1080P近辺の解像度だけ支援オンでガックガクになるんだよね。

何も解決してない気がするのは気のせいだろうか。
エンコオプションやエンコしたファイルの詳細情報も書いてないし
1080pの60fpsはニコ動にはオーバースペックだと思うのでどうでもいいけど。

確かに解決してないですねｗ
偶然答えを見付けたけど、解けた理由が分からないという感じでしょうか。
エンコオプションはこれまで色々試したけど駄目で、ヤケクソで解像度を上げてみたら
なぜか問題が無かったから不思議なんです。

>>205
どんなGPU使ってるのか知らないけど、2048x1152の時はGPU再生支援が効いてないんじゃないの。
DXVACheckerの「デコーダデバイス」で見た時に、H264系の最大解像度が1920x1080までになってるとか。
実際にハードウェアアクセラレーションが効いてるかどうかは、DXVACheckerでトレースログとればわかるから、
とりあえずちゃんと効いてるかどうか確認したほうがいいんじゃないかね。

再生支援について詳しいわけじゃないけど、エンコオプションによってH.264 Levelも変わってくるし、
>>204に書いてあるように、質問するなら自分から情報出さないと駄目だと思うよ。

6/8にリリースされたFlashPlayer11.3.300.257の挙動について。>>9の続きみたいなもの。
なんかまた変わってるっぽいのですが、正しいかどうか追加検証をしていただけるとありがたいです。

【ハードウェアアクセラレーションOFF時】
　　●colormatrixやfullrangeを反映するようになった。指定無しの場合はBT.709のTVレンジとしてデコード。
　　　 （11.2では両方とも無視してBT.601のTVレンジとしてデコードしていた。11.3では11.1の時と同じ挙動に戻ったことになる。）
　　●deblockが有効になっている動画で映像崩壊が起きることがあるという問題はそのまま。
　　　 （なお、この問題はハードウェアアクセラレーションONの場合には発生しない）
　　　　　　ttp://www.nicovideo.jp/watch/sm17278404

【ハードウェアアクセラレーションON時】
　　●colormatrixやfullrangeを反映するようになった。指定無しの場合はBT.709のTVレンジとしてデコード。
　　　 ハードウェアアクセラレーションOFFの場合と同じ挙動になった？
　　　 （★ONの場合は、かなり前からcolormatrixもfullrangeも無視してBT.601のTVレンジとしてデコードしていたはず。）

【その他の既知の問題】
　　●10bit-depthのH.264をデコードすると色が微妙におかしいという問題はそのまま。
　　　 11.1まで出ていた右側のマゼンタ色の縦線は11.2で出なくなったし11.3でも出ない。
　　　　　　ttp://www.nicovideo.jp/watch/sm16808896

【色空間テスト用動画リスト】
　　ttp://www.nicovideo.jp/mylist/27805122

なお、ハードウェアアクセラレーションONの挙動を確認してもらった環境は以下のとおりです。

【OS】Win7 Home Premium 64bit (英語版)
【CPU】i7 860
【GPU】GeForce GTS 240
【ブラウザ】IE9
【FlashPlayerのバージョン】11,3,300,257

x264guiExの作者であるrigayaさんが、FlashPlayer11.3でのcolormatrixとfulrangeの扱いを検証して下さったようです。

　　rigayaの日記兼メモ帳 FlashPlayerもついにまともになったようだ
　　http://rigaya34589.blog135.fc2.com/blog-entry-240.html

>>207-208にも書いたように、11.3では、ハードウェアアクセラレーションのON/OFFに関わらず、
　　●colormatrixもfullrangeも反映する
　　●指定がない場合はBT.709のTVレンジ(圧縮レンジ)としてデコードする
という挙動になっているようです。

そんでもって、>>207-209を踏まえて考えると、【オススメ設定を変えたほうがよいかもしれない】のですよね。
現在は
　　「BT.601で出力して、colormatrixにはsmpte170mを指定する」
というのを勧めているわけですが、こうしていたのは、
　　「FlashPlayerはハードウェアアクセラレーションONの時は強制的にBT.601でデコードするから」
というのが理由でした。（OFF時はcolormatrixを反映するので、これによりどちらでもBT.601で正しくデコードできた）

しかし、11.3で>>209のような挙動に変わったことを考えると、話は少し変わってきます。
ポイントになってくるのがエコノミー動画の扱いです。
サーバー側で生成されるエコノミー動画では、colormatrixもfullrangeも指定されていません。
そのため11.3では、「どのエコノミー動画もBT.709でデコードされる」ということになります。
つまり、「BT.601でエンコードした動画のエコノミー動画は、11.3での視聴時に色が変わってしまう」ということになります。

つまり、「11.3で、エコノミー動画での視聴も含めより多くの人に正しい色で見てもらうこと」を考えた場合、
　　「BT.709で出力して、--colormatrix bt709をつけてエンコードする」
というのが、よりよい設定だということになってきます。
（ただし、PlayStation Vita等、強制的にBT.601デコードする端末については色が変わってしまうことになりますが。）

・・・しかし、最近のAdobeを見てると、11.3の挙動で安定するのかどうかちょっと不安なんですよね・・・。
どうしたものか。

あとは、AviUtlの色変換の設定はデフォルトがBT.601なんで、もしBT.709にするってことになると
そこの設定を忘れてBT.601出力にしたまま--colormatrix bt709にする人も増えそうかな〜みたいな。
まあそこまで心配してもどうしようもないかもしれんけども。

「そのときのニコやFlashに確実に合わせる」ならいろいろ考える必要あるんだろうけど

ファイル自体の汎用性考えたら本体の入出力もGUIExの設定も全部自動でよくね?　情弱意見ですまんけど

>>212
考え方によるよね。両論併記ではどうか？初心者には混乱の元かな？

あれ自動にしてたら画面サイズで変わるんだっけか
ややっこしいなあ

エコノミーの事なんて考えてないからこれからもBT601でいくわ
低ビットレートで充分な時は回避するし

うわぁ・・・
じゃあニコニコでほとんどを占めるSDサイズの動画は
かなりの効率で色がおかしくなるのか・・・
ある意味以前よりひどくね？
またadobe・・・

>>216
色々勘違いしてると思う。SDサイズとか関係ない。

TV番組等をローカルに保存することを目的とする一般的な動画のエンコードでは、
「SDサイズならBT.601、HDサイズならBT.709にする」というのが定番だけど、
ニコニコ向け（というかFlashPlayer向け）のエンコードでは、
「HDだろうがSDだろうがBT.601にする」というのがこれまでの推奨設定だった。
colormatrixをつけるのも推奨されていたから、ちゃんとそうしていたなら通常動画は11.3でも別に問題ない。
エコノミー動画の多くは色が通常動画とは少し変わって見えると思うけど、気づかない人も多いかもね。

エコノミー全滅か・・・

何か視聴に耐えない程に色がおかしくなると勘違いして無いか？

何気なく見てるだけなら、色空間の違いに気づく人は少ないというかほとんどいないだろうね。

「意図したとおりの色で見てほしい」という投稿者はどうすればいいかというお話ですわな。

ここに書く事かわらないけど色空間の話題が出たから

普段AMV3（YV12）で撮った動画をソースに使ってるんだけど
どうもHD解像度(720p)で撮った動画も色変換にBT.601を使ってる気がする
サイト見ても特に書いてなかった気がするけどその辺調べた人っていたりするかな

>>221
使い方によって変わる。
　Case1　AMV3にRGBデータが渡された場合は、AMV3がRGB→YV12変換を行う。
　　　　　　この場合は必ずBT.601の変換式が使われる。解像度も関係ない。
　Case2　AMV3にYUVデータが渡された場合は、AMV3はそのYUVデータをYV12形式にするだけ。
　　　　　　渡されたYUVデータがBT.601ならBT.601になるし、BT.709ならBT.709になる。

Case1の例としてはアマレココが挙げられる。
Case2の例としては、アマレコTVでデバイスからの入力フォーマットがYUY2・UYVY・HDYCの場合が挙げられる。

AviUtlでAMV3を使う場合は、ファイル→環境設定→コーデックの設定で、AMV3のところで
「YUY2で圧縮する」にチェックが入っていればCase2になるし、チェックが入っていなければCase1になる。

これはAMV3に限らず、AMV2や、UtVideoのULY2、ULY0、Huffyuvでも同様。
一般的に、コーデック内部でのRGB⇔YUV変換はBT.601となっているものがほとんど。
もしかするとBT.709を使うコーデックもあるかもしれないけど、少なくとも自分は知らない。

あー、ごめん>>222にちょっと補足。

＞これはAMV3に限らず、AMV2や、UtVideoのULY2、ULY0、Huffyuvでも同様。

AMV2とHuffyuvはYUV圧縮だけじゃなくRGB圧縮モードもあるので例としてはあまり適切じゃなかった。
これらについては「YUV圧縮する場合」のみの話ととらえてくれい。

>>222>>223
なんとそうなってたんだ、しばらく疑問に思ってたことがやっと解けた
例も分けてこんなに詳しく解説してくれて本当にありがとう！

念のため確認しておきたいのですけど、
　　・FlashPlayer11.3.300.257
　　・ハードウェアアクセラレーション有効
という状態で以下の２つの動画を見た場合、どちらの動画が正しい色で見えますかね？
（ハードウェアアクセラレーション無効ならBT.709のほうが正しく見える）

　　【色空間テスト】640x360 BT.601 colormatrix無し
　　http://www.nicovideo.jp/watch/sm18077634

　　【色空間テスト】640x360 BT.709 colormatrix無し
　　http://www.nicovideo.jp/watch/sm18077675

>>207で示したテスト動画リストは1920x1080サイズで、そちらはBT.709のほうが正しく見えたようなのですけど、
まさか指定無しの場合に解像度でBT.601とBT.709を区別してるなんてことはないよなあという確認です。
自分じゃ試せないもので、どなたか確認してみていただけると助かります。

>>225
少しでも恩返しを

＞FlashPlayer11.3.300.257
＞ハードウェアアクセラレーション有効
の状態で確認したところ>>225の動画もフルHD動画（のcolormatrix無し）も
BT.709が鮮明な（おそらく正しい）色、BT.601が黒っぽい色の動画に見えました

>>226
ありがとうございます。別の方からもBT.709のほうが正しく見えたと報告いただけましたし、
やはりcolormatrix指定無しならば解像度に関わらずBT.709でデコードということであってるようですね。

640×360の撮り貯めた写真集をニコに投稿しようと思うけど
写真の場合ビットレートはどのようにしればいいでしょうか？
普段動画の時は綺麗さと重さを考えて1200〜1500程度にしています。

写真なら移り変わる時間によるが1枚5秒程度なら100kbpsもあれば充分過ぎる画質になるんじゃない?

写真ならとりあえずcrf23ぐらいでエンコしてみれば？
wikiだと2pass推しだけどある程度慣れたらこっちの方が断然綺麗で低容量

>写真ならとりあえずcrf23ぐらいでエンコしてみれば？
crfというものを知らないけど
普通の動画と同じエンコじゃまずいの？
音楽付きだからビットレート1200ぐらいでエンコードしようと思ってたけど

解像度640×360　一枚5秒から8秒程度　音楽付き

スライドショーはビットレート低くてもいける
とりわけ640x360みたいな（画像集としては）超低解像度なら
ためしに600くらいでテストエンコしてみたら？
たぶんそれで十分

>>231
crfというのは指定した品質（画質）になるようにエンコするモード。
（23がデフォルトで数値を下げるほど綺麗）

エンコ対象の映像が圧縮しづらいものなら品質を維持するために自動でビットレートを上げるし、
圧縮しやすいならビットレートを下げる。

どのくらいのビットレートにするか迷うならcrfでエンコして結果40 or 100MBに収まればよし、
収まらなかったら40 or 100MBに収まるように今度はビットレート指定でエンコし直せばいい。

という事を>>230は言いたいと思われ

動画ごとに2passのビットレートを決める参考に品質基準VBRでやることあるな。

>>233が言いたい事を全部言ってくれたありがとう

最初からslow-firstpass trellis 2のキメ打ちじゃいかんのかそれは

で、fullrangeって何？
おいしいの？

>>236
「ビットレート指定の自動マルチパス」と「品質指定の品質基準VBR」は根本的に異なるもの。
>>233と、まとめWikiの「拡張 x264 出力（GUI）の設定項目とその機能について」のページをよく読もう。

Wikiではビットレート指定の自動マルチパスが推奨されてるけど、これはニコニコ動画では
ビットレートやファイルサイズに上限があるためやむを得ずそうなっているだけ。
TV番組の保存などを目的としたエンコードでは、「これくらいの品質で記録しよう」ということで
品質基準VBR（--crf）でエンコードするのが一般的。

ビットレート指定だと自分でビットレートを指定しなきゃいけないわけだけど、プレミアム会員の中には、
「目安がわからないし、とにかく高画質にしたい」という理由で無駄に高いビットレートを指定する人もいる。
その結果、
　　「実際には500kbps程度で十分綺麗なのに、無駄に5000kbpsと指定した結果、大して画質は変わらないのに
　　　ファイルサイズが10倍になり、視聴時の読み込みも遅く、再生負荷まで高くなる」
という、ほとんど誰の得にもならない、むしろ害悪な動画ファイルが出来上がることもある。

品質基準VBRならば、とりあえず品質（--crf）の値を20〜23くらいにしてエンコードすれば、
ニコニコ動画向けとしては十分綺麗な画質になり、ビットレートもその画質に見合ったものになる。
無論、「複雑で動きが多く解像度が高い映像」の場合はかなり高いビットレートになってしまうし、
ファイルサイズ制限を越えてしまうこともあるので、その場合はビットレートを抑えてエンコードしなおす必要があるが、
そうでないなら驚くほど低いビットレートで済むことも多い。スライドショーなんかは特にそう。

ニコ動などで色々な人に見てもらうには、画質だけでなくファイルサイズとのバランスも重要なので、
適切なビットレートを探るためにも品質基準VBRのエンコードを試みてみるとよい。

自動マルチパス
・ほぼ指定サイズに収まるためエンコードが1回で済む
・動きの少ない所では無駄にビットレートを消費し、動きの多い所では足らずに画質が落ちる

品質基準VBR
・エンコードが終了するまでサイズの予想が付かない
・画質が一定なので動きの少ない場所でビットレートを節約し、多い所に割り振ってくれる
→ファイルサイズが同じなら自動マルチパスよりも高画質な動画になり、同じ画質ならファイルサイズが小さくなる

>>239
間違ってる。

＞・動きの少ない所では無駄にビットレートを消費し、動きの多い所では足らずに画質が落ちる

これはシングルパス固定ビットレート指定の場合でしょ。
自動マルチパスは１パス目の解析結果をもとに適切にビットレートを割り振る。

>>239
違う。同じビットレートなら品質基準vbrよりもslow-firstpassを使って2passした方が綺麗になる。
ビットレートが充分な場合は品質に準拠してもそれと同程度のビットレートを割り振った2passでもほとんど変わらないが問題はビットレートが不足するような場合
品質基準vbrの場合全体を見ずに出力するのでサイズに余裕がないのに馬鹿みたいにビットレートを取る場面が出てくる。
slow-firstpassを付けたabrの場合は最終出力と同じ設定で1pass目の解析を終えているので全体的に人間の視覚上よりよく見えるように配分してくれる
例えとして動画ファイル全体を1枚の絵と見たてると2passは自動的にaq strangeを最適値にあわせてくれるようなものでファイルサイズ比の見てくれを良くしてくれる
ただしslow-firstpassを使わないと最終出力と同じ設定で解析をするわけではないので使った場合に比べ全体の品質が落ちる

マルチパスは限られたビットレート内で最適な圧縮をするものであって
基本的にほぼ固定ビットレートな動きをしてたと思うんだが変わったんかな

すまない
avinapticを使ってグラフを見てみたらマルチパス動画も普通にビットレート変動してた
どうもエンコード中に出てくるkbpsを見て勘違いしてたみたいだ

翻訳解説

CRFは区間の複雑なシーンやシンプルなシーンのバランスをqcompで調整し、必要に応じてビットレートを分散します。
複雑なシーン、またはハイモーションシーンのフレームの品質を減少させることによってこれを実現します。
一定の区間は入力fpsやtcfile-inによる？

CRF = CQP + AQ + QCOMP.
qcomp = 1はmbtree = 0と同義です。

ABR、別名平均ビットレート
シングルパスモード。設定したビットレートに応じてサイズを与える。このモードでは、CRFと同じくらい速いです。
しかし、ビットレートの差異は限られています。

2パスVBR
このモードでは、特定のファイルサイズにエンコードすることができますがビットレートの分散が
限定されるものではないので、画質はABRよりもはるかに高いです。
2パスの最初のパスはターゲットビットレートを目標にするための解析に必要です。

--trellisは、基本的にはAQの逆の効果があり、フラットで、滑らかな領域からビットレートを奪うことにより
圧縮を向上させます。
Psy-Trellisは、基本的に同じことを行いますが、圧縮が向上することはありません。
ディテールとテクスチャからビットレートを取って、エッジなどでそのビットレートを使用しています。
Psy-RDと同じように、この設定が高すぎると、アーティファクトが発生する可能性があります。

Psy-RD、この設定は、ディテールやグレインのシャープネスを向上させる。

PSY RDOの評価は、通常のPSNR単位歪みに加え、再構築されたフレーム間での複雑さの違い
（ビデオのデコードにどのように見えるか）とソースフレームも含みます。

ディテールが画面全体の鮮明度？
エッジがピクセルの境界線？

撮った動画の実fps値を測定できるツールはありませんか？
処理の重いシーンなどでフレームレートが落ち込んだりしている時のfps値等が知りたいです。

--slow-firstpassってプラシーボじゃなかった？

テンプレ読め

ニコエンコでエンコした動画は正しい色が出ますか？
以前は使ってたので…

>>16
恐ろしく亀だがiPhoneでは元々ref 16の動画は再生できない｡プレイヤ自体が弾いてるのでどうやっても無理

>>241 >>246
slow-firstpassは効果はあるけど実際には誤差程度しか変わらないという話だった気がする。

>>248
v0.77だったら一応colormatrixがついてるので大丈夫だけど過去バージョンは知らない。
もう使ってないようだけど念のため言っておくとニコエンコの使用は非推奨。

>>249
大百科の記事によると「ニコニコ動画iPhoneアプリ4.20に更新すれば再生可能」らしいけど。
　　http://dic.nicovideo.jp/id/4131469

昨日のやり取りを眺めてたけど

スライドショーや紙芝居、アニメみたいな動きの少ない動画は品質基準VBRが小さく仕上がる
ゲームや実写みたいな動きの多い動画は自動マルチパスが画質を考えつつきっちりサイズ内に抑えられる
ってことでいいのかな

高ビットレートの2パスとCRFを比べても画質の違いは少ない
ビットレート制限があるけどビットレートに余裕があるならCRFで済ませても良いだろう

じゃないか？

2Passで静止画なんかに明らかに必要ないようなレート指定してエンコードしてもその数字になるの？
自動的に下がる？

自動的に下がる

ありがと
なら別にCRFでなくてもいいんじゃないの
もちろん視覚上あまり必要ないレベルでの余計なレートは食うかもだけど

>>253
まさにそれをﾃｽﾄとしてやってみたことがあるけどビットレート下がるよ

以前x264のqpmin qpmaxのデフォルトが10 51から0 69に変更になったとき
「非常に単純で低解像度の静止画」をあえて--qpmin 10 --qpmax 51 --bitrate 274でやってみた時のログ

　エンコ時にログに黄色文字で警告とエラーメッセージが出た。(下段は訳)

x264 [warning]: Error: 2pass curve failed to converge
　　　　　　　　　　エラー: 2passカーブは収束に失敗しました
x264 [warning]: target: 274.00 kbit/s, expected: 222.76 kbit/s, avg QP: 10.0011
　　　　　　　　　　目標: 274kbps 期待値: 222kbps 平均量子化値: 10
x264 [warning]: try reducing target bitrate or reducing qp_min (currently 10)
　　　　　　　　　　目標ビットレートを減らすか、qpminを少なくしてください (現在は 10)

平均ビットレートがより小さくなりファイルサイズが縮んでた。

余談だけど2passで逆に「明らかに内容に対して足りてない」ビットレート指定でやると
平然と(何のメッセージも出さず)5%くらいは目標値オーバーするよ
(--bitrate以外のビットレートに関する指定がないとき)

>>255
そりゃ、黒い静止画が続くだけの映像に自動マルチパスで1000kbps指定したような場合は
数kbpsに落とされるのは確かだけど、それなりに動く映像の場合は、まさに
　　「視覚的にあまり必要でないレベルでの画質を上げようとして無駄にビットレートを割り振ってしまう」
というのが問題なわけで。

ファイルサイズ制限ギリギリのビットレートを指定して自動マルチパスでエンコードするのが一番綺麗になることは間違いない。
ただ、それと引き換えに、無駄にファイルサイズがでかくて再生しにくい動画が出来上がることもある。

品質基準VBRを試してみるメリットは、
　　「ある程度の画質を保ちつつ、ビットレートは必要十分な程度に抑えることができる」
という点にある。つまり、
　　「適切なビットレートがわからない場合でも、画質とファイルサイズのバランスがとれたファイルを作ることができる」
ということ。
シングルパスで済むのでエンコード時間が短くて済むというのもメリット。
ただし上限をオーバーしてしまうことがあるので、その場合は自動マルチパスでやり直さないといけない。

つまりあれか
CRFかVBRかでファイルサイズ上限にあわせて設定を
自動でどうにかできるようになれば最強なんだな

個人的オススメエンコードルート

とても複雑で常時動き回っているような映像ですか？
　│
　├→Yes →時間的に余裕がありますか？あるよね？まずは落ち着くんだ。
　｜　　　　　　　│
　｜　　　　　　　├→Yes →まずは品質基準VBRでエンコードしてみましょう。
　｜　　　　　　　│　　　　　　　　　　↓
　｜　　　　　　　│　　　　　　　　　★１へ
　｜　　　　　　　│
　｜　　　　　　　└→No →仕方ないなあ。じゃあ自動マルチパスでエンコードして投稿しましょう。
　│　　　　　　　　　　　　　　ビットレートは投稿条件の上限を守りつつも、上げ過ぎないように注意。(※)
　│
　└→No →まずは品質基準VBRでエンコードしてみましょう。
　　　　　　　　　　　　　　↓
　　　　　　　　★１　ビットレートやファイルサイズの上限は守れましたか？
　　　　　　　　　　　 また、ビットレートは高すぎになりませんでしたか？(※)
　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　├→Yes　→そのまま投稿しましょう
　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　└→No　→自動マルチパスで上限を守って適切なビットレートになるように
　　　　　　　　　　　　　　　　　　　　　 エンコードしなおして投稿しましょう

2passにあって品質基準にないものは何？

ビットレートを規定値以内に抑えられる。
さらに、このことで最終的な容量も予想できる。
品質基準だと動画によってまちまちになる。

高画質動画の場合、ビットレートが高いと低スペＰＣだとカクつくとかってのがあると聞くので
プレミアムであってもそれを気にする場合は、容量オーバーしてなくてもビットレートを抑え目に設定したりする。

エコノミー回避のために黒ベタ追加した動画をエンコする時ってひょっとして2passでもよかったのか

>>263
用語を間違えてるだけかもしれないけど、黒ベタ(枠)を追加する必要があるのは、
素材動画のアスペクト比が１６：９または４：３になってない時だけだよ。

エコノミー回避というかビットレート確保のために動画の最後に黒画面が連続する映像を付け足すのは黒ベタとは言わない。
この場合は普通は２パス（自動マルチパス）を使うと思うけど。

2passと品質基準でまったく同じサイズのファイルができたら
それはまったく同一品質ということでいいの？

2passは目標qpが勝手に決まる
品質基準はビットレートが勝手に決まる

ってだけの違いだよね？

あー、>>259に「数分程度の動画なら」という条件書くの忘れてた・・・。
あと、ちょっと品質基準VBRをプッシュしすぎた気がする。
「動きが少なめの動画に無駄に高いビットレートを振るのを防ぐ」というのを狙ったんだけど
素材次第では逆にこれまで以上のビットレートで投稿する例も増えちゃうかな？
　　・どのくらいの品質を指定するのか
　　・「ビットレートの上げすぎ」とは具体的にどれくらいのことか
とかの要因にもよるけど、なかなか単純には言えないから難しいね。(´･ω･`)

>>264
ああ黒画面だったかありがと
今までずっと品質指定でやってたのよ

翻訳解説

2パスエンコードの利点の一つは、あなたが2回目のパスの結果が気に入らなければ、
設定を変更して、別の2回目のパスを行うことができるということです。

いくつかの設定は、2回目のパスで変更することはできません。
number of b-frames, b-adapt, weighted b/p-frames, no-fast-pskip, rc-lookahead and enabling/disabling mbtree.

どうせみんな自動マルチパス使ってるんだからその説明いらない

avinapticで検証してみた

マルチパスの場合、PBフレームのqp値は一定にならず、ある程度上下する
常に動きのある映像の場合、動画の最後のほうのqp値が低下する(画質が落ちる)場合がある※未検証
品質基準VBRだと、vbv-maxrateとかを使わなければPBフレームのqpはずっと一定になる

それはavinapticがmbtreeに対応してないからじゃなかったかな

fullrange使ってる？

エンコードというかその後？の編集の質問なんですが
Aviutlで出てきた動画をウィンドウズムービーメーカーで読み込んで字幕をつけたんですが
いざ出力しようと思ったらそのまま出力するという選択肢が無くて困っています
字幕だけつけてぽいっと出してくれると思ったら・・・181MBの動画を入れたのに1.65GBで出てきましたorz

Aviutlの拡張編集でも字幕付けられるよ。

FlashPlayerを最新版にしてからFlavieの挙動がおかしくなって悲しい

>>274
基本的に編集→（ニコニコ用）エンコードだよ。
劣化が少ない状態で全部作り上げてから、最後に規格に合わせてエンコードをしてやる。

>>276
FlashPlayer11.2くらいからおかしくなっちゃったよね。
１つ目の動画を再生した後、２つ目の動画をD&Dしても映像が出てこないとか。

今のエコノミー回避って445になったんだよね？
それで出して回避して画質テストしてる人のも結構みたけど、
?eco=1を入れたら低画質モードになりますって出てるんだけど、
それって失敗してるってこと？それとも原宿じゃなくてZeroのみ445？

>>279
2012/4/19から、エコノミー回避していても低画質動画が生成されるようになった。
　　iPhone,PS Vita等での動画再生の向上について‐ニコニコインフォ
　　ttp://blog.nicovideo.jp/niconews/ni031570.html
そんでもって、?eco=1をつけると、低画質動画が再生されるようになっている。
エコノミー回避時の低画質動画生成の挙動については>>40を参照。

エコノミー回避の基準は原宿もZeroも関係ない。
エコノミー回避（445kbps以下）にして投稿すれば、PCからの視聴なら、
一般会員のエコノミーモード時間帯でもオリジナル動画を再生できる。
（生成された低画質動画が使われるのは携帯端末からの視聴時のみだと思われる）

まあ要するに「?eco=1で低画質モードと表示されるかどうか」というだけでは
エコ回避の成功/失敗を判断することはできなくなっている。

投稿直後に?eco=1で再生してみて「低画質モードで再生します」の表示が出なければ成功しているが、
低画質動画がすぐに生成されていた場合は「低画質モードで再生します」の表示が出てしまうこともある。
心配であれば、投稿した翌日くらいのエコノミーモード時間帯に?lo=1(一般回線で視聴)で再生してみて、
そのときに「低画質モードで再生します」の表示が出ていなければエコ回避に成功している。

なるほど。ありがとうございます。
でもすぐには500再生いかないと思うので
一般回線で見ても変わらないかもですね。
500再生超えたころにエコノミー回避出来てませんでしたってのは悲しいし。。。
回避して良い画質にする術もないんですけどね。
ありがとうございました。

Ｏｈ．．．．500再生のこと忘れてたアルよ・・・うっかりしてたごめん。
投稿前にしっかり実ビットレートを確認しとかないとダメね。

mediainfo使えばええやん

mediainfoじゃ実ビットレート分からんやん

じゃあ実容量/動画時間を計算すればいいじゃん。この上無く正確だぞ

それぞれ1分の、flvファイルA・Bを、「Moyea FLV Editor Lite」で結合しました。
結合したファイルを「aviutl」の「Libav-SMASH File Reader」プラグインで読込→
エンコ。
エンコ完了ファイルを再生すると、元ファイル「A.flv」の長さ分しかありません。
（結合したファイルは、「ひまたんぷれいや」で問題なく2分再生できています）
どんな原因が考えられますか？

aviutlでflv読み込めるなら、aviutlで結合すればいい。
２つのスコトを使うから変なことになる。

スコトって。。。
「ソフト」の間違いです

>>287
flvファイルの前後数秒をカットしたくて、「FLV Editor Lite」を
使ったのですが、タイムコード関係のエラーですかね…。
数秒カットはあきらめ「aviutl」の「追加読み込み」機能で問題なくできました。
どうもでした。

AviutilでFlvファイル読み込めるのなら
拡張編集を使えばカット編集もできるだろ。
Aviutilの本体側で動画を読み込むんじゃなく
設定＞拡張編集の設定で開いた窓に動画を放り込んでやること。

まあカット編集だけなら本体で普通にできるけどね。

非可逆圧縮で録画したものをmp4に変える際に
かなり画質が低下してしまいます。
ビットレート等は上げ下げしてみましたがあまり関係なかったです。

ニコニコに出ているものや、DVDのものをエンコードする際には
そこまで低下していないように感じるのですが、原因は何があるでしょう？

今のところ勝手な憶測ですが、
24bit→8bitになることによる劣化なのではと考えていますがあってますでしょうか？

まず元ファイルの解像度、フレームレートと、
エンコ後の動画の解像度、ビットレートの情報が無いと何も言えん

とりあえず「24bit→8bit」の部分は確実に間違ってるけど、
真空波動研の情報でいいから出さないとなんとも言えんよね。
「かなり画質が劣化」と言うほどならエンコ前後の画像比較サンプルなんかもあるといい。

失礼しました。ありがとうございます。
元々１００MBの制限から画質が劣化してしまうのは仕方ないのですが、
もう少し設定を煮詰めることができる部分があるのではないかと考えておりました。

エンコード前
ID : 0
フォーマット : RGB
コーデック ID : 0x00000000
コーデック ID/情報 : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
ビットレート : 259 Mbps
幅 : 800 ピクセル
高さ : 450 ピクセル
解像度 : 16:9
フレームレート : 30.000 fps
BitDepth/String : 8 ビット
ビット/(ピクセル*フレーム) : 24.000
ストリームサイズ : 4.19 GiB (99%)

エンコード後
ID : 1
フォーマット : AVC
フォーマット/情報 : Advanced Video Codec
プロファイル : [email protected]
CABAC : はい
RefFrames : 3 フレーム
コーデック ID : avc1
コーデック ID/情報 : Advanced Video Coding
Duration_FirstFrame : -17秒
ビットレート : 780 Kbps
最大 : 1 993 Kbps
幅 : 800 ピクセル
高さ : 450 ピクセル
解像度 : 16:9
モード : VFR モード
フレームレート : 30.000 fps
最小 : 30.000 fps
最大 : 40.000 fps
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 ビット
スキャンの種類 : プログレシッブ(PPF)
ビット/(ピクセル*フレーム) : 0.072
ストリームサイズ : 12.9 MiB (100%)

どんな映像かにもよるがこれなら普通にビットレート不足じゃないかな。
「かなり画質が劣化」ってのがどういう劣化なのかによるし、x264の設定にもよるからなんとも言えないが

それより何故VFR？

非可逆圧縮で録画と言ってたのに無圧縮だし、100MBの制限と言いながらデータとして出してきたのは
130秒程度のサンプルみたいだし、どういうことなのかよくわからないね。
実際には15分くらいの動画を780kbpsでエンコードしてる状況ってことなんだろうか。
使ってるエンコーダーやソフト、それにその設定も不明だし、どんな映像なのかもわからないし。
既に指摘されているようにVFRになってるし、どういう手順でエンコードしてるのだろう。

そのＶＦＲも元動画が30fpsなのに
最大が40fpsって。。。。もうね。。。。

実際にはもっと長い動画です。、
エンコ練習用に非可逆圧縮のものを別ソフトで無圧縮で書きだしてます。
VFRに関しても、練習用に短くしているから関係はないのですが、
実際には色んな動画を重ねて１５〜２０分のものを作ろうとしています。

実際ビットレート不足なのは否めないのですが、如何せん容量に制限があるので。
ですが、エンコ回避していても凄まじい高画質の動画なんかもあるので、
x264の設定もおかしいところがあるとおもいますが、私ではどこかはわかりません。

>>300
練習の時点でVFRになってるんだから問題ありまくりでしょ。根本的に何か間違えてるってことなんだから。
よく動く動画と、動きの少ない動画とでは必要なビットレートも全然違うし
>>298に書いたような情報をしっかり書いてもらわないと、こちらとしてもアドバイスしようがない。
そもそもx264を使っているかどうかすらもわからないレベル。
質問するのであれば、自分の状況を整理して正確に説明する努力をしたほうがよいかと。

MediaInfoの情報にしても、一部を切り出すよりも、>>1にあるpastebinを使うなり、
結果のテキストをどこかにアップロードするなりして全体を見せてくれたほうがいいです。

素人だからここで質問しているので、
自分の状況もどうすればいいのかわかっていないので正確に説明は無理です。
諦めます。
答えて下さった方ありがとうございました。

素人ならなおさら聞く前にいろいろ調べるべきではないだろうか

情報をなるべく詳しく出さないとエスパー以外答えようがないぞ

エンコード後の動画を提示してどの辺がどういう劣化しててどうしたいのかを説明するだけでかなり的確にアドバイスもらえるんだけどね

復旧age

せめてテンプレ読んでから質問してくれたらいいんだが

上でVFRの話あったけど、AVIUｔｌでx264guiEX使うと勝手にVFRにされると思ってたけど違うのか？

>>308
VBRと勘違いしてないか？

>>308
自動フィールドシフトとか使うならともかく、ニコニコ向けにエンコードしてりゃ普通そんなことはない。

ＣＤ音質（1411kbps）の動画を作成する方法を教えていただけないでしょうか？

画像・音楽などの素材は準備出来ています。
Aviutlで作成できると嬉しいのですが・・・

>>311
仮に作ったとしても無駄に重くて、再生環境によってはまともに再生もできず視聴者にとっても迷惑な動画になります。
おとなしくまとめWikiを見て普通にMP4を作ったほうがよいと思います。
　　ttp://nicowiki.com/aviutl_h264.html

音声ビットレートは192kbps程度でいいと思いますが、どうしても音質にこだわりたいなら
320kbpsくらいにしとけばいいんじゃないかと思います。
ただし、192kbpsと320kbpsとの違いがわかるかどうか、事前に自分で確認してみたほうがよいと思います。

WAV入りMP4が再生できないってのはローカルで再生する時の話じゃなかったか？
ニコニコ動画上で再生できないのには当たったこと無いが

>>313
FlashPlayerが使える環境なら大丈夫だけど、携帯端末とかじゃFLVは再生できないだろうな〜と。
もっとも高音質のMP4も再生できないかもしれないから、どのみち鯖エンコの低画質動画で見ることになるかもしれんけど。

スマホやVita等の端末でニコニコを見る場合って、なるべく元動画を再生しようと試みて、
端末のスペック上無理なら低画質動画になるっていう感じなんだろうか？携帯から見たことないのでよくわかんね。

vp6とwavをmuxすればいいんじゃないかな
CD音源丸上げを聞くような層は重いことを前提としてると思うけどwavなら負荷自体は少ないんじゃないだろうか
フラッシュプレーヤーの仕様はよくわからんけど

いまってもうflvだめなんだっけ

そうじゃなくて、
ビットレートが音声だけで1Mbpsを超えることになるから、読み込みが遅くなってしまうってことじゃないの
モノラル化やサンプリングレートを下げればビットレートを減らせるけど、そんなことやるなら320kbpsで圧縮したほうがいいし

>>312
可聴域については理解しています。
Aviutlを使用して普通の動画を投稿しているプレミアム会員でもあります。
でも1411kbpsの投稿が結構あってその方法が気になったんですよね･･･

aviutl＋FLV(VP6+MP3)出力プラグインで、音声設定の所でLame MP3やMPEG Layer-3ではなくPCMを選べば音声1411kbpsでの投稿ができる
mp4ではどうやっても無理

312〜317、319の皆さんありがとう。
作成することができました。

avc+alacのmp4上げられるがな

>>321
このスレのログを「alac」で検索して全部読め。

ああ、「かな」じゃなくて「がな」か・・・。上げたとしても音は出ないと思うんだが、そのへんどうよ。

すみません質問というかアドバイス願います。

レトロゲームの動画を60fpsで作成してアップしたら文字の移動がカクついたので
アップした動画を落とし直して確認したらカクつきませんでした。
何が原因か調べたところ、テンプレの>>8が正に該当していて。Flavieで元動画を確認したら
カクついてました。
そこでアドバイスもらいたいのですが、FlashPlayerで60fpsが実現できるかどうかと、
できる場合はエンコ設定のポイントを教えてもらえないでしょうか？

60fpsは普通にできる

単純にPCのスペック不足じゃないの
まずはPCのスペックとmediainfoで調べた動画の情報晒してみなよ

>>325
レスありがとうございます。
まずPCスペックは以下です。

CPU：Core i7 860
M/B：ASUS P7P55D-E
RAM：W3U1333Q-4G DDR3-1333 PC3-10600 4GBx2 (Elixir)
VGA：PowerColor AX7750 1GBD5-NH
DISK：X25-M Mainstream SATA SSD SSDSA2MH080G2R5
　　　：WD20EARX [2TB SATA600]

mediainfoは
http://privatepaste.com/f89e9d5396

です。
診断願います。

FlashPlayer自体は60fpsに対応してるけど垂直同期は取れてない
だからPCのスペックに関係なく多少のコマ落ちは生じる
特に文字のスクロールとかは目立つかもね

困っています
一般会員で現在60分程の作業BGM動画を作っていてつんでれんこで行ったのですが、出来上がった動画が見れないほどに悪くなってしまいました。
ちなみにつんでれんこでは限界ビットレートが77で音声を66映像を11に設定しました
そしてビットレートを音声を38映像を39に設定してみたところ容量オーバーしたというコメントが出てしまいました

どうすればいいでしょうか

その長さの動画を、一般アカで、分割しないでやろうとするのがそもそも無茶

>>328
どんな映像なんだか知らんけど、そんだけビットレート低けりゃ画質ひどくて当たり前じゃねえの。
容量オーバーについては映像と音声のバランス変えてやってみるとか少し低めを設定してやってみれば。
聞くまでもないことだと思うが。

fps下げてIフレーム減らせばいいだけだろ

60分の静止画の映像ではなくて動く映像を素材にすれば画質がひどくなるのは当たり前です
なので、静止画にする、時間を短くする、プレミアム会員になるのどれかか、
100MBのaviなどでサーバーエンコードの動画にする方法があります。

>>327
やはりFlashPlayerの進化や大体技術の台頭・浸透が無いと難しそうなんですね。
回答ありがとうございました。

>>333

HTML5に期待だね。

元動画の加工の、最初の段階でつまづいてる。

m2ts の元動画を加工しようと思ったんだけど、元動画にノイズ？　があるのか知らんが、うまくエンコできない。
　m2ts → mp4変換 　　　として再生すると、前半数十秒は問題ないが、後半から音声が途切れる
　m2ts → Huffyuv変換 　としてPowerDVD等で再生すると、最初に早送りみたいになって、その後静止画となり、音だけ流れる状態になる。
　　　　　　　　　　　　AviUtilで読み込んで見るとキチンと映像は入ってるのに・・・　

　　　　　　　　　　　　また、PowerDVDで見てみると、一応視聴可能ではあるものの、一時停止すると何故か「再生時間」の時分秒の値が、
　　　　　　　　　　　　再生中の時分秒の値と違う値を表示する。

これって元動画が壊れているってことですかね？
直す方法ないのかな。

あ、上の「また、PowerDVDで見てみると、一応視聴可能ではあるものの・・・」の一文は、
mp4に変換したファイルを再生したときのことです。

>>335-336
・元のm2tsはどうやって作成したものなのか
・m2tsつっても色々あるのでMediaInfoのテキストモードの情報
・変換に使ってるソフトとそのバージョン
・m2tsの読み込み方法（AviUtlであれば入力プラグインは何で、どのバージョン使っているのかとか）
・変換手順
・出来上がったMP4のMediaInfo情報

こういった情報がないとアドバイスできんと思う。

カンタアアアアアアア は、ニコエンコを使ったせいでビットレートが極端に過剰になりファイルサイズが巨大に。

リトバスの日常OPパロは、おそらくはニコエンコを使ったせいで512x288にリサイズされてしまい、
原宿でもZeroでも拡大再生されてしまいぼやけてしまっているという結果に。


余程の理由がない限り、ニコエンコを　使 っ て は い け な い　というのは、もっと周知していきたい。

　　ニコエンコとは - ニコニコ大百科
　　ttp://dic.nicovideo.jp/id/4131469

aviutlとguiexで充分簡単…
と思ってたんだが知り合いにskype越しに付きっきりで教えたんだが最低限出力させるだけでも大変だなこれ
〜がなくて動かない。入力フィルタって何?そんなの見たサイトに書いてなかったよ。出力したmp4が見られないgomなら開けた。とか
変に古い情報が溢れてるせいで非常に教え辛い

ニコエンコは使ってはだめだ、と言われるわりには
つんでれんこの周知があまり徹底されていない気がするんだが…
このスレのテンプレにすら入っていないというのは…
それとも他に選択肢ある？
guiexはハードル高いしな

guiexはまとめwikiの通りにやるだけで出来るんだから相当楽だと思うけどなぁ
文字の読めない焼酎は知らんけど

ニコエンコが更新でもされたらいいんだけどな

ニコエンコは、同梱問題もあるから・・・。

>>341
>guiexはまとめwikiの通りにやるだけで出来る
一年以上前に(ひどい場合はex以前の頃に)一度設定したまま、更新してない人とかもちらほら

>>344
先月の俺のことか

まあ古いからって大問題ってことも無いけどな
今のニコニコの仕様さえわかってれば多少ツールが古くたって・・・
・・・ではない人向けのWikiとかだったな

エンコードに関する質問

突然失礼します。
ゲーム動画をBandicamを使用してキャプチャしたもの（RGB24)を
AviUtlを使ってmp4ファイル（H.264コーデック）に変換し、
ニコニコ等のサイト上にアップロードしようと考えているのですが、上手くいきません。
（文字数制限の為以下連投失礼します）

>>346
続きは？

>>345
Flashplayerの仕様もコロコロ変わっているので、大問題ではないにしても注意が必要
(colormatrixの扱いとか、deblockのバグとか)

テンプレに必要かどうかはわからんが有用そうなリンク

ｘ264でのニコニコ動画用エンコードで注意すべき設定(AviUtl)
http://chround30.blog.fc2.com/blog-entry-24.html
ニコエンコ使っていなくても、preset veryslow を使ちゃうとref=16になってダメとか、keyintは-1にしましょう、とか
わかっている人はいいけど、古いwikiの記述を真似ただけでみたいな人向けの注意のまとめ

夏蓮根 (つんでれんこ改造版)
http://www43.atwiki.jp/tdenc/pages/21.html
つんでれんこに、ニコ動向けの品質基準VBRを追加したり、簡易GUIフロントエンドを付けたりしたもの

つんぷれ
http://www43.atwiki.jp/tdenc/pages/31.html
つんでれんこ等についている再生確認ツール部分を独立させたもの。
・ハードウエアアクセラレーションのオンオフ切り替えが出来る
・原宿サイズ、Zeroサイズでの実際の見え方が確認出来る
・ビットレート、ファイルサイズ等の情報が同じ画面に表示され、一目で分かる

>>346です。
文字数制限ひっかり続け規制食らってました。
問題点：
キャプチャ直後のものはWMPで再生・操作できるのですが、
エンコード後のものを再生中に再生ポイントが移動する動画下部に表示されるスライドバー？
の先の部分をクリックして再生ポイントを移動させようとすると、

「ファイルの再生中に Windows Media Player に問題が発生しました。」
というエラーが表示され、動画再生が終了してしまいます。
（ポイントをクリックしなければそのまま再生できます。）
Gomでは問題なく再生・操作ができました。

以前、二重変換？（MPEG-1→mp4）を誤ってしてしまった時同様の症状が出た為、
RGB24の設定でキャプチャしたファイル（AVI）に問題があるのかと思い、
色々調べてますが解決に至れません。

>>346です。
Bandicamのビデオフォーマット設定
　RGB24 Half Size 60.00fps 80q オーディオ　48.0kHz,stereo
AviUtlのバージョン：0.99i7

>>346
ニコニコ動画用にエンコしたmp4を、WMPで再生しても意味ない

>>348 のつんぷれ か、>>3 にある、Flavieといった、Flashplayerを使ったプレーヤーで確認するのが、まず最初

で、それでも問題があるなら、>>1 のテンプレ(x264のエンコードオプションなど) を書いてくれなきゃわからん

>>353
ありがとうございます　また規制でした；
AviUtlのエンコードオプション
--preset Medium --bitrate 993 --pass 3 --stats ".
\x264.stats" --aq-mode 2 --aq-strength 0.05
--min-keyint 1 --direct auto --me esa --subme 9 --output nul

撮影直後のファイルをMediaInfoに入れてみた結果
　コンテナと全般情報
　AVI(OpenDML):30.0GiB,7分 46秒　使用したエンコーダ：BandiAviMuxer1.0
　１ビデオストリーム：RGB
　１オーディオストリーム：PCM

上記ファイルをAviUtlでH264動画にエンコードしてみたもののMediaInfoの結果
　コンテナと全般情報
　MPEG-4(Base Media):62.5MiB,7分 46秒
　１ビデオストリーム:AVC
　１オーディオストリーム：AAC

>>346です。

情報が足りなかったらすみません；
文字数制限と規制との戦いで連投＆長期にわたってしまい申し訳ありませんでした。

以上の内容で何か解るでしょうか？必要な内容ありましたら教えてください！
お願いします。

>>357
１．>>353氏が書いているように、まずは>>3の「Flavie」、または>>348の「つんぷれ」で再生してみるように。
　　それで問題が起きるかどうかを確認する。問題ないならアップしてしまっても構わないと思う。
　　問題があるならまたあらためて質問してください。

　　なおFlavie等で問題なかった場合、WMPで問題が起きるのは再生環境が原因である可能性が高い。

２．あなたが使っているAviUtl本体とMP4出力プラグイン(Seraphy氏のx264gui)は、かなり古いものです。
　　できればニコニコ動画まとめWikiを見て、最新のAviUtl本体＋rigaya氏のx264guiExに変えたほうが
　　トラブルも減るし、色々と便利になっています。
　　　　　http://nicowiki.com/aviutl_h264.html

>>358
ありがとうございました！
ちょっとインストールしてチェック＆本体も新しいものに変えてみます。

ニコニコ生放送のタイムシフトを StreamTransportでダウンロードしました
flv 512×288 16:9です
これをFreemake Video Converterで不要な部分をカットして小さいサイズにしたかったのですが、
内容をカットしてもサイズは1.5倍くらいになってしまいます
サイズも小さくなるようにカットできないでしょうか？
画面サイズを変えればいいんでしょうか？

動画についてなんですが、設定をミスってしまったので修正したいのですが、
元データがない場合にエンコ済み動画を再エンコしても修正は利かないんでしょうか？
修正したい箇所は--refと--bframesです

劣化するができる

>>362
ありがとう
再エンコしてうｐしてみます

なにを言ってるのか分からないかもしれないけどスマソ

画面下部字幕つきの実写動画をAviUtlでMP4（ニコ一般500kbps程度）にするのに
x264.exeとGUIを現時点での最新に変えてから旧バージョンと同じパラ渡したら
字幕以外、動画のほうが動きの多い部分でフォトショのスポンジフィルタ掛けたみたいになるんだけど

なんか処理方法が変わったのかそれとも設定項目増えた？
これってダウングレードしたほうがいいのかな

旧（2011年6月辺りの？）：字幕と背景動画はシャープな感じ
新（0.125.2208 d9d2288）：字幕がくっきりした代わりに背景動画だけスポンジ

自分でもワケワカメなんで意味不明ならスルーで・・・

>>364
１．とりあえず>>1にあるように、出来上がったMP4をMediaInfoで解析して
　　テキストモードで表示される内容を貼ってみて。
２．再生に使ったプレーヤーは何？（まさかQuicTimeじゃないよね。）
３．使ってるGPUは？

ニコニコ生放送のタイムシフトを StreamTransportでダウンロードしました
flv 512×288 16:9です
これをFreemake Video Converterで不要な部分をカットして小さいサイズにしたかったのですが、
内容をカットしてもサイズは1.5倍くらいになってしまいます
サイズも小さくなるようにカットできないでしょうか？
画面サイズを変えればいいんでしょうか？

>>366
ビットレートを下げればいいんじゃない？
「freemake video converter 使い方 ビットレート」でググればいくらでも解説ページが出てくるよ。
ビットレートの意味もちゃんと調べておきましょう。

OBRモード:VBRモード オーバルビットレート:658Kbps
プロファイル:[email protected] CABAC:はい RefFrames:4
幅:640ピクセル 高さ:360ピクセル 解像度:16:9 モード:CFRモード フレームレート:29.970fps
ColorSpace:YUV ChromaSubsampling:4:2:0
BitDepth/String:8ビット 使用したライブラリ:x264core125r2208d9d2288 エンコードライブラリの設定:
cabac=1/ref=3/deblock=1:0:0/analyse=0x3:0x112/me=umh/subme=10/psy=1/psy_rd=0.50:0.00/mixed_ref=1/
me_range=10/chroma_me=1/trellis=2/8x8dct=1/cqm=0/deadzone=21,11/fast_pskip=1/chroma_qp_offset=-2/
threads=3/lookahead_threads=1/sliced_threads=0/nr=0/decimate=1/interlaced=0/bluray_compat=0/
constrained_intra=0/bframes=5/b_pyramid=2/b_adapt=2/b_bias=0/direct=3/weightb=1/open_gop=0/
weightp=2/keyint=300/keyint_min=29/scenecut=40/intra_refresh=0/rc_lookahead=40/rc=2pass/mbtree=1/
bitrate=520/ratetol=1.0/qcomp=0.10/qpmin=1/qpmax=51/qpstep=4/cplxblur=20.0/qblur=0.5/ip_ratio=1.40/aq=2:0.85
matrix_coefficients:BT.601-6525,BT.1358525,BT.1700NTSC,SMPTE170M
プレイヤーはGOMとMPC＋FFDS共に補正無しRGB出力　GPUは伝説の地雷GFFX5200

http://uploader.sakura.ne.jp/src/up103324.png
左が新Verに移したあと　右が旧Ver

どっちも汚いんだけど、左みたいにシュワっと弾けるようなことは無かった
というか動画はオマケで字幕を見せるように作りたかったんだけど
テンプレみたいに可変で変動量60〜70％にすると動いてるほうに引っ張られて字幕が潰れたんで
何度も試してる間に実は固定のほうが字幕はキレイになることが分かって
でもそれだと動画のほうが死ぬから可変で変動減らして行って
最終的に変動量10％のなんちゃってVBRにしてある　つもり

っていうか新Verは字幕の周りのノイズがすさまじい　なにこれ

>>369
・比較するなら同じフレームにしたほうがいいんじゃないかと思った。明らかに違うフレームやん？
・qcomp小さくするってのはやったことないので、そのへんは設定詳しい人にまかせるけど、
　とりあえず旧バージョンでエンコしたほうもMediaInfoで調べて貼って、
　オプションが同じになってるかどうか確認してみたら？
・古いバージョンがどれなのか、x264.exeのバージョンとx264guiExのバージョンを明記したほうがいいと思う。
・GOMはまともじゃないので参考にならない。

うｐの為ではなく個人的使用が目的なのですが

例えば
映像ビットレート20000の動画を。500にエンコして
その500の動画を、更に1000にエンコした場合
その動画は映像ビットレート1000の動画として扱われるのでしょうか？
それとも、一度500になってるから表記は1000でも中身は500の動画なんでしょうか？

厳密に言えばちょっと違うけど見た目は500かそれより下、実際のビットレートは1000って感じになる
あとスレチな

ごめんなさい(´･ω･｀)

最後に、もう１つだけ質問
その500の動画を、別サイズ＆1000にエンコした動画と
500の動画を、↑と同サイズ＆500にエンコした動画は
同一なんでしょうか？

違う方法でエンコードしてるのに同一なわけないだろ

>>370
新Verはどのフレームも全体的にボケてるかノイズがあるかのどっちかだからどこ見ても同じ
当然確認した
x264.exeは115 r1995 c1e60b9から125 r2208 d9d2288　GUIは0.35から1.50v2
GOMだけで見たわけじゃない、MPCと両方で見てみて新Verはボケ
GOMはいつも色調がおかしいから信用してない

デブロックの強度を1〜2くらいでDCT外すと字幕周りは旧Verと同じような感じになるが
今度は動画のほうがもっとひどくなる

なんかいろいろ弄ってたら直ってきたからこれはこれでいいや
たぶんボケたんじゃなくて全体的にシャープなノイズが出ないようにする改善策じゃないかと思い始めた
とりあえず旧Verのパラ設定だと新Verでは違う結果になる
自分はこれを見た感じ悪化だと思ってるけど、他の人が見たらどうなんか知らない
ボケ直らないからそれ踏まえてとりあえず新しくパラ振りするからおｋ　さんくす

とりあえずニコニコ用のエンコードしてるなら確認はGOMとかMPCじゃなくてFlash Playerでした方がいいぞ。
>>3のFlavieだとか>>348のつんぷれ辺り推奨

>>377
おｋボス

http://uploader.sakura.ne.jp/src/up103343.png
この最終的にぼかしてるのはAviUtl+x264guiExのどの設定か分かる？
シャープ掛けようがマスク掛けようが最終的にボケる
同じビットレートだとデフォで入ってるプロファイルどれ使ってもボケる

というより何で今までボケなかったのか
シャープにするにはどうしたらいい　どのパラが関係してるの

YC48→YUV変換 utl
-deblock x264
フィルタは知らね

>>379のリンクは踏まないほうがいい。まともな掲示板じゃない。
画像アップする時は斧使え。

>>381
おま・・・　どこまで探しに行ってきてくれたんだ
みんな大好き直ﾘﾝで専ブラの類使ってたらその場でサムネ表示されるんじゃないのか
流れてればエラー返されるだけで
ほい　斧http://www1.axfc.net/uploader/Img/so/146553.png

>>380
デブロ切っても弱めても変わらんかった
Utlのほうのどれだか分からぬスマソ　出力前はボケてないからフィルタでぼかしてるわけじゃない
他の設定もちょっとずつ動かしてるんだけど変わらない
x264.exeを以前使ってたのに戻してもボケるっぽいからGUIが何かデフォで渡してるのかもしれない

おまいらのほうも低レートにするとボケるの？　蚊ノイズみたいなのが出ないで

>>382
サムネ表示って何？な専ブラ使ってる俺の身にもなれ
2chは画像掲示板じゃないから不便に思うことはまず無いけどな

ここで聞けばいいのかも分からないが
Block match thresholdってなんの数値かぜひ教えていただきたい
インタレ解除するツールに入力する欄があるんだけど

http://lmgtfy.com/?q=%22Block+match+threshold%22+-%E3%82%B8%E3%83%A3%E3%82%AE%E6%B6%88%E3%81%97%E3%81%AE%E9%96%BE%E5%80%A4%E3%81%8A%E3%81%A3%E3%81%B1%E3%81%84%E3%81%AA%E3%82%81%E3%81%9F%E3%81%84

すれ違いとは思いますが、お願いします。

flvからのエンコツールで今の定番はコレ、ってのを教えて下さい。
手持ちの中では、iWisoft Free Video Converter＞XMedia Recode
なんだけど、サイズが3倍程度になってしまうので・・・。
フリーソフトで、劣化少・肥大化少・簡単操作の三点でバランスの良いものを。
変換形式はmp4,wmv,avi,mpgあたり。サムネ表示は必須です。

つんでれんこ

>>386
肥大化するならビットレートなり品質設定なり下げればいいじゃん。
スレ違いなんだからおとなしくDTV板の初心者スレあたりに行ってください。

　　【初心者歓迎】総合質問スレッド-79-【ダウソNG】
　　http://toro.2ch.net/test/read.cgi/avi/1335404660/l50

最近無音の動画でリピートがきかなくなるんだが
いったい何が悪いのか？
以前はなかったと思うんだが…

MediaInfoのGeneralのOverall bit rateの値って実ビットレートじゃないの？
計算して出した値とほとんど同じなんだが。

10bit深度の動画が11.4β入れたらおかしくなった。動画支援は切ってる

>>390
正確には少し違う。
>>7の計算とは違い、Mediainfoのは再生時間(秒)の小数点以下を切り捨てていない。
通常は誤差のうちだか、数秒程度の動画だと大きく変わってしまい、一般会員の制限を越えたりする。
また、ビットレート制限ギリギリを攻めていたりすると問題になる

>>392
なるほど。
MediaInfoの値は参考程度にとどめておけばいいわけね。
ありがとう

>>389
ニコ動本スレにも来てたみたいだけど、再生の問題なんだし、ここはスレ違いでしょ。
そもそも無音の動画なんてあんまりないんだからサンプルを示すとか、
原宿なのかZeroなのかとか、ブラウザやFlashPlayerのバージョンとかも書かずに質問したって
答えが返ってくるわけないと思うよ。

WikiにあるH264の通りにエンコードしているのですが、100M以内にできても再エンコがかかります。
ぐぐってみたところ前スレにもでてきているのですが、mp4v2というものがひっかかっているのでしょうか。
これは何が原因でなっているのでしょうか？元の動画が原因だったりするのでしょうか・・・。
真空波動研で見ると以下のようになっています。
640x380 8Bit AVC/H.264 [email protected] Unspecified 59.99fps 38991f 1161.46kb/s
AAC 48.00kHz 2.0ch(2/0 L+R) HE(LC) 93.94kb/s
MP4 v2
[MPEG4] 00:10:49.919 (649.919sec) / 102,505,876Bytes

>>395
MP4v2なのは関係ない。
　　・実は再エンコなどされていない。（>>8を参照）
　　・実は一般会員（これはないと思うけど）
のどちらかじゃないかと。
「再エンコがかかってしまう」というのはどうやって確認したの？

関係ないけど640x380って変な解像度だね。ちゃんと640x360でアップしたほうがいいと思うよ。

>>396
ありがとうございます。
再エンコはかかってしまう、というのは画質が明らかに落ちているからです。
素で解象度おかしいのに気付いていなかった・・・修正してみます。

>>397
「明らかに」とあるから勘違いではないと思うけど、FlashPlayer特有の見え方を勘違いしている可能性もあるし
念のため何らかのダウンローダーで動画を落として確認したほうがいいかもね。
自分はNicofoxとSmileDownloaderしか使ったことないけど。

少なくともWikiによると、100MBの判定は 104,857,600[Bytes]　または　104,853,504[Bytes] のはずだから
>>396が引っかかるとは思えない。ただ、いつのまにかサーバー側で「100MB」の解釈が
変わってたという可能性もあるかもしれないけど・・・。

>>395
もちっとビットレートに余裕持たせてみたら？

間違えた。
ファイルサイズだ。

プレミアムならちゃんと再エンコされずにうｐ出来るmp4でを一般会員でうｐした場合、
ビットレート超過なら再エンコ食らうんじゃなくて弾かれるよね。ファイルサイズ超過もそうなるんじゃないっけ？
ここはあまり経験ないからちょっとハッキリ言えないけど、再エンコされるならビットレートとかファイルサイズの問題じゃないって事になるんじゃ？

>>398
104,857,600 残り7バイトまで詰めた事あるから間違い無いはず

色々ありがとうございます。
何度か試してみましたが直らず、別のエンコードでやると問題ありませんでした。
一度aviutl一式入れなおしてみます。。。

flashplayerをVerUPしてからflavieで最初の10秒ぐらい音しか出なかったりでおかしかったんだけど
--ref 12を6に、--bframe 9を3にしたら起きなくなったからその辺の問題なのかなー
大百科の動画がおかしくなる方は大百科をクリック→とも関係してるんだろうか

既出だったらすまん

>>404
FlashPlayerスレで同じこと言ってる人はいた。
　　http://toro.2ch.net/test/read.cgi/swf/1341324585/16

ただ、うちでは11.3系を使っても「開始10秒くらい音しかでない」という現象は起きてない。起きてるのは
　　「１つファイルを再生した後に別のファイルを再生しようとするとほとんどの場合音しか出ない」
という問題かな。
ただ「FLV Still」とかでは特に問題ないし、Flavie側の問題かなと思ってる。
Flavie側で修正くるといいけど、こないなら「つんぷれ」とかの別ツールを推奨したほうがよくなるかもね。

まあうちではWinXPでシングルコアの低スペック環境なので11.3は基本的に使い物にならないため
普段は10.3.183.20を使ってる。

win7 64ult+3930kで再生支援切ってるけどflashplayer更新したらブラウザ上で飛ばすと緑画面になって見られなくなる事が凄い増えた気がする
11.4βだけど

>>405
flavie側の問題みたいねー
もう1度色々設定を弄っていくつか動画を作ってみたけど
どうもこっちの環境だと--refが12以上になると起きるみたいで
11以下にしたら今まで通りに再生できるように

ハードウェアアクセラレーションon/offが変えられなくて、deblock問題が確認できない「Flavie」
バッチファイルゆえにファイル名やパスに記号とかがあるとコケることがある「つんぷれ」

>>408
Flavieって、ハードウェアアクセラレーションありのＰＣだと強制的にハードウェアアクセラレーションONになるの？
（うちのPCは再生支援無しなもんでOFF状態）

右クリックするとFlash PlayerではなくFlavieのメニューが出てきて(Flavieからは)変更できない
低スペPCの頃は一瞬Flashのメニューが出てその上にFlavieのメニューが出てきてた

おそらくIEのActiveXを使用してるはずだから、IEでDXVAを切ればFlavieでも切れるんじゃないの

諸事情で貼れないが、普通に投稿されてるとある動画を落としたら
ファイルサイズが余裕で100MBを超えていた(投稿者は一般会員)
ファイルサイズオーバーを不正に回避してうpする方法ってあるの？

>>411
多分MP4やFLV以外の形式（WMVとか）で投稿して、サーバー側のエンコにまかせた動画なんじゃないかな。
サーバー側でエンコした動画は、Wikiにあるように基本的には映像360＋音声64＝約424kbpsの動画になるから
約33分の動画で100MBになり、もっと長いと100MBを超えることになる。
ただし>>40にあるようにビットレートはもっと低くなることもあるので、これは計算の一例にすぎないけど。

この方法で、一般会員の規定を超える40MB以上のMP4が生成されることは確認してたけど、
>>281が本当なら100MBを超えることもあるんだね。
一般会員でもWMVとかの形式なら100MBまで投稿できるけど、それを超えるサイズのMP4を作ってどうすんだか・・・。
普通なら100MB以内におさまるようにサーバー側のプログラムを組むと思うが、そういうの抜けてるんだろうな。

勘違いしないように言っとくけど、サーバー側のエンコードの品質はかなりひどいものだから、
一般会員でも自分で40MB以内でMP4にエンコードしてアップしたほうが綺麗になることがほとんどだよ。
それでどうしても綺麗にならないならどのみち限界を超えてるだけなので、
おとなしくプレミアムに入るか分割してアップしたほうがいい。

投稿した時はプレミアムで今は一般になったんだろう
自分も画質いい動画上げる為にプレミアムになった
しばらく投稿しないなら一般に戻ろうかと思ってる

>>412
なるほどサーバーエンコードに任せると容量が爆発することもあるわけか…
うん、多分それだと思います。ビットレートの情報もほぼその通りだし
ちなみに60分の動画で180MBくらいあるんだよね

h265が実装されれば高画質うpの為にプレミアムになってた層のどれぐらいが一般になるんだろう
読み込みと総投稿容量制限から戻る事はまず無いが

>>415
規格が発表されるのが来年の１月。
一般的になるのにどれくらいかかるのだろうか
それまでniconicoは残っているのかな

x265エンコーダが非公式ながら完成して出力出来る段階なんだからフラッシュが対応すれば即移行が始まるはず。容量比画質は現行のx264 highに比べ1.5倍程度は良い
youtubeだってwebMの画質が悪いとかですぐにh264に戻したんだから高画質で帯域が大幅に抑えられるh265に今すぐにでも移行したいはず。その需要の高さからフラッシュ対応も相当早いと思うよ
あくまでもライセンスがh264のような感じなら

また重いとかカクカクとか言われるかな？
画質は上がるけどフレームレート稼ぐのには向いてなさそう

>>417
現状では、デコードの負荷がh264の２倍って話だから
重いって不満の方が多いんじゃないかな。
まだまだ低スペックのＰＣが現役で動いているようだし

そうなるとベンチマーク動画が怖くなるなｗ
今あるやつらなら何とかフリーズまでもっていかれはしないが
8Kとかきたらどうなるかわからんわ

4分程度の動画をエンコードしようとしています。
（avi形式　UtVideoULRGで出力→aviutlで編集→UtVideoULRGで出力→つんでれんこ）
ところが、汚くなると噂の赤色が割と混ざっているせいか、限界のビットレートにしても画質が上がりません。
そこで色々と調べ、以下のように理解したのですが、合っているでしょうか？
　　・ニコニコ動画向けにエンコードすると、色情報がYUV形式になる
　　・RGB→YUVへの変換の際、劣化が発生する
ということは、最初からYUV形式で出力・編集を行えば劣化しないのではないかと
単純に考えたのですが、この考えは間違っていますか？

それ以前に、
UtVideoULRGで出力→aviutlで編集→UtVideoULRGで出力→つんでれんこ
こうじゃなく
UtVideoULRGで出力→aviutlで編集→aviutlでｍｐ４にエンコード
って考えは無いのか？

flashplayerの見てくれとしてはうん。劣化はするけど目立ちにくくなる。uvダウンサンプリングフィルタでも良いけどそれだとRGBはどこに挟んでもデメリットにしかならなくなる
因みにyuv422でもニコニコに上げられるけど同程度のssim psnrでもデータ上有利なはずなのに420に比べ更に劣化が目に付く。444やRGBは再生不可

>>422の方法にしたところで何が変わるんだ？
AviUtlでx264エンコードしてもフィルタリングしない限り一緒だからその選択肢は無意味だろう

適当な設定でやると投稿できなかったりするしね＞AviUtlでmp4にエンコ
よくわからなければ、つんでれんこにまかせとけば再生できないファイルは作られないでしょ。
画質は置いておいて。

AviUtlでエンコしている人の何割が、
つんでれんこより軽量かつ高画質でどんな試聴環境でも問題ないような
ベターな設定にしているんだろうね

エンコ請け負っている人でも怪しい人がちらほら

ありがとうございます。
ＹＵＶで出力するほうが多少有利　という感じでしょうか。
ＹＵＶの方が表現できる色が少ないと聞いたので、デメリットがあるとすればそのあたりでしょうか？

aviutlでエンコードしないのは、まだ慣れていないのと
フィルタ等について調べ切れていないからです。慣れたら移行してみたいと思っています。

>>426
＞つんでれんこより軽量かつ高画質でどんな試聴環境でも問題ないような
＞ベターな設定にしているんだろうね
軽量かつ高画質とかエンコ初心者なの?aqやpsyを弄ってより適した出力結果を得るってのなら分かるがどんなソースで誰が見ても設定変更前よりよくしろってのならmeやref、threadsを弄っていく事になるし両立出来るわけない
また全て視聴者の事を言ってるとしてもデフォのmidium以下でそれ以上の高画質なんて無理。cabacかbフレ切るレベルでないと実感出来る軽量可なんて無理だからな
そもそも512×384のmidiumなんて北森世代でも動くだろ

>>428
軽さと画質のバランスが取れた、と言いたかったんだけど、どう読んでもそうは書いてないね。すまん

--ref 16は論外としても、ビットレート過剰だったり、colormatrixがあやしかったり、deblockバグ踏んでたり
いろいろ

>>429
deblockのバグって、deblock有効な動画をハードウェアアクセラレーション切って再生すると映像がおかしくなるってやつ？

>>430
そうそれ。
flashplayer10.1では起こらないそうなので、バグだと認識している
http://togetter.com/li/270474

>>421-427
前提条件を考えてないから色々間違ってるというか行き違いがあると思う。

まず>>421の、「RGB→YUV4:2:0への変換によって色の劣化が発生する」というのは正しい。
この劣化は色空間の変換によるものなので、ビットレートをいくら上げても修復できない。
赤色のエッジを多く含んだRGB映像を、YUV4:2:0で圧縮するUtVideoのULY0で圧縮してみれば、
「可逆のはずなのにすげえ劣化しちゃってるじゃん！」という現象が起きてるのがわかる。
RGB→YUV4:2:0変換を行っただけで劣化するということなので、それ以上綺麗になりようがない。
　　参考： ttp://www1.axfc.net/uploader/Img/so/70976.bmp

次に
　　Ａ．「最初からYUV4:2:0形式で出力・編集を行えば劣化しない」
　　Ｂ．「途中でRGBをはさむのはデメリットにしかならない」
というのが成り立つのは、
　　「カメラで撮影した動画素材やDVD素材等を、基本的にカットのみ行い、
　　　字幕やエフェクトの追加、重ね合わせなどの編集はほとんど行わないで出力する」
という場合くらいだと思っていい。
DVDやカメラ動画などは基本YUV形式だから、YUV形式で動画を扱えるソフトで途中の処理を全てYUVのまま扱い、
映像そのものに手を加えないのであれば、無駄な変換が入らず劣化は少ない。
（というかDVDやカメラ動画になった時点で劣化してるので、それ以上に劣化させないで済むだけというべきか）

（続く）

（続き）
しかし、MMDやAE・NiVE・AviUtl等によるオリジナル映像作成や、字幕やエフェクトの追加、
素材の重ね合わせなど、いわゆる「一般的な映像素材作りや編集」は、基本的にRGBで行われるし、
編集者はそのRGB映像を見て編集していることになる。

そのため、「YUV形式で編集」というのは基本的に不可能だし、編集映像をYUV形式で中間出力すれば、
そこでRGB→YUV変換が発生して劣化してしまうということになる。
「中間出力で劣化する」か、「x264出力で劣化する」かの違いだけなので、どのみち劣化は避けられない。

つまりYUV4:2:0形式で中間出力するメリットは「中間出力時に劣化を把握できる」という程度であり、
それ以上の意味はあまりない。（データが小さくなることもあるけどまあここでは関係ないし）

なので、色空間変換による劣化への対策として映像作成者としてできることは、以前から言われているとおり

　　●編集中にYUV4:2:0化した時の状態を確認し、なるべく劣化しないような色使いや絵作りを心がける。
　　　　（上に書いたように一度ULY0に出力して劣化具合を確かめてみる方法もあるし、
　　　　　AviUtlなら「UVダウンサンプリング」や「4:2:0化フィルタ」等で編集中にチェックすることもできる。）

　　●UVダウンサンプリング等のフィルタを使い、RGB→YUV変換時の劣化を少しでも減らす

　　●大き目のサイズでエンコードし、再生時に縮小再生させることで劣化を目立たなくする

といったことくらいになるのではないかと思う。

ニコ生の録画についての質問なのですが板はここであってますか?

>>434
板は合ってるが、スレ違い

ニコニコ生放送の質問に答えるスレ part14
http://anago.2ch.net/test/read.cgi/streaming/1335467364/

再エンコの画質上がった頃に、昔の再エンコ動画も新規格に合わせて
生成し直しますって言ってた気がしたけど、本当にされてるのかな？

>>436
されてるよ。以下の大百科の掲示板のレス366-370あたりを参照。

　　エコノミー症候群とは - ニコニコ大百科
　　http://dic.nicovideo.jp/id/492

YouTube並みとは言わないが、制限を300MB位まで上げてくれないだろうか

ここ数年でyoutubeなんてもの凄い高画質・解像度になったもんな
経営規模が違うとはいえニコニコも見習ってほしいもんだ
同じ日本の動画サイトですら500MBまで再エンコ無しとかあるのになー

一般40MBプレミアム200でいい

動画投稿容量を上げると今以上に回線が逼迫しそう

正直100MB以上が必要になるほど価値のある動画ってあんまりないと思う・・・。

スマホで見てる分には良いけど、デスクトップで見てると画像が荒くて

>>442
youtubeから転載してる人はうれしいんじゃない？
再エンコする手間が減りそう

>>444
転載自体にいいイメージを持っていないので、だからこそ反対というのもあるな・・・。
Youtubeの鯖エンコの画質は大したことないし、どうせなら1080pのをうまいことニコニコサイズに縮小処理して
綺麗にエンコードしてアップするくらいのことはしてほしいもんだ。

ただでさえ乱造投稿しやすく、画質のために無意味にサイズ上限ギリギリを狙う初心者もまだまだ多いというのに、
これ以上条件を緩めたら鯖や回線の負荷がやばいことになると思う。

個人的には一般の方のビットレートの制限上げてほしい。
1280x720に対応されても他が変わらないんじゃスライドショー的な動画しか需要ないでしょ。
動画サイトなんだから動画を投稿させてくれ…

>>446
そこまで言うならプレミア入りなよ・・・。一般の容量なんて上げたら馬鹿が増えるだけやん・・・。

まあ、色々事情が。（主にお金がね…

>448
そんなあなたにはプレミアムβ会員
【nico】 一般会員の動画投稿者で有利なプレミアムβ会員とは
ttp://looooooooop.blog35.fc2.com/blog-entry-900.html

>>449
おお！
ちょっとPayPalについて調べてくる

100MBなんて標準解像度でHEAACでも紙芝居じゃない限り10分ぐらいが画質の限界だからなー
既に時代遅れであることは否めない

paypalクレカしか使えないのか…

自分にとってはそれ最適な気がするわ
つーかアニメの仕様ひっくり返ってるじゃねーか

>>452
そんなあなたにはVプリカ
「ネットショッピング専用 Visaプリペイド-Ｖプリカ 本人確認、審査なしで発行できます。」
ttp://vpc.lifecard.co.jp/

paypal自体アカ作るのにクレカ情報は入らなかったはずだけどβ登録の際に必要
もしかしたらpaypal自身の入金に別口で入れる必要があるかも

>>453
βの話なら、国内での視聴はムリ
アカウントの住所は弄って海外にした場合見れるかどうかは分からん

>>454
そんなのもあるのか

でもpaypalアカウント年齢制限で作れなかったからどうにもならん

あきらめることにする

NICOにうｐするために、１００MBに抑えるためビットレート計算機でビットレート調節しているのに
できあがると175MBになったりする・・・orz
原因なんだろ？
10分の1の長さで区切ると１０MBくらいになるのに、全体をやるとそうなる

>>456
DTV板のAviUtlスレで誘導されたとはいえx264vfwGUIスレと両方にマルチするのはやめたほうがいい。
まとめWikiを熟読してください。
　　http://nicowiki.com/encode.html
　　http://nicowiki.com/aviutl_h264.html

まとめwiki読んでも理解できないなら、
エンコオプションの調整とかめんどいことはやらないことにして、
一手間増えるけど、可逆圧縮なaviで出力して
つんでれんこなり夏蓮根なりに放り込んだほうが早い

2パスでビットレートの変動を、、って辺りですかね
H264の計算表で音声映像療法で100MBに収まるようにしているんですよね
なのでそういう基本的な問題でなく、何か読み込みプラグインとか関係しているのかなぁ
dgaファイルを、DGAVCDecode.dllでavsで読み込ませている感じだと思うんだけど･･･
このやり方で編集できてる方いますか？

可逆圧縮でもいいんですけど、
あれってフレームはどうなりますか？
自分の動画が60iなので、その滑らかさを維持したいんです
29.97で可逆圧縮aviで書き出せば、変わらないんですかね？

>>459はまたDTV板のx264vfwGUIスレにマルチしてる
スルー推奨

もういいです。監視が凄すぎて気持ち悪い
さよなら
ちなみに内容は違いますよ。ちゃんと見てくださいね

>>459
>>1をよく読め。あきらかなスレ違い

質問です。
全くの初心者なのですが、ニコニコ用に字幕つきの一枚絵ボカロ動画を作成したところ、画質がボヤけて字幕も半ボケになってしまいショボーンな状態です。製作環境は、
iMac付属のiMovie'11
QuickTimeを使用して書き出し、フォーマットはMP4(H.264/AAC-LC)。ビットレートは映像300kbs、オーディオ128kbs。
映像のサイズは512×384、フレームレートは15です。出来た動画はflavieで視聴しました。
512×384というのはニコニコにおける4:3規定値だとまとめwikiで読んだので、そう設定したのですが、これだとものすごく画像がボヤけてしまいます。。1280×720HDとかにすると画質がクッキリしますが、これじゃダメなんですよね…？
念のためWindowsムービーメーカーを使って同じ設定で作ってみましたが結果は変わりませんでした。
どうすればニコニコに普通にアップロードされているボカロ動画のようなクッキリした動画が作れるんでしょうか。
どんなことでもいいので何か助言してくださると助かります。。

Zeroで見てるならZeroの解像度が縦486pxなのでそれ以上の大きさにしてないとボケる
4:3なら648x486か

＞1280×720HDとかにすると画質がクッキリしますが、これじゃダメなんですよね…？

これ、なんでダメだと思うの？ダメではない。重くはなるが。

あとボカロ曲なら音声ビットレート128kbpsじゃなくてもうちょっと、192kbpsとか256kbpsとかにしたほうがいいと思う

一枚絵なら映像の方のビットレート落とせるんじゃないか？
字幕の出し方にもよるだろうけど

QuickTimeで書き出しているのなら、標準フィルタのsharpenを試してみる。
もう古い時代のプログラムなので、単に画像が荒れるだけかも知れないが。

画質にこだわるなら、h.264とx.264について学習して、QuickTime用プラグイン
のx.264、またはHandBrakeを使ってエンコードした方が良いと思う。

>>424
ありがとうございます。今のところzeroではなく旧プレイヤーで考えています。
投稿する場合、1280×720HDなどでも良いのでしょうか？512×384(あるいは16:9のもの)の規定値を超えるとニコニコ側で再エンコードされて結局画質はボヤけてしまう…という認識なのですが正直そこのところがよくわかっていません。。重くなるだけで済むのでしょうか？
試しにニコニコにUPしてみたいのですが今ちょっとそういう環境にないのでそれもできません、すみません。
>>425
そうですね、映像はビットレートを下げてオーディオを上げたいと思います。

レス番号まちがえました
>>464さんと>>465さん宛てです。

>>466
一応、WindowsムービーメーカーとAviUtlで同様の設定の動画を作ってみたんですが、画質が悪くボケたままでした…。
うまくいかない場合、最終的には勉強してQuickTimeをいじってみようと思います。ありがとうございます。

一般アカなら1280x720まで
プレアカは解像度制限はない

>>470
そうだったんですか！超基本的なことを勘違いしていました…。見た情報ページが古かったのかな。。
お騒がせしました。

>>467
アンカーミスってる？

ごめん、リロードしてなかった。
無視して

>>471
ニコ動の投稿動画の制限とかはココ見ればわかると思うよ
http://nicowiki.com/encode.html

どこの段階で画質悪いと感じてるのかをまずハッキリさせるべき。
動画作って書きだした段階で悪いのか、その書きだした後に更にエンコードしてるのならそこで悪くなってるのか、
またはニコニコにうｐするまでは大丈夫だけどうｐ後に悪くなってるのか。
ここがハッキリしない状態でアドバイスしても無駄だと思うが

作ったやつflavieで視聴したって言ってるじゃん

友人が上げた動画がロードに時間がかかる気がして落として確認してみたんだけど、1280x720の1分半ぐらいの動画でビットレート7000とかにしてあったんだけど、品質求めるとこんな数値になっちゃうの

BSデジタルとかBDと比べると全然たいしたことないビットレートだな

動画サイト用の動画でこの数値はどうよ。って思ったんだけど、意外と普通なのか？

7000もあればロードが遅いと言われてもしかたがないけど
画質面で言えば法外に高いというほどでもない

理由によっては、大分意味合いが違うね
品質を求めて意図的にやったのか、
それともニコエンコの自動で勝手に100MBぴったりになったのか、
ビットレート計算して、100MBを狙ったのか

>>481
たぶん一番下。
ファイルサイズの限界の100MBに近づくようにエンコしてるらしい。
自分で品質基準VBRでエンコしたら実ビットレート3000ぐらいになったから。無駄にビットレート振ってるんじゃないかと。

>>482
Qualityがいくつでやったかも書かないと正しい判断無理です。
俺の手持ちのHD動画をQuality20（crf=20）でエンコしたらビットレート7000を超えた。
動画の映像変化などの要素で変わってくるけどHDで高画質にしたけりゃ5000以上になることはよくある。

>>483
スマン、16です。
ベタ塗りだからHD解像度でもかなり縮むと思う

crf16てものすごい高品質じゃね？
自分18までしかやった事ないわ。内心プラシーボだと思いつつね。
でなきゃ0で可逆にするか。

>>485
そうなの？

どこかのページでcrf16だとSSIMの値がほぼ0.99になるってのを読んで、それ鵜呑みにして16にしてやってみた。動画の再生時間も短いし。

自分が気になったのは、crf16でも実ビットレート3000ぐらいになったのに、2passで7000指定してエンコするのは無駄が多いんじゃないかなってこと。

品質基準でやるならデフォルトのcrf=23でも必要十分に綺麗でしょ。
それで不満でもせいぜいcrf=20くらいまでにしといたほうがいいと思うけど。

とりあえず ID:nPD9x3v40 は、その友人に
　　「短いベタ塗り動画でファイルサイズ上限狙うなんてアホだから、crf=23からやってみろ」
と言ってあげたほうがいいと思う。

>>487
crf23は目に見えて劣化がわかる気がするんだが…気にしすぎか？
まあとりあえずまずは品質基準で書き出してどうなるか確認するように言っておく。

>>486
このページかな？ どうでもいいけどパーマリンクには日本語入っててURL長すぎｗ
ttp://tutinoko.org/blog/2010/12/25/

実写の場合は細かいところが劣化しても目立ちにくいし
心理視覚効果も利く(≒SSIMがそこまで高くなくてもよい) のでcrfを大きく取っても許容できる
それに対しアニメの場合は僅かな劣化も目立つからcrfを小さくする必要があるが、
ベタ塗りなら総情報量は多くないのでビットレートは実写に比べて低くなる
という感じだと俺は理解している

7000とかはともかく
一般の上限なら品質基準なんてまず使うことないよね
今までやったことないんだけど

>>489
そうそこそこ。
自分でも色々crfいじってやってみたけど、基本18で落ち着いてる。実写ソースは20。

上でも言われてるけど、動画投稿サイトにアップするなら画質とビットレートのバランスが大事だからなあ。
必要以上の無駄な高画質にするより、快適に読み込めたほうがいいと思ってる。

HDでも1500kbps以上にはしたくない。鯖の調子によってはプレミアムでも重くなるし
その分ref bframe以外は盛り盛りでいくが

よくしらないですが、フレームレートって
ネットで見る分にはなんでもいいですよね？

フレームレートが15Fで非圧縮のアニメ.aviをつくったんです。
で、それをエンコードするとき、
youtube HD っていう設定があったのでその設定を流用して
フレームレートだけ15にしたんです。
結果容量は１０６M
そのあと、30fにしたらどのくらい容量増えるのかなぁ
と思って試してみたら容量は・・・
９３M
減ってる！？

こんなことってありえるんでしょうか？
ようは時間的に等倍に引き延ばすだけなので容量変化なしっていうなら
まあわからなくもないんですが・・・減るって
そういうもん？

エンコードしたソフトは adobe media encoder　というやつです。

何でもいいってなんだよ

テレビとかDVDだとフレームレートは決まってるけど、ネットだとあまり制限ないってことはないですか？
減らしすぎて不味いことってあります？　

ちがった！
フレームレートをあげたら容量が下がってるんじゃなくて、
2passを1passにしたものが全部容量下がってるんだ・・・・

でもなんで？
2passのほうが容量は下がるだろうに・・・？

圧倒的に

基本知識が足りてない

fpsは”自分がそれでいいなら”ネットだろうとローカルだろうとどんな値でもいいわな
自分ならソースを維持出来る値を使用する

素材なしで一から動画作るのなら基本30fpsで、動きがほぼないようなものなら15や10とかまで下げる事はあるかも

あれ passを増やしてもだけど
やっぱりフレームレートを下げても容量がふえる・・・

素材は完全に15fのカクカク非圧縮aviアニメでそれでよいのですが
それを30fでmp4に変換する場合と15fのままででmp4に変換する場合だと
30fのほうが容量が少なくなる・・・・

どういうこと？

30fのほうが圧縮しやすいの？
でも普通に考えたらフレームレートを増やすってのは容量を増やすことになるような・・・

空フレームを入れたらサイズが縮まるなんて原理上ない
少なくとも15フレのソースを30フレに変換しても情報量はまったく増えない
つんでれんこ使え

なんでもかんでも教えてやっても誰の得にもならんよ

x264のcrfはフレームレートが高くなるほど同じ品質を設定しても画質が悪くなる
フレームレートが高いのに情報量がほとんど増えてないのでファイルが痩せる
あともっと知識付けるか他所に書いてくれ

GPU支援がされてるかの確認ってどうすればいいの？アクセラレーションオンオフでもCPUの使用率変わってないような気がしてわからん

>>504
自分も知りたいな
【FlashPlayer映像崩壊】デブロック有効時のサンプル
http://www.nicovideo.jp/watch/sm17278404
で、問題が起きるかどうかで<見てたけど、本当はどうするのがいいんだろう？

逆にアクセオンでバグりまくりでオフにすると普通見られるのあったけど
プロファイルレベルとrefは大丈夫そうだったんだよなあ

凄い興味あるなそれ
見てみたい

普通にHTML5で見られるようにならんかなあ

>>504-505
＞GPU支援がされてるかの確認ってどうすればいいの？

DXVACheckerというソフトでトレースログを取るという方法があるかな。

　　ホームページ：　ttp://bluesky23.yu-nagi.com/DXVAChecker.html
　　※環境によっては起動時にブルースクリーンが発生するとのことなので、ホームページの注意書きをしっかり読むこと。

　　１．DXVACheckerを起動
　　２．「トレースログ」のタブを開いて「開始」ボタンを押すとログの記録が開始される。
　　３．動画視聴ページを開いて動画を再生。
　　４．「更新」または「停止」ボタンを押すと、それまでに記録されたログが表示される。
　　　　（押されるまで表示されないので注意。確認するだけならログを大量にとっても仕方ないので
　　　　　ちょっと再生してすぐ止めるといいかも。）

　　　　　ログ取得例：　ttp://www1.axfc.net/uploader/Img/so/147945.jpg

他に良い方法があったら誰か教えてちょ。

http://www.nicovideo.jp/watch/sm18616783
環境によるかもしれんけどこれ支援オンだと映像乱れるのは1080pでlv3.1だから？
キー少なすぎも原因なのかね

>>510
レベル違反してるからその可能性が高いかな。大雑把なパラメータを見ると
　　1920x1080　29.97fps　[email protected]　ref=5　keyint=infinite　keyint_min=29
という感じになってるけど、1920x1080の時点でLevel4.0以上が必要。更にref=5にするならLevel5.0以上が必要。

パラメータを見た感じ、x264guiEx1.44より前のバージョンに含まれる「ニコ動 プレミアム 実写 高画質」の
プロファイルをベースにしていると思われるのだけど、手元で試してみたらrefは2に減るはずだし、
keyint関連もこんなことにはならないはずなので、何をこじらせてこうなったのか不明。

補足情報

　　x264guiEx1.44よりも前のバージョンに含まれるニコ動関連の各種プロファイルは
　　HDエンコを想定していないため、基本的にLevel3.1を明示指定しています。
　　そのため、高解像度（目安としては1280x720の30fpsを超えるもの）でエンコしようとすると
　　警告が出てレベル違反となる可能性があります。

　　x264guiEx1.44でプロファイルの見直しが行われており、レベルが自動設定に変わったことで
　　この問題は解消されていますし、その他にも色々とバージョンアップされていますので、
　　古いx264guiExを使っている人は最新版に更新しておくとよいと思います。
　　あわせてx264.exeも更新しておくとよいでしょう。

なんか、Zeroで最適に見られるように864x486で動画作ってエンコードすると、
確かにZeroバージョンでは画素数ぴったりのそのままの解像度での表示になるんですけど、
原宿のプレイヤーで縮小して閲覧すると、気持ち解像度がはっきりしない感じ。

原宿ユーザー向けに640x360で作るか、Zero向けに864x486で最適化するか迷うところ。

何でわざわざこんな解像度にしたんだろうな
普通に854x480にすればよかったのに
まあ過去最大の改悪って評判だし原宿で安定じゃないか

解像度上げるとファイルサイズも大きくなるしね
小さくて良いならそれに越したことは無い

一枚絵の表示が多いので、イラストを生かしたいように考えてるんですけどね。
実際のところ原宿とＺＥＲＯ、どっちをどれだけ使ってる人がいるんだろう。

でもＺＥＲＯを一般向けに開放したところを見ると、ひょっとして使う人いなかったんじゃ…

普通に考えて原宿じゃないかな
youtube版のニコ動関連スレでもzeroはいい評価もらえてないもん

>>514
854x480（FWVGA）も正確な16:9じゃないから微妙な気もする。
　　480/9*16＝853.333333・・・
横のサイズである854ピクセルというのも2の倍数でしかないから、例えば「横が8の倍数であること」という制約をもつ
AMVコーデックではエンコードできなかったりする。（まあこれは編集段階の話ではあるけど。）

とはいえ、倍数縛りをつけて現在のZeroWatch大画面モードサイズ（864x486）に近いサイズを探すと
　　■16の倍数縛り→768x432(16:9)、576x432(4:3)
　　
■8の倍数縛り→896x504(16:9)、672x504(4:3)
　　
■4の倍数縛り→832x468(16:9)、624x468(4:3)
といった感じになるのでどれも微妙ではある。

なお、ZeroWatchの解像度については、担当者の志賀さんが「今後変更する可能性もある」というツイートをしている。
あくまでも「可能性」であって、実際に変更される可能性はかなり低い気はするけど。

　　ユーザ： ZeroWatch大画面モードの4:3サイズは648x486であってますか？

　　志賀さん： 一応そうです。ただ現状の解像度設定が特殊なのでそこに問題意識は持っており、
　　　　　　　　　もしかすると変更をする可能性もあり得ると思っています。
　　　　　　　　　まだいつかは未定ですがデフォルトを切り替えるタイミングまでには結論を出します。 (2012/7/31 22:52)
　　　　　　　　　　　ttps://twitter.com/flashoman/status/230299935793364992

でも志賀さんってzeroのデザインした人でしょ
一般人と感覚が乖離してるからなあ・・・

普通にqHDにすればよかったのになぁ

>>518
たしかにきれいな数字じゃないね

NTSC-D1だっけ？は縦486じゃなかった？一般的じゃないのは確かだが。
それにならってるのかは知らんけど

動画と音声(wav)が別にある状態で
・mp4boxでh264+mp3にすると>>10により鯖エンコされてるようでAAC64kbpsになる
・mp4boxでh264+AACにすると再エンコされていない模様
・mp3でアップロードしたい理由があるのでmp3でも再エンコされない方法が知りたい

ニコニコにアップロードする前の動画の情報
　http://pastebin.com/6r5g93fC
ニコニコで再エンコードされた動画の情報
　http://pastebin.com/jssHqDtG

ニコニコで再エンコードされなかったAAC版の動画の情報
　http://pastebin.com/0ycBeW37

使用ソフト
　mp4box aviutl Lame NeroAACEnc SoundEngineFree
PC環境
　XP SP3 他に必要な情報がわからない

>>523
mp3にしたいならh.264じゃなくてvp6にすれば？

>>523
>>522も書いてるけど、どうしても再エンコードさせずにMP3でアップしたいならFLV(VP6+MP3)でアップするしかない。
正確な挙動は試したことがないが、>>523を見る限りニコニコ側で強制再エンコされる仕様になってるようだし、
仮に再エンコードさせずにアップできたとしても、>>120に書かれているように、
FlashPlayerは「H.264+MP3」のMP4の音声を再生することはできない。
Flavieで再生してみれば、音声が再生されないことがわかると思う。

ただ、FLV(VP6)でアップした場合、GPU再生支援が効かないので、
512x384とはいえ60fpsの動画だと、低スペック環境では動画の再生が厳しくなるケースもあると思う。

MP3でアップしたい理由というのを知りたいとこだけど、個人的にはH.264+AACのMP4でアップすることを勧めるかな。

×　>>522も書いてるけど、
○　>>524も書いてるけど、

>>524-525
ありがとう
mp4にh264とmp3は使えるって情報と
ニコニコはmp3形式に対応してるって断片的な情報しか無くて困ってたんだ
少し考えて見て264の維持かmp3の維持か決めて見る

結局なんでmp3で上げたいんだ？
H.264+AACでだめな理由でもあるのだろうか

>>528
論理的な理由じゃないし説明が面倒なので宗教上の理由とかそういう感じと捉えていただければ

flashplayer11.4でintelの再生支援でも問題発生しなくなったな
正式アプデ来たら-me tesa -ref 6 -bframe 3でやってたのをこれからは-me umh -ref 16 -bframe 5-8ぐらいでやろう
しかしβ2になっても10bit深度相変わらず色おかしいままだなぁ

>>530
FlashPlayer11.4は、既に昨日か一昨日くらいに正式版として11.4.402.265がリリースされてますよ。
Chrome内蔵はまだ11.3ですが。

それとref=16で再生支援に問題がないというのは、どのGPUで、どの動画で確認したのでしょう？
IvyBridgeなら問題は発生しなくなってますし、ref=16であっても問題が発生しない動画もあります。
手っ取り早く確認できるのは大百科記事にあるこちらの動画になるかと。

　　大百科：動画がおかしくなる方は大百科をクリック→とは
　　　　　　　　http://dic.nicovideo.jp/id/4623324

　　テスト動画： http://www.nicovideo.jp/watch/sm16620105

ということで11.4.402.265でのテスト結果を教えてくれるとありがたす。

つうか、ちょっと試してみたら11.4.402.265だと10bit-depthの再生がぶっこわれてるみたいだ。
11.3.300.271や、Chrome内蔵のpepflashplayer.dll 11.3.31.265では色が微妙におかしいという程度だけど、
11.4.402.265だと全体的に緑がかった色になる。ActiveX版もPlugin版もダメ。

　　http://www.nicovideo.jp/watch/sm16808896

>>530
>>531に補足。ref16の再生支援の問題はFlashPlayer側で対処できるとは考えにくいので、
ドライバの更新などで対応された可能性もあるのではないかと思います。
　　・使っているGPU
　　・GPUのドライバのバージョン （可能であれば色々とバージョンを変えてみるとか）
　　・11.4.402.265での確認結果
　　・11.3.300.271(脆弱性あるけど)や10.3.183.23での確認結果
　　・ハードウェアアクセラレーションの有効/無効を切り替えた際にページのリロードを忘れていないか
　　・ハードウェアアクセラレーションを有効にした時に、間違いなく再生支援が効いているか
　　　（Youtubeの動画情報などでもチェックできます。）

こういった点も検証できるといいかなと。（すみません、うちのPCでは確認することができないもので。）

ごめん勘違いだった
自分が代理投稿した動画(ref16 bframe2エンコは自分でやっていない)をmedia info読みでref16だからという理由で動画がおかしく(ryのタグ付けてたんだが問題が発生しなかったようで
最新版のflashplayerを使えばおかしくならないというコメントを見て普段DXVAを切っている11.3から11.4にしてみると当然だが問題が発生せず11.3に戻す事も出来ないので11.4ではオプションのフラグを見てDXVAを自動的に切る仕様になったのだろうと思ってた
ためしに-preset insaneで出力した動画を上げてみてみると見事にぶっ壊れてました
2450M HD3000 ドライバ8.15.10.2342
ごめんなさい

徐々にビットレート下げてくエンコード方法ってないの？
例えば30分動画をつくる場合始め1分くらいはビットレート最大2000くらい割いて
中盤、終盤になるにつれて徐々に下がっていって最終的に最大500まで落とすとか
そうすれば容量がかなり節約出来ると思うし、画質がだんだん劣化していっても正直気づきにくいと思うんだよね。心理的に考えて

>>535
分割エンコして連結すれば良いんじゃないかな

それかx264の--zonesオプションを使う
--zones 100,200,b=0.8/400,500,b=1.2
とすれば
100フレーム目から200フレーム目までは0.8倍のビットレート
400フレーム目から500フレーム目までは1.2倍のビットレート
として調整してくれたはず

>>536
ありがとうー
今度試してみる

別カットをつなげる時に、普通につなげるのと
クロスフェードではどちらがビットの節約になりますか？

試してみなさいよ・・・

知らないなら黙っとけ

>>540
知らないなら黙っとけ

>>540
試してみなさいよ・・・

オウム返しはアスペ

>>532
仕様変更でしょうかね？

>>544
どう考えてもただのバグ。

再エンコ動画の作り直し本当にやってるのかなぁ

>>546
>>437

http://www.nicovideo.jp/watch/sm17895662
の動画って本当に一般会員でアップロード出来る画質か?
今までやったことなかったが試しにHi10Pで1280x720の500kbpsくらいでエンコだけしてみたが到底無理

>>548
すごいなー1分も無いとはいえ映像500kbps総容量3MBでここまできれいに作れるのか

落としてみればわかるけど>>548は10bit-depthじゃなくて8bit-depthだね。

動画説明文にあるのは、10bit版のx264使ったってことなんじゃないの？

設定見る限りもうちょっと綺麗にできそう
動きの少ない背景真っ黒、真っ白のシーンが占める割合多いし、全体的に背景が止まってるシーンが多いから
見た目異常に絞りやすい映像なのは間違いない

あれ...もしかしてこのタグはw

>>551
何か勘違いしてるのだと思うけど、10bit版のx264というのは10bit-depthで出力するためのもの。
>>548をダウンロードしてMediaInfoで見るとBit Depthが8bitsになっているので、
これは8bit版のx264でエンコードされたもの。

>>554
bitは普段意識しないので適当なことを言ってしまった
スマン

>>554
よくわからないけど普通のx264を使ってても設定を詰めればこの質にできるってこと？

>>556
まあそういうことになるね〜。
x264の設定だけじゃなくて事前のフィルタ処理とかも工夫してるのかもしれないけど
自分はそこまで画質を追及したことないのでよくわからん。

ブラウザで再生中に微妙にフレームがドロップするのってエンコードオプションで軽減できる？
そんな高解像度でもないのに滑らかに再生できなかったりするよね？
Bフレなしにしたら圧縮率さがるし他にドロップ起きやすいオプションとかあるんだろか

--preset ultrafast

それはエンコ速度を早くするやつだろ

動画作成についての質問もここでしていいのでしょうか？

>>558

どっちかって言うと、FlashPlayerの問題じゃないですか＞微妙にフレームがドロップ
最近のは以前のバージョンに比べてよくフレームがドロップするんだよねー。

>>561
どういう動画を作りたいのか知らないけど、そのへんの話は別のスレで。
この板にはMAD初心者スレとか車載動画スレとか色々あるし、それ以外だとDTV板の初心者スレあたり。

>>558
俺もFlashPlayerとかニコニコのプレーヤーとかの問題がでかい気がするけど、
エンコード時の工夫で再生負荷を抑えてドロップを起きにくくするということなら
Wikiにある「再生負荷を抑えるコツ」を見ればいいんじゃないかね。
　　http://nicowiki.com/aviutl_h264.html
手っ取り早いオプションとしては--tune fastdecode があるけど、意味をちゃんと理解して使ったほうがいい。
　　http://nicowiki.com/%E6%8B%A1%E5%BC%B5%20x264%20%E5%87%BA%E5%8A%9B%EF%BC%88GUI%EF%BC%89Ex%E3%81%AE%E8%A8%AD%E5%AE%9A%E9%A0%85%E7%9B%AE%E3%81%A8%E3%81%9D%E3%81%AE%E6%A9%9F%E8%83%BD%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6.html

レターボックスを簡単に追加できるソフトってないですか？

320*240のFLVを4ファイルと480*360FLVを4ファイル、
計8ファイル（全部で20ＭＢ）を1つの512*384MP4に結合したいと考えています。

理想としては通して480*360、320*240いずれもそのままのサイズ再生されるようにで周りを黒枠（ウィンドウボックス）で囲みたいです。
当然320*240再生時には黒枠の面積が大きくなります。

そのために現在「XMedia Recode」を使用して各々の動画の拡大を試みていますが、
レターボックスを選択しても動画が引き延ばされてしまいます。

>>564
AviUtlあたりでやった方が楽だと思う

>>562>>563
flashプレイヤーでもyoutubeとかは大丈夫じゃない？
やっぱBフレ切るしかないのかなあ
ビットレートの高さで負荷は必ずしも比例する？
CPUやGPU的には余裕あるからドロップが負荷問題なんかもよくわからん

>>558
-bframe 3, -ref 3, -merange 24から

ごめんミス
>>558
前に同じ内容の動画上げたときに
--bframes 16 --ref 12から --bframes 3 --ref 3にして軽くなった。
これはいいけど、--merangeを24から48にしても何故か軽くなったような記憶がある。
動画サイズは640x360。

他のオプションが全く一緒でビットレートの大小で比べるなら大きい方が負荷高い

ビットレートが大きいほうがネットが重くなるのは確実だ　（生放送の動画紹介では重要）

確かYouTubeは一切Bフレーム使ってなかったな
refも最近のHD動画は1frameだし(480p、360pと以前のHD動画は3frames)、徹底的な再生負荷低減が図られてる

実はエンコ負荷を下げたいだけだったりしたら笑えるな

つべみたいに強大な鯖と回線があれば圧縮率なんか無視して再生・エンコ負荷低減の方が嬉しいんだろうな
しょっぱい鯖と回線を騙し騙し使ってるニコニコとは真逆

試しにref1 Bなしにしてみても変わらんようなw

レベルを下げれば再生可能性が上がるんでしょ？
ずっとPCで見てるとさっぱり分からんけど

専用CPUのハードウェアエンコーダにエンコさせてて
そのCPUがref1Bフレなしを処理しやすい設計にしてあるとか
そんな事情かなと妄想

フルHDで10分くらいある動画を100MBに抑えてるのってどんなタネがあるんでしょうか？
俺は640×320で7分くらいの動画で画質音質を落としに落としてやっと80MBくらいに抑えてるんですけどタネが知りたいです。
使った事はないんですけど、つんでれんことかaviutlでのエンコードなら設定次第で可能なんでしょうか？

更新したらsage忘れましたすみません…

画質なり音質なりを落として100MBに収めてます

やってみればいいじゃん

動きがないとか動きがあっても画質落としまくればフルHD10分でも100MBに収まるよ

フルHD10分って1300kbpsぐらいしか使えないぞアニメでも24fps維持するならある程度の画質はinsaneでも無理だろう
のっぺりつるぺたエンコするかフレーム削るか目が悪いなら別だがな
URL貼ってくれたら色々スレ民が解説してくれるだろw

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

>>566

Youtubeとニコ動の大きな違いは、

・ニコ動は動画再生中にコメントが流れる
・ニコ動は動画再生中に広告やニュース(プレーヤーの上)が流れたり・切り替わったりする

だと思うけど、この辺の負荷が大きいような気がする。
Bフレやビットレートの再生負荷もある程度有ると思うけど、再生して同じ場面でもカクついたり
カクつかなかったりするから。
ニュース(プレーヤーの上)が切り替わる時、再生が一瞬止まる（ドロップ発生）ことが多いんだよね。

新バージョンのZeroは試してないけど、Zeroだと違うのかな？

ググったり別のビデオでも試したがわからなかったのでご助力ください
スレチだったら誘導してもらえるとありがたい

【問題点】mpeg2→mp4で、動画先頭(1秒程度)のみ、画面ほぼ全体に灰色のノイズが発生

【元ファイル】キャプチャボードで録画したゲーム映像(mpeg2)を編集、640x480、
29.970fps、2895kbps、映2454kbps、音384kbpsのmpeg2
ビットレートはソフトのデフォのまま

【出来上がり】何れも640x480、映520kbps、音48kbps、ノイズ発生
・00:30.030、29.970fps、固定、567kbps ←元ビデオ.16から開始
・00:30.030、29.970fps、固定、568kbps ←.15から開始
・00:30.030、29.970fps、固定、570kbps ←頭から開始(以下2つも同様)
・00:30.030、29.970fps、可変、570kbps
・00:30.000、30.000fps、可変、567kbps

aviやwmvからだとノイズはないが、前者はHDDの容量の都合で極力避けたい
後者は画質が望んでいるレベルから程遠かった

【使用ソフト】Ulead VideoStudio 7 SE、つんでれんこ
【PC環境】WinXP sp3

バイナリから弄ってどうなるもんでもないよね？(弄ろうにもどこがどれだか、という状態)

忍法帳のためにレス消費した。申し訳ない。宜しくお願いします

>>585-587
使ってるつんでれんこのバージョンは？
もし最新のv2.71を使ってみて駄目なら、夏蓮根の最新v1.51を試してみるといいかもしれない。

Ulead VideoStudio 7 SEが気になるしこれからの出力は何を使ってるのか不明だし・・・

ああそうか、VideoStudioからmpeg2保存してつんでれんこに渡したわけじゃなく、
キャプチャボードでmpeg2で保存したものをVideoStudioで編集して
なんらかの形式で出力してつんでれんこに渡したのかな？
そのへんの手順も明確にしたほうがよさそうだね。

>>588、589
つんではv2.71。夏蓮根v1.51、試してみたが変わらなかった

VS7については古い事を指してる？
↑で>>585の元ファイルに書いたmpeg2を作って、それをmp4にしてる
書き方が悪かったのならすみません

mpeg2→mpeg2で劣化させるんならdivxでも他の使ったらいいんじゃない

同意。mpeg2で出力するんじゃなくDivXのAVIで出力すればいいんじゃないかな。
640x480で2800kbpsも使えばファイルサイズも上のmpeg2と同等だし、画質も十分綺麗になるでしょ。

あと、問題の出るmpeg2をどこかにサンプルとしてアップしておけば夏蓮根の作者あたりが
対応してくれるかもしれないね。

>>582
あった。これです
http://www.nicovideo.jp/watch/sm15713348

俺は別にフルHDで投稿しようって気はないんですけど、画質音質あんま落とさず容量下げる術のヒントになってくれないもんかと思ってます

動きの少ないシーン多いから低ビットレートでも綺麗になる。
さらにfpsが29.97だけど、コマ落ち多くて同一画像のフレームが多いから実質的にはもっと低フレームレートだし。
設定は極普通だからそれDLしてそのままつんでれんこに入れても普通にそれくらいな画質になるよ

>>593
夏蓮根のメンテナです。

>>585-587さん と同一かどうかわかりませんが、ある方から同じような症状になるサンプルを頂きました。
問題の動画は、Codec : MPEG-1V で、
この動画の場合は、ffmpeg.exeで一旦aviに変換すれば問題が起きないことは確認しました。

ffmpeg.exeからx264にパイプで渡せば良いかと思うのですが、まだ解決していません。

ただ、問題が起きるのがMPEG-1V な動画全てなのかどうかがわからないので、自動処理としてはどうすべきかな、と思っています。

設定ファイルでデコーダを選ぶことは出来るので、自動で処理するのではなく、
設定ファイルで選択する候補に追加する方が良いのかもしれませ
ちょっと検討してみます

>>590、592、593
前回見落とし、すみません。ソフト:形式IN/OUTで書くと
キャプボ:mpeg2、VS7:mpeg2/mpeg2、つんで:mpeg2/mp4
という形で作業をしてます
DivXのAVI、試してみます。結果報告まで少し時間掛かると思います
レスありがとう。助かってます

度々すみません
>>596
私とは別の方ですね
ご参考までに、下記にエンコ前後のファイルをzipにしたものをupしました
DLパスは「nico」です
いつもは塗りつぶしのようではなくまだらで出てましたが…よろしければご参照下さい
ttp://www1.axfc.net/uploader/Ne/so/138970

>>595
細かくありがとう。嬉しい限りっす

とりあえずつんでれんこ入れてみる。理由もなく敬遠してたんだが今持ってる動画編集ソフトで色々悩むよりよっぽど結果が早く出せそうな気がしました！

>>598
ありがとうございます。
こちらは、MPEG-2Vですか。じゃあ、codecで判定しちゃダメってことですねぇ
ちょっと対応方法を考えてみます。


# 既にmpegになっているものについては、aviに変換すれば正常にエンコードできるようです
# その際、画質的には、UtVideo Codec等の可逆コーデックを使うのがベターです
# 何を使ってもいいですが、夏蓮根の「おまけ_音声と動画の抽出スクリプト」でも動画を出力するように設定すれば変換できます

>>599
つんでれんこの設定はプリセットとしてはかなり練られてるから、ある程度の知識持っててもあれよりいいエンコードをするのはハードルかなり高いよ。
下手にAviUtlとかで設定作ってやるよりよっぽどいいものが出来る。

質問です。

http://nicowiki.com/aviutl_h264.html
こちらのページを参考にし動画のエンコードを進めているのですが、
バッチ登録の項にあるMP4BOXの指定が出来なくて困っております。
(該当箇所がremuxer.exeの指定になっている)
指定されているプラグインは全て入れてあるはずなのですが、何か入れ忘れている物があるのでしょうか？

aviutlは0.99m、拡張 x264 出力（GUI）は1.57を使用しております。

>>602
L-SMASH muxer用のx264guiEx.iniを入れてるからそうなってる。
mp4box使いたいならauoフォルダに入ってるx264guiEx.iniを使用しましょう

>>603
ファイルを入れ直したら無事、目的が達成できました。
ありがとうございました

>>604
バージョンがx264guiEXの最新版と同一だったので分かったけど、
x264guiとx264guiEXは別プラグインなので区別して書くようにしないと混乱しかねないので注意

avi=無圧縮のイメージだったもので申し訳ない
いただいたアドバイスを参考に、mpeg2→avi(圧縮)→mp4でノイズ発生しなくなりました
コーデックはどれにするか検討中ですが、取り敢えず解決することができました
ありがとうございました

無劣化にこだわるならUtVideo、劣化許容するならDivx辺りかな

重ねてありがとう。その2つも候補に入れてる
avi作る段階で音ズレしたりしてるっぽいからもうちょっと試行錯誤してみるよ

創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね　
創価 死ね　
創価 死ね　
創価 死ね　
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね
創価 死ね

つんでれんこで作ったのにニコニコうｐるとエンコードが終わらないのですが
こういう場合もあるのですか？　つんでれんこってｐが一番高音質にできますね。
自分でやってた時より高音質になったけど、やっぱ少し安いスピーカーで聞いてるような音になってしまいますね。

つんでれんこの音声エンコードはどのプリセットも共通。ビットレート上げれば高音質になる

いや、それぞれ３２０ｋｂで作ったけど音質変わってたよｐが一番よかったです。
後、動画じゃなく画像とＷＡＶＥくっつけると音質一番よくなかったです。

↓念視能力を持つ御方が颯爽と登場

自己解決しました！動画と音楽の長さが少し違っていてエンコードエラーになっていたみたいです。
調度同じにしてうｐれました。

ちなみに上に書いたｐは、つんでれんこの　どのプリセットを選ぶ？ｌ〜ｘという中のｐです。

>>614
解決したのは、おめでとう
ただ、「長さが違っているせいでエンコードエラー」ってのは、これまで見たことないなぁ
音のほうが長い時は、動画の最後にシークできないで音だけ鳴る部分ができるだけだし

ちなみに、夏蓮根では、音のほうが長かったら、動画に合わせて自動で最後をカットするようになっている

同じ素材を全く同じようにエンコードしたら同じ結果になるので音質の差は出ません

60iの動画をエンコードする際に
インターレースの解除はどうするのがよいのでしょうか？
そのまま解除しなくても、動画自体のインタレが気になることはないのですが
アイコンや画像などを早く移動させるとちょっと気になることもあるし･･･
解除したらしたで、60iの滑らかさはどうなりますか？
落ちますか？

>>617
Flash Playerがインターレース対応してないから解除しないとダメでしょ。
滑らかさを保ちたいなら60pにすればいい。

便乗してちょっと質問
Aviutlで60fps読み込みすると輪郭とかがチカチカして見えるんだけどこういうもん？
ソースはもちろん60iの映像

1フレームを2フィールドに分解して、歯抜けになっている画素を補完して2フレームにするんだと思うけど、
その処理過程でこういう事が起こるのかな？それとも何かやり方が悪いんだろうか

>>619
そういうもの。

60fpsフリッカ軽減でぐぐると幸せになれるかもしれない

>>618
詳しいことはわからないのですが
aviutlでインターレースを自動にすればいいですか？
60pでなくて、60iで撮影した動画では今更どうしようもないですよね
解除した場合、60iそのものよりは滑らかさは劣るのでしょうか？

>>622
AviUtlなら動画ファイルを読み込むときに60fps読み込みにチェックを入れてインターレース解除なしで書き出せば60pになるよ。
フィールドオーダーは先に指定しておく必要あるだろうけど。

30pにするなら自動よりは二重化の方が滑らかに見えると思う。
ダブったフレームになるだろうけど。

すいません、読み込むファイルなんですが
編集ソフトで編集して、utvideoで書き出したaviなんです
フレームは2997でした
これをドラッグで読み込ませたらどうしたらいいのでしょうか？
解除なしにすればいいのか、自動にすればいいのか

60fpsの読み込みのチェックの項目ってどこにありますか

インターレスをプログレにする時
60iの場合30pにするのはなぜかというと
60ｐにして隙間補間したとしてフレームごとに１ドット分上下にぶれるからです。
補間なしでも同じですが、上下幅が半分になるので体幹としては倍ずれることになります。
仮にこの上下のズレも補間したとして完全にはなりません。
動きがあればごまかせるけど、動きが少ないと境目のところなど色や明るさの差がある部分で
動きがないはずなのに変化を繰り返すことになります。
たぶん、>>619の言っているチカチカはこれが原因かもしれないですね。

>>621の言ってるのは、時間軸系のノイズ除去フィルタを使えってことだろうけど
これだと動きの速い部分がノイズと判断されて消える可能性があるので・・・。
60iを無理に60pにせずに30pでやるのが賢明な判断だと思いますよ。

60iを60pにしてる例みたいな動画ないですかね？

糞補間じゃなきゃそんな風にブレないぞ

>>624
ドラッグじゃなくてファイル→開くから読み込む。
出てきたウィンドウに60ｆｐｓ読み込みのチェックボックスあるよ

60pにしたいなら60fps読み込みのチェックつけて解除なしで出力。
30pにしたいなら普通に読み込んで解除は自動か二重化で出力。

>>624を見た感じ、編集ソフトでインタレ解除済みな気がするから
AviUtlで60fps読み込みとかインタレ解除とかする必要はない気がする。
なんにせよ編集全体を通しての動画の扱いの問題だからこのスレではスレ違いじゃないかね。
自分が使ってる編集ソフトでのインタレースの扱いとかを調べたり、
一般的なインタレースについての知識をググって調べたりしたほうがいいと思うが。

>>627
じゃあAviutlは糞補間なの？

皆さんありがとうございます。勉強になります
若干スレチなようでしたらごめんなさい
もう少しだけお願いします。

つまりは60iとか滑らかさとか考えずに、
インターレースは解除を選んでおけばようつべでは大丈夫でしょうか？
解除にすれば、自動で60iから30pというものになると思っていていいですか？


ソフトでこの可逆圧縮のaviを書き出して、aviutlでMP4にした物をいくつか作ったのですが、
実写映像の部分はよこしまが着になることはなかったんですけど
重ねた画像とかにアニメーションをつけて流すと横島が見えました。
これってインターレース解除にはなってないのでしょうかね？

60i→30p or 60pにする工程と動画編集は別にすべき

>>631
元素材となる動画がどんなものかもわからないし、使ってる編集ソフトの名前もわからない。
編集ソフトへの読み込みや処理、書き出し方法なんかでも変わってくるだろうし、
編集ソフトでインターレース解除をやってくれてるのか、AviUtlでやらなきゃならないのかちゃんと調べないといけない。
インターレース解除の手法にしたって色々あるから素材にあわせてやらないとダメなんじゃないの。
そういったことを初心者にゼロからここでレクチャーするわけにもいかないし、
インターレースについての解説サイトは色々あるんだからググったりして知識をつけていくしかないんじゃないの。

間違いないのは、元素材を編集してMP4にするまでのどこかでインターレース解除を行わないとダメだということ。
気になる横縞が残るようなら、素材の扱いや解除の方法を何か間違えてる可能性が高いということ。
どこで間違えてるのかは、自分の編集の各段階を１つ１つ見直して原因を突き止めないといけないということ。

だと思うのだが。

あれですよね？
インタレ解除のないまま、可逆圧縮でやってしまうと
横島がそのまま残ったママ固まってしまうから、
切り離した方がいいってそんな感じですよね？
どこかの工程でそうなってしまっているような気は自分もしていますが
もう頭がいっぱい出回りません。処理限界超えてる･･･

一応、元素材はハンディカムの60iのm2ts動画です
編集ソフトはビデオスタジオ
編集ソフトで可逆圧縮で出す時に、まずインタレ解除がどうなってるかですかね
少し頭を冷やして、順番で考えてみます
とりあえず、ようつべに揚げる際には
インタレ解除した方がいいというのがわかっただけでも助かりました。

つべは60pで上げても意味ないんじゃない？
再エンコで30pになるんで

ボカロ動画の画素数って、いまの主流はどうなっているんでしょうか？ランキングに載るような有名Pさんの動画とか。
自分がエンコードする際は、512×384だと27インチディスプレイで観るのは厳しいかな、でもHD画質だと重くて嫌がられるかな、などとウダウダ迷ってしまいます…。

Zeroサイズでいいんじゃね？

凝ったPVならそれなりに細かいほうがいい
1枚絵とかならfpsを落とせば負荷を下げられる

今ならHD解像度でも問題ないと思うけどな。
下手な設定しなけりゃ重くなることもないだろうし。

FullHDはやめてくれと思うけど。

前々から思ってたんだがプレイヤーの表示サイズぴったりにするのはその方が綺麗だからなの？
原宿とZEROがどうなるか分からない時期だから、
色々悩んだあげく適当にメジャーな解像度でよくねと思ってしまう。

ぴったりの方が綺麗

あとNVIDIA ION搭載のPCだと、FlashのDXVAが有効の場合どういうわけか補間が効かずガタガタの動画になってたことがあったな
最近はHD3000のPCしか使ってないけど今でも発生してるのかな

dot by dot
ただプレイヤの整数倍に出力すれば色空間的には有利かもね

表示サイズがみんな同じとは限らないんだけどな

色空間に関しては、colormetrixだけ指定すればいいんだっけ？
それとも、colormetrix、colorprim、transfer全部指定した方がいいんだっけ？

x264でエンコード時にusing SSE2と出るんですが、CPUが3770kなので他の命令で実行したいです。
x264guiEx上でどこの設定で変更できるのでしょうか？

>>645
ttp://rigaya34589.blog135.fc2.com/blog-entry-182.html

ありがとうございます。asmオプションはgui画面からは指定できないのでしょうか？

>>647
「using SSE2」って、もしかしてログの最初に出てくる
　　　auo [info]: converting YUY2 -> nv12p, using SSE2
のことを言ってない？
これはx264guiEx内部で行っているデータ変換処理のことなのでx264の--asmは無関係。

x264で使われている命令は、そのもう少し下に出てくる
　　　x264 [info]: using cpu capabilities: SSE2
のところで表示される。
これは使ってるCPUを自動検出して適切な命令が使われてると思うけど。
もう一度ちゃんと確認してみることを勧める。

--asmオプションを指定したいなら拡張タブの追加コマンド欄に書けば普通に効く。

>>648
ありがとうございます。まさにそこのことを言ってました。そこは関係ないのですね。
using cpu capabilitiesのログが出ずに、下記な感じになってます。

auo [info]: converting YUY2 -> nv12p, using SSE2
auo [info]: arguments passed...
--bitrate 500 --pass
（以下略）

追加コマンド欄に書いてみて試してみますね。ありがとうございます。

すみませんlog表示がnoneになってました。infoにしたら色々な命令セット利用してるのを確認できました。
最初のusing SSE2のご指摘ありがとうございました。

ノイズ除去フィルタがありますが
これは非可逆圧縮された映像をソースにした場合向けで、
MMDから無圧縮もしくは可逆圧縮で出力した映像の
エンコードには必要ないと考えていいのでしょうか？

必要ない
むしろフィルタを掛けると(特に強く掛けた場合は)細かい模様とかをごっそり削ってしまう

わかりました。
ありがとうございます。

おまじないとしてAviUtl標準の「ノイズ除去（時間軸）」「ノイズ除去」だけデフォルト値でかけてる。
512x384 30fpsで出力したきしめんサンプルを --preset ultrafast --crf 23 でエンコした場合、
ノイズ除去無しだとファイルサイズは18,318KB、有りだと18,192KB。
Youtubeにある1080pのTell your Worldを640x360にリサイズして --crf 23 でエンコした場合、
ノイズ除去無しだと103MB、有りだと100MBとか。
この程度だと地味すぎるので本当におまじない程度。調整とか面倒なのでデフォルト値のままという超手抜き。
NL-meansとかは重いし。

地デジとかのノイズのりまくりのソースだとデフォでもかなり効果あるけどね。
特にアニメとか。

実写は微弱なグラデまですべてシグナルだから
ノイズ除去をかけると情報量の減少に直結するから難しい
ここは実写のエンコしてる人あんまりいないかもだけど

ニコニコみたいに制限のきつい所だとNLみたいに輪郭をしっかり保ったままぼかせるのを強くかけてエンコした方が
結果的に画質が良くなる事も多いのよね
実写はわからないけど

スレチだけどどなたかご教授ください
複数言語のまま圧縮できるコンテナって何がありますでしょうか？(ﾉω･､)

ガードの無いDVD教材などですが海外で長期滞在の際、会話力つける為に大量に買ってisoでリッピングしてHDDにつっこんでいました
が、HDDが満タンです

DVD形式みたいに字幕、音声、複数言語の選択が出来るエンコードって無いのでしょうか？
そういった高画質高圧縮が可能なコンテナがあればiso動画データ全部エンコードしたいのですが・・・・
どなたかお願いします┏○ペコ
当然ですが自分用です

「ご教授」っていってる教えて君見るとイラッとする

その前に日本語を覚えろよ

>>659
>>660
申し訳ないです
寝ずにググって色々調べてて日本語乙ってますね
ここって質問スレですよね？
ひとまずMKVコンテナ辺りが可能っぽいけど・・・画質が微妙だとか。

分かるのであれば教えてください┏○ペコ
知らないなら華麗にスルーして下さいね
MP4くらいの高画質でなんとかならないのかなぁ・・・4GB→700MB程度で

HDD増やせば解決するんじゃないの？
それを選択しない理由が明確でないと無駄な行為になるよ

別に無駄じゃ無かろう
HDD無駄に食いつぶす方がもったいない
Yambとかで全部くっつけたら？MKVでもいいけど
あとコンテナに画質求めるのはちょっと違わないか…

mkvだと画質微妙でmp4なら高画質とか言ってる時点で色々勘違いしてそう。
とりあえず初心者質問スレ行ったほうが良いよ。
http://toro.2ch.net/test/read.cgi/avi/1335404660/

isoファイルあるならHandbrakeで簡単にエンコできるんじゃない？

>>662
大事な映像もまじってるんでバックアップHDDもあります
すでに2TBHDDを2個満タン寸前、なので3TBを2台買い増しとかはちょっときついです

>>663
Yamb？ググってきます

>>664
色々まだわかってないんでもうちょっとググります
handBreakこないだ落としてきたけど仕事でまだテストしてなかったんで時間ある時設定調べてやってみますね

ありがとうございます┏○ペコ

>>661
＞知らないなら華麗にスルーして下さいね

スレチなのに、その態度はいかがなものか。
たとえ、思っていても書くのは大人として品格を疑われる

まぁ、五体投地なみにへりくだって書いたのに煽りで返されたりするとキレたくなったりはする

そんなへりくだらなくていいから自分で適切なスレを探すくらいの努力はしていただきたい
たまに本当に見当たらないこともあるがそういうときは該当板の総合・雑談・質問系スレに行くことにしている

>>668
【質問】て書いてるので質問スレだと思っていました；
スレチだったんですね
他探してきますね

>>669
1 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2012/04/06(金) 09:52:52.64 ID:i/Nnjuac0 [1/9]
ニコニコ動画へ動画をUPするためのFLV/MP4ファイル作成に関する質問スレです。
テンプレやwikiをよく読んで、わからない時に質問するようにしましょう。

※ここは『作成済みの動画をニコニコ動画にアップ出来る制限内のFLV/MP4に変換する』ためのスレです※


あのさぁ…

日本語分からないんだからもういいよ

http://i.nicovideo.jp/watch/sm18981246
ニコエンコよりつんでれんこの方がいい感じにエンコードできるのかな・・・？

Aviutlでaviファイルをmp4にエンコードしてます
設定は【拡張x264出力(GUI)Ex】の【プレミアム　実写　高画質】を使い、その他は扱っていません
出来上がったファイルは100M以下なのですがアップすると再エンコードされてしまいます
ニコ動にアップする場合プレミアム会員で容量(100M)以外に再エンコードに引っかかる条件って何が有るんでしょうか

ちなみに同じaviファイルをニコエンコでエンコした場合は再エンコードされず
夏蓮根(1.58)だと緑色のノイズがかかったガクガクした動画になってしまいました

>>673
>>10やってみた？

>>674
はい
『混雑中のため〜』の表示は出ませんでした

エンコしたファイルのMediainfoの情報とかが無いとなんとも。

>>676
失礼しました
元動画：http://pastebin.com/uDBBNMtp
aviutlエンコ後：http://pastebin.com/hFqxtKjL
何処までの情報が必要なのか解らなかったのでとりあえず全てコピペしてます

追記
元動画は30分くらいですがエンコは先頭から10分ほどを切り出してやってます

プロファイル : JVT
コーデック ID : avc1
になってるのはなんでだ

あーわかった。L-SMASH使ってるでしょ。
それ使わずにmp4box使ったら解決すると思うよ

>>680
ありがとうございます
mp4boxを使ってもう一度挑戦してみます

>>680
無事高画質のままUPする事が出来ました
ありがとうございました！

だいぶ前から気になってたんだけど、ニコニコの動画プレイヤーでは、全ての動画の上部1px分が
黒く塗りつぶされて表示されない。これって俺だけなのか？
結果として、黒い縁が下部は1pxなのに、上部は2pxあるように見える状態になってる。
画面キャプチャしたりものさしソフトで測ったりして調べても、表示されている縦幅が383pxしかない。
ニコニコ動画Zeroのプレイヤーで画面サイズを中にすれば、ちゃんと384px全て表示されるっぽい。

動画制作・投稿する側からしたら知っておく必要ありそうな事なのに、適当にぐぐってもそれらしい情報が
ヒットしないから、他の人はちゃんと表示されてるのか……？

なんとなくプレイヤ内で再生してる動画をキャプチャしたことあるけど384pxあったはず

エンコード後のファイルの品質にPCスペックって関係ありますか？
低スペックのPCでエンコしてるからカクカクってコメントをいただいたんだけど

え

>>685
画質、容量に微妙な差は生じるが、カクカクになるかどうかといった違いは起きない

x264の--threads
http://rigaya34589.blog135.fc2.com/blog-entry-268.html#more
http://rigaya34589.blog135.fc2.com/blog-entry-270.html#more
http://rigaya34589.blog135.fc2.com/blog-entry-272.html#more

ですよね
もしかしたら再生負荷的な事でカクカクって書きたかったのかな・・・

低スペックなPCで視聴してるからカクカクってのはあるけどね

1.UPした動画がカクカクして非常に見ずらいのでスムーズにしたい。
2.H264 29.97fps CBR(固定ビットレート)　CABAC 3300kbits/sec
3.93.48MB 640X364 mp4
4.Adobe Premiere Pro Cs4 TMPGEnc Video Mastering Works 5
5.Windouws7professional 64bit Corei7 x990 メモリ24GB

※2に関してはmediainfoにかけていないのでよくわかりません。
ニコは再エンコしているという話ですが、エンコする前は画質も良くスムーズに再生できている
のになぜＵＰするとそうなるのでしょうか？
でも他の動画とかで画質がきれいでしかもスムーズに動いているのもあるので何が問題なのでしょうか？
詳しくて親切な方教えて頂けるとありがたいのですが。
よろしくです。

追記
一応プレミア会員です。

>> 2.H264 29.97fps CBR(固定ビットレート)　CABAC 3300kbits/sec
動画のキャッシュが溜まって再生してもかくかくするのなら
エンコード設定が重たいのかもしれない

>>690
解決策でなくて申し訳ないけど、動画閲覧画面の下にある「一般回線で見る」
を押すと少しだけ改善されたりしない？
うちのPCも低スペックなんだけど、再生は同じ症状なんじゃないかと
(別件の問題でFlashPlayerは10.3の方入れてる)

↑の仕組みについては画質が低ければ再生できるって認識だけどそれで
合っているのかは調べてないからわからない
ちなみに見てたのは踊ってみたの変態画質とタグがついているような動画だった

>>692
ありがとうございます。
確かに設定が重いですね。
ニコでDLLしたファイルは40MBとかものすごくきれいでスムーズなのに
以外にファイルサイズは小さいのが多いですね。
このスレの8にありましたがこの手の質問はご法度だった見たいですね＞＜
再エンコ回避基準の中で平均ビットレートが映像、音声合わせて1049kbps以下
とありましたが現在もそうなのでしょうか？
後解像度は640x364で回避できるのでしょうか？
質問ばかりですいません。
ちなみに貴殿はどのくらいのビットレートでＵＰしてらっしゃいますか？
よろしくおねがいします。

>>693
ありがとうございます。
「一般回線で見る」とかあったんですね。
一応試して見ました。多少改善されたように思います。
あとflash playerはバージョンは11activeXが入ってます。
flash playerって32bit対応だから64bitではカクカクしますとマイクロソフト
の人に言われましたが、他の方の動画はスムーズできれいですからそれは
違うのではと思いましたがどうなんでしょうね。
いずれにしてもありがとうございます。

画質が悪いから再生が軽いなんてのは全くの間違い
重い動画程画質良くなりやすい、軽い動画程画質悪くなりやすいのは確かだけども

一般回線で視聴ってのやるとニコニコに再エンコされた、
いわゆる「低画質モード」とか「エコノミーモード」とかって言われる動画になる
これはエンコード設定も速度重視でビットレートも低いから再生も軽くなる

あと解像度、640x364とかって意味の分からない数値にせずに640ｘ360にしては？
まあ今はZeroの解像度、864ｘ486でうｐするのが主流だけど

更にAdobe製品でH.264にエンコードすると品質悪いから画質あげる為にビットレート高くしないといけなくなるんで、
劣化ないように書きだしたものをつんでれんこや夏蓮根でエンコードしてうｐすると同じ画質でもビットレートも軽くなるから問題解決すると思う

なんとなく11.5β入れたらtridentでもchromeでもかなりフレーム落ちは改善した。
今までは60fpsだと3コマに1コマとか飛んでたのがキャプチャして確かめてもほぼ60fpsで見れてる@win7 64、3930k
10bit動画の再生は相変わらずだがこんなに変わるとは思わんかった

>>696
ありがとうございます。
確かにAdobeのH264は使えないですね。
なので一応aviで出力して(場合によってはUt video Codecで可逆圧縮で)ます。
それからTMPGEnc Video Mastering Works 5でH.264出力しています。
AviUtlは以前使った事があるのですがどうも設定とかよくわからずPCを新しく
してからは使っていません。
でもやはり画質きれいでスムーズな動画をUPしている方々はそのつんでれんことか
夏蓮根とか使っているんでしょうね。(設定が大変そうですが）
Zeroはなんか使いずらそうなので通常のバージョンでアップしています。
いずれにしても参考になりました。
ありがとうございます。

>>697

ハードウェアアクセラレーション有効？

>>696
追記
640ｘ384の間違いでした。
すいません（汗）

>>697

あと、プレーヤーは？ ZERO？

>>696
エコノミーについてはあんまり理解できてなかったから思い切り
誤解を招く書き方をしてしまった
解説ありがとうございました。私も勉強になりました

>>696
Zoroバージョンで再生したらカクツキがなくなりました。
でも解像度が640x384なので画質がおちますね。
当たり前か。でも864ｘ486UPしたらまたカクカクするんですかね？
今度ためしてみます。

>>698
情報小出しにするな
あとMediainfo入れて出てきた情報をちゃんと出せ

>>704
別に小出しにしてないですよ
690見ればだいたいわかるでしょう？
教えてもくれない奴に偉そうに言われる筋合いはないよ

>>704
あと基本free softとかあまりインストしたくないんですよ
ほんとオタってネットとかで偉そうな奴多いな

悪いが俺は696だ

>>707
だったらそんな偉そうにする事ないでしょう？
いくら２ＣＨだからって。
こっちは真面目に誠意をもって聞いている訳だし。
記述ミスだってあるでしょうけど、それを「出せ！」とか普通そんな言い方
しないよ。
あまり詳しくないから詳しい人に聞きたい訳だけどそんなんじゃ質問する奴
いなくなるでしょうよ！
質問側も同じ人間なんだから。

>>707
なんなだよこのスレは。
質問スレじゃないのかよ。
あなたみたいな人がいるからオタクはバカにされるんだよ。
なんかリアルでオタクとかいたらいじめたくなるよ。

>>706
メーカーのサポートにメールしろ
その方が早いだろ情弱

>>707
でも感謝はしますよ。
回答してくれたわけだから。
嫌な思いはしたが、なんとなく解った事
プレミア会員のビットレート制限が撤廃され出力ファイルサイズ100MB以下なら
再エンコされない。
しかし、エンコの時のビットレートが高過ぎるといくら100MB以下であったとしても
カクツク原因になる可能性がある。
僕の場合、TMPGEnc Video Mastering Works 5で固定で3300で出力した98MBのファイルが
カクツいたので固定ではなく2PSSで平均ビットレート1500〜2000ぐらいでエンコしてみよう
と思う。

該当する動画へのリンクを貼ればすぐ解決したと思うのだが
いまさら2chの書き込みと紐づけするようなことしたくないだろうな

テンプレで求められてる後から出した情報があったらまた答えが変わるんだよ
だからテンプレでそういう情報出せって書いてあるのが分からんのか
そして「※2に関してはmediainfoにかけていないのでよくわかりません。 」はミスじゃなくて故意だ

TMPEGも進化したもんだな

ミス、TMPGEnc

>>710
ニコでUPした時にカクカクするのでその原因が知りたかったんですよ。
メーカーにメールしてもわかんないでしょ！
だからオタクに聞きにきた訳だけどこんなに偉そうな奴が多いとは
思わなかったですよ。
ググれば！の意味がよくわかったよ。
しかし、このスレのタイトル変えた方がいいよ。
それと1の所に8の内容も入れておいたほうがお互い嫌な思いしなくて
すみますから次のスレはそうしてくださいな。
たぶん俺だけじゃなさそうだもん。上の方から読んだけど結構嫌な回答
してる奴多いんでびっくりしたわ。

>>713
ここではmediainfoとかが当たり前なのでしょうがfree soft入れると不具合の
原因になる場合が多々あるので入れたくないんですよ。
mediainfoのなんの情報が逆に知りたいのかが解れば知らべる術はあったのです
けどね。
一応書いときますよ。
DVD DecrypterでリッピングしたファイルVOBをadobe premiere Proで編集して
ＴＭＰＥＧでh264で出力したファイルです。
一応その時premiereから出力するときは劣化を防ぐためにUt video coder
でavi で出力したファイルですよ。
1の項目をみて690に記述したのですが、ここまで書けばわかるのかな？？
ミスは前スレちゃんと読んで下さいよ。
640x384 を　640ｘ364　と書いた事に対してそんな訳のわからない解像度で
ＵＰしない方がいいよと言われたのでその時記述ミスに気がついたわけですが
そのミスの事ですよ。
故意でもなんでもないよ。
ちゃんとスレ読んでくれよ。

>>713
それに最初からfree softは入れたくないなんて宣言したら
あなたみたいな人に袋叩きあいそうだし、そもそも失礼だから
知りうる範囲で書いたんですよ。
なんでそんなに怒られなきゃいけないんだよ。
なんかここ異常だぜ

TMPGEncの人ここ行って聞いてね
ttp://toro.2ch.net/test/read.cgi/avi/1336701629/

UPした時の動画がカクカクするのは設定が重いせいだぞ
アドバイスは軽い設定でエンコードしろだ

最後に自己弁護しておきますね。
情報を小出しにしたのではなく、ここでのやり取りで解った事
が結構あったので追記的に情報を出していったのですよ。
後で読んでくれた人でもしかしたら回答してくれるかもしれないとね。
俺はあまり2chこないけど現実世界の会話とあまりにも違いすぎるのも
人としてどうかと思いますよ。
キャラ変わりすぎの人が結構多いのでは？？
力のある人、人より優位に立ってる人なのであればなおさらですよ。
ではでは。

>>719
ありがとう。
あなたみたにいい人もいるんですね。
ちょっと安心しましたよ。

　　　　　　　　　　　　　 ,,.. -──-　､,
　 　 　　　　　　　 ,. ‐'":::::::::::::::::　 　....:｀`'-､
　　　　　　　　 ,／:::::::::::::::::::　....::::::::::::::::::::::::ヾ:､　　　　　　,....,
　 　 　 　 　 ／:::::::::::::::　..:::::::::::::::i､::::::::::::::::::::'､':,.　　　 ／　　ヽ
　　　　　　 /:::::::::::　....:::::::::::::::::::::i:::!`､:ﾄ､::::::::::::i i!　　 /　　　　 i
　　　　　　i　　　...::::::|'､ヽ;::::::::::::::|,!:!__ﾘ,,'iヽ::l''､:'､ 　 / 　 　 　/
　 　 　 　 |　..::::::::;:::i!:i ヾ:､ヽ:::::::::| ﾘ , -─ ﾘ　i;il:ヽ, i　　　　/　　　　あはははは〜
　 　 　　　l:::::::::::::::i',i ':i　,メ､ ＼;:l　'ﾞ　　　　`､　!::::/l ...::::::/｀`ヽ
　　　　　　l::ヽ:::::ヽ:i,レ',.ﾞ-‐''''　　　　　　　　　',/'/..::::::::::/ 　　 l'ヽ;､　　こいつ２ちゃんで態度を
　　　　　　 i:::::>､:ヾ,' /　　　　 _,.. -‐'ヾi　　　 ,ﾚ'::::::::::;r':..　　 /　 i_＼
　　　　　 　 i:::i.　`'‐,ゝ　　　 i" 　 　 　 '! ,.‐''" :::::::::::iﾞ::::::::...／.　 ﾉ 'i　　　　気にしてるよ
　 　 　 　 　 !::＼　`ヽ　　　　':,　　　　　l{　　 ..:::::／::L,. ‐'":::::;／　 !
　 　 　 　 　 l::::::::`''‐r＼　　　 ヽ.,＿_,.ノィ'‐-‐''"'ｫ‐--,ﾞ弋''''"::::::;.ノ
　　　　 　 　 |::::::::;ｨ:::}､　｀`'''─--､-‐ﾆ┤　＿__ハ,｀''ｰヽ-'=‐''":::
　 　 　 　 　 !::::::/ i:::|､＼　　　　　ヾ´.　i　　ヽ　　 ､''‐-､_:::::::::::::::::　／
　 　 　　　　i:::::/　i:::ハヽ｀''‐､／l＿_＼,|　／　　　 ヽ--､,.ﾆ=‐--‐'"

このスレ見ながら5分くらい考え込んてしまった・・・。

だめだこりゃ

知的障害者と精神異常者の嫌なところは自分が正常だと思ってること

mediainfoってやたら更新多いけど何やってるの？

フリソに偏見を持った人間が二コニコに投稿するのは難しい
x264すら使えんな
フリソに偏見を持ち続けていつまでも苦しむがいいさ

UTだってフリソじゃん
使うなよwwww
フリソdisっといて何だ？

ビットレートちょっと上がったくらいでカクカクとかあるの？
読み込みが間に合わなくてってのは分かるけど

平均ビットレートより瞬間ビットレートが高くなりすぎてカクカクになったり止まったりってのはあるね

CBR(固定ビットレート)
てとこがまずかったりするの？

h.264はキーフレームを除いてフレーム間の差分だけを記録する事で圧縮率を上げている（gifアニメみたいに1枚絵の連続ではない）から
固定ビットレートだと動きの少ない（差分の少ない）部分で無駄にきれいになって激しい部分（差分が多い）で汚くなってしまう

ニコニコの低画質モードってCBRじゃないっけ
動画見る限りそんな感じの荒れ方してる
カクカクするとかっていう重さって観点なら動き激しい部分でもビットレート低いCBRの方がVBRより軽くなる可能性はあるかと

CBRと言うよりもMAXレートを抑えてあるんじゃね
上限を抑えとけばファイルサイズは必ず想定内に収まるし
上限超えない分はそのまま帯域の節約になるから鯖側にはお得だ

いつからかわからないけどguiExの高速1st pass効かなくなってる？
ログ見ると最初から2回目と同じ設定でエンコしてるのと1回目と2回目でほぼ同じ時間かかってる

問題ないけどね
preset slowerあたりで再検証してみな

ニコニコでアプコンされた動画探してみたけど凄いな…
warpsharpかけまくり破綻しまくりな動画を解像度高いだけでみんな綺麗綺麗言ってるじゃねえか…それも1つどころかほとんどという…
批判的な意見もほとんどないし目がおかしいんじゃねえのか

今まで個人的にエンコードをしていたもののニコニコには投稿していませんでした
これから投稿しようと考えているのですが、プレミアム会員で100MB未満のファイルでも
MP4BOXではなくL-SMASHを使用して作成した動画は再エンコードされてしまうのでしょうか？
>>673-682でそのような話が出ているので気になり質問させてもらいました

やってみたら？

>>738
>>673です
動画ファイルのサイズを70M程度まで落として投稿してみても再エンコされてました

>>740
>>682はなんなの

ゴメン。
ちょっと読み違えてた。
無視して。

>>740
ありがとうございます！
L-SMASHは使用しない方がよさそうですね

>>743
それはL-SMASH関係ない
gpac版のx264でmp4出力してるのが悪い
L-SMASHのremuxerはbrandに関しては全ての入力ファイルから全てのbrandを継承するだけでmajor_brand
の書き換えなどはしない
どうしてもx264でmp4出力したければx264_L-SMASHを使う
どうしてもgpac版x264を使いたければraw bitstream出力した後にL-SMASHのmuxer（remuxerではない）を使いMP4にmuxしmajor_brandをmp42にする

はっきり言ってMP4を作りたいのであればGPACを全ての過程から排除すべき（勿論MP4やGPACの仕様等を熟知しているのなら別だが）
よくわからないのであれば尚更L-SMASH（のみ）を使うべき

mp42にしたいたらyambに放り込んでremixじゃだめなん

yambとか使ったこと無いからしらんけどMP4Boxだと-brand mp42を指定してmajor_brandをmp42にすればいい

gpac版のx264のmp4 muxerはmajor_brandをavc1に
MP4Boxを-brandオプション指定なしに使用するとisomをmajor_brandに指定する
MP4でmajor_brandをiso* (iso5とかisomとか）にするのははっきり言っておかしい

とりあえずx264guiEx＆L-SMASHの組み合わせでサンプルアップロードしてテストしてみたよ。
詳細は動画説明文に書いたのでそちらをどうぞ。
一応x264guiEx.iniを書き換えて音声を先にremuxするようにしてもうまくいくみたいだけど、
それをやるくらいなら>>744の言うとおりx264_L-SMASHを使ったほうがいいんじゃないかと思った。

　　x264guiEx.iniをL-SMASH用に置き換えたもの（Mux時に映像を先に取り込み）
　　http://www.nicovideo.jp/watch/sm19091798
　　　　→major_brandはavc1。再エンコードされてしまう。

　　x264guiEx.iniをL-SMASH用に置き換え、更にbase_cmdを書き変えたもの（Mux時に音声を先に取り込み）
　　http://www.nicovideo.jp/watch/sm19091863
　　　　→major_brandはmp42。再エンコードされない。

　　x264_L-SMASHでエンコード＆Mux
　　http://www.nicovideo.jp/watch/sm19091971
　　　　→major_brandはmp42。再エンコードされない。

一応major_brandの違いを挙げてみたけど、再エンコされてしまう原因がmajor_brandなのかどうかは知らない。

書き込んでから
　　「再エンコードされてたやつのmajor_brandをバイナリエディタでavc1からmp42に変えてアップしてみりゃいいじゃん」
ということに気づいたので追加テスト。

　　http://www.nicovideo.jp/watch/sm19092081

mp42にしたら再エンコードされなくなりました。

>>737
高音質とかいってAACの300kbps以上だったり音が割れてたり
所詮子供の集まりだから自分で良し悪しを確かめずタイトルや周りにつられて絶賛したりするのがニコ動

なんか書き方がいまいちだったのでまとめ。

■x264guiExでエンコードする際に気をつけること（x264guiEx v1.57を想定）

　●x264_L-SMASH（内蔵MuxerにL-SMASHを採用しているx264.exe）を使う場合

　　　　→○外部Muxerがどれかに関わらず基本的にmajor_brandは
　　　　　　　mp42になるので今回の問題は気にしなくてよい。

　●x264_GPAC（内蔵MuxerにGPACを使っているx264.exe。例えばx264.nlのバイナリなど）を使う場合

　　　　→○外部MuxerにMP4Boxを使う場合は、-brand mp42が指定されるようになっているので問題ない。

　　　　→★外部MuxerにL-SMASHを使う場合、major_brandがavc1になってしまうので
　　　　　　　サーバー側で再エンコードされてしまうという問題が発生する。

ぶいまにさんがtwitterでこの件について触れてた
https://twitter.com/MP4_maniac
https://twitter.com/K4095

この辺のやり取り見たらどういうことか大体わかった
ツイート抜き出して時系列順に並べるの面倒だったので上の二人のやり取りさかのぼって見て下さい

>>750
AACの300kbpsでも世間一般に言われる"高音質"に当たると思うが

>>750
truevbr 127が低音質とな

音質ってか再現性云々の話？
とりあえず「高音質」って設定にして喜んでるってこと？

なんか>>751も微妙に誤解を招きそうなのでもう少し補足整理。
major_brandと言ってるのは、MediaInfoで言うと「"General"の項目の１つである"Codec ID"」に示されるものです。

x264guiExのニコニコ動画向けエンコードの流れは基本的に以下のようになっています。
やり方によって順番等を変えることもできますが基本の流れのみ触れます。
　　手順１．映像をエンコードして、映像のみのmp4を出力。
　　手順２．neroAacEncで音声をエンコードして、音声のみのm4aを出力。（major_brandはmp42）
　　手順３．１と２を外部MuxerでMuxして、最終的なmp4を作成。

まず手順１で出力されるmp4は、以下のようになります。
　　●x264_GPACを使った場合はmajor_brandがavc1になる
　　●x264_L-SMASHを使った場合はmajor_brandがmp42になる

次に手順３については、以下のようになります。
　　●MP4Boxを使う場合は、-brand mp42を明示指定するので、最終のMP4のmajor_brandはmp42になる。
　　●L-SMASHを使う場合は、Muxするもののmajor_brandを継承するので、最終のMP4のmajor_brandは以下のようになる。
　　　　　・手順１でx264_GPACを使っていればavc1
　　　　　・手順１でx264_L-SMASHを使っている場合はmp42

L-SMASHだけが原因でavc1になってるわけじゃなく、
　　・x264guiExの出力手順
　　・x264_GPACはavc1で出力する
　　・L-SMASHのremuxer.exeはmajor_brandを継承する
という３つの仕様のあわせ技でavc1になってしまうことがあるということです。

ちなみにニコニコではmajor_brandをmp42にしてアップしても、サーバー側でisomに変更されます。
アップロードしたものを落としてみるとmajor_brandがisomになっていることがわかります。

そこまでビットレートあげるならmp3のほうが音がいいとかいう話じゃないの？
なんでaacなんだよｗと

より上があるから高音質じゃないって言ってんならそれこそ見当違いだと思うけど
自分で良し悪しを確かめずフォーマットだけ見てることになるし
そもそも高音質の基準も曖昧なのに

子供が128kと320kの違いなんて聴き分けられるわけないのに
ビットを浪費してるだけだからな

ソースが128kなのに320kで再エンコして高音質なんて言ってたら
それはもはや悪意に満ちた詐欺だからな

再エンコード時にビットレートを上げるのは
ソース保持的に一般的なテクニックの一つだろ
詐欺とは違うと思うね
それが高画質高音質なのかはまた別の問題

>>750
自分の上げた動画が56Kbpsで高音質言われてるときは
お前ら耳鼻科行ってこいってマジで思ったわ

そもそも、人の耳の分解能が（ｒｙ

>>761
ビットレートが高ければ高音質だと思って96を320にするやつもいるって話だろ
96の音質をできるだけ維持するために192とかにするのは別の話
ていうかそれするなら分離して生のまま合わせろよと思うけど(加工とかしないならね)

flvにwav入れてる動画とかあるけど、あれはちゃんと再生されてるの？
flash playerが勝手にいじってたりはしないんだよね？

とりあえず音は出るし音質も圧縮音源よりは良く聞こえる
厳密に元と同じ音が出てるかはシラネ

>>743です
たくさんのレスありがとうございます
gpac版のx264を仕様することがいけなかったのですね
解説、検証をしてくださったスレの皆様、金の髭様、muken様、たくあん様に重ねてお礼申し上げます
本当にありがとうございました

gpac版のx264を使用するのがいけないって結論じゃないぞ
avc1 brandでうｐするとダメって話で、そうなる原因の一つにgpac版のｘ264を使用ってのがあるだけでそれを使っても再エンコされない動画は作れる

>>762
俺はお前だ

たくあん氏とmuken氏のツイート見る限り
x264guiExでmp4出力する際は.264で出力してからMP4BoxやmuxerでMP4にmuxするのではなくx264から直接.mp4を出力して音声とMP4Boxやremuxerでremuxする。
その際gpac版のx264だとgpac mp4 muxerが使われmajor_brandにavc1が付けられる。（L-SMASH版だとmp42になる）
これをMP4Boxでremuxするとmajor_brandがisomに上書きされる。（muken氏曰くこれはおかしいらしい）
remuxerでremuxすると互換性の観点からbrandの書き換えはまずいというL-SMASHの方針からmajor_brand avc1が維持される。
たくあん氏は
「取り敢えず*.264で出力してからmuxerでmp4にするようにしたりMP4Boxでmuxするなりしたらそもそもこんな問題は起きなかったと思う」
「取り敢えずx264guiExでgpac版x264とL-SMASHの組み合わせはx264guiExに一旦raw bitstreamで出力後L-SMASH muxerでMP4にするオプションでもつかない限り
ニコニコ動画に投稿する用途では実用的じゃないと思う．」
といってる。
そこでmuken氏がx264にニコニコで再エンコードされないようにmajor_brandをavc1以外にするpatch書くかって言ってる。

結論としては
次のx264の更新でgpac版のx264でも問題なくなるはず。
現行のリビジョンを使うのであればmuxerにL-SMASHを使う場合はx264もL-SMASH版を使うべき。
たくあん氏の言うような”一旦raw bitstreamで出力後muxerでMP4にするオプション”がguiExに実装されれば現行のリビジョンのgpac版x264とL-SMASHの組み合わせでも問題はなくなる。

x264_GPACを使った場合でL-SMASHのremuxer.exeだとmp42やisomは不可能って理解でOK？

>>770
thx L-SMASH版使用が無難なんですね

guiExのmp4出力を使う限りでは無理。
.264で出力してから自分でコマンドラインからmuxerでmp4にmuxすると自動的にmajor_brandがmp42になる。

公式アニメの情報見てみたんだけど、フレームレート29.97fpsになってた。
テレビ放送版を確認する限り、23.976fpsのはずなんだが、ニコ動版は結構適当エンコなのかな？

正直L-SMASHはあまり使いたくないな、今の時点では
SH-01Bがコンテナがisomじゃないと音声しか再生されない謎仕様だったり、Writing application:にqaacのエンコオプションをいちいち書いたりするし
isom問題は携帯を買い換えれば解決するからまあいいとして、Writing applicationに余計なこと書く必要あるんだろうか

x264をraw出力してmuxerでmp4にしてqaacで作ったadtsもmuxerでm4aにし
muxerでremuxすればWriting applicationはL-SMASHになる

youtube板にエンコスレがここしかないからスレ違いを承知で聞きたい
H.264+AAC 29.97fpsの1080pをyoutubeに上げると音ズレするんだけど
エンコードオプションによって音ズレが発生したりするの？
ちなみに720pだとズレなかったりする
この音ズレ解消法知ってる人がいるなら教えて欲しい

またかよ

>>775
L-SMASHがqaacのエンコオプションを後から調べて追記できる訳ないだろ
qaacの作者に文句言えよw

x264といいqaacといい、なんでこうまでエンコオプション隠したがるやつが多いのか

>>777
同じ動画なら、ほぼ一定の時間だけズレるみたいなので、
あらかじめ、その分ズラしておくぐらいしかないんじゃない？
https://twitter.com/charound30/statuses/246829816165326848

>>779
皆何も判ってないから数字に拘る
IPBフレームしかないのにそれすらも理解してないのだから(ry

つ

つべはAACよりmp3の方が相性いい後はggr

>>673-682 および >>738-773 で出ていた、「major_brandがavc1だと再エンコされてしまう」という件。
別途行った調査で「major_brandがmp41の場合も再エンコされてしまう」ということもわかっていたのですが、
本日18時前に、謎の人物から
　　「ニコニコの brand 判定を修正しました」
という連絡をいただき、あらためてテストしてみたところ、avc1でもmp41でも再エンコードされなくなっていました。

　　　MP4Boxで-brand mp41としてMuxしたものの再テスト
　　　http://www.nicovideo.jp/watch/sm19102737

　　　major_brand＝avc1での投稿の再テスト
　　　http://www.nicovideo.jp/watch/sm19102825

ほとんどの人はmp42またはisomでの投稿になっているはずなので元々関係なかったと思いますが、
この修正により、x264guiExでL-SMASHのremuxer.exeを利用するような場合も問題なくなったはず。
対応ありがとうございました。

うわーmuken氏から突っ込まれてるー

しかしよく分からん
fdk-aacでエンコするとWriting applicationがまるでffmpegですべて仕上げたようになるし、
neroaacだとWriting applicationではなくAudioのWriting libraryに表記される(mp3だがlameも同様)

試しにコマンドラインから出力したら、m4aの時点でこの違いが出てるんだな
ってことはmajor_brand問題と同じで、L-SMASHはWriting applicationをmux時に書き換える(削る)ことをしないからこうなったってことなのか？
あるいはmuxまですべてx264guiExでやってるから、ただ単にx264guiExの仕様なのか？

考えれば考えるほど分からん

>>784
x264guiExはデータをx264やneroAacEnc、MP4Boxやremuxer.exeなどの各ツールに順次渡していくだけ。
各ツールで実行されるコマンドのオプション等はx264guiEx.iniに書かれている。
なので「x264guiExの仕様」ということはなく、実行されるツールと実行時のコマンドによって発生していること。
（x264guiEx.iniでこういうオプションを指定してるからだーというケースはあるかもしれないけど）

音声のWritingLibraryの書き込みを行っているのはneroAacEncなどの音声エンコーダー。

音声エンコ後に、MP4BoxまたはL-SMASHのremuxer.exeで映像と音声をMuxして
最終的なMP4を作るけど、そのMuxの際に、
　　・MP4Boxの場合は、WritingLibraryのデータを消すようになっている
　　・remuxer.exeの場合は、WritingLibraryのデータを残すようになっている
という動作の違いがあるというだけなんじゃないかな。これは多分両ツールの仕様。

どうしてもWritingLibraryの記述を残したくないのであればMP4BoxでMuxするのが手っ取りばやいかもね。
あとは音声エンコーダーのソースをいじって自ビルドするとか。

バイナリエディタ最強

ソースをいじったのかバイナリエディタで書き換えてるのかはわからないけど、
x264のWritingLibraryのとこに出る記述(通常はバージョン番号)に
自分のハンドルネームを埋め込んでる人は見たことがある。

>>780
だれだよそれｗ
上げて落として元とのズレ確かめてその分ずらして上げ直すのかー
面倒だなあ

その人腕疲れないの？

サーバー側でエンコードされる低画質動画のフレームレートって、今年2/8のエコノミー仕様変更後は

　　「元動画のフレームレートに関係なく29.97fpsにされる」

という仕様になったと思ってたんですけど、>>748-749、>>783で投稿した24fpsの動画の場合、
どれも鯖エンコされた動画は24fpsのままになってるんですよね。

何か仕様が変わったのかと思って色々調べてみたんですが、例えば
　　http://www.nicovideo.jp/watch/sm19096159
の場合は、元動画が20fpsにも関わらず、?eco=1の低画質動画は29.97fpsとなっています。

低画質動画のフレームレートの法則ってどうなってるんでしょう？どなたかご存知ないでしょうか？

関係ないですが、ゲーセンから直接投稿するmaimai動画の場合は、
SEGAが別途エンコシステムを用意してるのかニコ動側の別ルートを使ってるのかわかりませんが、
通常動画だけでなく低画質動画も一緒にx264 r2197で30fpsでエンコして投稿されてる模様。

　　　maimaiまとめサイト
　　　http://www.nicovideo.jp/maimai/

>>757
まずニコニコではh264+mp3は受け付けられず強制的に再エンコされる｡上げるためにはflvにするしかない
第2にmp3がaacより音質で勝っているビットレート帯域は無い｡192kbps以上ではまず普通の人には分からないので汎用性の為に現在でも音声フォーマットとしてmp3を使う人が多いだけ
mp3は44.1khzが規格上限でaacは40.0khzだが普通高音質とされるlameでは最高設定でも18.5khzからローパスフィルタをかけており20khz以上は存在せず実際の再現度(人の耳ではなくpsnrのようなもの)で比べてもaacの方が高い
また使用上限のビットレートはステレオならmp3、320kbpsまでAAC、512kbpsなので瞬間的に不足する事が多いmp3に対しaacではまずそういったことが起こりえない

neroとかaacギャップレス再生出来ないhaalispitterとか使ってるならしらんが

>>792
スレチだからあんまり話し続ける気はないんだけどその主張だけ放っておくのもなんなのでURL貼っておく
http://kobo-aok.jp/is3/mp3vsaac.htm
全てが間違ってるとは言わないけど4行目だけ引っかかったので
失礼しました

上限周波数はWAVでもサンプリング周波数の1/2
上の音質を目指すならサンプリング周波数上げたほうが吉ソース次第だけどね
以下自重

フルレンジや10ビットは使うべきでしょうか？

>>795
10bitはまだ正常には再生できないんじゃなかったっけ？

>>795-796
フルレンジも10bitも使うべきではない。
そもそもフルレンジなんて一般的じゃないし、フルレンジで投稿しても低画質動画には
フルレンジのフラグがつけられないので色が変わってしまう。

10bitについては
　　・GPU再生支援が効かない
　　・現在最新のFlashPlayer11.4.402.287には10bitの映像が緑がかってしまうというバグがある。
　　・ちょっと古いバージョンでも、色の再現性がおかしく、8bitより悪いという問題がある。
という感じなので、使ってはいけない。

　　参考：
　　　　10bit-depthでの色テスト【640x360、BT.601】
　　　　http://www.nicovideo.jp/watch/sm16808896

>>797
いつの時代の人間だよ今やtsにしたってフルレンジだぞ
TVレンジ変換なんてすると汚くなるだけじゃないか

？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

>>798
ツイッター上でも某氏からつっこまれているけど、お主こそいつの時代の人間でござるか。
フルレンジ時代なんてこれまで一度もなかったと思うけど。未来人？

POP氏が過去に「あるアニメ作品が変なレンジになってる」という検証記事を書いたことがあるけど、
もしかしてそれを見て勘違いしてるの？それくらいしか心当たりないけど。

そろそろZEROが終了のお知らせだけどまた解像度変わんの？

投稿できる容量を増やしてほしい
解像度は720Pが標準になるのかな？

容量上げてほしいのは山々だけどあのクソ重い鯖どうにかするのが先な気もする
プレミアムの金はどこへ消えてるんですかね･･･

プレミアムなのに読み込めない動画まだまだあるもんなあ

容量は増えずH265待ちだろうな

競合相手がいないから現状に胡坐掻いて進化しないんだろうな
故zoomeは一般200MBのプレミアム1GBだったというのに

だから故人になったという見方も…

動画1本あたりの容量をデカくするとその分回線の負荷も大きくなるから
解像度やビットレートの制限は緩和しても
100MB制限だけはなかなか変えられないんじゃない

長い動画なら回線が空いてない時間帯はプレミアムでも2Mbps程度まで(最悪読み込めるギリギリまで)落とされるし同時に何十と動画が見られる訳でもないから容量よりビットレートの方が影響ずっとでかいと思うけどなぁ
zoomeは従量課金。bittorentDNAだっけ?は発想は良かったんだけどな
あれ入れたらプレミアムと同等の視聴環境になりますとかアナウンスかければすぐに回線問題なんて解決しそう

zoomeは色々と先進的だったなあ
ただ余程苦しかったのか知らんが一般が動画を上げられないようにした時点で潰れるのは目に見えていたが

動画共有サイトは自前のコンテンツで食ってるわけじゃないから
面白い動画をアップしてくれる人間をいかにして呼び込むかだよな
アップロード制限を絞りすぎるのは自殺行為だろう

緩くなったら緩くなったで海外串刺してアニメ丸上げしまくる奴とか出そうだな

>>811
おとなしくようつべに来いよ

ようつべかあ
映画2時間弱がHDで上がってるくらいだもんな
鯖余裕ありすぎだ

>>813
ちょっとその返しは意味が分からない

魅力的な制作者に報酬を払うyoutube
魅力的な制作者に料金を徴収するニコニコ

つべが60fpsの動画をサポートしていないのは
flash playerが60fpsの動画を正しく再生できないからなのか？
60fpsの動画はどんなに軽く作ってもカクつく

>>817
ニコ動の話だよね？
個人的に作った120fpsの動画あるけど、問題なく再生できたよ
60fpsだと違うのかな？

「あとで開発者ブログとかにまとめますが、Qwatchの画面サイズは中画面(サイズ変更なし)がデフォルトになり、
　大画面は854x480(FWVGA)になってます。zeroの864x486に合わせて動画投稿していただいた方には申し訳ないです。もう当面変更はないはずです。」

中って640x360か

良かったわこのサイズ好きだわ
覚えやすいし8の倍数だし

これからも640x360安定かー

縦480になったのはいいことかな
アス比4:3の動画なら640x480の選択肢ができた。
今更4:3の動画を作るかどうかは置いといて

>>818
動画撮ってみ 60fpsで上げて60fpsでフレーム落ち無く撮っても数割のフレームが欠落してる
11.5βにしたらwebkitでもそれよりもコマ落ちの多かったtridentでも相当マシになったがそれでも読み込めてない時は結構落ちてる

あれっ、そうなの？4:3て遅れてるの…？
思い切り640x480で作って上げてた。今後サイズ変えるかなぁ

>>823
あー、PCスペック的にキャプチャは無理だな。30fpsでもカクつく時あるようなマシンだから。

よかったら確認してくれ。
http://www.nicovideo.jp/watch/sm18440733
http://www.nicovideo.jp/watch/sm18440908
どっちも同じ内容だけど、下のほうが負荷はかからない

>>823

カクつくよねー。
いくらマシンスペックを上げようが、軽い動画でもニコ動やFlavieではカクつく。
Media Player ClassicやらWMPやらVLCではその動画はカクつくことは無いのに・・・

>>825

面白い動画ですねー。
下のやつをデジカメ（1280x720/60fps）で撮影してみた。
カメラのシャッタースピードも1/60にして、PCのモニタのリフレッシュレートも60Hzなので
右上の「60fps」のカウントは、

ニコ動でコマ落ち無し（カクつき無し）で再生されるなら
撮影した動画も数字のカウントの欠落が無い

はずだが、やはりところどころ数字が飛んでいる。（コマ送り再生すると分かる）
撮影したのをうｐしたよ。↓
http://www1.axfc.net/uploader/He/so/375848.mp4

PCは、Core i7 980X(3.33GHz)/GTX570/Windows7/IE9


カクつきは数字のカウントより、物のスクロールや画面パンの方が分かりやすいよ。

>>827
ビデオ確認しました。
確かにコマ落ちしてる。
改めてコマ落ちがあると思って動画見直してみると確かにちょっとカクつく時があるかも。
ちなみに下のURLの元動画↓
http://www1.axfc.net/uploader/Sc/so/386451.mp4

動画自体はまとめwikiに120fpsまで投稿可能ってのを見て興味本位で作っただけです。

>>828

まぁ、ニコ動に限らずFlashPlayerのカクつきはしょうがないみたいですね・・・

120fpsなんてモニタでドロップするから意味ねえじゃん
30fpsでもドロップっていうか等速でフレームを再生してくれずにガク付きがでるんだよなあ
どうにかならんものなのか

120Hz液晶買えよ
モニターが120Hz対応してないだけだろ

Chrome最新とniconico新バージョンのQwatchにしたら
かなりカクつきが減った。
今までで一番イイかもしれない。

クローム使ってるとかｗｗｗ

基本的な事を聞くんだが60fpsの動画を60fpsで再生できるプレーヤーで再生したとして
60Hzのモニタで表示したら位相がちょっとずれてて表示されないフレームが出るってことは無いの？
>>827のはカメラも秒間60コマで撮影してるんだからカメラ側でも位相がずれてる可能性があるんじゃないの？
最低秒間120コマぐらいで撮影した方がいい気がするんだが。

>>834

デジカメで秒間30コマとかで撮影すると表示されないフレームが出るが、>>827のは秒間60コマで
シャッタースピードも1/60にして撮影してるので出ない。

「位相」の意味がちょっと分からないが・・・

>>835
数直線をイメージして欲しいんだが、60Hzのモニタの表示を時刻0秒から開始するとすると、
1フレーム目が表示される時刻は0秒、2フレーム目は1/60秒、3フレーム目は2/60秒・・・となる。

これを秒間60コマで撮影できるデジカメで撮るわけだが、
モニタの表示タイミングとデジカメの撮影タイミングを完全に同期させるのは不可能なはず。
デジカメの撮影開始時刻を仮に0.5/60秒とすると2コマ目は1.5/60秒、3コマ目は2.5/60秒・・・となる。
位相のずれと言ったのはこの事。位相という言葉を使うのが不適切だったらすまない。


さて、以上はモニタとデジカメの表示/撮影速度が厳密に60Hz/秒間60コマと仮定しているわけだが
実際には両者が完全に一致しているとは物理的に考えにくい。

仮にデジカメの方が1.001/60秒ごとに撮影するとする（≒秒間59.9コマ）とどうなるか。（分かりやすくするためにあえて大きく外れた値を設定する）
問題を単純化するために今度は時刻0秒での表示タイミングと撮影タイミングが完全に一致しているものと考えると、

モニタ：1フレーム目は0秒、2フレーム目は1/60秒、3フレーム目は2/60秒・・・1000フレーム目は999/60秒、1001フレーム目は1000/60秒、1002フレーム目は1001/60秒
デジカメ：1コマ目は0秒、2コマ目は1.001/60秒、3コマ目は2.002/60秒・・・1000コマ目は999.999/60秒、1001コマ目は1001/60秒

このようにデジカメではモニタの1001フレーム目を撮り逃してしまう。
（対応関係は1000フレーム目を1000コマ目で撮影、1002フレーム目を1001コマ目で撮影）
時間にして約16.7秒毎にデジカメ側で欠落が発生する。

こういう風に考えたので実験方法にちょっと疑問を覚えた。長くなってすまん。