牢人専用装備 #GhostOfTsushima

現実のファイヤーウォール: 防火壁
なろうのファイヤーウォール: 炎の壁

media-video/nvidia_video_sdk::gentoo が 6.0.1 しかないんですが、調べると最新は 11 みたいじゃないですか……
マジで？？？

ffmpeg の hevc_nvenc で -preset p7 とかが使えない……

media-video/nvidia-video-codec::gentoo も 8.2.16 で止まってるし……

pulseaudio で null-sink と loopback 使って音声のリダイレクトを試してみてるんだけど、 latency がちょっとゲームでは許容できるか微妙なところだ……
pacmd list-sinks によれば current latency: 2.07 ms とか configured latency: 7.13 ms とか出てきてるんだけど、体感できるのはおかしくない？

mpd から音楽を再生して切り替えてみると明らかに遅れがあるので、到底 5ms とかで収まっているとは思えない (そもそも latency_msec=1 してるんだけど "friendly request" なので遵守してもらえない……)

これは若干思わないでもないので nvidia-video-codec リポジトリの最新のコミットを覗いてみたんですが、単に新しい SDK バージョンに書き換えるだけでなく非自明な変更が入っていた (つらい) のでまあ普通に無理です (つらい)

音声処理は (単一のフィルタとかであればともかく) 時間方向での処理が多いとかグラフ構造を処理することになるとかが多くてハードウェアでの処理に不向きなのではなどと妄想している

グラフィックスは、ある意味ではかなり declarative なところがあって、1/60 秒のフレームごとにドローコールが全部飛んでくる、過去フレームの保存はそんなに多数必要ない、みたいな感じだからどうにかなっているのでは (超適当)

や、でもドローコールが stream に対応して頂点バッファがサウンドのバッファに対応していると考えると、時間方向は割とどうにかなるのか……？ (この文章は何も考えないで書いている)

ノイキャンは時間的に同期していて、かつ source と sink のヒエラルキーがほぼ固定できるからでは

http://itline.jp/~svx/diary/images/2020/20200421_5.png

たとえばこういう構成にしようとしたとき、依存関係とその深さが用途ごとに割と動的に変化しそうな雰囲気があって、まあ CPU でやるしかないのか……？ という諦観が湧いてくる

loopback だけでなく null-sink 側で latency がかなり入ってそうな予感がしてきた、これはもしや……どうしようもないやつ……

まあやろうとすればできるのかもしれないけど……うーん……？

ハードウェアによる処理は、動的に構成・変更される依存関係ヒエラルキーを扱うのが苦手であるという、そんな感じの偏見があるので、そこまで不自然に感じない

信号をフィルタ処理などによって変形するとかは、まあ正直ハードウェアでできると思う (というか既にできてるのだと思う、応用例をあまり知らないけど)

まだ寝るどころか風呂に入ってない

テスト動画で遅延を確認したけど、 null-sink と loopback 通すとだいたい 420〜480 ms くらい遅れてたわ……
そりゃ体感するわけだ

Audio Video Sync Test 60 FPS - YouTube
https://www.youtube.com/watch?v=TjAa0wOe5k4

これ使った

http://twitch-event-engineering-public.s3.amazonaws.com/sync-footage/Sync-Footage-V1-H264.mp4

http://twitch-event-engineering-public.s3.amazonaws.com/sync-footage/Sync-Footage-V1-ProRes422.mov

大学の人事課にメール送ったんだけど、送信元アドレスの確認を忘れてて「あれ、もしかして loliconductor の方のアドレス使ってたりしない？？？」と冷や汗をかいた (大丈夫だった)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

DocumentType ノードが Document ノードの first child になるものとばかり思っていたんだけど、もしかしてそんなことない？？？ (実験してない)

XML DOM 、個人的に「なんでやねん」と思う場所がいくらかあるので挙動が想像しづらい)

DocumentType なんてどう考えても Document ノードだけがたかだか1つ持つ属性なんだから、 Node インターフェースを経由して提供すべき情報ではなくない？？？

これも将来の拡張を想定してのことなのかな……

とりあえず libxml2 を軽く眺めてみたけど、 DocumentType は DTD ノードで、これはちゃんと Document ノードの直下に出てきそうな雰囲気がある

さて今回の試みは何時間融かすことになるかな……

あれ、 Namespace Node みたいなのがある気がしてたんだけど、あれは infoset か何かの話で DOM ではないんだっけ

XML Information Set (Second Edition)
https://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.namespace

はぁ〜ややこし

DOM Level 2 Core だと namepsace は Node interafce の方に入ってくるのか

Text とかはどう考えても namespace 無関係なのに……

考え事を、していた

そもそも何故 XML を使いたかったかというと、独自のスキーマ (および検証) と独自の変換 (XML → HTML) を柔軟に用意したかったからなんだよな

もっといえば、データ構造の定義とその変換自体をデータとして記述できることが望ましかった。
よーするにプログラムみたいなもんだ

