単位の変形の話とか。
同じチャンネルの動画。思わず笑ってしまったので貼っておく。
適度な距離感で同じ業種の人が2人いると話が弾んで良いな。1人を呼んで話を聞くと中途半端な(比較的浅めの雰囲気の)範囲しか聞けないような感じがして物足りなかったり、同じ会社から2人呼ぶと一人が話してもう一人は相槌打って、みたいな状況になりがち。あまり距離感が近すぎない同じ業種の2人だと、取材を意識して深いところまでは潜らずとも、仲間内で話してくれるから面白い。この動画の場合は人選が良かったというのもあるんだろうけど。片方が積極的に話を回して、もう片方がそれにいい感じに反応して、話が難しくなりすぎたら聞き役が質問して。ただ、競合他社の人を集めなきゃいけなくなるから、こういう構成ができる分野は狭そう。
別のチャンネルのコンテンツで、普通の取材では話さないようなディープな話も、みたいなコンセプトでも、専門家一人に対して聞き役一人であんまり深くないような雰囲気がしてしまっているものもあるし。深掘りする話ってのは掘るのがなかなか難しい。「餅は餅屋」で、同業種の人に掘ってもらうのが一番良いんだろうな。
あとは、NHKの『ザ・バックヤード』も似た感じで、聞き役が全くの部外者だから、あまり深掘りできていない感があってもったいない。
実は「専門家が楽しそうに話している」みたいな内容って、NHKの『100カメ』が一番近そうな気がする。一応NHKのカメラ(大量のスマホとかGoPro)は意識しつつ、とはいえ普段の仕事場だから仕事の話がメインだし、楽しそうな職場であれば楽しそうな場面がいっぱいあるし。
紅茶のいれ方を米科学者がアドバイス、英国人の憤慨に米大使館が対応 - CNN.co.jp
英国人がこよなく愛する紅茶のいれ方を巡り、英米間で２５０年前のボストン茶会事件以来となる外交論争が勃発している。
紅茶がどうのこうのと若造がなにか騒いでおるぞ(コーヒーを飲みながら え? 本物の英国人は紅茶もコーヒーも飲まない? 酔っ払いが何を言うか。コーヒーでも飲んで目を覚ませ!
味として感じない程度の塩味で苦味が遮断されるそうだ。スイカに塩をかけて食う我々日本人的感覚からすると塩をかけると余計味を感じそうな気がするけど。
「完璧な紅茶」作るには塩を入れるべき、米科学者がアドバイス 英米「紅茶論争」に発展 - BBCニュース
教授の説明によると、塩には、紅茶の苦みを感じさせる受容体をブロックする働きがある。
なるほど。
ほかにも、紅茶の温度をより熱く保つためには、背の低いどっしりとしたマグカップを使うこと、マグカップとミルクを事前に温めておくこと、ミルクは紅茶を注いだ後に入れることなども挙げている。
ほう……?
例の話題のやつ、リンク貼っておきますね
https://www.jstage.jst.go.jp/article/faruawpsj/51/6/51_566/_pdf
http://satcom.jp/93/spacejapancommentaryj.pdf
ターミナル・リストの続編。前作よりは少しマイルドになったかな? どちらかといえばという話だけど。
誤字脱字の量から感じられる不景気よ(小並感 前作は誤字そんなになかったような気がするけど。出版前に誰も中身チェックしてないんだろうなぁ。言論・表現・出版の自由バンザイ。
100カメでHTV-Xスペシャルとかやらないかなー。HTV-X/H3の製造工程から、射場作業、レイトアクセス、打ち上げオペレーション、フェアリングが割れる映像や点のようにしか見えないISSがどんどん大きくなる様子、ドッキング中の作業や、ハッチを開ける映像を内側から。最後に生鮮食品の食事シーンで終了。さすがに規模がデカすぎて大変そう。2時間とか3時間のスペシャルで…… 普段の100カメも膨大な映像をギュッと詰め込んでいるから時々スペシャル版やってほしいなー。
SDR#ってIPv6には対応してないんだな。なんでだよ……
SDR#、4GiB越えのWAVにも対応していないし、dataチャンクの長さが0なのも対応していないし、いろいろ不便。ファイル開放もしてくれないし、簡単にハングアップするし、GUIはあちこちとっちらかって使いづらいし。
C#のDns.GetHostAddressesでローカルのPCの名前からIPアドレスを取るのに、3秒程度かかっていて、ちょっと遅い。試しにDNSサーバーをデフォルト設定からGoogle Public DNSに変えたら0.4秒くらいまで縮まった。まだちょっと遅いけど、我慢できるレベル。ローカルのデバイス名を名前解決しようとすると存在しないドメインの問い合わせになるから、近所のDNSサーバーに無くて順繰りに色んな場所へ問い合わせなきゃいけないから遅くなるのかな? マトモなDNSサーバーならまだいいけど、存在しない名前を渡されたら広告サイトのIPアドレスを返すみたいなサーバーにあたると面倒なことになりそう。
ローカルのPC名からの名前解決、DNSサーバーまで問い合わせずにローカルで完結させるような機能ってないんだろうか。それっぽい設定は大昔の記事で出てくるけど、Wikipediaで斜め読みした感じXPあたりから少しずつ削られて7あたりで廃止されたらしい?
GetHostAddressesはローカルの名前解決専用みたいな話らしいけど、とはいえGetHostAddresses("google.com")とかやるとちゃんと取れるから、インターネット上のDNSサーバーを使っているはず。
dll叩けばローカルの名前解決専用のAPIがあるらしいけど、さすがにそこまでするのもなぁ……
C#のInterlocked.Exchangeってコストどの程度なんだろうか。
メンバ変数を取ってクリアする、みたいな処理、var a = _hoge; _hoge = 0; みたいなやつを var a = Interlocked.Exchange(ref Hoge, 0); みたいに1行で収まるから書くのが楽。しかもスレッドセーフにもなる。オトク! 知らないで見ると何をやってる処理なのか分かりづらいのがネック。あとCLI準拠じゃないぞと脅してるのが気になる。ググってもいまいちどういう意味なのかよくわからない。マルチプラットフォームを想定すると実装依存だから注意してね、みたいな感じなのかな。
ffplayでMPEG-2 TSのリアルタイム再生、うまく動かないんだけどなんでだろう? TCP、パイプ、名前付きパイプを試してみたけど、どれも配信側が終了するまで再生が始まらない。
TCPはTcpListener/TcpClientで、パイプはProcess.StandardInput.BaseStreamで、名前付きパイプはNamedPipeServerStreamで作って、それぞれ書き込んだけど、書き込んでいる側のプログラムが止まるまでffplayの画面が表示されない。
書き込んでいるtsファイルに対してffplayを起動すると、起動時にファイルの中身がカラだからエラーで落ちる(5秒位待ってからffplayを立ち上げると再生される)。
Processで起動したffplay以外にも、ターミナルから手動で起動したffplayでも同じような挙動。
ffmpegでUSBカメラをMPEG TSに変化してTCPサーバーを立てて、ffplayで再生するコマンド
ffmpeg -f dshow -video_size 320x240 -i video="USB Camera" -f mpegts tcp://[::1]:1234?listen
ffplay tcp://[::1]:1234
エンコードが間に合わないんでQVGAを設定している(適当な大きさでいい)。ffplayを起動すると10秒近く経ってから再生が始まる。
ワンセグのMPEG-2 TSも、しばらく(数十秒)読ませると再生が始まるから、バッファに溜まるのを待っている感じの挙動なのかな。ffmpegのUSBカメラだと早めに再生されるのはビットレートの違いかな。ffplayの-helpを探してもそれっぽいオプションが見当たらない。ffmpegのオプション多すぎて全部読むの厳しそう。。。
試しに最初に32MBくらいヌルパケット送り込んでみたけど、変化は無かった(エラーメッセージ増えたかなくらい)。ヌルパケットを破棄してるってことはネットワークレベルのバッファじゃなくて、映像信号レベルのバッファか。
ffplayで-fflags nobufferを追加すると、ffmpegからUSBカメラの映像を受け取るときはだいぶ低レイテンシで再生できる。ただ、ワンセグはやはりソース側が閉じるまで再生が始まらない。
切断はどうやって判断してるんだろ?と思って、試しに送信側でバッファして1秒毎くらいに転送させてみたけど、相変わらず終了するまで再生が始まらない。送り側が終了したらほとんど直ちに再生が始まるのが謎い。
USBカメラはあまり遅延なく再生できるってことは、間にffmpeg挟んでトランスコードしてffplayに突っ込めばいいんか?と思って、そういう感じでやってみたけど、今度はffmpegが身動きできなくなってる。
試しにVLC media playerをインストール。最初はストア版を入れてみたんだけど、なにかおかしい。ということでアンインストールの後に通常のx64インストーラーでインストール。VLC、インストーラー版もWindowsストア版も名前はVLCだけど、中身は全くの別物なんだな。
ストア版だとtcp://[::1]:1234みたいなストリームには非対応だけど、インストール版なら問題なく動く。C#からProcess.Start(@"C:\Program Files\VideoLAN\VLC\vlc.exe", "tcp://[::1]:1234");みたいに起動してやれば、C#のTcpListener/TcpClientで送ったストリームを再生してくれる。ただしパケットのタイミングによって正常に再生できる場合とできない場合があって、後者の場合は映像は再生できるけど音声は出ない、みたいな感じになる。
ffmpegはとにかく持てるだけ大量のパケットを受信してから解析して再生することで、できるだけ正しく再生しようとするし、VLCは可能な限り少ないパケットを解析することでレスポンスを良くするが、高い頻度で間違えたまま突っ走る、みたいな感じなんだろうな。そんな両極端じゃなくて、もうちょっといい塩梅のヤツは無いものか。
VLCの名前の由来、Video LAN Clientなのに、ストア版はLAN経由のVideo Clientとしては使えないんだな。何という名前負け。。。TCPでMPEGTSを直接突っ込むみたいな使い方じゃなくて、もっと普通のLAN共有なら動くんだろうけど。
あきらめムードでググってたら、それっぽい話題が出てきた
ffmpegのオプション -analyzeduration と -probesize - 脳内メモ＋＋
-probesize 32は試していたけど、効果は無し、という判断だったのだけど、改めて試してみたらちゃんと効果があった。ただし適切な値を設定してやる必要がある。これはバイト数を指定するが、最小の32の場合、おそらく必要なデータが溜まらないので延々に待ち続けて、別の症状が出ていたんだと思う。
デフォルトは5MBだが、ワンセグ放送の480kb/sでは約1.4分程度の長さだから、再生が始まるのにこれくらいの時間がかかる。probesizeに48k程度(1秒弱)を与えてやれば、コマンドから1秒程度の待ちで映像が表示される。プロービング量が足りない場合は音声だけ(+スペクトルの映像)が再生されたりする。VLCの場合は映像だけはよくあるけど、音声だけというパターンは遭遇していない。ffmpegの挙動とまた違うのかも。
probesizeを188に設定すると、音声が再生される(音声か映像かは確率的かもしれないけど、何回か試した中では音声しか出てきていない)。一方でprobesizeを187に設定すると再生が始まらない。1パケットに満たない長さの場合はうまく認識でくなくなるようだ。一方で189を設定すれば(188と同様に)再生されるから、必ずしもパケットサイズの整数倍である必要はない。ワンセグをffplayで見る場合は48kがちょうど良さそう。
analyzedurationは時間で指定できるから、ビットレートによらず設定できるこっちのほうが便利そうだけど、とはいえどれくらいのデータを解析したらどれくらいの時間になるかと言うのは解析してみないとわからないはず。ためしに500000(0.5秒)を指定しても期待した動きにはならなかったから、probesizeで指定したほうが良さそうな感じ。映像データは固定ビットレートではないからprobesizeも確実というわけではないけど。
VLCも内部はffmpegを使っているらしくて、起動オプションでprobesizeも設定できるらしいが、今のところはうまく動いていない。どこか別のオプションが先にリミットに達したりしてるのかも。VLCはヘルプを日本語で出せるからどのオプションがどういう効果なのかはわかりやすいかな。結局ffmpegのオプションを調べなきゃいけないけど。。。
RazerのNAGA PRO、ホイールのチャタがいい加減頭に来たのでググったら、エンコーダを掃除したら治るよ、みたいな話が出てきたので、そんなばかな、と思いつつためしに分解。メーカー修理? こんなガバガバな製品作るようなメーカーがまともなサポートなんてあるわけ……
分解はすごく簡単というほどでもないけど、難しいというほどでもなく、面倒なだけ。基板がいっぱい入ってる。メインボードの下にはmicroBコネクタだけ乗った基板が1枚入っている。使い方によっては頻繁に抜き差しするから、摩耗したり破損した場合はメーカーに送ればコネクタだけ交換してくれそう。一番下に入ってるから作業コスト高そうだけど。
ホイールの側面にRGB LEDがついた基板と、本体側面にポゴピンを受ける基板、上面にデフォルトで感度設定が割り当てられたボタンが付いた基板。側面パネル(3個)にもそれぞれスイッチやRGB LEDが大量に乗った基板が入ってるから、トータルで製品に8枚くらいのPCBが入っている。そりゃまあこの値段にもなるか……という感じはする。納得はしないけど。
右クリックと左クリックはRAZERのロゴが入ったマイクロスイッチ。中クリックはTTCのマイクロスイッチ。ホイール左右はタクトスイッチ。エンコーダはKailhものが空中配線されている。
エンコーダは汚れている雰囲気はなかったけど、何回かグリグリやって組み立てたら、チャタリング解決した。なんでだよ。
組み立ててしばらく使っていてから気がついたけど、ホイールのクリック感が時々強くなる時がある。このホイール、クリック感が非常に弱くてエンコーダの中途半端な相で止まることがあって、不意にスクロールしたりすることがあるんだけど、もしかしたら不良個体を引いただけなのかもしれない。本来はもっと歯切れのいいクリック感があるのかも。
Kailhでググるとマウス用のエンコーダの話が大量に出てくるから、一応ちゃんとしたメーカーではあるんだろう。ただ、ちょっとした埃で正しく動作しなくなるとか、品質面ではちょっと微妙な気がする。不良個体だから影響を受けやすかったという可能性はあるにしろ、それなら不良個体を出荷した品質管理という話になるし。
やっぱりマウスを買うときは店頭で現物を触ってから買う方が良い。手に馴染むとかの話だけじゃなくて、不良個体を買っても判断ができない。明確に使用できないとかならともかく、ちょっと動作がおかしい程度だと「品質悪いけど、こんなものか」で済ませてしまう可能性がある。可動部の数で言えばキーボードよりマウスのほうがシンプルだけど、複雑度で言えばマウスのほうが高い。キーボードだと他のキーと打ち比べたりできるけど、マウスは各機能の直交性が高いので判断が難しい。
ホイールのチャタが治って安心してたんだけど、数日でまた軽微なチャタが出始めた。んなーーー。それっぽいエンコーダ買って交換しようかな。。。
PC側ソフト、最近は比較的安定していたんだけど、最近また調子悪くなってきた。サイドパネルのボタンが反応しなくなる症状。パネルの着脱とかマウス側の電源OFF/ONでは復旧せず、PC側ソフトの再起動で復旧する。数時間ごとにこういう挙動が出るから、いちいち再起動させるのが面倒。Razer君さぁ、マジなんなん?? 低品質なハードウェア、低品質なソフトウェア、高いのは値段だけ。
液晶を内蔵したトラックパッドってないんだろうか。マウスとしても使えるし、ジェスチャ操作だったり、画面端からフリックしてショートカットキーを表示したり。ASUSのノートPCとかでいくつか例があるけど、デスクトップPC用で同様のデバイスってないのかな。
5インチくらいのタッチ液晶に適当なPC側のソフトを組み合わせるだけで作れそうな気がする。液晶にアプリを常時表示させておいて、HID入力をキャプチャして上書きしてやればいい。探せばそんな感じのアプリありそう。ちょうどいい大きさのタッチ対応液晶のラインナップがほとんど無いのが難しいところ。
0 件のコメント:
コメントを投稿