ffmpegを使って動画形式を変換したらファイルサイズが激減した
あるテレビ番組の動画をPCに取り込んだのだが、とてもファイルサイズが大きい。
ハイビジョンやフルハイビジョン、4Kに8Kの時代なので、１つの番組で数GBは今は当たり前なのかも知れない。
しかし、個人的にはそんなに綺麗な映像で無くてもサイズが多少小さくても、ある程度綺麗で内容が分かれば良い、というものを残して置きたかった。
ドラマもあるが、基本的にはドキュメンタリーや放送大学の講義などが中心なので、画質にはこだわりが無いのだ。
録画時に品質を落として保存し、メディアに書き込むときにさらに品質を落としている。
それでも2時間番組で1.99GBもあるのだ。
そこでffmpegを使って、動画形式を変換し、改めてエンコーディングしてみた。
これが元の動画の情報である。
Input #0, mpeg, from 'input.mpg':
Duration: 01:54:04.77, start: 0.255589, bitrate: 2392 kb/s
Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, smpte170m), 720x480 [SAR 32:27 DAR 16:9], max. 9571 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x80]: Audio: ac3, 48000 Hz, stereo, fltp, 256 kb/s
レコーダーからDVDに焼いたのでmpeg2形式である。
品質を落としているので画面サイズも720x480になっている。
これを以下のオプションで変換してみた。
ffmpeg -i input.mpg -vcodec hevc -r 30 -acodec aac -strict -2 -b:a 128k -ar 44100 output.mp4
ちょっと色々なページで情報を集めたのでオプション指定の仕方に古いものと新しい物が混ざっている。
本当はacオプションでチャンネル数を指定しなくてはいけない気もするが、できあがったものはステレオになっていたので良しとする。
とにかく動画のコーデックにH.265とも呼ばれている形式を、音声コーデックにはAACを指定してエンコードした。
H.265についての説明は以下を参考にした。
P08-もっと知りたい人のための「H.264」と「H.265」の違い : 富士通研究所
地デジやDVDに使われているMPEG-2に比べて4倍の圧縮性能があると言われている。
上のオプションで変換したところ、ファイルサイズが318MBまで小さくなった。
以下が変換後の動画の情報。
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'output.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2mp41
encoder : Lavf56.40.101
Duration: 01:54:04.83, start: 0.023220, bitrate: 372 kb/s
Stream #0:0(und): Video: hevc (Main) (hev1 / 0x31766568), yuv420p(tv), 720x480 [SAR 32:27 DAR 16:9], 231 kb/s, 30 fps, 30 tbr, 15360 tbn, 30 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 133 kb/s (default)
Metadata:
handler_name : SoundHandler
良くわからないが、変換形式は指定通りだ。
動画のビットレートが相当小さくなっていて情報が失われているような気がする。
しかし、実際に動画を見てみた範囲では、多少、細かいところがつぶれているものの、さほど劣化を感じなかった。
あるシーンのスクリーンショットである。
変換前
変換後
個人的にはほとんど違いはわからない。
これでファイルサイズが1/6になるなら、十分満足できる。
残しておく動画はこの形式で変換しようかと思う。
こだわりがある人は、この指定方法では良くないと思う人もいるだろうが、個人的には不満はないのでこれで良いかなと思う。
注意が必要なのは、H.265は新しいコーデックなので、新しいGPU、取り分けCPU内臓のものの場合はかなり新しい世代のものでないと、ハードウェアでのエンコード、デコードはできない。
うちの環境では上の動画を変換するのに30分くらいかかった。
もっともスレッド数や優先度の設定をしておらず、他の作業ができる状態だったので、設定次第でもう少し早くなると思う。
再生もハードウェアの動画再生支援機能が効かないのでCPUに負担がかかる。
古いマシンでは再生するさいにカクつきなどが出るかも知れない。
スマホやタブレットでも性能によってはちょっと厳しいことになる気がする。
再生を重視すれば、一つ前の世代のH.264の方が良いのだろう。
もう一つGoogleドライブにアップロードした場合、H.264であればストリーミング再生ができるが、H.265である場合はストリーミング再生ができないようだ。
GoogleがH.265の代替として勧めているVP9を使ったWebM形式ならストリーミングできるんだろうか？
もっと良い指定方法や変換ソフトがあったら教えて欲しいと思う。
Kona LinuxとかLubuntuの聴き比べで使用していたお気に入りの曲、高音質の曲
先日、こんな記事を書いた。
これでKona LinuxのJACKとLubuntuのPulseAudioの聴き比べをした。
YouTubeの動画であること、元の音質以上には良くはならないことはわかっていたが、手軽に聞けることとやっぱり聞きたい曲を聞くのが良いだろうと思い、ブラウザで聞いていた。
まずはこれ。
鬼束ちひろの『流星群』
テレビ朝日のドラマ、トリックの第２弾のエンディングテーマだった。
『月光』も良いが、『流星群』とか『私とワルツを』の方が好きかも知れない。
現在、AbemaTVで『トリック』シリーズが配信中なので上に上げた曲はどれも再びちょっと注目されているのではないかと思う。
そして、あまり知られていない名曲だと思うのがこの曲。
『蛍』
映画『ラストゲーム 最後の早慶戦』の主題歌。
鬼束ちひろの曲で一番好きかも知れない。
困ったことにKona LinuxだとFirefox ESRで聞いていると曲の終わりか切り替わり時にブラウザがクラッシュする・・・。
YouTube動画をSMPlayerで聴けるSMTubeで見るのが良いのだろう。
ブラウザで聞くよりも高音質のはずだし。
もともとYouTubeでハイレゾ音質の動画はアップロードできないそうだから、どれを聴いても程度の差だろう。
より高音質で聞きたい場合は、上の記事でも紹介したe-onkyoのサイトで試聴するのが良いと思う。
2017年上半期 もっとも聴かれたランキングTOP100発表！ - ハイレゾ音源配信サイト【e-onkyo music】
96kHz/24bitのハイレゾ音源が聴ける。
もっと高い音質の曲をほぼ丸ごと聞きたい場合はこちら。
2L High Resolution Music .:. free TEST BENCH
ファイルサイズが大きいので注意。
他にも諫山実生など良いアーティストの良い曲があるが公式チャンネルの動画がなかったので紹介は控える。
上のe-onkyo.comのランキングを見ても分かるように、多くの人はジャズやクラシックを聴くようだが、個人的には声のある曲、詩のある曲が聴きたい。
この記事を見た人で、おすすめの曲があったら、コメントなどで教えて欲しい。
Puppy Linuxを自動で作ることができるスクリプトmakepupを試してみたが・・・
最近、話題らしく、日本でも幾つかのブログで取り上げられている。
流行に乗るのも悪くは無いが、個人的には公式サイトなどで配布されているPuppy Linuxを使うほうが良いと思う。
特に古いマシンの場合には、多くのマシンに対応できるように考えられて作られている。
素人が適当に作ったものよりも遥かに使いやすいはずだ。
また、不具合が出た場合にそれが各バージョンのPuppy Linuxに特有のものなのか、自分でビルドしたものが良くなかったのか分からない可能性も高い。
さらには多くの対処法や、有志の人が作ってくれたpetパッケージは、公式で配布されているPuppy Linuxのカーネルやライブラリを前提にしている。
同じカーネルやライブラリであるから対処できる方法があり、動作するアプリケーション、ライブラリのパッケージがあるわけで、独自ビルドではうまくいかない可能性がある。
自分で対処できるスキルが無いなら、やめておいたほうが良いと思う。
では、何故、今回使ってみる気になったかというと、新しいPCで使えるPuppy Linuxを作るためである。
2,3年前のIntel CPU搭載のマシンでも古いバージョンのPuppy Linuxでは動かない。
成熟し安定動作が期待でき、不具合があっても対処法が既にネットに情報提供されているTahrPupも動かないのである。
まだTest版という位置付けであるXenialPupなら、不安定ながらも動くという具合だ。
問題の核心はカーネルが古いというところにあるらしい。
なので、今回、紹介しているmakepupというスクリプトで指定できるカーネルを新しいものにすれば、新しいマシンでも動作するPuppy Linuxができる可能性が高くなる。
このスクリプトを動かすには大前提として
- 最新のPuppy Linuxの上で動かすこと
- ネットにつながっていること
- パーティションに5GB以上の空きが必要
になるだろうか。
最初、Puppy Linuxでしか使えないことを知らなくてUbuntuで試していた。
Puppy Linuxが動かないマシンのためのPuppy Linuxを作りたいのに、スクリプトを使うためにPuppy Linuxが必要だというのはちょっと納得がいかないというか残念だ。
文句を言っても仕方ないので、Puppy Linuxが入った別のマシンで作ることにした。
上のサイトでmakepup.tarをダウンロードして、適当な名前のディレクトリを作り、そこへmakepup.tarをコピーする。
tarという拡張子は掲示板にアップデートするためのダミーなので、これを削除する。
chmod +x makepup
として実行可能にする。
ファイルマネージャの「パーミッション」で変更しても良い。
./makepup -h
でコマンドオプションを確認できる。
--target: 1 is arm, 2 is x86, 3 is x86_64
--distro: 1 is debian, 2 is devuan, 3 is slackware, 4 is trisquel, 5 is ubuntu
--release
Debian: 1 is Stretch
Devuan: 1 is ascii
Slacko: 1 is 14.0, 2 is 14.1, 3 is 14.2
Trisquel: 1 is belenos
Ubuntu: 1 is trusty, 2 is xenial
--KERNEL: # as offered during slackware-based build
1 huge-3.0.103-tahr_noPAE_retro.tar.bz2
2 huge-3.12.21-slacko4G-i686.tar.bz2
3 huge-3.12.22-tahr-PAE-i686.tar.bz2
4 huge-3.14.20-tahr_PAE.tar.bz2
5 huge-3.14.20-tahr_noPAE.tar.bz2
6 huge-3.14.54-slacko32_noPAE.tar.bz2
7 huge-3.14.54-tahr_64.tar.bz2
8 huge-3.14.55-slacko_noPAE.tar.bz2
9 huge-3.14.56-tahr_PAE.tar.bz2
10 huge-3.14.56-tahr_noPae.tar.bz2
11 huge-3.14.79-tahr64.tar.bz2
12 huge-3.14.79-tahr_noPAE.tar.bz2
13 huge-3.16.43-s32-700.tar.bz2
14 huge-3.16.43-s64-700.tar.bz2
15 huge-3.18.22-slacko64.tar.bz2
16 huge-3.18.22-slacko_noPAE.tar.bz2
17 huge-3.4.103-tahr_nopae.tar.bz2
18 huge-3.4.94-slacko4G2-i686.tar.bz2
19 huge-4.1.11-slacko64_2.tar.bz2
20 huge-4.1.11-slacko_PAE.tar.bz2
21 huge-4.1.11-tahr64_2.tar.bz2
22 huge-4.1.30-xenial_PAE.tar.bz2
23 huge-4.2.5-slacko64.tar.bz2
24 huge-4.4.70-s32-700_PAE.tar.bz2
25 huge-4.4.70-s64-700.tar.bz2
26 huge-4.9.13-xenial_noPAE.tar.bz2
27 huge-4.9.13-xenialpup64.tar.bz2
28 huge-4.9.15-xenialpup64.tar.bz2
29 huge-4.9.30-s64-700.tar.bz2
が使えるそうだ。
何も指定せずに
./makepup
とすると
./makepup -t 2 -d 3 -K 24
としたことになる。
./makepup –target 2 –distro 3 –KERNEL 24
と同じだ。
これはx86 32bit用で、ベースとなるディストリビューションはSlackware、カーネルはhuge-4.4.70-s32-700_PAE.tar.bz2が使われるということだ。
--release 3
が省略されている。
今回、自分のマシンで使うために以下のオプションを指定して策せしてみた。
./makepup -t 3 -d 5 -r 2 -K 28 -D
64bit CPU用で、Ubuntuベース、リリースバージョンはXenial、カーネルはhuge-4.9.15-xenialpup64.tar.bz2を使うということだ。
「-D」オプションはプログラムをビルドしたりするときに使う開発者用のDEVXパッケージも一緒に作るということである。
2回警告文が出るがどちらも「y」と入力してエンターする。
マシンの性能にもよるだろうが、1時間以上は待たなければいけないだろう。
完成すると、以下のディレクトリにisoファイルができる。
woof-out_<main_distro_name>/woof-output-<derived_distro_name>
前述のコマンドラインオプションで実行すると
woof-out_x86_64_x86_64_ubuntu_xenial64/woof-output-xenialpup64-7.0.8.4
になった。
ちょっと待て。
今、Test版で公開されているXenialPupは7.0.8.5だ。
今回できたのはそれよりも古いのか？
気になったので、makepupを実行したPuppy Linux、XenialPup64 7.0.8.5で
uname -r
を確認してみた。
4.9.15
だった。
これはオプションで指定したカーネルのバージョンと同じだ。
う〜ん。
作る意味が無かったということだな・・・。
あとで動くかどうか確認するが、あまり意味は無さそうだ。
本当にマシンに合わせた独自のPuppy Linuxイメージを作ろうと思ったら、woof-CEの使い方をちゃんと覚える必要があるということだ。
実際は「-p」オプションがあり、処理の途中でポーズして、パッケージやリポジトリを変更できるらしいが、それをする知識があればwoof-CEで作る方が良いのではないかとも思う。
よほどの理由が無い限り、もう自動化スクリプトを使うことはないだろう。
一応、起動はできた。
これがデスクトップ。
見た目が違うが一応、JWMらしい。
前にフォーラムで手に入れた日本語化+MozcのSFSパッケージを読み込んで日本語化。
出ているダイアログはPaleMoonのアップデートしているところ。
PaleMoonは起動したが、Firefox、Chromiumはいろいろライブラリが足りないようだ。
また、やっぱり何かの拍子に動作が不安定になり、最悪の場合、フリーズする。
さらに配布されているものよりもメモリの消費量が大きい。
足りないライブラリをインストールするとメモリもファイルサイズも増加する。
4GBや8GB、場合によってはそれ以上のメモリを搭載しているPCもある中でメモリの消費量はそれほど大きな差があるとは言えなくなってきてはいる。
また、pfix=nocopyでsfsファイルを事前にメモリに読み込まないようにすることもできる。
初期の空きメモリは大きくなるが、メモリに主要ファイル群が読み込まれることによる高速化が期待できなくなる。
HDDやSSDの高速化によって昔ほど遅くなくなっているから使うアプリに使用するメモリの分を空けておきたい人には便利かもしれない。
それはともかく個人で作るよりも、公式として配布用に作られているものはちゃんとそういうところが最適化されているのだ。
また、上に書いてある通り、いくつかの限られた選択肢から選ぶようになっており、大体の骨組みは決まっている。
ということは単純な自動スクリプトまかせなら、誰が作っても同じものができるわけで個人で作るメリットはない。
素人がイメージを自分で作るメリットはあまりないのではないだろうか？
何だったら、公式のPuppyを下地に必要なものをインストールし、いらないものをアンインストールし、日本語などの設定をしたものでSFSイメージを作るリマスタ機能もあるのだから、それを使えば良い。
比較的新しいマシン用のPuppyが出てくるまで待つしかないらしい。
Slackoとかならうまく動くのだろうか・・・。
LubuntuよりもPuppy Linuxの方が全体的に軽くて3D描画速度も良いので魅力的なのだが不安定では困る。
