IT - Yano's digital garage

昨日の対処でFFmpegによるmp4エンコードも復活したのだが、今度はまた先々週できるようになったMediaTombのDLNAトランスコードがまた失敗する状態になってしまった。

昨日のmp4エンコード対処を参考にFFmpegのオプション指定を弄りつつ見直してみたものの、どうやらOPT_SEEKPOS="${3:+-ss $3}“があるとうまくいかないようだ。試しにOPT_SEEKPOS="-ss 120"とかするとちゃんと120秒飛ばしたところから再生が始まったように見えるので、MediaTombがパラメータを正しく渡せていないように思われるが、今回MediaTomb自体には手を加えていないので、何が良くないのか想像がつかない。

手元にあるMediaTombのソースツリーもバリエーションがいくつかできてしまって紛らわしいので、もう一度svnから最新版を取得しなおしてfix_libav_0.7_support.patch、libavformat_0.11_support.patch、mediatomb-seek.patchの３パッチを適用する事で、先々週と同等のソースツリーが再構築できた。

yano@GT110b:~/software/MediaTomb$ wget "https://launchpadlibrarian.net/71935204/fix_libav_0.7_support.patch"
yano@GT110b:~/software/MediaTomb$ wget "http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20120618/f6d39a21/attachment.patch" -O libavformat_0.11_support.patch
yano@GT110b:~/software/MediaTomb$ wget "http://sourceforge.net/tracker/download.php?group_id=129766&atid=715782&file_id=372446&aid=2995015" -O mediatomb-seek.patch
yano@GT110b:~/software/MediaTomb$ svn co https://svn.mediatomb.cc/svnroot/mediatomb/trunk/mediatomb mediatomb-newsrc
A    mediatomb-newsrc/README.UTF_8
A    mediatomb-newsrc/devconf
A    mediatomb-newsrc/AUTHORS
A    mediatomb-newsrc/webnew
～～～～～～～～～～～～～～～～～～～～～～～～～～
A    mediatomb-newsrc/web/js/items.js
 U   mediatomb-newsrc
リビジョン 2104 をチェックアウトしました。
yano@GT110b:~/software/MediaTomb$ mv mediatomb-newsrc mediatomb-r2104
yano@GT110b:~/software/MediaTomb$ cd mediatomb-r2104/
yano@GT110b:~/software/MediaTomb/mediatomb-r2104$ patch -p 0 < ../mediatomb-seek.patch
yano@GT110b:~/software/MediaTomb/mediatomb-r2104$ patch -p 1 < ../fix_libav_0.7_support.patch
yano@GT110b:~/software/MediaTomb/mediatomb-r2104$ patch -p 1 < ../libavformat_0.11_support.patch
yano@GT110b:~/software/MediaTomb/mediatomb-r2104$ autoreconf -i
yano@GT110b:~/software/MediaTomb/mediatomb-r2104$ ./configure && make
yano@GT110b:~/software/MediaTomb/mediatomb-r2104$ sudo make install

実際の/usr/local/bin/mediatomb-ffmpeg-video.shに関しては以下の通り。前回aspect_ratioを指定する事でREGZAの選択画面において映像がプレビュー出力されるようにできたものの、元ソースのアスペクト比(4:3か16:9)に合わせた表示ができない軽微な問題があったのだが、今回Wikipediaのエントリを参考にaspect_ratioに変えてtargetをNTSC-SVCDに設定する事で期待通りのアスペクト比で出力されるようになった。

昨日、libavformatの例外障害対処で復旧したMediaTomb。

流れでffmpegを1.1.2 “Fire Flower"にアップデートしたのに伴い、今度はmp4エンコードがコケるようになったので、その対処。

/usr/local/share/ffmpeg/libx264-hq.ffpresetと~/bin/ts2mp4_1280x720.shオプション類を見直して、以下のように改修する事でこちらも無事復旧。

**yano@GT110b:~$** cat `/usr/local/share/ffmpeg/libx264-hq.ffpreset`
vcodec=libx264
vprofile=baseline
maxrate=10000000
bufsize=10000000
level=41
crf=25
coder=1
flags=+loop
cmp=chroma
partitions=+parti8x8+parti4x4+partp8x8+partb8x8
me_method=umh
subq=7
me_range=16
g=250
keyint_min=25
sc_threshold=40
i_qfactor=0.71
b_strategy=1
qmin=10
rc_eq='blurCplx^(1-qComp)'
bf=16
bidir_refine=1
refs=6
**yano@GT110b:~$** diff -b libx264-hq-20121014.ffpreset `/usr/local/share/ffmpeg/libx264-hq.ffpreset`
5c5
< cmp=+chroma
---
> cmp=chroma
**yano@GT110b:~$**

**yano@GT110b:~$** cat `~/bin/ts2mp4_1280x720.sh`
#!/bin/bash
CPU_CORES=$(/usr/bin/getconf _NPROCESSORS_ONLN)
PREFIX=/usr/local;
FFMPEG=${PREFIX}/bin/ffmpeg;
OUTDIR=/mnt/newpool/Videos;
LOGDIR=${OUTDIR}/.logs
FORMAT="mp4"
# OPT_SWSFLAGS="-sws_flags mmx2";
OPT_THREADS="-threads ${CPU_CORES}";
OPT_PROCESSER="${OPT_SWSFLAGS} ${OPT_THREADS}";
X264_PRESET=${PREFIX}/share/ffmpeg/libx264-hq.ffpreset
OPT_VCODEC="-vcodec libx264 -fpre ${X264_PRESET}";
OPT_VCODEC="${OPT_VCODEC} -bufsize 10000000 -level 41 -crf 25";
OPT_FILTER="-filter:v yadif"
# OPT_VRATE="-b:a 2M -bt 2M"
OPT_VRATE="-re -b:v 5M -maxrate 10M"
OPT_VSIZE="-aspect 16:9 -s hd720"
OPT_VCODEC="${OPT_VCODEC} -r 30000/1001 ${OPT_FILTER} ${OPT_VRATE} ${OPT_VSIZE} -vsync 1"
OPT_ACODEC="-acodec libfaac -ac 2 -ar 48000 -ab 128k"
OPT_MAP="-map 0:0 -map 0:1";
INFILE=$1;
FNAME=`basename "${INFILE}" .ts`;
OUTFILE=${OUTDIR}/${FNAME}.${FORMAT};
LOGFILE=${LOGDIR}/${FNAME}.log
FFMPEG_CMDLINE="-y -i ${INFILE} ${OPT_PROCESSER} ${OPT_VCODEC} ${OPT_ACODEC} ${OPT_MAP} -f ${FORMAT} ${OUTFILE}"
if [ ! -s ${OUTFILE} ]; then
        echo "${INFILE} -> ${OUTFILE}"
        date > "${LOGFILE}"
        (time ${FFMPEG} ${FFMPEG_CMDLINE}) 2>&1 | tee -a "${LOGFILE}"
        date >> "${LOGFILE}"
fi
touch --refer=${INFILE}  ${OUTFILE}
# ls -la ${INFLIE} ${OUTFILE}*
**yano@GT110b:~$**

参照

FFmpeg http://www.ffmpeg.org/

先々週、ゴールに達したMediaTomb。

昨夜、久々に動画ファイルを追加登録していったらWebコンソールが反応しなくなってしまった。

yano@GT110b:~$ sudo service mediatomb restart

と再起動しても変化なし。/var/log/mediatomb.logを確認したところ設定ファイルのチェックはパスしているようなので、データベースが壊れたのかも？と思いデータベースを初期化して再起動。

yano@GT110b:~$ mysql -u root -p < ~/mysql_script/mediatomb_reset.sql
yano@GT110b:~$ mysql -u root -p mediatomb < ~/mysql_script/mediatomb_setup.sql
yano@GT110b:~$ sudo service mediatomb restart

とやって一件落着。

かと思いきや、動画ファイルを登録してたらまたWebコンソールが反応しなくなってしまった。

yano@GT110b:~$ sudo service mediatomb restart

と再起動してもやはり変化なし。

/var/log/messagesを見たところ

yano@GT110b:~$ fgrep -i mediatomb /var/log/messages
Feb 20 00:56:15 gt110b kernel: [335366.128708] mediatomb[1672]: segfault at 7fb774032738 ip 00007faf8e87d9de sp 00007faf82749e60 error 4 in libavformat.so.52.31.0[7faf8e82c000+9e000]
Feb 20 01:42:55 gt110b kernel: [338165.254856] mediatomb[24251]: segfault at 801dae6d8 ip 00007fa79a0819de sp 00007fa78ecd78d0 error 4 in libavformat.so.52.31.0[7fa79a030000+9e000]
Feb 20 01:43:53 gt110b kernel: [338223.575835] mediatomb[24285]: segfault at 800bdea68 ip 00007f632ef049de sp 00007f631f7fc8d0 error 4 in libavformat.so.52.31.0[7f632eeb3000+9e000]
Feb 20 01:44:30 gt110b kernel: [338260.963663] mediatomb[24374]: segfault at 7f8b7806be38 ip 00007f838a6199de sp 00007f837f26f8d0 error 4 in libavformat.so.52.31.0[7f838a5c8000+9e000]
Feb 20 07:24:13 gt110b kernel: [	173.934537] mediatomb[1679]: segfault at 7f37e4070d58 ip 00007f2ff53129de sp 00007f2fe91de8d0 error 4 in libavformat.so.52.31.0[7f2ff52c1000+9e000]
Feb 20 08:49:43 gt110b kernel: [ 5286.936510] mediatomb[2547]: segfault at 7f85ac005ef8 ip 00007f7dbc9dd9de sp 00007f7dabffdc20 error 4 in libavformat.so.52.31.0[7f7dbc98c000+9e000]

という事から、libavformatがsegfaultで落ちているのがわかった。

今日は地動説を唱えた事で有名なコペルニクスの生誕540周年との事。

紀元前300年代のアリストテレス以来、1800年以上も信じられてきた天動説が翻ってからまだ500年ほどしか経っていないとはね。

まだまだ宇宙の事がわかってないのも無理ないわけだ。

Google Doodlesをみて選挙をあしらったロゴがある事に気付いたのだが、昨年12月16日には衆議院議員総選挙をあしらった日本版のJapan Elections 2012もあったらしい。

参照

Wikipedia http://ja.wikipedia.org/wiki/

MdN Design Interactive http://www.mdn.co.jp/di/

今日のGoogleロゴ
今日のGoogleロゴはGoogle生誕14周年 2012年9月27日
今日のGoogleロゴは大みそか 2012年12月31日
今日のGoogleロゴは2013年お正月 2013年1月1日
今日のGoogleロゴは七草がゆ 2013年1月7日
今日のGoogleホリデーロゴはフランク・ザンボニー生誕112周年 2013年2月14日
今日のGoogleロゴはジョージ・フェリス生誕154周年とバレンタインデー 2013年2月14日
今日のGoogleロゴは小惑星2012 DA14観測史上最接近 2013年2月15日
今日のGoogleロゴはニコラウス・コペルニクス生誕540周年 2013年2月19日

Google Doodles http://www.google.com/doodles/

Japan Elections 2012 2012年12月16日

最新のMacBook AirにrEFItを入れ、CentOS 6.3とWindowsのトリプルブートにするお仕事。

rEFItをインストールし、diskutilでパーティションをシュリンクするところまでは簡単に終わったのだが、CentsOS 6.3を入れようとしたところ早々にフリーズしてしまって何もできない有様。

Ubuntu 10.10のテキストモードでもトライしてみたところ速攻でKernel Panicを起していたので諦めかけたのだが、最新のUbuntu 12.10 (Quantal Quetzal)を眺めたところ、ubuntu-12.10-desktop-amd64+mac.isoというのを発見。

