晴れのち曇り時々iPhone Android

Ubuntu14.04が不調に陥った為にこの際なので15.04にしようとインストールしたのですが
*依存系が壊れて、調べると、修復はかなり困難らしい（バックアップは大切だね）

システム

GA-Z87X-UD5H
BIOS 10c 06/12/2014


日本語入力の設定方法が変更された
日本語入力の初期設定が変更されたので、それを解決するのに時間が掛かりました。


細かな問題
なぜか頻繁にエラーが出る


最大の問題
ネットワークが寸断される

一定間隔というわけではないが、とにかく切断される、ひどい時はHPを検索するごとに切断される

再接続すると、IPv6が認識されなくなるので

仮の対策として　手動で　IPv4　と　IPv6　を手動で設定して切断される度に、再接続をする。

IPv6手動設定

接続の状態を確認して
IPv6が　2408:221:21c7:3400:c9bd:615:8c09:4d58/4　　 なら

IPv6アドレス 2408:221:21c7:3400:c9bd:615:8c09:4d58
プレフィックス：4

になるので、以下の様に記載する

例
IPv6アドレス：2408:221:21c7:3400:c9bd:615:8c09:4d58
プレフィックス：4
デフォルトゲートウェイ:fe90::313:e3ff:ef80:b563%10

こちらを参考にさせてもらいました　感謝！
ゆっくり備忘録

ドライバと型番をこのコマンドで調べる
$ dmesg | grep eth0
$ dmesg | grep eth1

調べた結果　NICが2つあり、それぞれ


Intelダウンロードセンター　

ドライバ
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.15-k

型番
Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

https://downloadcenter.intel.com/ja/download/24598/Network-Adapter-Driver-for-82575-6-82580-I350-and-I210-211-Based-Gigabit-Network-Connections-for-Linux-

最新ドライバ
igb-5.2.15.tar.gz



ドライバ
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k

型番
Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 04)

https://downloadcenter.intel.com/ja/download/15817/Network-Adapter-Driver-for-PCI-E-Gigabit-Network-Connections-under-Linux-

最新ドライバ
e1000e-3.2.4.2.tar.gz

e1000eのドライバが古いのでインストール

e1000e-3.2.4.2.tar.gzをtmpフォルダに解凍

以下へ移動
cd tmp/e1000e-3.2.4.2/src

インストール
$ maike install

ドライバの反映
$ modprobe e1000e

確認
$ modinfo e1000e

再起動

無事インストールは済みましたが、不定期に切断される現象は直りませんでした。

$ dmesg でログを出してみる

igb＝eth0
e1000e＝eth1

この二つが同時に落ちている


$ ip addr
IPアドレスがeth0/eth1に割り当たっているか調べる

