「Linux」カテゴリーアーカイブ

H265 NVencが固まってきた

暫く試行錯誤してましたが、大体固まってきました。

目的は、録画したTSファイル、過去に録画して、あまあま(低圧縮H264)mp4を再エンコードして、容量を圧縮、保存すること。

本当なら、リサイズして1280か720位にしてビットレートを稼ぐのが良いのでしょうが、リサイズは嫌いなので、放送字のサイズを保ったままのエンコードを行います。

音声についても、基本は放送のママ。字幕なんかは切り捨ててますけど。

と言う条件でやっております。

読みにくいので、改行を挟みながらの記載にします。

/usr/local/bin/ffmpeg \
-hide_banner \
-ignore_unknown \
-dn \
-y \
-vsync 0 \
-hwaccel cuvid \
-analyzeduration 200M -probesize 200M \
-c:v h264_cuvid \
-deint adaptive -drop_second_field 1 \
-i input.mp4 \
-sn \
-c:v hevc_nvenc \
-vf hwdownload,format=nv12,yadif=0:-1:0,hwupload_cuda \
-preset slow \
-b_ref_mode 2 \
-rc vbr_hq \
-cq 30 -qmin 20 -qmax 40 -qcomp 0.6 \
-b:v 2M -maxrate 20M \
-rc-lookahead 50 \
-i_qfactor 0.75 -b_qfactor 1.1 -spatial_aq:v 1 -aq-strength 15 \
-c:a copy -fflags +discardcorrupt \
output(H265ReEncode).mp4

オプションの説明らしきモノ(誤解してる内容があると思うので、信用度は低いですよ)

  • -hide_banner:ffmpegを実行したときに出てくるVer情報とか、enableにしてるオプションの情報なんかを表示させない。
  • -ignore_unkown: 不明なストリームタイプを無視,
  • -dn: データを無効。
  • -y:出力ファイルが存在する場合、上書きする。
  • vsync 0: 映像の同期方法。 フレームをドロップ・コピーしてタイムスタンプをあわせることで映像を同期する。 (0,1,2を選べる。詳細はffmpeg Documentationを参照)
  • -hwaccel cuvid: HWエンコードでcuvidを明示.
  • -anaryzeburation 200M -probesize 200M
  • -c:v h264_cuvid(インプットファイルの前に書いてあるヤツ):入力ファイルをデコードするデコーダーを指定。
  • -deint adaptive -drop_second_field 1
  • -i input.mp4 :入力ファイル。
  • -sn:字幕出力しない。
  • -c:v hevc_nvenc:出力ファイルのエンコードをH265のNVEncで行うように、エンコーダーを指定。
  • -vf hwdownload,format=nv12,yadif=0:-1:0,hwupload_cuda:hwdownloadでハードウェアフレームをシステムメモリへダウンロードする。hwupload_cudaで システムメモリフレームをハードウェアサーフェスにアップロードする。 らしいが、詳しくは解らん。 format=nv12は色空間の指定。 yadif=0:-1:0は、インターレース解除で有名なヤツ。オプションは”一番メジャーなインターレース解除フィルタ yadif | ニコラボ”を参照して下さい。
  • -preset slow:11種類あるので、好きなのを選ぶ。詳細は”ffmpeg -h encoder=hevc_nvenc”を参照すればOK。
  • -b_ref_mode 2:Bフレーム対応のGPUだと有効にできます。(1660Superより上位のRTXシリーズだと対応してるっぽい。”ASCII.jp:GeForce RTX&新NVENC、OBSで高画質ゲーム配信できるって本当? (2/8)“を参照
  • -rc vbr_hq:プリセットのレートコントロールを上書きする。
  • -cq 30 -qmin 20 -qmax 40 -qcomp 0.6: 品質指定(0-51)、最低品質、最高品質を指定、 q値をどのくらい変動させてよいかの尺度らしい。
  • -b:v 2M -maxrate 20M:ビットレートを指定。0に設定するとcqに沿って行う(ビットレートは最大値までの間でcqを満たす値でエンコードされる)が、0以外の値を指定すると、こっちが優先で、cq値が合わなくなってくる。(主にビットレートが足りないときには指定したcq値よりも大きくなる。)
  • -rc-lookahead 50 :レート制御のために先読みするフレームの数。
  • -i_qfactor 0.75 -b_qfactor 1.1 -spatial_aq:v 1 -aq-strength 15
  • -c:a copy -fflags +discardcorrupt
  • output(H265ReEncode).mp4:出力ファイルの名前、適当にどうぞ。

自宅サーバーのエンコード現状

2月中旬から自宅サーバーをリニューアルし、(と言っても、眠ってた第2世代インテルcore-i5 2500なんだけれど)録画サーバーもEPGStationに変更し、いろいろと設定していました。

何をしていたかというと、録画した番組をH265で圧縮するのに、CPUが貧弱なので、グラフィックボードのGPUを使ってある程度の速度を確保しながらのエンコードをしようと挑戦してました。

んで、現在の結論としては、H264のエンコードを考えなければ、保存用には向かないけど、大分良い感じだね。

という、元も子も無い(h264よりも同ビットレートなら画質が良いという理由でh265を選択している)結論に落ち着きました。

ってか、H264でも十分保存できるなぁと思ってしまったのが、運の尽き。かもしれません。

とまぁ、そういうことで、EPGStationにはH265_nvencのエンコードを実装するのを諦め、ある程度貯まってきたら、パワーのある、メインPCでTMPEGEncを使って圧縮することにします。

自動で保存するほどの設定でH265圧縮するには、サーバーのCPUを良いのにするしか無いかな。

Ubuntu 18.04.4 LTS にTV録画環境をインスト その2

タイトル通りです。忘れても良いように、メモとして残すだけなので、正確じゃ無いと思いますが、気にしないように。ココの内容を再利用する方は自己責任でお願いします。私は責任取りませんので悪しからず。

以下のソースコード中に出てくる「&」が「&」に置き換わってしまっているので、コピペするときは十分注意すること。

viでの痴漢コマンドは、

%s/&/&/g

でよかったはず・・・たぶん。バックスラッシュ必要だったっけな・・・・(汗

続きを読む Ubuntu 18.04.4 LTS にTV録画環境をインスト その2

Ubuntu 18.04.4 LTS にTV録画環境をインスト その1

TV環境だけじゃ無くて、wordpressなんかも入れるので、以下にリストを書いておこう。

  • wordpress
  • tt-rss
  • pukiwiki
  • syncthing
  • mirakurun
  • EPGStation
  • ffmpeg EVENC可能Ver
  • fail2ban
  • plex

不精者なので、bashファイルとしてソースをのせていくが、信じないで下さい、致命的なエラーが含まれているかもしれません。私は責任とれませんので、信用しないように。

サーバー復活

あちこちにガタが来ているようです。諦めて、新しい筐体を準備しないといけないようですね。hddは定期的に交換してたんですが、マザーボードが疲れてきているようです。メモリもね。

ってことで、家中からかき集めてもう一台くみ上げて新しいサーバーにすることにします。

さて、何日かかるやら・・・・

温度の不思議

仕事中に簡易懸濁法について話をすることがあります。そのときに使用するお湯の作り方で、ポットのお湯(95度)と水道水(約18度)を等量混合で55度程度のお湯が出来ますよ。と説明するんですが、学生時代にやってた家庭教師の時の学生からの質問をいつも思い出します。

中学2年生「100度のお湯と氷を同量混ぜても50度にならないのはなぜ?」 -> 大凡10度の水になるはず。(氷の融解熱が大凡333J/gとすれば、前記の値くらいになるはず・・・)(1)

この質問は、理科の授業で反応熱を勉強し始めた頃に出て来てた気がします。たぶん・・・。んでもって、ちゃんと説明して理解してもらった後に、次の問題を出すとチンプンカンプンになってしまうという罠があります。皆さんご注意を・・・

「100度のお湯と0度の水を同量混ぜると50度になる?」 -> 50度の水(お湯)、ただし水とお湯以外に熱が逃げなかったとする。(2)
「質量100gの0度の水と-15度の氷を同重量混ぜたら何になる?」 -> 0度の氷水、ただし(以下略 (3)

 

 

つまり、氷と水の違いが液体、固体だけじゃなくて、エネルギーが違うんだぞってのを教える難しさがよくわかる内容なんですよ。うん。今だから、難しいのが解るw

 

続きを読む 温度の不思議

(更新)QNAPにOpenSSHを入れて接続

更に追記(2017/10/06):バージョン4.3.3で確認しましたが、デフォルトのSSHでユーザーを指定してのSSHログインが出来るようになっているようです。色々いじる必要も無く、「コントロールパネル」->「TELNET/SSH」->「SSH接続を許可する」にチェックを入れ、下にある「アクセス許可の設定」からユーザーをしてすることでSSHが有効になる。

 

(追加の追加情報 2015/10/29)Var4にアップデートしたら、ipkgが使えなくなっているので、この記事のように行っても無駄になりました。新しい方法はこちらの記事を参考に。といってもリンクを張ってるだけですが。

久しぶりにlinux系のお話。

 

前置き

相も変わらず、忘備録なので信じちゃだめですよ。私がうまく動いても他の人が動くという保証はないですからね!

というテンプレはさておき。何がしたいかというと。現在のデスクトップPCがUBUNTU15.04なので、QNAPの提供しているQSYNCというフォルダ同期ソフトが使えない。
クライアント(デスクトップ)PCがlinux系なので、rsyncをcronで動かせばいいだろう。という発想に落ち着いた。

さて、それでrsyncについて調べてみたら、どうやらSSH通信をしているらしい。

さて、それでQNAPについて調べてみたら、どうやらSSH通信がメンドクサイらしい。

 

ということで、まずはQNAPにSSH通信をできるようにしよう。という話。

んでもって、QNAP標準のSSHを使ってみたら、これはビックリ、admin(管理者)しかログインできない。とのこと。私の感覚だと、管理者以外でのSSHログインは認めるが、管理者NGってのが普通だと思ってたので、こりゃいかん。どうにかして、一般ユーザーのSSH通信を確保せねば。

という経緯がある。

ということで、QNAPにOpenSSHを入れて、一般ユーザでのSSH通信を行う。というのがこの忘備録の目的である。

続きを読む (更新)QNAPにOpenSSHを入れて接続

TmpegEnc,ffmpegどっちを使う?

ソースは30分アニメ(m2ts形式ファイル、CMカットなど編集してるので、実質24分前後)

現在の環境は第二世代Core i 5なので、エンコードにはちょっと時間がかかる。なので、できるだけきれいにそして短い時間で終わることが望ましい。相反する命題なんで、無理だとは解ってるけど!w

まぁ、x265にも興味があったので、実験がてら、タイトル通りのことをしてみました。

 

結果、90秒のサンプルを用意し(BS11放送うたわれるものOP使用)同じ設定でどちらがどのくらいの時間がかかるか。を見てみたところ、
ffmpegをpowershellで動かした時が、4分47秒。
TmpegEncが6分8秒

 

うん、こりゃ、ffmpegが早いな。90秒で2分の差、つまり24分だと32分の差となるわけだ。これが50本あるとしたら、1600分、つまり約26時間分時間がかかることになる。ちなみに、50本のエンコードはだいたい2日ちょっと。まぁ、これが、3日になろうがあまり影響はないんだけど、(エンコ専用マシンなので)消費電力考えると、結構悩ましい時間でもあるw

 

ちなみに、メインマシンの第6世代Core i 7で同じ実験をしたところ、ffmpegで2分26秒。TmpegEncで4分41秒。

やっぱりffmpegの方が早い。

 

ということで、x264のままであるならば、ffmpegのバッチエンコでしばらくは続けそうです。

 

x265が実用的な時間でエンコードできるようになったらまた考えるかも。

TmpegEncのH265オプション

TmpegEncの話がでましたので、ついでにH265のオプションも気になったので調べてみました。
調べてみた、というよりも、先人たちの記事を丸写しした、といったほうが正しい。

参考にしたのは「私的x265解説まとめ:Nothing Here – ブロマガ」。

表の左側はTmpegEncで出力したMP4ファイルをMediainfoで設定を引っ張ってきたもの。
右にその解説。ただ、この設定がTmpegEncのどの設定項目なのかはまだ確かめていない。

wpp WPP(Wavefront Parallel Processing)、波状並列処理。
ctu=32 HEVCは動画をCTU(Coding Tree Unit:四分木型符号化単位)という正方画素ブロック単位にわけ、さらにそれをCU(Coding Unit:符号化単位)単位に分割して様々な処理を行う。PU(Prediction Unit:予測単位)とTU(Transform Unit:変換単位)が扱う領域の平坦なところをまとめて処理すればその分圧縮できるので、これの最大値が大きいほどビットレート当りの画質を稼ぎやすい。逆に複雑な部分にはより細かなCUを割り当てる。減らしたぶんだけエンコードも早くなる.
tu-intra-depth=1 ブロック階層はCUの四分木分割の回数
tu-inter-depth=1 ブロック階層はCUの四分木分割の回数
me=1 動き予測アルゴリズム。4:Full Searchは3:Starに毛が生えた程度で時間に見合うだけの出力が得られないので1:Hexか2:Umhでいいと思う。 Umhで満足できない画質なら、他の設定が悪いかソースが悪いの2択なので無理に上げる要素ではない。
subme=1 サブピクセル動き予測。数値を上げた分だけ画質も上がるがかなりエンコ時間が増える。3が実用的な値だと思う。5以上は時間が有る時にしたほうが良い。
merange=44 動き検索範囲。再生時間にもよるが増やしたぶんだけ効果はある。けど4桁5桁に設定するとエンコードが終わらないので57~99の範囲で設定するのがいいと思う。最大値にするとエラー吐いて止る。
no-rect CUに分けて処理する際に予測ブロックを正方形以外の形や長方形などにも分解できるようにする。
no-amp rectがオフだとampはオンにしても働かない。
max-merge=2 動き保障予測の範囲を決める。隣接するブロックの動き情報が似ていればそれを流用し、その位置情報を代わりに送る事で1つに統合して符号量を減らす。HEVCの強力な機能の1つで、動きの激しい動画では特に有効的。常に5でいいと思う
temporal-mvp
early-skip 最大サイズのCUを分析して省けそうな計算を取り除く。出力にほぼ差は出ないがエンコードが早くなる・・・・・・らしい。
no-fast-cbf Disable Cbf fast mode
rdpenalty=0 penalty for 32×32 intra TU in non-I slices. 0:disabled 1:RD-penalty 2:maximum
Default: 0
no-tskip Disable intra transform skipping
tskip-fast 唯一のN×Nイントラ予測(4×4ブロック)のスキップ変換を評価するパラメータ(解読不能)。
no-strong-intra-smoothing Disable strong intra smoothing for 32×32 block
no-lossless ロスレスの名のとおり超低圧縮(元の半分ぐらいの容量)でエンコしてくれる。
no-cu-lossless
no-constrained-intra Disable constrained intra prediction (use only intra coded reference pixels)
fast-intra イントラ予測では隣接する上左ブロックからの補間で予測画像を作成し、その差分を符号化することで容量を削減する初期値では有効になっており合計で10モードチェックする。–no-fast-intraで無効にすると合計で33モードチェックする。オフにしても劇的な画質向上はないけれどもエンコ時間は微増加.
open-gop
interlace=0
keyint=300
min-keyint=1
scenecut=80
rc-lookahead=10 レート制御先行検査フレーム数。先読みするスライス型フレームの最大数を決める。上げた分だけ効果はあるが最小値はbframesまでで、最大値はkeyframeを超えると効果が減る。
bframes=1 最大Bフレーム連続数。値が少ないほどエンコが早くなる。当たり前だけどb-adaptの値で効率が変化する。
bframe-bias=0 Bフレーム挿入傾向。値を増やせばよりBフレームを使うようになる。
b-adapt=0 適応的Bフレーム挿入。
ref=6 L0の最大参照数を決める。最大16まで使えるけどx265の方式ではBフレームを使用すると7までで、b-pyramidをオンにすると6までしか使用できない。それ以上にするとprofile none 、level none扱いとなりエラー吐いて止るので実質6まで。どうしても7以上使いたい場合はallow-non-conformanceをオンにする事で使える。アニメ素材や定点録画なら6にして、それ以外なら3以下でいいと思う。
no-weightp 重み付き予測を有効にする。Pスライスは1枚の画像から復号されるスライス
no-weightb 重み付き予測を有効にする。Bスライスは複数の画像から復号されるスライス
aq-mode=0 適応的QP(AQ)。複雑な部分ではビットレートを増やし、平坦な部分では減らす。 0でオフ。 1でAQをオン。 2でauto-variance AQをオン。
aq-strength=0.00 AQ強度。0にするとAQオフ。実写やゲーム以外のソースでは上げる必要はないと思う。
cbqpoffs=0 Chroma Cb QP Offset
Default: 0
crqpoffs=0 Chroma Cr QP Offset
Default: 0
rd=2 RDO(Rate Distortion Optimization)、レート歪み最適化のレベルを決める。3から5のどれかでいいと思う。
psy-rd=0.30 画質の視覚的な調整をする。人の視覚的に細かいと感じる部分をぼかす事で画質を稼ぐ。使うなら初期値か上げても1.00未満。
psy-rdoq=0.00 psy-rdのぼかしを防ぐことができる機能。rdoq-levelが1か2で使える。(?)実写や細かい粒子が漂う動画なんかでは、この値を高くすることで元の画質を保持できる。psy-rdと共に動きの激しい部分で効果がある。
signhide hide sign bit of one coeff per TU (rdo)
lft Enable Loop Filter
Default: Enabled
no-sao 画素適応オフセット(Sample Adaptive Offset)。エッジ・オフセット処理とバンド・オフセット処理で構成される。デブロッキングフィルタがブロックの境界の歪みを減らしてくれるのに対し、SAOはブロック内部のリンギング歪み、グラデーションの縞々の劣化を減らしくれる。
no-sao-non-deblock
no-b-pyramid ピラミッド参照。再生規格の問題で、PC以外で利用予定がないならオンでいい。
no-cutree x264のmbtreeのような物。動きが少なく参照数も少ないところはビットレートを少なく割り当て、頻繁に参照される部分には多く割り当てる。激しく動く動画では効果がある。オフにするメリットはエンコ時間が減らせるぐらい。
rc=2
pass
bitrate=2816
qcomp=0.60 ビットレート変動量。高い値にしておけばcqp(固定量子化量)の品質が改善する。
qpmin=0
qpmax=51
qpstep=4 最大QP変動幅。知らぬ間にコマンドから消えた。
cplxblur=20.0
qblur=0.5
vbv-maxrate=50000
vbv-bufsize=50000
ipratio=0.71
pbratio=1.30