Ubuntu 12.04.2 LTS (Precise Pangolin)には無い

This image is adjusted to work properly on Mac systems.

という記載もあるので、最後の望みを託してトライしたところうまく行きました。

grubからMac OSを起動する事もできるようだが、Macのシステムアップデートで上がらなくなると厄介なので、取り敢えずrEFItを使う事に。

参照

rEFIt http://refit.sourceforge.net/

Ubuntu http://www.ubuntu.com/

最近Tsubameのハードディスクに遅くなってきた感が炸裂。

よくよく考えると2011年10月当時は主力機の環境を残したままH67M-ITX環境を構築する必要があり、取り敢えず浮いていたWD15EARSにインストールして、安定稼働を確認したところで手持ちで最新＆最速な7200rpmのHDS721010CLA332に載せ替えようと目論んでいたような気がするのだが、すっかり忘れていたよ。

WD15EARSに世代交代しても相変わらず**「低速病」**の噂は完全には消えていないのも気になるので、遅ればせながらHDS721010CLA332への差し替えを実施する事に。

現状、AMD FX-6300＋ASRock 990FX Extreme4の構成でWindows 8 Pro 発売記念優待パッケージ版をインストールしていたので、まずはライセンス関係がややこしそうなWindows 8環境を予備のCaviar SE16 WD5000AAKSに移行する事に。

取り急ぎライセンス認証を活かしたままHDDを乗り換えるには標準の「システムイメージのバックアップ／復元」が一番早くて確実と思ったのだが、HDDの容量が1TBから500GBにダウンするためにちょっと厄介。データ量的には100GBも使っていないので基本的にはパーティションをシュリンクしたあとで「システムイメージのバックアップ／復元」を行うだけで問題無いはずなのだが、バックアップはできたものの「システム修復ディスク」から起動していざ復元という段になると復元エラー。

手を変え品を変え何度トライしても埒があかなかったのでひとまず断念し、ライセンス認証を電話でやり直す覚悟でWD5000AAKSにクリーンインストール。最初は「以前のバージョンの Windows がインストールされていなかった」という事でプロダクトキー自体が無効になっていたのだが、その状態でもう一度同じインストーラを起動し、HDDを再フォーマットしてクリーンインストールやり直す事でライセンス認証をあっさりパス。

終わってみれば**「ライセンスキーを復活させる手続き」**も不要で単純に「オンラインでライセンス認証をやり直す事ができた」ので、急がばまわれ、案ずるよりなんとやら、という事ですかね。

TsubameのWindows 7もパーティションを縮小してから標準の「システムイメージのバックアップ／復元」で大丈夫と思ったのだが、「Windows 7 システム修復ディスク」から起動した時にそもそもUSB外付けドライブのバックアップイメージが見つけられない。Windows 7より新しいASRock H67M-ITXのインテル H67 ExpressやUSBコントローラに対応していないのかと思ったが、USB3.0/eSATA/USB2.0/ネットワークなど可能な限りのデバイスとドライバにトライしても状況が微妙に変わるだけでバックアップイメージの認識ができず断念。

最終的にPartition Wizardの「Bootable CD」でWD15EARSからHDS721010CLA332に2区画(システムで予約済み,Windows 7)のパーティションをコピーし、「Windows 7 システム修復ディスク」で「スタートアップ修復」を実施してHDDの乗り換え完了。

結局、この週末は合計10時間以上を浪費した事に。orz

参照

＠IT http://www.atmarkit.co.jp/

Windows 7のバックアップ機能 2010年12月22日
Windows 7のシステム復元機能 2011年1月20日
Windows 7のシステム修復ディスクを作成する 2012年4月6日
Windows 8レボリューション：第8回　Windows 8によるPCの「リフレッシュ」と「リセット」 2012年11月15日

Microsoft Windows ヘルプ http://windows.microsoft.com/ja-JP/windows/support

GIGAZINE http://gigazine.net/

