2022/3/7 (月)

diary/Kojima

・ffmpeg-5.0の対応状況

ffmpegがメジャーバージョンアップして、共有ライブラリのバージョンも変り、APIも変ったようなので、 ffmpegを使ってるマルチメディア系ソフトウェアの対応状況を調べてみた。

久しぶりに新バージョンが公開されたmplayerだけど、これはもともとffmpegを内蔵しているので、 特に影響は無さそう。一応、内蔵のffmpegも5.0になっているらしい。

mpv は、元となった mplayer と比べて更新頻度が高く、0.34.1 で対応済み。

VLCは開発中の4系でffmpeg-5.0に対応したようだけど、3系へはbackportされてないっぽい。

libfreerdp2.so.2.6.0はffmpeg-5.0のlibavcodec.so.59に問題なくリンクできる。

gegl-0.4.36のff-{load,save}.soがffmpeg-5.0に未対応。多分、gimp-3.0くらいで対応するつもり?

参照している `avcodec_get_context_defaults3' という関数が ffmpeg-5.0では deprecated として削除されたのでビルドできない。開発チーム的には対応しているようなので、次のリリースでは対応してそう。

libasound_module_rate_lavrate.so, libasound_module_pcm_a52.so が参照しているものの、ffmpeg-5.0でビルドし直せば問題なさそう。

型変換でエラーが出るので、meson.build の common_flags のリストに"-fpermissive"を追加すればビルドはできるようだけど、動くかどうかはよく分からない。一応、Input/ffaudio.so は ffmpeg-5.0のライブラリを見るようにはなった。

もともとBLFS方面のパッチをあてて ffmpeg-4 系に対応させていたので、かなり大規模な変更が必要っぽいけど、もうQuickTime用のライブラリは不要な気がするな。

ffmpeg4のライブラリは互換性のために残しておくつもりなので、 とりあえず、vlc/geglあたりの最新版をffmpeg4系でビルドしておけば、ffmpeg5に移行しても何とかなるかな?


2022/3/3 (木)

diary/Kojima

・ファイル名の長さ制限

最近、WindowsのNTFSなら問題ないけど、Linuxのext4/xfs/btrs だと”filename too long"なエラーになる ファイルに遭遇したので、少し各ファイルシステムのファイル名の最大長を調べてみた。

Wikipediaによると、ファイル名の最大長はNTFSが256「文字」なのに対し、ext4/xfs/btrfs だと256「bytes」らしい。多分、このあたりの制限で長すぎるファイル名がLinux上では展開できないようだ、と判断し、NTFSなFSをloopbackでマウントして、そこに展開してみることにした。

当初、mkfs.ntfs は " mkntfs [options] device [number-of-sectors]" という使い方なので、 loopback用のファイルをNTFSにできないのかな、と心配したけど、-F(force)オプションを指定すれば、 ファイルもNTFS形式にフォーマットでき、loopback 経由でマウントできた。

 最近のカーネルだと、mount -t ntfs3 すれば、従来のfuse経由ではなく、カーネル・ネィティブな NTFS ドライバが使えるっぽい

このloopbackマウントしたNTFSなFS上だと、Linux上ではエラーになる長いファイル名も問題なく展開できたので、 NTFSも捨てたものじゃないな、と見直しているところ。NTFSってFSの世代的にはXFSよりも新しくZFSと同世代だから、 FUSEではなく、nativeなkernel driverで対応するようになったNTFSって、案外面白いかも知れない。

 試してないけど、NTFS3 を組み込んだ5.15カーネルなら NTFS を rootfs にできるんじゃないかな?
 kojima@pl74_1031:/loop/Test2$ cat /proc/mounts | grep loop /dev/loop0 /loop ntfs3 rw,relatime,uid=0,gid=0,iocharset=utf8 0 0 
 kojima@pl74_1031:/loop/Test2$ touch A.txt 
 kojima@pl74_1031:/loop/Test2$ touch a.txt 
 kojima@pl74_1031:/loop/Test2$ ls -al 
 合計 4,096 
 drwxr-xr-x 1 kojima users     0  3月 16日  12:13 ./ 
 drwxrwxrwx 1 root   root  4,096  3月 16日  12:12 ../ 
 -rw-r--r-- 1 kojima users     0  3月 16日  12:13 A.txt 
 -rw-r--r-- 1 kojima users     0  3月 16日  12:13 a.txt 

大丈夫なんじゃね? > case sensitive -- kojima 2022-03-16 (水) 12:14:03


2022/2/22 (火)

diary/Kojima

・ねこの日

毎年、「ねこの日」に合わせてカルディで「ねこの日バッグ」を売り出してて、 昨年までは先着順で私が行くころには「プレミアム」は売り切れ、通常版を買うしかできなかったんだけど、 今年はネットショップとスマホアプリでそれぞれ抽選になってて、両方とも申し込んでみたところ、 ビギナーズ・ラックで両方とも当選した(w

kaldi_01.jpg
kaldi_02.jpg

自分としてはゲットできただけで満足で、中身は母と妹に譲ってしまったんだけど、 まぁ、200年に一度の「スペシャルねこの日」として記憶に残る日であった(w


2022/2/18 (金)

diary/Kojima

・らんぼるぎーに

久しぶりに神戸に買い物に行って、元町あたりを歩いていたら、 「ボゴン、ボゴン」という大きなエンジン音が聞こえてきて、 何だろう?、と思って振り向いたら、ランボルギーニのウラカン?が停まっていた。

子供のころ「スーパーカー」ブームがあって、展示会とか行って写真を撮ったなぁ、、と 想い出しつつパチリ。

lambo_01.jpg
lambo_02.jpg

格好いいとは思うものの、狭いし、シートは低くて乗り降りしにくそうだし、 周囲も見づらそうだから、あまり自分で運転したいとは思わないけど、 まぁ、これがジジイになった、ということなんだろうな(苦笑


2022/2/16 (水)

diary/Kojima

・にんにく

日清的には「にんにく」って「黄色」のイメージなのかな?(w

にんにく.jpg

2022/2/12 (土)

diary/Kojima

・Wayland

Xorgサーバを更新するのに合わせて、少し Wayland 回りを調べてみた。

Wayland は、従来のXではXserver一つでディスプレイへの描画からキーボード、 マウスといった入力システムまで面倒みていたのを反省し、 基本的にクライアント自身が入力を受け取って画面を仮想的(メモリ上)に描画するとこまで実行し、 その結果を compositor に送って実際のディスプレイ上に表示してもらうような仕組みになっているらしい。

wayland.jpg

Xサーバの元々の設計は40年以上前で、 そこからのコンピュータの長足の進歩とXとの互換性を考慮するとこういう仕組みになるかなぁ、、という印象で、 Xに比べて特に「新しくこれが出来るようになった」みたいな機能は無くて、 「Xサーバの機能を分散しました」くらいな位置づけに加え、 従来との互換性のためにXクライアントに対応する Xwayland なサーバを用意したりしているので、 開発者がWaylandネィテイブなアプリを開発しようというモチベーションは起き無さそう。

まぁ、最近ではX用のアプリも、直接 X プロトコルを叩いてどうこうすることは無くて、 たいていは GTK なり Qt なりを経由してるから、とりあえずその手のToolkitレベルがWayland に対応すれば、 その上で動くアプリも自動的に Wayland に対応するようになる、みたいな感じで普及を進めていくんだろうな、という印象。

2008年ごろに始まったらしいので、そろそろ10年選手なものの、Xに置き替わるにはもう10年くらいはかかりそうだなぁ。。


2022/2/9 (水)

diary/Kojima

・plamo 以下のパッケージ数

こんな感じのPythonスクリプトで、plamo 以下のパッケージを数えてみたら、

 basenames = []
 for root,dirs,files in os.walk('/mnt/kojima/Srcs/Plamo-7/Plamo-7.x/x86_64/plamo') :
     for f in files:
         if f.find('.txz') > 0 or f.find('.tzst') > 0 :
             if root.find('old') < 0:
                 dt = f.split('-')[0]
                 basenames.append(dt)
 
 print(basenames)
 print(len(basenames))
 $ python count_pkgs.py
 ['less', 'net_tools', 'readline', 'zlib', 'acl', 'ncurses', 'bash', 'btrfs_progs', 'libfastjson',
  ...
  'kernelsrc', 'cgroupfs_mount', 'lxc', 'lxcfs']
 1000

ということで、現役のパッケージはちょうど1000個あるらしい(w

contrib以下は292だったから、パッケージ数は1292か。


2022/2/7 (月)

diary/Kojima

・LLVM-13 と mesa-21.3.5

LLVM-13が出ていたのでパッケージ化して、mesa-21.3.5 をビルドしようとしたら、

 [1899/2789] Compiling C++ object src/gallium/drivers/swr/libmesaswr.a.p/swr_shader.cpp.o
 FAILED: src/gallium/drivers/swr/libmesaswr.a.p/swr_shader.cpp.o 
 c++ -Isrc/gallium/drivers/swr/libmesaswr.a.p -Isrc/gallium/drivers/swr -I../mesa-21.3.5/src/gallium/drivers/swr 
 -Iinclude -I../mesa-21.3.5/include -Isrc -I../mesa-21.3.5/src -Isrc/mapi -I../mesa-21.3.5/src/mapi 
 ....
 次のファイルから読み込み:  ../mesa-21.3.5/src/gallium/drivers/swr/rasterizer/jitter/builder.h:168,
        次から読み込み:  ../mesa-21.3.5/src/gallium/drivers/swr/swr_shader.cpp:43:
 ../mesa-21.3.5/src/gallium/drivers/swr/rasterizer/jitter/builder_mem.h: 
 メンバ関数 ‘virtual llvm::CallInst* SwrJit::Builder::MASKED_LOAD(llvm::Value*, unsigned int, 
   llvm::Value*, llvm::Value*, const llvm::Twine&, llvm::Type*, SwrJit::Builder::MEM_CLIENT)’ 内:
 ../mesa-21.3.5/src/gallium/drivers/swr/rasterizer/jitter/builder_mem.h:87:36: 
   エラー: cannot convert ‘llvm::Value*’ to ‘llvm::Type*’
  87 |     return IRB()->CreateMaskedLoad(Ptr, AlignType(Align), Mask, PassThru, Name);
     |                                    ^~~
     |                                    |
     |                                    llvm::Value*
 次のファイルから読み込み:  ../mesa-21.3.5/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp:50,
        次から読み込み:  ../mesa-21.3.5/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h:32,
        次から読み込み:  ../mesa-21.3.5/src/gallium/drivers/swr/swr_shader.cpp:32:
 /usr/include/llvm/IR/IRBuilder.h:755:36: 備考: initializing argument 1 of ‘llvm::CallInst* 
   llvm::IRBuilderBase::CreateMaskedLoad(llvm::Type*, llvm::Value*, llvm::Align, llvm::Value*, 
   llvm::Value*, const llvm::Twine&)’
 755 |   CallInst *CreateMaskedLoad(Type *Ty, Value *Ptr, Align Alignment, Value *Mask,
     |                              ~~~~~~^~

みたいなエラーになってビルドに失敗するみたい。

同じコードがLLVM-12ではエラーにならないので、どうやらこれはLLVM側の変更が原因らしい。

とりあえず LLVM-13 の場合は、このあたりのコードを変更するようなパッチも提案されているものの、 mesa側はこのあたり(swr)のドライバはobsoleteだから削除しよう、という方針らしく、mainのブランチには反映されていない。 確認してないけど、今RCになっているmesa-22.0だと削除されてたりするのかな?

まぁ、もうしばらく様子を見て、mesaがLLVM-13で正しくビルドできるようになってからパッケージする方が安全な気はするものの、上述のLLVM-13用のコードでビルドを試しているところ。


2022/2/6 (日)

diary/Kojima

・Polarの心拍計

愛用しているPolarのCS200、かれこれ10年近く使ってるのかな?コンピューター部のスイッチカバーが劣化して、スイッチが剥き出しになってるし、胸に付けるセンサーもカバーが破れだした。

mini_polar.jpg

そろそろ交換したいんだけど、このシリーズはディスコンで互換性のある後継機種も無いようなので、ホイルの回転数センサーやペダルのケイデンスセンサーも合わせての交換になるからちょっと面倒。とりあえずダメになるまで使い続けるしかないかなぁ。。


2022/2/4 (金)

diary/Kojima

・NHKの歌謡スクランブル

「ポップス・バラード集」と言いながら、後半で突然 Kalafina の特集をやってやがる(w 朝の「古楽の楽しみ」同様、とりあえず録っておいて、興味無いのは捨てる、みたいな形の方がいいかな?



トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS