perlでMP4やMOVの縦横サイズを取得する
タイトルのまんまのエントリ。
動機としては、ウチのおひとり様ActivityPubサーバーに動画をアップロードしてみたい。
んで、ActivityPubサーバーは、フォロワーさんのところに投稿（ActivityのJSON）を配送するんだけど、この時に縦横のピクセルサイズが必要っぽい。
動画を扱う時に、鉄板の定番のffmpegでサイズ取得も当然、ほかに解像度変更やファイルサイズの圧縮とかいろいろできるんだけど、レンタルサーバーでffmpegを使えるという話を見たことがなく、当然わたしが利用しているロリポップも使えない。
となると、縦横のピクセルサイズは自力でなんとかする必要がある。
ぐーぐる先生に聞きまくってなんとかなったのでメモ。
「MP4のファイル構造を解説」
https://qiita.com/satken2/items/d14b4113fe3fb5f5597b
↑こちらのサイトで一発解答（多謝！）
MP3とMOVファイルは基本３つのブロックの塊らしい。
| サイズ | タイプ名 | データ |
| 4バイト | 4バイト | 可変 |
最初の4バイトに入ってるサイズでブロック全体の長さがわかる。
BOXの長さの情報が2^32バイト(=4294967296)を超える場合、最初の4バイトには0x00000001が格納され、その変わりに9バイト～16バイトに実際のBOXの長さが書かれます
ということだけど、今回わたしの場合は10秒もないようなSNSに上げるためだけの動画なのでスルーする。
そのブロックにもろもろの情報が入っているので、欲しいところを取得する。
このブロックのタイプはいったいなんなの？というのは
「QuickTime File Format」
https://developer.apple.com/documentation/quicktime-file-format#//apple_ref/doc/uid/TP40000939-CH204-SW1
↑こちらに全部ある。
ここまでわかればやることはわりと単純。
1)最初の4バイトをみてブロックサイズを取得
2)次の4バイトをみてブロックのタイプを取得
3)必要なタイプだったらそこで情報を取得して終了
必要なタイプじゃなかったら次のブロックをみにいく
ちょっとハマったのが
各ブロックはデータを持たないものと持ってるものがあるということ。
しょうがないんで、次のブロックを先読みしてタイプ名があるかないかで判定。
以下で欲しい情報が取れた。
わたしが欲しいのはタイプ「tkhd」(たぶん、トラックヘッダーの略)のブロックのデータ部に入ってる幅と高さ。
my @parent = (
'cmov', 'ctts', 'edts', 'esds',
'free', 'ftyp', 'iods', 'junk',
'mdia', 'minf', 'moov', 'mvhd',
'pict', 'pnot', 'rmda', 'rmra',
'skip', 'stbl', 'trak', 'uuid',
'wide');
my @child = (
'fiel', 'mdat', 'rdrf', 'rmcd',
'rmcs', 'rmdr', 'rmqu', 'rmvc',
'wfex', 'cmvd', 'co64', 'dcom',
'elst', 'gmhd', 'hdlr', 'mdhd',
'smhd', 'stco', 'stsc', 'stsd',
'stss', 'stsz', 'stts', 'tkhd',
'vmhd');
open(IMG, $file) || die;
binmode IMG;
my $len; my $type; my $data;
my $width; my $height;
while(1){
my $buf;
read(IMG, $buf, 4);
$len = unpack("N", $buf);
read(IMG, $type, 4);
last if ! $type;
# check next type
my $has_data;
seek(IMG,4, 1) || last;
read(IMG,$buf,4);
last if ! $buf;
$buf = quotemeta $buf;
unless( grep(m!$buf!, @parent) || grep(m!$buf!, @child) ){
$has_data = 1;
}
seek(IMG, -8, 1);
if( $has_data ){
$len -= 8;
last if $len < 0;
my $begin = tell(IMG);
read(IMG, $data, $len);
}
if($type =~ m!tkhd!){
my @check = unpack("x76 n x2 n", $data);
if( $check[0] && $check[1] ){
$width = $check[0]; $height = $check[1];
last;
}
}
}
perlはやっぱり凄くて、バイナリファイルも簡単に扱うことができる。
とはいえ、それを扱うスキルがない人間のせいでずいぶん時間がかかってしまった。
これでうちのActivityPubサーバーに動画をあげるための下準備はできた！
…と思ったんだけど、動画ファイルって5秒ぐらいのものでも1M〜2Mもあって慌てた（今さら
わたしはロリポップのビギナーコース。そんなでかいファイルを気楽に上げてたらあっという間に利用できるディスクスペースを食い尽くしてしまう。
なもんで、ここまで作ったけど諦め。きっとそのうち何かの約に立つ、こともある、かな。
今の時期、まじでタケノコ美味くて悶絶する。
刺身で美味いのはもちろん、焼きタケノコがもう絶品。
水分を飛ばすイメージでじっくり弱火のフライパン。水分が飛んできたかなと思ったらオリーブオイルを回しかけてタケノコに焼きめをつけて、塩をふたふり。
これだけでいくらでもご飯が食えるし酒が飲める。
マジでオススメ！！！
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
おひとり様ActivityPubサーバーの詳細
先月、ウチのおひとり様ActivityPubサーバーの全体像、実際やってることはホームページに個別ページを作って掲載した。
あらためて、こっちのブログでもその告知。
ブログとホームページの棲み分けというか、以前、SNSに投げた通り
１）SNSで思いつきをちらほらメモ
２）ブログで自分のSNSを見ながら動機や経緯を整理
３）１と２を経て、ホームページに完結した個別ページとして掲載
各Activityを実装するにあたってのブログのエントリとそれを完結させた個別ページはあるけど、サーバー構成について完結させた個別ページはあるけどブログのエントリはなかった。
上記の棲み分けでいうと、２）→３）ではなく３）→２）が今回のエントリ。
おひとり様ActivityPubサーバーの構成::On Golden Pond
https://www.doncha.net/activitypub/activitypub013.html
↑ホームページ掲載はこちら
大雑把にやってることは
・htaccessでリクエストのリダイレクト設定
・リダイレクトされたリクエストをスクリプト１で処理
・ActivityPubの仕様通りにスクリプト２で対応
ウチの構成を丸裸…こういうページを作ることで、自分でも未確認だったり再確認することがいろいろ出てきてびっくり。
昔からよく言われるように「ひとに教えるのは自分に教えることになる」というやつか。
自作実装したのは「自分のわかる範囲で片付ける」ため。
仮にMastodonなど定評のあるActivityPubサーバーソフトウェアをめちゃくちゃ頑張って導入/設定したとしても、何か問題が出た時に、自分のスキル/知識では解決できるとは思えない。管理運用するサーバーの種類も多いし、それらを操作する言語もひとつじゃ済まないし。
おひとり様でサーバーを立ててFediverseに参加できても、すぐに退場することになるんじゃ困る・面白くない。
てことで
・ドメイン取得済み
・レンタルサーバー契約済み
・perlならどうにか手癖で書ける
・apacheなら少しわかる
・データベースも少しはわかる
・htmlとcssは手書きできる
という現状環境と自分のスキル/知識の範囲内。
ActivityPubの仕様、というか決められてる「約束事」は最低限のリクエストのやりとりだけだし、上記程度のスキルで対応できる。
仕様を実装した上で、気をつけたのはひと様の投稿の扱いだけで、それ以外はいろいろがっつり省いた。
だいたい、フロント側はアクセスしたらタイムラインを表示するだけ。もちろん、ページ更新は手動で再読み込みというチープな作りだ。
それでも十分面白いし、自分のタイムラインにどっぷりハマってる。
現状環境、スキル/知識の範囲内でいうとphpやrubyを使えるひとが多いだろうし、phpやrubyでwebというひとはデータベースも使えるだろう。ドメインやレンタルサーバーなんかは外食2回分ぐらい。
やってみると、思っていたよりもFediverse参加のハードルは低い。
おひとり様サーバーを作って参加してみませんか！？
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
お散歩デジカメ日記2025年3月号
個人ホームページのお散歩デジカメ日記に月刊デジカメ徘徊老人日記3月号追加した。
今年はウォーキングを頑張るのがひとつの目標。
還暦すぎると健康第一。その健康維持とボケ防止のため。年初から3ヶ月続いていて、ウォーキングがほぼ習慣化してる。デジカメでパシャパシャ撮るものを探して歩いて、同じコースでもちょっとした発見があるので飽きない。
そうして撮りためた写真をホームページに掲載する、という成果物を得られるんで、一石二鳥。
お散歩デジカメ日記::On Golden Pond
https://www.doncha.net/toydigi.html
1月2月は撮ったものを、なんの加工もせずそのまんま。
今月、3月は縦横比こそそのままだけど、少しトリミングをしてみた。
KODAK PIXPRO FZ45はデフォルトのワイドの画角は50mm換算27mmとかなり広い。ズームすればいいんだろうけど、ぱっと撮りたい時にいちいちズームして〜とかやってられない。
そもそもウォーキングの記録、みたいなもんだしあまりこだわってもなあ、と。
とはいえ、ホームページに掲載するにあたって、写真を選んでると、ここもっと寄りたいよなあ、こっちに詰めてこっちは広がりを残したよなあ、とか欲が出てくる。
色味の調整とかフォトショでやりだすとキリがない。そもそもFZ45で写真の保存形式はjpgなのでそれをいじると劣化することになるし。
ただ、構図については、少しいじってみようと、今回はいくつかの写真でやってみた。
昔、新卒で入った底辺エロ出版社で写真集のために写真のトリミングはさんざんやってたことを思い出す。見せたいものを見せたいように見せるのも編集者の仕事、ということだったなあ。
まあ、還暦すぎの趣味、続かないと意味がないんで気楽にやっていこう。
個人ホームページ 『On Golden Pond』 はオレオレMovableTypeが生成する静的ページ。それってのは、表示速度最優先のため。
なので、1ページに表示させる写真は1枚限定。
ページ遷移してもらう＝クリックしてもらう、というのはかなりコストが高くてほとんどのひとはクリックしないもの、というのは理解してるけど、それでも、それ以上に表示速度はだいじだ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ActivityPubサーバーのバグ修正メモ
ここんとこ時間もあるので、おひとり様サーバーの機能追加やバグ修正。
忘れないようにメモしておこう。
・仏語アクサンや独語ウムラウトまじりの投稿で文字化けを起こしてJSONのdecodeで失敗していた。
JSON.pmは文字コードというかutf8フラグの扱いにクセがあって。
decode_jsonに渡すJSONはutf8フラグがついていてはいけない/事前にutf8フラグを外す必要がある。
なので、事前にEncode::is_utf8でutf8フラグの有無を調べて、utf8フラグがついてたらEncode::encode('utf8',JSON)などと、utf8フラグを外して渡してた。
アクサンやウムラウトは見た目1文字
「â」「ë」
だけど、コードポイントは２バイト使う（日本語などは3バイト）ので、スクリプトではutf8フラグをつけて扱う（検索などにそのまま使えるから）
これをEncode::is_utf8でうまく検知できてなかったっぽい…「ぽい」というのは、まだしっかり特定できてないから。
evalでdecode_jsonを括って$@でエラーを捕捉してるところ、エラーが出たらもう一度同じ処理を入れることにした。原因追求をさぼって結果オーライ、というのは昔からの得意技（技？
・お相手サーバーの生存確認を追加した。
応答の確認に時間がかかるサーバーがあった。セッション切れを起こしてしまうのは致命的。
「LWPでtimeout指定が効かない」
https://t2aki.doncha.net/?id=1731205503
↑この対応で解決したはずなのに、このtimeoutの処理が効いていないサーバーがあった。
同じ500番代なのになんでだろ…。
てことで、投稿を配送する前にお相手サーバーが応答してるかどうかの確認することにした。
lwpでリクエストを投げてもたぶん同じことだろうし、Net::Pingを使うことにした。
今のところ意図通りに捕捉できてる。
・アナウンスした時にフォロワーさん以外に通知が飛ばない。
Activityの配送先は自分のフォロワーさん。なので「自分のフォロワーさんじゃないアカウント」の投稿をAnnounce（ブースト、リポスト、リノート）したら、そのアカウントにも配送する必要がある、ということをすっかり忘れてた。
AnnounceするActivityの投稿者をフォロワーリストで確認。
フォロワーリストに入ってなかったら、配送先に追加。
細々というか、2年近く使ってるというのに、いろいろ出てくるもんだ。
けっこうなスピードで疾走感があった。楽しそうでいいよねえ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
自作ActivityPubサーバーにリプライを実装
当初からリプライを実装するつもりはなかったんだけど、今日とりあえずリプライを実装した。
どうしてリプライを実装しなかったのか。
タイムラインの投稿の返信（リプライ）ボタンをポチッとクリックして、画面の向こうのたぶん面識のないひとに安直に話しかけることの距離感があやういから（わたしの場合）
返信するケースというのは、ほとんどの場合がマウント合戦だと思っていて、
「それ、おれ/わたしも知ってるー！」とか
「おれ/わたしはもうやってきたことだ」とか
「おれ/わたしの方が詳しい/当事者だよ！」とか
そこまでの関係性のない、あかの他人に話しかける動機というのはやっぱり、親近感とか共感だけではなくて、なにかが少し混じってビミョーに違ってると思う。
なので、SNSでやらかすのはこんな局面だろうと思ってるし、わたしもやらかしの返信をしてきたこともあり、リプライは危ないから実装をしない、とActivityPubサーバーを作り始めた時点で決めていた。
なんだけど。
Mentionをいただいて返事をする時に、ウチはリプライに未対応なのでリプライ要素のないJSONを返していた。投稿に対するリプライ要素があればツリー表示となるけど、リプライ要素がないJSONだと単品のMentionとして表示されるだけ（だと思う）
お相手にしてみると「あれ？なんだっけ？これ」ということになるだろうしなあ。
てことで、リプライ要素を付与したActivity（JSON）を返すように実装した。
ただし、返信（リプライ）ボタンを表示するのはMentionをいただいた投稿限定。
ホームタイムラインに流す投稿には表示しない。（わたしの場合）やらかす危険しかないから。
昨日実装した「転送」と今日実装した「リプライ」について、別サーバーの別アカを使って確認したところ、「意図通り」反映してるっぽい。
転送もリプライも、いろいろちょっと危ういんで、様子を見てながら運用する、ということで。
昨日、今日と2日続けてActivityPubサーバーをいじっててしみじみ。
やっぱ、ActivityPubも、それを実装するperlもめっちゃ面白い！
還暦過ぎの趣味、ボケ防止の趣味としては文句のつけようがないよなあ。
通り抜けた向こう側に光がある、という絵面。定番だし、やっぱ好きだわ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
自作ActivityPubサーバーに転送を実装
Activityの転送という仕組みがあって、それはActivityPub的には必須（MUST)とされている。
ずっと未対応だったのはFORMデータ本文＝ActivityのJSONに対する署名のやりかたがわからないから。
…今もまったくわかってない。
・Activityを転送する
受け取ったActivityを、受け取ったサーバーがそのまま自分のフォロワーに配送する。
この時、もしもActivityが改ざんされていても受け取ったサーバーはわからないし、わかりようがない。とりあえず、そのまま転送するだけ。
なので、この問題を解決するのが、Activity本文について署名をする＝JSON-LD（JSON Linked Data）署名。
この署名をActivityに付与することで、Activityの改ざんなどを検知できる、ということ（らしい）
ただ、このJSON-LD（JSON LinkedData）署名は、AcitivityPub的には必須（MUST）ではない。実際、今日時点で確認したらCreateのActivityにJSON-LDの署名がついているのはMastodon系のサーバーで、ほか、Misskey系やAkkoma系のサーバーではJSON-LDの署名はついていない。
それならば。
ActivityPub的に転送はMUSTなので、JSON-LD署名は未対応のままでも実装だけはしてしまおうと（今さら
どうして転送なんてのがMUSTになっているかというと。
https://argrath.github.io/activitypub/#inbox-forwarding
注: ゴーストリプライ問題を避けるための転送
以下の節は、連合ネットワークで時々問題を引き起こす、 「ゴーストリプライ」問題を緩和するためのものである。この問題を例で示す。
Alyssa は、会議での論文の発表が上手くいったことを投稿し、 友人である Ben を含む彼女のフォロワーコレクションに送りました。Ben は祝福する内容を Alyssa のメッセージに返信し、 宛先に彼女のフォロワーコレクションを含めました。しかし、Ben は Alyssa のフォロワーコレクションの内容にアクセス出来ないので、 Ben のサーバは彼のメッセージを彼らの inbox に転送できません。次の機構がない場合、その後 Alyssa が Ben に返信すると、 彼女のフォロワーは、Ben の返信を見ることなく Alyssa が Ben に返信するのを 見ることになります。これはとても混乱します!
わたしがお相手とMentionで会話をした時に
・わたしは自分の投稿をフォロワーさんにも配送してるのでわたしのお相手への投稿は見える。
・でも、お相手からのわたしへの投稿はわたしのフォロワーさんに見えるとは限らない。
・わたしが壁に向かってなにか喋ってるようにしか見えない、ということになる。
なので、お相手からわたしへの投稿を、わたしのフォロワーさんにも見えるように転送する、ということが必要。
必要かどうかは全面的に賛成ではない、というか必須にする理由としては弱いと思ってるんだけど、仕様的にMUSTとされちゃってるからには対応せざるを得ないよなあ。
で、転送を実装しちゃったんで、転送したNoteに対するDeleteも実装。
・転送したNoteのIDをリストで保存
・Deleteが飛んできたらNoteの転送履歴を確認して転送した投稿が該当してたらDeleteを転送する
ということにした。
転送がMUSTなのは仕様で見てたけど、実装してなかったのは。
JSON-LDに対する署名のやりかたがわからない、というのが一番問題で、次に、それとはまた別レイヤーでの話もあって。
わたしは、自分の投稿がどう扱われようが、割とどうでもいいと思ってる。
だけど。ひと様の投稿については、わたしが関わることでご本人の意図しない形で扱われるのはめちゃくちゃ困るしそれは避けたい。
ActivityPubの仕様上、Delete（削除）、特にリモートサーバーでの削除が意図通りにならない。ご本人は削除したつもりでも転送された別サーバーでは残ってることがないとは言えない。
https://argrath.github.io/activitypub/#delete-activity-inbox
あるアクティビティが発信元サーバからリモートサーバに転送された後、 オブジェクトの表現をリモートをリモートで削除することを 強制する 方法は、ActivityPub プロトコルにはないということに注意すること
なもんで、ひと様のデータを転送することには抵抗があった。
ちなみに転送するNoteは
わたし宛のメンションで、宛先（「to」や「cc」）に「public」や「わたしのfollowers」が指定されているもの。
（DMなんかはもちろん除外）
何かをたった「ひとつ」実装するだけとはいえ、考える/考えなきゃいけないことがいろいろあるよなあ。
足立やっちゃ場の旧日光街道に佇む松尾芭蕉…って、こんなだったんか。初めてみた。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