XML 技術スタックであれば XML, XSLT, RelaxNG および XHTML, SVG, MathML, XLink, etc. があるのでその辺りの「構造と変換を記述」が十分に可能だった (処理系が充実してるとは言ってない)

此度の私の迷走は、これらの XML 規格の処理系が貧弱である以上、構造と変換の記述を Rust でネイティブにやった方がよくない？ という発想に基いている。
ただ、 Rust での XML 関連も負けず劣らず貧弱だった (←しってた)。

で、ちょっと思ったんだけど、基本的に DOM のフル機能が欲しい場面って実はそんなにない気がしていて (たとえば XPath とかはかなり関数型寄りな言語仕様だけど実用上はそこそこ使える)、であればさっさと DSL を定義してしまった方が実は早いのではと。

構造定義と変換の定義をできる軽めの DSL を定義したうえで、その処理系を実装してやればいい。
不幸中の幸いと言うべきか、 DOM の実装は煩雑で充実度が低いが、 SAX / StAX のようなストリーミングパーサの実装は Rust でも選べるくらいにはある (はず)

DSL でなく処理系が API を露出したうえで WASM とかで変換器を置いておいた方が一般性があるのでは？ ともちょっと思ったけど、結局その WASM を吐くための元言語でのコードも一緒に置いておかないと変更がままならなくなるし、元言語でそんなに充実した変換器が書けるなら最初からネイティブでやれと

というわけで、次の目標は DSL をでっちあげることです (白目)

XSLT はつらいし、 XPath はつらいし、どうすりゃいいんだ……

思うに XPath のつらさは infoset を前提にしているところが一因なのではと

https://mastodon.cardina1.red/@lo48576/105174713705125707

これ s/XPath/XSLT/g やんな

意識高い人「しんどいはエンジョイと似ている」

普通に HTML に class とか data-foo とかの属性であれこれメタデータ付けてやるスタイルもn年前から検討しているんだけど、やっぱり footnote まわりとかいろいろを考えると弱いのよね。
たとえば [1] とか [2] とか [2a] とかのようなマーカーを CSS の疑似要素を使わずに出したいみたいなことを考えると、どうしても XSLT みたいな外部の変換を通すことになるし、だったら敢えて拡張なしの HTML で意味論の曖昧な属性をベタベタ貼り付けるのは微妙かなと

なぜ疑似要素が駄目かというと、あいつらコピーしたときテキストとしてクリップボードに入ってこないから。
ブラウザで選択してコピーされない文字列は装飾にしか使えない

あとは、データ構造を記述するうえで普通に toml とか json のような外部形式を使いたいというのもある。
これやると結局 XSLT 1.0 では足りないので、ネイティブロジックで変換を書くのは避けられない

SNS の投稿を引用するとき ActivityPub の JSON をポンと置いておけば自動的に整形されるとか、ほしいじゃん？
(javascript を使えとかいう意見は絶対に認めない)

URL の短縮表示で「…」みたいなのを後ろに置くときとか、 ::after 使うといいなどはある

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

両方くれという感想しかない >教科書を紙にするか電子化するか

検索できない教科書はカスだし、 DRM がかかっていたり独自形式だったりするせいで10年後や30年後に読み直すことができない教科書はもっとカス

このアカウントは、notestockで公開設定になっていません。

普通の要素を CSS で選択拒否するだけだと、スクレイピングとか javascript とかでテキスト化したときに余計なものが入ってくるので……

このアカウントは、notestockで公開設定になっていません。

https://mstdn.rinsuki.net/@rinsuki/105174799818860307 #これすき

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

PS2 もコンポジットだったからなぁ

D端子……使ったことない気がする

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

64ビットマシンであるところの NINTENDO64 が最新に決まってるよなぁ！ (適当)

ロシア語…… novaya zemlya くらいしか知らない (?)

ノヴァヤゼムリャ - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%B4%E3%82%A1%E3%83%A4%E3%82%BC%E3%83%A0%E3%83%AA%E3%83%A3

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

DDOS FTW

邪悪な概念、すき

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

https://twitter.com/waganahatantan/status/1325121396213653512

これほんま好きやわwww

このアカウントは、notestockで公開設定になっていません。

「男子高校生の日常」実写映画化！菅田将暉、野村周平、吉沢亮が非モテ男子に : 映画ニュース - 映画.com
https://eiga.com/news/20130417/3/

？？？

有害薬物には詳しくないが、シーシャというのが全て C# の話だと思って生きている (???)

このアカウントは、notestockで公開設定になっていません。

それはそう

そもそも “日常系” にもコメディ成分が強いものとそうでもないものがあるので

アニメ絵にする際にかかっているデフォルメとそれに伴うキャラの強調を、実写で見るとそれはそれはサムく見える

このアカウントは、notestockで公開設定になっていません。

https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%BC%E3%83%81%E3%82%AB#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Albania_bunkers.jpg

誰かこれに「ゆるキャン」のロゴ画像付けといて

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ずいぶん近代的な群馬県だ (?)