あけましておめでとうございます。
今年もよろしくお願いします。
そしていい年でありますように。
Pjax(history.pushState, history.replaceState and the popstate event)のサポート具合。
正直言うとこれだけ対応していていないのかと愕然としてしまう...。
Firefox/Chromeは安心。しかしSafariはフルサポートじゃないとかもうね。
HDMIキャプチャを買ったので、1080iのビデオをキャプチャをしてみたのですが、AMD X2 2.1GHzという今ではいささかPoorなCPUであるため、H.264へ変換しながらキャプチャするのには向きませんでした。
また、既存のHDMIビューア/キャプチャソフトも使い勝手が悪いとか、キャプチャでコマ落ちするとか、途中で信号を見失ってキャプチャできなくなるなど、不具合があるので調査してみると、アマレコTVがよいということがわかりました。
また、アマレコTVでデフォルトで使えるAMVビデオコーデック(シェアウェア)を使うと、非常に低負荷でエンコードしつつキャプチャできるので都合がいいです。
しかし私がよく使っているAvidemuxは、カット編集しつつAVI/H.264/AVCへ変換できるため重宝しているのですが、このAMVビデオコーデックには対応していません。
ということでなんとかAVI+AMVビデオコーデックをH.264/AVCに変換する方法が欲しいと思いました。
なおAMVビデオコーデックはそのままでも使えますがエンコード時にAMVロゴを挿入するので、今回はWebMoneyで払いました。1500円(2011/1/1現在)でした。
AviUtlには、プラグイン機能があって、その中のプラグイン出力を使うと、AVI以外の出力ができるようになります。
この機能を使うと、AVIファイルをH.264/AVCへ直接出力することが可能になります。
また、AviUtlはコーデック変換の機構をWindowsに頼るため、エンコーダ/デコーダを適切に導入していれば、AviUtlで使えます。
つまりAMVビデオコーデックで作られたAVIファイルも読み込めるようになります。
ちょっと面倒ですがこれらを読むと(特に二番目を読んでください)、H.264/AVCで出力することができるようになります。
うまく行きました。
1080iでキャプチャしたAVIファイルを、1080p(30fps)や1080iに変換できたので、プレーヤが賢いデインターレースを持っているのなら、1080iで書きだしてTVと同じ環境で再生することも可能になります。
実際やってみると比較的高画質でスムーズに再生されて満足できました。
職人気質の人といえばいいか。最近はこういう人は少なくなってきているのかも。
かわええｗ。
この仕組はわりと導入している所が多いように思うけど、パターンを多くしようとするとそれなりに作る側がめんどうくさそうだな。
正直言うと、TVにネット端末を組み込むビジネスモデルは破綻しているように見える。アイデアはいいのにね。
それよりもiPad3/iPhone5早く出せと思っている人が多そうだ。
マザーボードっていっても組み込み用のもので、Arduinoを電子ブロックみたいにしたイメージですね。
個人的にはちょっと中途半端な気はしますが、増えて行って欲しいジャンルです。
正直言うと、「ふぬああ」は録画というより手元を映すWebカメラのビューアとして使ってました。
非常に多くのパラメータを設定でき非常にマニアックな使い方ができるらしいのですが、開発が止まっていること、設定項目が多いことなどから、敬遠する人は多そうですね。
設定の複雑さがこのソフトの利点であり欠点でもあります。
個人的にはキャプチャするだけならアマレコTVを使ったほうが設定が楽ですので好ましいと思います。AMVコーデックとの相性もいいですしね。
まぁアマレコTVには警告ダイアログが鬱陶しいとか、録画に関する支援がないとかいろいろ欠点もあります(録画支援はふぬああもありません)。
ということで必要に応じて使い分けることになると思います。
MP4読込プラグインを導入するだけです。
元々がMP4であるもの、変換した以前のMP4を読み込んで編集できます。
AviUtlで読み込めるということは、他の形式のAVIファイルやMP4に書き出しもできるということになります。
AviUtlには、シーンに応じた多彩のプラグインがあるため、比較的な画質がよくシャープなレンダリング結果を得られる利点もあります。
【ニコニコ動画】AviUtlの拡張編集を使ってプレイ画面と手元の動画を簡易的に合成する説明
AviUtlは編集というよりAVIに特化したコーデック変換の補助という位置づけだと思いますが、編集さえもできるようにした強者がいて、見ての通りエフェクトも含めたレイヤーを持つ編集までもできるようになっています。
アプリとしての柔軟性もさることながら全部AviUtlでやっちまえという精神に感服しますｗ。
ちょっと癖がありますかね。
通常NTSCのMPEG2/MPEG4を出力する時に、720x480pxで出力することが多いと思いますが、「拡張 x264 出力(GUI) - x264」タブで、「アスペクト比」を指定する時は、
です。
ちなみにNTSC 4:3は、
です。
アスペクト比をそのままにしておくには、SAR比を指定(デフォルト)「0:0」にしておきます。
| 曜 | タイトル | 時間 | CH | 評価 | nyamo | aria |
|---|---|---|---|---|---|---|
| 月 | 銀魂 | 18:00-18:30 | TSC | 2 | ○ | × |
| 火 | BLEACH | 18:00-18:30 | TSC | 4 | ○ | × |
| 火 | コズミックフロント | 21:00-21:58 | BSP | 2 | ○ | × |
| 水 | リリカルなのは | 02:03-02:33 | TSC | 2 | ○ | × |
| 木 | あの夏で待ってる | 00:30-01:00 | BS11 | ○ | × | |
| 木 | 夏目友人帳 肆 | 01:50-02:20 | TSC | 2 | ○ | × |
| 木 | SKET DANCE | 18:00-18:30 | TSC | 4 | ○ | × |
| 木 | サイエンスZERO | 18:55-19:25 | ETV | 3 | ○ | × |
| 木 | 地球アステク | 22:00-22:30 | BSJ | 3 | ○ | × |
| 木 | 宇宙ニュース | 21:54-22:00 | TSC | 2 | ○ | × |
| 金 | TIGER & BUNNY | 18:30-19:00 | BS11 | 2 | ○ | × |
| 金 | パパのいう事を聞きなさい | 23:00-23:30 | BS11 | ○ | × | |
| 金 | モーレツ宇宙海賊 | 23:30-00:00 | BS11 | ○ | × | |
| 土 | BRAVE10 | 00:00-00:30 | BS11 | ○ | × | |
| 土 | バクマン。2 | 17:30-17:55 | ETV | 2 | ○ | × |
| 土 | 偽物語 | 23:30-00:00 | BS11 | ○ | × | |
| 日 | ゼロの使い魔F | 00:00-00:30 | BS11 | 2 | ○ | × |
| 日 | TO | 00:00-00:30 | BS-TBS | 5 | × | ○ |
| 日 | ハイスクールDxD | 00:30-01:00 | BS11 | ○ | × | |
| 日 | 妖狐×僕 SS | 00:30-01:00 | BS-TBS | 2 | × | ○ |
| 日 | アマガミSS | 01:30-01:30 | BS-TBS | ? | ○ | × |
| 日 | ギルティクラウン | 02:00-02:30 | BSフジ | 3 | ○ | × |
| 日 | アクエリオンEVOL | 02:35-03:35 | TSC | 2 | ○ | × |
| 日 | ガリレオX | 08:00-08:30 | BSフジ | 3 | ○ | × |
| 日 | ドラゴンボールZ | 10:00-10:30 | BSフジ | 3 | ○ | × |
| 日 | 機動戦士ガンダムAGE | 17:00-17:30 | RSK | 5 | ○ | × |
| 日 | ファイ・ブレイン | 17:30-17:54 | ETV | 4 | ○ | × |
| 曜 | タイトル | 時間 | CH | 評価 | nyamo | aria |
|---|---|---|---|---|---|---|
| 日 | アイドルマスター | 01:00-01:30 | BS-TBS | 2 | ○ | × |
| 日 | 僕は友達が少ない | 01:30-02:00 | BS-TBS | 1 | ○ | × |
| 曜 | タイトル | 時間 | CH | 評価 | nyamo | aria |
|---|---|---|---|---|---|---|
| 日 | キルミーベイベー | 01:00-01:30 | BS-TBS | 4 | ○ | × |
木曜と日曜に偏ってるな...。
この機種は私も注目していた。もうちょっとレビューを待って買ってみようかと思う。
正直言うとあんまり興味ないなぁ。Servletで困ることってストリーミングだけのような気がしています。
ああHot Deployは開発時問題になりますね。それはそう。でもこれはコンテナ次第。
たぶんRails方面の人からすると今挙げたことに加えて、Rackのような機構も欲しいかもしれませんね。現状でも似たようなことは可能ですが。
Herokuの記事とほぼ同じ内容でした。同じように感じる事が多いということは、この業界において真実なのかもしれません。
ただしこれを日本企業に持ってきてもたぶんうまく行きません。少なくとも大手は。
この日記システムは自作なんですがコメント機能は実装していません。実装は予定に入っているのですが優先順位は低めです。
その理由は、
ですかね。少なくとも最近TrackBackはもう死んだと思ってます。
まぁこの手の話は古来(ぉぃ)からあったわけですが、対策を明確にしたのは珍しいかもしれません。
転売した人だけが得する形になるのも理不尽ではあります(でも転売人が特定された場合は今度は買えないかもしれませんけど)。
まぁこのカメラにいたってはダサいかどうかは関係ないんじゃない?
使いやすく思う通りに写真が撮れるかどうかがこのカメラの意義なんで(まぁコレクションとして買う人もいるだろうけどね)。
TKG! TKG!
下請けになってしまうのか、という反面、欧州勢も協業を考えるようになってしまったのかという意見もあってなかなか面白い。
有機ELはやはり小型のもの以外はまだまだってところですかね。
ソニーに体力があればコストを無視して製品出し続けると思うんですけどね。
ちなみに業務向けは続けるそうです。
なおタイトル通り、韓国勢の持っている特許(それなりに持っている)だけでは生産することができないらしく、特許料の支払いがボトルネックになる可能性もあるみたいです。
翻訳とはいえ、まるで2chのスレのような(おもしろい)コメントでわらったｗ。
しかしコミケ参加者はよく訓練されてるなぁ。
そうそう地味で実用的なものを地味に提供することも大事。
正直言うとRAIDっていらないんじゃないかなーとか思ってたり。
機械的な故障の他に、ハードエラーをちゃんと検出してくれる仕組みになっているかという話でもあるのかな。SATAは信用できないという話に。
まぁどちらにしても壊れる時は壊れる。壊れることを前提にシステムを作ることも大事。
これは私にとっても重要なAPIになるかも。コンテンツ検索に必要な機能の1つだね。
「ごはん」とは聞こえませんがｗ、「くれ、くれ」というポーズに驚かされますｗ。
java.io.Consoleを使うと、コンソールアプリが組めるのですが、Mac OS X上の標準JREではあまりうまく動きません。
OpenJDKならもうちょっとマシなのかもしれませんが、いろんな理由からJLineを使ってみようと思います。
JLineは、Un*xでよく使われるreadlineライクな文字列入力ライブラリです。
ここからJLine 1.0がダウンロードできます。バイナリを引っ張ってきましょう。
すでにJLine 2もあるんですが、JLine 1.0で欲しい機能は一応持っています。
今回はただ単に入力プロンプトを出力し、入力したコマンド文字を再表示するだけにします。
import jline._
object Hello extends App {
def prompt(reader: ConsoleReader, msg: String)(p: String => Boolean): Unit =
while (reader.readLine(msg) match {
case null => false
case line => p(line)
}) {}
val reader = new ConsoleReader
reader.setBellEnabled(false)
prompt(reader, "> ") {line =>
println("--> [" + line + "]")
!line.equalsIgnoreCase("exit")
}
}...\JLineHello> java -classpath ... Hello > aaa --> [aaa] > bbb --> [bbb] > exit --> [exit] ...\JLineHello>
ConsoleReaderを生成して、そいつにプロンプトを表示させ入力待ちにする(ConsoleReader#readLine)。
入力文字がnullか"exit"なら終了し、そうでなければ表示するというだけ。
本来はCompletorを使うといろいろできるんですが、これだけでも入力された履歴も使えますし、カラムの移動もできます。
便利ですね。
Caffe BuilderとSiphone Coffee MakerをJLine対応にした。
これでMac OS Xもちゃんと動くはず。
マイクロソフト ウェブカメラ LifeCam Studio Q2F-00008
これがいいかなぁ?
マイクロソフトのってハードがいいの多いよね。コメントもだいたい評価が高い。ただ付属ソフトには不満が多いようです。
オートフォーカスでマイクもついています。
そして三脚用の穴が開いています。これはむしろ必須ですね。
LOGICOOL HD プロ ウェブカム 500万画素 カールツァイス社製レンズ採用 C910
こっちはハードソフトとも評価高いですね。
個人的にはロジクールのWebカメラは信用していないのですが(以前画質が悪かったので)、今はいいんでしょうか?
コメントを見るとコントラストが悪いとか青が強調されるとか不評の部分もあります。
さらに遠方はピントが合いにくいようです。ビデオチャットを前提にしているようです。正直言うとビデオチャットにHDが必要に思えないのですが...。
両製品の中間が欲しいなぁ。結構高いんだし。
安定度でLOGICOOLの方が安心して使えそうです。レンズもカールツァイスですし。
どちらにしてもUSB 2.0ですのでHD(720p)には向きにくいと思いますが、Ust.などの配信の場合は言うほど秒間コマ数は必要無いので、ドライバを含めたソフトさえ安定していればいいのかもしれません。
SDで配信するにしてもオートフォーカスは必須に思えますのでこのクラスは必要に思います。
LOGICOOLの方は遠方だとピントが合いにくいようですので、工夫が必要かもしれません(例えば貼るタイプの広角レンズを付けるとか。しかしカールツァイスレンズにつけるのかという矛盾も)。
マイクロソフトのヤツがソフト的に安定していれば一番いい感じがします。ドライバはどうしようもありませんので、キャプチャソフトだけは付属ではない他のものを使う必要があります。
音声はどちらも悪くないようです(必要最低限)。
まぁどちらもいろいろ問題を抱えているということです。ちゃんとした中継の場合は、HDMIやS端子などを出力できるビデオカメラにキャプチャデバイスをつなげて使うのがいいのでしょうね。
YouTubeにはいくつかあがっているので貼っておきます。
Accell DisplayPort to DVI-D Active Single-Link Adapter B087B-005B
3画面運用しているので、3ポート出力できるAMDのRadeon HD6850と、DiplayPort変換器(Active)を買いました。
HD6850はエントリークラスのグラフィックカードですが、消費電力が少し低くかつ安価であり、3ポート同時出力できるのが特徴です。
なおDisplayPortにDVI/Dモニタに接続する場合はAMD Eyefinityに対応したものを使う必要があります(対応していなくてもActiveタイプなら表示できる可能性があります)。これが結構高い。
AMD系列のグラフィックカードは当然NVIDIAのCUDAが使えないのですが、OpenCLなどは使えGPGPUも自分で開発する分には使えます。でもたいてい対応してるのはCUDAだけなんですよね。
| CPU | Core i5 2400 |
| OS | Windows 7 64bit |
| メモリ | DDR3 4GBx2 |
| グラフィックス | 5.5 |
| ゲーム用グラフィックス | 6.3 |
| グラフィックス | 7.7 |
| ゲーム用グラフィックス | 7.7 |
| LOW | 871 |
| LOW | 5846 |
| HIGH | 3603 |
1280x720
| Benchmark A | 31.8fps | B |
| Benchmark B | 27.0fps | C |
| Benchmark A | 182.3fps | S |
| Benchmark B | 126.5fps | S |
P3617 3DMarks
| 3DMark Score | P3617 |
| Graphics Score | 3353 |
| Physics Score | 6086 |
| Combined Score | 3559 |
| GraphicsTest | 115.5 FPS |
| GraphicsTest | 216.03 FPS |
| GraphicsTest | 320.91 FPS |
| GraphicsTest | 410.04 FPS |
| PhysicsTest | 19.32 FPS |
| CombinedTest | 16.56 FPS |
いろいろトラブルが出ました。
まぁ電源容量の問題はむしろスロットの接触不良と勘違いしていたのかもしれません。
でもこのクラスのグラフィックカードは最低で500Wを要求しているので、今回は620Wの電源に換装しました。
今まで
という組み合わせで使っていましたが、VLCを動かすとどうも重たくなり困っていました。
その問題は解決しましたし、以前よりスムーズに再生できるようになりました。
新製品がどんどん発表されているのでいまどきのグラフィックスカードに比べると多少見劣りするかもしれませんが、それでも満足行くパフォーマンスを達成できていると思います。
AMDのGPUですからCUDAには対応していません。OpenCLで使えというのが順当なんでしょうか。ATI Stream SDK(現在の名称を知りません)でNativeに動かすことも可能ですので、実際にHPCで使って高効率に計算している例があります。
OpenCLは最近CUDAのオープンプラットフォーム化発表で意義が薄れてきているのかもしれませんが、Mac OS Xの機能の1つになってますし、NVIDIA/AMDのGPUで計算処理のアクセラレーションをする実験は出来ます。私も遊んでみるつもりです。
NHK 地球ドラマチック 2012年 1月21日(土) 19:00-19:44 さようならスペースシャトル ～栄光と挫折の30年～ 前編 2012年 1月28日(土) 19:00-19:44 さようならスペースシャトル ～栄光と挫折の30年～ 後編
うーん...。
ウイルス対策ソフトも入れていましたしそんなに悪い対応ではなかったようですが、これは某海外の団体から横槍が入りそうです。
2400W縛りって結構大きいと思います。まぁ会場に太い電源が来ているわけじゃありませんし妥当でしょうけど。
ちなみに富士通のブレードサーバ6台(72コア)だったそうです。もちろん単なる力技ではありません。
ボンクラーズはボナンザ由来ですが、「大阪」が何やらやらかしたようですねｗ。
そろそろ落ちてるかな。今日落ちないと明日以降という話のようです。
まぁFeliCaは最初から運命は決まっていました。でも今でも割り切りのいい規格だと思いますよ。
メインヒロインを死なせてしまいましたｗ。
日本製品は前から。でも今回は比率が増えた気がします(正確には不明)。
PHPの配列は時々殺したくなりますよねｗ。
エディタのハイライトやエラーだけではなく、コンパイルもできるらしい。
履歴を見るかぎりどうもRhinoを使っているらしい。私がやった方法と同じだ。
被害が出ずとりあえずほっとしました。
次回に期待しましょう。
ストレージがもう規格として古いCFなのが...。SDカードならよかったのに。 miniSDカードスロットがありました(^^;
大きさは気に入りました。このスペックならDOSだけではなく簡単なLinuxサーバも起動できるでしょう。
でも微妙に低スペックなんですよね。そして高い。
ITXマザーでAtom PC組んだほうがましな気がします。
import util.DynamicVariable
object DSLTree {
val children = new DynamicVariable[xml.NodeBuffer](null)
def clear {
children.value = new xml.NodeBuffer
}
object Elem {
def apply(name: String)(p: => Unit) {
val nodes = new xml.NodeBuffer
children.withValue(nodes) {
p
}
children.value +=
xml.Elem(null, name, xml.Null, xml.TopScope, nodes: _*)
}
}
object Text {
def apply(data: String) {
children.value += xml.Text(data)
}
}
}
object ApplyTree {
object Elem {
def apply(name: String, children: xml.Node*): xml.Node =
xml.Elem(null, name, xml.Null, xml.TopScope, children: _*)
}
object Text {
def apply(data: String): xml.Node =
xml.Text(data)
}
}
object Hello extends App {
def benchmark(msg: String, p: () => Unit) {
println("---- " + msg)
val st = System.nanoTime
try {
p()
} catch {
case e: Exception =>
println("Error: " + e.getClass.getName + ": " + e.getMessage)
}
val et = System.nanoTime
println("----")
println(" " + ((et - st).toDouble * 1e-6) + "ms")
}
def execDSL {
import DSLTree._
clear
for (i <- 0 until 10000) {
Elem("html") {
Elem("head") {
Elem("title") {
Text("Hello, world!")
}
}
Elem("body") {
Elem("h1") {
Text("Hello, world!")
}
}
}
}
}
def execApply {
import ApplyTree._
for (i <- 0 until 10000) {
Elem("html",
Elem("head",
Elem("title",
Text("Hello, world!")
)
),
Elem("body",
Elem("h1",
Text("Hello, world!")
)
)
)
}
}
benchmark("DSL tree", execDSL _)
benchmark("Apply tree", execApply _)
}DSL 86.97703399999999ms 76.991123ms 71.947682ms 72.19763499999999ms 71.555039ms 103.218083ms 78.321011ms 76.832543ms 89.727189ms 75.70559899999999ms Apply 19.914545ms 18.096667999999998ms 18.133086ms 32.318222ms 18.144672ms 17.901009ms 34.670108ms 18.06919ms 18.167185ms 38.934222999999996ms
| DSL tree | 78.587477ms |
| Apply tree | 22.1892095ms |
実行時間が1秒もかかっていないのであまり精度には期待できないし、もっと大きなツリー構造を扱うべきだが傾向はつかめると思う(あまり回すとOutOfMemoryErrorになるのでループ回数を抑えている)。
一方はDynamicVariable(JavaのThreadLocal相当)で動的にオブジェクトツリーを作り、もう一方はobjectのapplyメソッドによってオブジェクトツリーを作ってみた。
結果は前者は動的でかつDynamicVariableを使う、後者は静的にコードが書かれたものという大きな違いはあるものの、この例ではDSL+DynamicVariableが3.541697914倍遅い結果になった。
静的なコードになっている分applyで生成したオブジェクトツリーの方が速いのはまぁあたりまえなのだが、DSL+DynamicVariableで作ったオブジェクトツリーもそこそこなパフォーマンスで生成できている。
まぁパフォーマンス優先の場面では注意が必要だが、生成時間は言うほどかかっていないようだし通常の場面ではあまり気にしなくてもいいかもしれない。
いろいろ感想や意見はあると思いますがいいことではないでしょうか。
正直言うと海外の媒体は買いたくありませんが(生産地が問題ではなく日本の会社が品質を行なっているかどうか)。
SVGって不遇ですね。ほとんど使われていない。
とはいえ最近はIEなどでも対応が始まっていてそこそこ表示はできるようになっています。
OSSではないのではないかというコメントがちらほら。
OSSの定義についてはこちら。
みんなの感想はこちら。
584 ：名無しＳＵＮ [↓] ：2012/01/31(火) 17:33:40.35 ID:RZ0oZ9aK 新運搬機械って特集の長征5号ロケットについての報道 ttp://news.cntv.cn/china/20120124/113214.shtml ・現在長征5号ロケットは既に基本設計が終了し重要部品の製造段階にある ・長征5号は燃料に液体窒素と液体酸素を使っているので推進器の内部は－250℃などの低温状態にあるので氷箭と呼ばれたりする（中国語でロケットは今も火箭） ・長征5号は直径5m、全長63.2m、重量850t、LEO25t、GTO14t、安全性98%（現在成功率100%の有人ロケット長征2号Fは97%）、発射費用も長征2Fと比べ20～30%低い ・中国のロケットは直径3.35mだったので直径5mのロケットを作るのに工場も設備も人員も再構築・再教育が必要で大変苦労した ・燃料タンクは軽量化のために140tの燃料を貯蓄できるが自重は2tしかなく最も薄いところでは3mmしかなく卵と同じサイズにすると卵の殻の4/10万の厚さとなる ・2008年に概念設計が終わった時、ペイロートは国の目標より1、2t低かったため試行錯誤の後再設計して軽量化に成功したためペイロードが上がった ・エンジンは西安、補助ロケットは上海から運ばれ天津で組み立て最終チェック後、海南発射場に運ばれる
やることいっぱい～
西本 圭佑(NISHIMOTO Keisuke), Twitter: @keisuke_n, mailto:keisuken atmark cappuccino.ne.jp