$ cat /etc/resolv.conf.d/*
$ cat /etc/resolv.conf
でnameserverを調べる　結果　nameserver 127.0.1.1


NetworkManagerのログを見る
$ grep NetworkManager /var/log/*
$ grep nm /var/log/*

この二つのログからsleep状態にNICが落ちている模様

http://ubuntuforums.org/showthread.php?t=1690093
システムがアイドルになると有線NICが落ちるという人がいるけど，未解決

結果的にDNSが落ちてるんじゃないか？ということになり

迷宮入りｗ　私の環境には合わなかったのかなぁ

Ubuntu14.04に戻す事にするか・・

Ｗｉｎｅのインストール

以外に使えるWineをインストールします。　簡単なプログラムならWindowsの物が動かせます。

現在の最新版は1.7ので、それをインストール

$ sudo add-apt-repository ppa:ubuntu-wine/ppa
$ sudo apt-get update
$ sudo apt-get install wine1.7 winetricks

インストールしたら

コンピューターとオンラインリソースを選択から　「Wineの設定を起動」

自動的に色々なインストールが始まります。

終われば終了です。

デフォルトでは　Windowsのバージョンが　WinXPになっているので適切に変えましょう

プログラムは自動でインストールされるのもありますが、そうでないのもあります。

自動でインストールされない場合

.wine/drive_c/Program File
.wine/drive_c/Program FIle(x68)

のいずれかの中にフォルダを作って保存します。

ショートカットのコマンド
ショートカットのアイコンはなんとかしてください・・・

ショートカットを何とかしました　作り方はこちら

アイコンをなんとかしたら、　基本　タブ　の「コマンド」に　以下を書きます

env WINEPREFIX="/home/ユーザーネーム/wine" wine "/home/ユーザーネーム/.wine/dosdevices/c:/Program Files (x86)/Hoge/hoge.exe"

解説　Wineを経由して実行する

簡単な説明ですが、こんな感じです

最新版のMakeMKVをインストールするコマンド

$ sudo add-apt-repository ppa:ubuntu-ebower/ebower
$ sudo apt-get update
$ sudo apt-get install makemkv-install
$ makemkv-install latest


おまけ

アイコンの絵柄が表示されなかったので、それをするようにしてみた


$ sudo gedit /usr/share/applications/makemkv.desktop

/usr/share/icons/hicolor/64x64/apps/makemkv.png (アイコンの絵柄の場所）

以下の様に書き換えて保存、再起動すると、アイコンの絵柄が出ます。

[Desktop Entry]
Version=1.0
Name=MakeMKV
Comment=DVD and Blu-ray to MKV converter and network streamer
Exec=makemkv
Icon=/usr/share/icons/hicolor/64x64/apps/makemkv.png
Terminal=false
Type=Application
Categories=AudioVideo;Qt;

出来上がったファイルはHandBrake等でエンコードすれば、モバイルデバイスでも視聴出来るようになります

AviUtlを現状で画期的に速くする方法を考えてみた

エンコード状態を（画質等を保ったまま）維持したまま画期的に速くする方法は残念ながら無かった訳ですが
（設定を弄る事により、少々早くはなりますが）

私がたどり着いたのは、「AviUtlをSSDに入れること」です

ざっくりとしていますが、効果はあったと思います

AviUtlに関係する物を全てSSDにコピーしてしまうと、ちまちま設定するよりずっと速くなります

例

使用環境
Intel(R)Core(TM)i7-4770k CPU（コア数４　スレッド数８）
実装メモリ32ＧＢ
Windows7 64Bit 　　500GB相当のSSDにインストール

以下追試の結果ですが

SSDにAviUtlとソースを置いた場合（約24分の24フレームの動画）
総エンコード時間　0時間１８分0.5秒

SSDにソースを置いてＨＤＤにAviUtlを置いた場合（約24分の24フレームの動画）
総エンコード時間　0時間２５分６.２秒

ちなみに、SSDにAviUtlを置いてソースをHDDに置いた場合の結果は残っていませんが
記憶ではSSDにAviUtlとソースを置いた場合と、あまり変わりませんでした。（約24分の24フレームの動画）


実行するソースやプラグインにもよりますが、実時間に近づきました

OS起動にSSDを使っている人はためしてみると良いかも？

実はなぜSSDに入れるとエンコードが速くなるのか？真相は不明のままです


AviUtl程の小さなアプリなら、メモリに展開されて実行されている　というのが普通なので、
SSDに入れたからといって、理屈では速度自体は変わらないはずなのですが、今回のテストでは
確実に向上しています。

AviUtlはエンコードする時に何かを大量に書き出して、それの読み込みを行っているのでしょうか？
それなら話は変わってきますが、・・・作者さん・・どうなんでしょうね？

AviUtlのCPU使用率を観察してみた　はこちら

AviUtl、CPU使用率との兼ね合いを見て、速くなる設定を探してみた。その１　はこちら

RunAsDate for Windows　　時間を止めるプログラム




プログラムの時間を止めるプログラムです。
基本は英語ですが他言語パッケージは下のほうにあります。

利用例

期限付きのプログラムの時間を止めます

利用したいプログラムのフルパスを参照から選択します

即時モード、プログラムの起動時に日付情報を変更する　にチェック

ショートカットの作成を押すと、RunAsDate経由でのプログラム起動用ショートカットをディスクトップに作成します

各種設定が終わったら、閉じるをクリックします

RunAsDate　　

nirsoft

　

Ubuntu14.04 に　handbrake　をインストール

Installing handbrake in Ubuntu 14.04

ファイル置き場
https://launchpad.net/~stebbins/+archive/ubuntu/handbrake-releases/+packages

handbrake-cli_0.10.2ppa1~trusty1_amd64.deb

handbrake-gtk_0.10.2ppa1~trusty1_amd64.deb

上記２つのファイルをUbuntuソフトウェアセンターからインストールする


依存関係が不足していると表示される　handbrake〜.deb　はUbuntuOSの別のバージョン系用の模様です。

Windows for VLC to BD

2020/06/15日現在ではVLC3.0で動く事を確認しました。

https://www.videolan.org/news.html#news-2018-02-09VLC3.0

http://vlc-bluray.whoknowsmy.name/
libaacs.dll for 32Bitを以下のフォルダにコピー

ProgramFile(x86)\VideoLAN\VLC\

libaacs.dll for 64Bitを以下のフォルダにコピー

ProgramFile\VideoLAN\VLC\

KEYDB.cfgを以下のフォルダにコピー

C:\ProgramData\aacs\


Windows for VLC to BD その２

BDのISOを作ってみた

K3B　2.0.2

BDをドライブに挿入　

K3Bを起動、「ドライブ/ディレクトリ」を選択してBDのイメージを制作する

「ディスクのコピー」を選択して、イメージ名を決める、オプションで、「イメージ削除」のチェックを外す

開始をクリックして、イメージを作成する

指定した「ドライブ/デレクトリ」に　BDのイメージが出来上がる。

BDのイメージをマウント

再生可能なプレイヤーにて本編が再生されることを確認しました。


Memo

オプションで、「イメージ削除」のチェックを外すと、作成されたイメージは消えません。


続きを読む...

AviUtl のエンコを出来るだけ速くしてみる　その２

その１はこちらの記事

速くしてみる　で疑問に思ったことを幾つか・・

出来るだけ速くしてみるというのは非常に魅力的な言葉ですが、この速くしてみる
人によって違うのではないか？（エンコード対象の動画によって違うのではないか）
ということです。

速くしたいのなら、出来るだけプラグインを使わない　これに行き着くからだと思います。

つまり、昨今のデジタル動画（ＴＳ）ファイルを使用してのエンコードなら、ノイズ除去やシャープ等のフィルタはほぼ必要ないと思います。実際にエンコードしてみましたが、大きな違いは見られませんでした。
（たまたま、使用した動画の性質上、違わなかっただけかもしれませんが）

要は、エンコードしたい動画用のフィルタが登録されたプロファイルを作り、必要ない物と、必要ある物を分けてエンコードすれば、結果的に時間は縮まる筈です。（わりと当たり前の結論ですが）


再放送で、フィルタが必要なら、それ用のフィルタ登録をしたプロファイルを作り、そこでエンコードします。

また、昨今のＨＤ向け動画ならほぼフィルタ無しの状態でエンコードしても多分大丈夫なはずです。
不安であれば、不安な部分を切り出して、フィルタあり、なしで試しエンコードして、どちらが良いか確認したほうが良いと思います。

そして、フィルタが必要だと感じたらなるべくマルチスレッドに対応したフィルタを使ったほうが速い筈です。



そして、私の最速は２４分の動画で１７分でエンコード　という「自己最速」が出ました
（「自己最速」これ大事ですｗ　もっと速い人もいるでしょうから）
　
使用環境
Intel(R)Core(TM)i7-4770k CPU（コア数４　スレッド数８）
実装メモリ32ＧＢ
Windows7 64Bit 　　500GB相当のSSDにインストールしています。

ＯＳはSSDにインストールしています。実はこの１７分、思いつきで、出しちゃいました・・
SSDにAviUtlも入れてみたらどうだろう・・

つまり、ＯＳの入っているSSDにAviUtlを入れて実行したわけです。
タスクマネージャーを見てると、AviUtlって以外にCPU使ってるんです。
なので、せっかく動いてるなら、速いSSD上で動かしてみたら良いのでは？

実際、プラグイン達はAviUtl上で動いています、HDDというボトルネックから開放してあげれば結果、速く動いてくれるという訳です。

ノイズリダクションや、シャープ系のフィルタ等のフィルターをチェックしたまま、丸ごとSSDにコピーして
適当な動画をエンコードした結果、今まで35分ぐらいのエンコード時間が20分程度までに圧縮

ソースは最近製作されたＨＤのＴＳファイル　ＣＭカットして大体24分ぐらいの長さの物です。

そして、比較の為にと、シャープ系、ノイズリダクション系のフィルタを外してエンコードした時、17分
という時間になりました。
（エンコード時間はソースによって変わります）

エンコード後の２つの動画を再生してみると、特別差異は感じられませんでした。

もちろんフィルタを掛けたのだから、こっちのほうがより綺麗であろう！　という　プラシーボ効果的な物は
ありましたが、その程度です。

もちろん、ちゃんとノイズリダクション系のフィルタを掛ける必要のある動画もあります。

適材適所　これ大事かなぁ




上記とＴＳソースが違いますが、こんな結果も出ました。

SSDにAviUtlとソースを置いた場合
総エンコード時間　0時間１８分0.5秒

SSDにソースを置いてＨＤＤにAviUtlを置いた場合
総エンコード時間　0時間２５分６.２秒

また何かあったら続編があるかも？


AviUtlを現状で画期的に速くする方法を考えてみた　はこちら

「透過性ロゴ(改)」CMカット＆ロゴ除去　プラグイン　for AviUtlを使って出来るだけミス無く且つ、素早くＣＭカットが出来るのか、挑戦してみた　の続編　「本編の最後を素早く見つける方法を考えてみた」

前回の記事　その２も合わせてお読みください

挑戦記録、多分その２

本編の最後を見つける方法を考えてみた。

まず、簡単に見つかるだろうエンディング、ここまでシークする。その後、「次検索」を何回かクリックし、エンディングの最後を見つけたら、AviUtlで「カット初め」を付ける。

その部分から、「次検索」を何回かクリックして、次回予告の始まりを見つけ、ＥＤの終わりから次回予告の最初までを、「手動でカット」

次回予告を再生して、提供の手前でカット初めを付け、エンディングカードの手前でカット終わりを付けて、その間を手動でカット

上記の場合　「次検索」で、次回予告を少し行き過ぎる場合があるのでコマ送り等で戻してください

これが、現在試している本編最後の見つけ方です。
（これが”今現在”最良とは思いますが、思いついたらまた書きます）


ＣＭ変則番組偏　その１

本編始まり部〜本編終わりまでが確保したら、「処理対象」を「指定Frameの前後のみ」に変更して、「Freme数・位置」をクリックして値を自動検出登録

ボックスの中の「先頭Frame」をクリックした後、「自動検出」を押してＣＭ候補を探す。

ここまでは、前回の「挑戦記録　多分その１」で書きました。

今回のその続きは、変則的な番組偏を考えて見ます。

通常の番組は

ＣＭ　オープニング　提供　ＣＭ　Ａ本編　ＣＭ　Ｂ本編　エンディング　ＣＭ　予告　提供　エンドカード

の順番だと思いますが、変則的な番組も混在します。


それらしい物を下記に記します（全ての組み合わせではありません）

例１（ＯＰとＡパートの間にＣＭが無く、ロゴ入りの提供がある）

ＣＭ　オープニング　提供　Ａ本編　ＣＭ　Ｂ本編　エンディング　ＣＭ　予告　提供　エンドカード

例２（ＯＰとＡパートの間に提供が無い）

ＣＭ　オープニング　Ａ本編　ＣＭ　Ｂ本編　エンディング　ＣＭ　予告　提供　エンドカード

例３（ＯＰとＡパートの間に提供が無い場合で、且つ予告が無い）

ＣＭ　オープニング　Ａ本編　ＣＭ　Ｂ本編　エンディング　ＣＭ　提供　エンドカード

例４（ＯＰとＡパートの間に提供が無い場合で、且つ予告が無く、エンドカードも無い）

ＣＭ　オープニング　Ａ本編　ＣＭ　Ｂ本編　エンディング　ＣＭ　提供

例５（ＯＰとＡパートの間に提供が無い場合で、且つＣパートがあり、予告とエンドカードの間にCMが入る）

ＣＭ　オープニング　Ａ本編　ＣＭ　Ｂ本編　ＣＭ　Ｃ本編　エンディング　予告　CM　提供　エンドカード

例６（ＢパートとＥＤの間にＣＭがあり、EDと予告の間にCMがある）

ＣＭ　オープニング　提供　ＣＭ　Ａ本編　ＣＭ　Ｂ本編　ＣＭ　エンディング　CM　予告　提供　エンドカード

例７（提供がおわった直後に次回予告が入る）

ＣＭ　オープニング　提供　ＣＭ　Ａ本編　ＣＭ　Ｂ本編　エンディング　ＣＭ　提供　予告

大体上記のような構造の番組が混在する事がよくありますので注意して観察すると良いかもしれません
（各番組タイトル毎にこの構成は変わってきますが、同一タイトルでの構成の変化は現在確認されていません（例外としてCパートが存在する場合はA-B-Cの構成がA-Bに変化する事があるのでそこは注意してください、大変稀な事ですが）、したがって、この番組はこういう構成である、などを覚えてしまえば、初回は大変かもしれませんが、次回からCM探しは楽になるはずです）


通常の番組と表記している様な構成の場合、CM_ON候補を提供の終わりに自動マークします。
この場合その位置から、−１０秒戻れば、たいていの場合数コマ戻るだけで、OP最後にたどり着きますので、提供を削除する場合、そこで、手動マークします。次のCM_OFFでA本編最初にマークされているはずなので、コマ送りで戻って、本当にA本編最初か確認してから、その間を削除すると良いでしょう。


さて、例１のような構成で　ＯＰとＡパートの間にＣＭが無く、ロゴ入りの提供がある場合。
ロゴ検知は次回ＣＭ候補をいきなりＡ本編の終わりで自動マークします。
このような場合で、提供をカットしたい場合。自分でシークして、提供を探して手動でカットします。少し面倒ですが現時点では仕方ないでしょう。


例２　から　例６のような変則番組の場合でも試した限り大体の位置ではありますが、ＣＭ候補を見つけてくれます。

例７は昨今少ないですが、稀にあります。この場合提供の次、エンドカードを見つける様に少し再生すれば予告であることに気が付きます・・・気が付いてくださいｗ


エンドカードはたいていの場合、提供のすぐ後ろにありますので自力で探してください。（ロゴが出ているものは検索されるが、ロゴの無いものもあるため、これは不確定です）