千早武士道の新作が来たことを RSS 登録しておいたとりあえずビールP のマイリスト更新で知ったので、さっそく開いてみた。すると、音がならずに動画再生のしょっぱなから 「この動画はご覧のユーザの皆様が、応援しています」 のアナウンスが、一定時間ごとに繰り返される。無限ループって怖ry そういや Flash Playerが 10.1 ベータ版のままだったんだっけ。昨日とは異なる不具合を発見、か。まだまだ探せばありそうだね。 ◇Flash Player 10.1のDXVAサポートを試す 〜IONネットブックで1080p動画がコマ落ちなしで再生可能 - PC Watch http://pc.watch.impress.co.jp/docs/topic/feature/20091118_329706.html んで、うちは NVIDIA の GeForce GT 285 のビデオカード
ニコニコ動画で明日から『ニコニ広告』なるサービスが始まるらしい。 ◇3/10 『ニコニ広告』 サービス開始! http://blog.nicovideo.jp/niconews/2009/03/002560.html 先立つものがなければ持続的な発展もありえないので、こちらの財布が痛むわけでもないし金儲け大いに結構といったところ。 ただ、まあ運営が赤字を解消したいのは分かるけれど、運営だけが金銭的に困っているって思ってるなら大間違いだ。きっと多くの視聴者が創造する以上に、投稿動画には膨大なものが投資されている。ツールや教科書などの必要経費、技術料、そして時間、時間、時間。その時間を仮にバイトなどに使っていたら。そういう考え方を経済学では機会費用というけれど、時給525円だとして動画一つで 1万円以上の投資が行なわれているなんて日常茶飯事だろう。身を削り手間を惜しまず金儲けの機会を逃
通りすがりさんからリクエストをいただきました。512x288+上下?黒ベタ96で作った512x384」の動画でのベンチです。これが512x288と512x384のどちらに近い負荷になるのかが気になってしまいました。 というわけで、実験に使ったのがこの動画です。 ◇アイドルマスター 猫太郎Pに贈る ふるふるフューチャー☆ ……ごめんなさい。 512x288 の素材を作ったら、前からやりたかったこのネタになってしまったんです。 orz ◇比較用 さて、これをいつものように MPlayer のベンチマーク・オプションで測定しました。 黒べた無し MPlayer [benchmark]: avg: 9574ms per60s: 4301ms 黒べた有り MPlayer [benchmark]: avg: 10620ms per60s: 4770ms 無しを 100 とすると、有りは
ニコニコ動画(ββ)にバージョンアップして、ユーザがニコニコ生放送を利用することができるようになりました。ニコマスのほうでは早くも積極的に使うPが出てきています。 12月14日の日曜夜には「ニコマスメドレー春 実況!オーディオコメンタリー」がこんにゃくP、ねこP、魔汁P、わかむらPによって放送。あっという間に来場者は500人を超えて満場になり入れない人が続出。30分枠を 3回にわたって使い倒し、以後に語り継がれるだろう名言もちらほら。 たまたま生放送開始に居合わせたので合作CMの経験を活かして、放送画面をプレイヤーごとキャプチャしてみました。一般的にストリーミング配信は著作権保護のためキャプチャしても動画部分は透明になってしまうものですけど、ニコニコ生放送は現状ではそうした処理を行っていないようで、最終的には映像と音声とを同時に動画ファイルに収めることができました。 続きを読む
・x264 ニコニコ動画 1Mbps の影響 ・x264 デコード負荷を軽減するために ・デコード負荷の軽減 - x264 日本語 Wiki の各記事を参照する人もいるようなので、まとめをとりいそぎ。詳細はそれぞれの記事を読んでください(内容が分散したり重複したりしてごめんなさい)。 ― ニコニコ動画のカクつきを抑えるために ― ・動画をデコード処理する CPU の速度がフレームレートに間に合っていない。 ◆視聴者にできること(上ほど推奨、下ほど非推奨) ・同時に並行して動くプログラム数をなるべく減らす。 ( あらかじめ CPU の使用率を減らして、デコード用に確保する) ・動画を完全に読み込んでから再生する。 (読み込みにも CPU を使うため) ・「コメントを自動受信する」を無効に。 ・「再生に合わせてスクロールする(一覧の再生同期スクロール)」を無効に。 ・
(まとめずに考えた順に書き連ねているだけなので、書きたい人は読みやすいまとめ記事などを書いてもいいですよ、っていうか書いてくださいませー) 新しい話はデコード負荷のあたり。つまり 動画60秒のデコード時間 -- __(512x288)__ -- __(512x384)__ -- 右/左 ・rev 777 CABAC 768kbps -- 3977ms(100.0) -- 4858ms(100.0) -- 122.15 ・rev1046 CABAC 768kbps -- 4048ms(101.8) -- 4960ms(102.1) -- 122.53 ・rev1047 CABAC 960kbps -- 4362ms(109.7) -- 5309ms(109.3) -- 121.71 ・rev1047 CAVLC 960kbps -- 3589ms( 90.2) -- 4441ms
ありがたいことに協力してくださる方も現れました。もう素直に嬉しいです。 協力してくださった _kt_ さんのおかげで x264 オプション一覧のページが整然とした見事なものに仕上がっています。すごいなあ。僕一人なら3日以上かかる仕事です。おかげで全体の構成に手を付け始めることができました。 まだ PukiWiki を導入したばかりで、 PukiWiki 本体の改造が落ち着いていない状態です。特にスキンや CSS などはもう少し手直ししたいところです。でも、Wiki のサイトとしての基礎部分は出来ているので、あとは内容を上に載せていけばいいだけのはずです。まあ、それが大変なんですけどw 上で _kt_ さんがオプション一覧を編集したので僕は全体の構成に手をつけられた、と書きました。これは x264 全般に言えることです。誰かが調べたこと、知っていることを公開して、他の誰かが持っている情
さてさて、ニコニコ動画の H.264/AVC ( MP4 )で「動画がカクついて見れない」というコメントに対応するべく始めた、x264 でデコード負荷を抑えながら高画質を目指すエンコード設定を探求する旅。出立から2ヶ月以上が経ち、そろそろ大詰めを迎えています。 ニコニコ動画にはビットレート制限があるのでマルチパスによるレート制御を使います。なので、第1パスの高速化についての実験成果も利用できます。やったね! まあマルチパスをしないでレート制御ができれば最善なのですけど、それは無い物ねだりです。 そんなこんなでエンコード設定のギリギリのところをガンガンに攻めていきます。動画職人の腕の見せ所です。とりあえず現時点で僕が実際に投稿した動画に使った設定とそのログについて紹介し、解説を書いてみました。 前回よりも動きが速くなって、実験にはもってこいですね。本当に他の方が投稿したソニックの動画で
2008年4月12日「ニコニコアニメが1週1話7分の理由」をかーずSPをはじめ数カ所で紹介してもらって瞬間的にアクセス数の桁が増えた。前に「HAPPY TREE FRIENDS、ウェブから外へ」を翻訳したときも体験したことだから初めてではないんだけど、それでもやっぱりびっくりする。 先日「ニュースサイトという権力について徒然なるままに書いてみる」という記事を見かけたけど、第四の権力はあるんだろうな。「権力(power)」って「持っている影響力」くらいの意味なんだし、ここみたいに普段は更新しても見る人が限定されたサイトにとってはありがたい存在。 大勢に紹介してもらうことで嬉しいことはコメントをもらいやすくなること。今回も反応を得られたので、反応への反応をば書いておく。カトゆー家断絶で関連記事として紹介されていた「見知らぬ動画を見る、最大限の時間が7分くらい。」についての私見。 7分とい
◇『ペンギン娘 はぁと』予告ムービー 〜そして伝説へ…〜 こういう遊びは嫌いじゃないw ◇ニコニコ動画がアニメコーナー開設。第1弾アニメは「ペンギン娘 はぁと」 17日に製作発表会が開かれた「ペンギン娘 はぁと」は第1弾作品にあたるもので、4月19日正午から毎週土曜日正午に1話ずつ、全22話を配信していく。ニコニコ動画に会員登録すれば無料で視聴でき、1話あたりの時間は約7分程度を予定する。 動画を投稿したことがあれば「7分」と聞いてピンと来るだろう。7分はニコニコ動画(SP1)でプレミアム会員が最高画質で投稿できる動画の長さの上限なのだ。 ニコニコ動画(SP1)で投稿できる動画(FLV、MP4)の容量上限は40MB。画質の目安となる、秒あたりのデータ量を表すビットレートの上限はプレミアム会員で約800kbps(一般会員は約600kbps)。1メガ=1024キロ、1バイト=8ビット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く