パーティションのリサイズ・作成・コピー・変換・完全消去などが簡単にできるフリーソフト「Partition Wizard Home Edition」 2009年8月15日

窓の杜 http://www.forest.impress.co.jp/

初期不良で交換となったGIGABYTE GA-B75M-D3H。

Socket 1155環境としてはPCIスロット2本構成なMicroATXマザーもなかなか希少な存在になってきたので、保険としてIntel DB75ENを追加調達しとく事に。

同じくTSUKUMOネットショップで7,970円也。

検品構成で動作確認は無事完了したが、いろいろ謎めいた挙動も多かったIntel DG45IDと同じくFOXCONNのOEMで液コン満載なので、新生GT110bとしてまずは「GIGABYTE Ultra Durable 4 Classic」に「オール日本製固体コンデンサ」で耐久性を謳うGA-B75M-D3Hで行く事にして、Intel DB75ENはPentium G620と共に予備機材として棚上げ。

それにしてもPS/2はおろか、パラレルプリンタのようなレガシーポートを持っていたとは驚いたね。2008年調達のDG45IDがレガシーフリーを謳っていたのとは対照的だ。

参照

インテル https://www.intel.co.jp/

Intel® Desktop Board DB75EN

価格.com https://kakaku.com/

インテル DB75EN 価格比較

TSUKUMO https://shop.tsukumo.co.jp/

Intel DB75EN

Intel https://ark.intel.com/

Wikipedia https://ja.wikipedia.org/wiki/

Xeon E3-1230V2に喚装し、DLNAサーバとしても完成の域に達したGT110b。

GIGABYTE GA-B75M-D3H [Rev.1.1] — GIGABYTE GA-B75M-D3H

さすがに8スレッドでエンコードさせるとCPU温度が90℃以上になるのが気になってきたので、CPUクーラーでも交換しようかと筐体を開けてスペースを測っていたところ、うっかりスケールをマザーボードECS H67H2-M2に接触させてしまい、GT110bが起動不可の状態に。GT110bでは昨年10月のBIOSアップデート失敗に続いて、4ヶ月も経たないうちにまた大失敗を繰り返すとは、我ながら迂闊っぷりにも程がある。

ECS H67H2-M2も苦労してBIOSアップデートしたのになぁ…、などと落ち込んでいる暇も無いので、取り敢えずまたIntel DG45ID＋Pentium Dual-Core E6500を移設して、PT2を1枚刺しで暫定復活。という騒ぎがあったのが実は6日(水)の夜。

パーツ相場も日々値上がり進行中のご時世なので、早々に代替のSocket 1155マザーを探したところ、メモリ4枚、PCIスロット2本構成のGIGABYTE GA-B75M-D3Hが5,502円と手頃だったので、7日(木)にTSUKUMOネットショップへ発注。

9日(土)には届いたのだが検品構成でBIOS画面すら起動しない困難な状態に直面した。GPU内蔵のPentium G620にしてもダメ。そもそもショートだとCPUやメモリ、ビデオカードはおろか電源ユニットすら故障の可能性があるので、改めて動作している機材にGT110bのパーツを一つ一つ組み込んで地道に確認したところ、結局マザーボード以外は問題無い事がわかりひと安心。

10日(日)の未明にTSUKUMOのWebサポートの問合せフォームに連絡しておいたところ、夜にはメールで応答があり**「CPUソケットの不良(ピンの曲り、グリスの付着)が無い事を確認して下さい」**という事だった。11日(月)午後に確認したところ問題無さそうに見えたので念の為にデジカメで撮影した写真を送ったところ、夕方には初期不良の認定及び交換手配が決定。しかも送料無料の引取交換という良心的な対応で翌12日(火)に早速代替品を発送してくれた。

本日14日(木)に恙なく交換を終え、検品構成での動作確認からGT110bの喚装まで完了して一件落着。もちろん、実際に店舗を構えているという事情もあっての事とは思うが、3連休の週末にも関わらず迅速な反応で顧客本位の誠実さを感じた事を記しておきたい。