Monthly Archives: June 2016

ヘルスケア関係のサイトにサイバー攻撃

昨今、情報を盗む目的で(もちろん詐欺やなりすまし)ヘルスケア関係のサーバへアタックが頻発しているそうです。

Bitdefender のシニア “e-threat analyst” のBogdan Botezatu氏によると、理由は一つ。
この手のサイトはセキュリティがイマイチだからだそうです。

さて、この手のサイトはマルウェアを仕掛けたりバックドアを仕掛けたり、脆弱性を突いたりすることによってサーバの中に入ることが出来たら、かなりの個人情報を得ることが可能になり、その人を装ってなりすましでカネを借りたり、詐欺をしたり、更にその病院やシステムを停止することも考えられる。

ヘルスケア関係者と言うのは現在のハイテク病院や製薬会社のことである。
ハイテク病院は色々な機器がネットワークにつながっているので、すべてのシステムの脆弱性を塞ぐことは不可能でありからこそ簡単に出来てしまうそうだ。
昨今、アメリカではコンピュータ管理から1960年代とも思われる「紙ベース」で管理することに決めたところすらある。

何しろ、コンピュータウィルス感染やランサムウェア(身代金型マルウェア–カネを払っても無意味なことが多い)によってシステムのシャットダウンに追い込まれた病院が多々あるのでと、システムを扱っているのは医師であり、コンピュータエンジニアではないのでアタッカーはやりたい放題でもある。

 

セキュリティの甘さだけではなく、管理者が不在でもあり、各々があまりにも複雑なので管理しようがないと言うのが現状。
厄介なのは、第三者が自分の情報を利用してなりすまされた時だ。
そのカネは自分が借りたカネではないと言う証明が難しい。

これにて米国ではソーシャルセキュリティーナンバーと名前を勝手に第三者によって使われて(盗むのは簡単)、他人名義でカネを借りて、いざとなったら自分はブラックリストになってクレジットカードすら作れないことになっていて、その自分でないと言う証明をするのに数百万の弁護士費用がかかったりする。
これは本当にあってはならないことで(弁護士費用も問題あるし、ノーチェックで18歳未満の子どもが何万ドルもカネを借りれることも問題もある)このようなコンピュータ依存社会に終止符をどこかで打つことは出来ないが、「待った!」を言える社会システムを作る必要があるだろう。

ナンバープレートにつける車載カメラ

この三日間(負け惜しみw)で私はMPEG4データと戦っていた。
何しろ、 https://pearlauto.com の車載リアビューカメラを発見してそれをいち早く伝えたく、データを編集していたら、結果的に最悪の結果に終わった。
そして記事の紹介をG社に取られてしまった。

まず、ナンバープレートに何かを装着することは日本ではご法度だ。
中には赤外線を反射するフィルムを貼って取り締まりを逃れる輩も少なくない。
こう言うのはバンバン摘発して欲しい。
更にナンバープレートの角度を調整したりする人もだ。

そう言うのを防止するために、ドライブレコーダがある。
今では保険屋さんも必要だと言うくらいだ。
Tumblrで保険屋さんは自分の取り分が減るとかと言った誤った情報が流れているので注意して欲しい。ドライブレコーダのおかげで明確に誰が悪かったかハッキリするので仕事が早く終る。

さて、前側にはあるが、後ろ側から追突されないこともない。
ロシアではよくある話だ。
だからこそ、ロシアではほとんどの車に前後を録画できるドライブレコーダが搭載されている。
誰の原因で事故を起こしたのか判明するからだ。

今回、紹介するのは、アメリカのみで販売予定しているモノだ。
是非日本のナンバープレートにも装着できるようにして欲しい。
あっ、盗まれないようにしないといけないのもね。
しかし、盗んだとしてもOBD(On-Board Diag)がないと動作しないからね。

まず、アメリカでは2018年までにすべて(その年に製造された)車にリアカメラを搭載と言う法案が通ったみたいだ。1984年には実は、似た法案があり、リアの中央ストップライトも同様だった。
これに対してスバル以外の日本のメーカは国内の車にはコストアップに繋がるので10年くらい後まで搭載しなかった記憶がある。スバルは国内外も同じ基準なのでラインを分けるほど余力がなかったのかはわからないが、米国規格に準拠して、日本でも中央のストップライトを設けた。リアビューカメラに対しても、日本メーカは同様かと思う。削れるところはすべて削る。たぶん、今回のスバルも現在はトヨタの資本が入ったのでどうなるやら・・・

2016-06-22 21.46.43

さて、このリアビューカメラはOBD IIの制御装置を使って iPhone や Android につなぐ。

これは車載ダイアグシステム(コンピュータ)の端子である。これは1996年以降あたりからほとんどの車にある汎用端子なのでここで同期を取る仕組みになっている。

2016-06-22 21.39.31

さて、日本での販売を期待したいが、まず日本の場合、法的にどうか?
あー、そんなのカンケーネ〜!って言ってしまうことも出来る。
なぜなら、今でも車アクセサリーでドレスアップ用のマウントが売っているからだ。
しかし、これはどうのか。
そして、日本おプレートサイズに合うようにすればOKあろうが、今ではちょっとサイズがあわないだろうと。(自分の車で実寸を測っていない–ヾ(゚Д゚ )ォィォィ 測って比べろよ)

そんなところで、保険業界としてはこのカメラが盗まれないようになればOKだろうが、車メーカが困るだろうな。ODB端子にこのようなモノを取り付けれられるって知っているメーカの販売店員さんですら知らないからだ。

現在、$499.99 の価格だ。5万円チョイ。
高いか安いかはわからない。
更に車を数台保有していたら、アプリの方で各車と同期を取れるだろうか?
ヨメと自分の車でアプリが両方オンになった時に弊害があるのか。
Bluetoothみたいに1対1だから、ケータイへは1台のみしか同期が取れないとか。
色々と考える余地があるので、聞いてみたい。

2016/06/24

Final Cut Pro 7でMPEG4データを読み込むには、その3

この数日間、ドツボにハマってます。

Final Cut Pro 7では MPEG4 を直接扱えない(iMoviesでは可能)なので、Android携帯で撮影されたムービーをFCPで加工するにはと・・・

まず、Final Cut Studioに付属のCompressorで色々なデータ方式に変換しました。

DV NTSC、Apple Intermediate Code(AIC)、ProRes 422などに変換。

そして一番素早く加工し易いのがDV NTSCと判明。
しかし、解像度がイマイチだわ。
AICのデータのままだとYouTubeにアップロード出来ないことが判明。
そして、たぶん、これはマシン性能かも知れないがProRes 422同様に短い映像データでも音声と映像の同期が取れないので編集で手こずる。

更に色んなフォーマットに変換し保存直してみた。

この時、データサイズはかなり異なった。

MPEG4に変換しても16:9だと4:3の圧縮になってしまったり(これはレターボックスにしないとアカンのかも)、色々と難しいことがありました。

見ての通り、色々と変換。
一番厄介だったのは、変換するとタイムライン上ではOKなのだが、保存したデータを見るとテロップの文字がズレる!

これには頭を悩ませた。

FCPの初期化の問題かとも思った。
それで ~/Library/Preferences の中の com.apple.FinalCutPro.plist と Final Cut Pro User Data フォルダを削除してみたがそれでも改善されない。

結論からして、MPEG4データは扱うなと言うことだわな。
時間の無駄なので、iPhoneで撮影して(本当なら、iPhoneのカメラ解像度を選択することが出来るならありがたいんだが)、編集したほうが良いと言うことだった。

しかし、問題は iOS9.2 ではOKだったのに9.3にアップグレした iPhone だと、FCPで読み込んだときにデータが逆さになる。そしてタイムラインに乗せると天地がまたひっくり返る。勘弁してくれとつくづく思う。

誰かの参考になればいいです。

via Blogger http://ift.tt/28UpRHi

Final Cut Pro 7でMPEG4データを読み込むには、その2

昨日、丸一日かけて3分弱の映像をレンダリングするハメになった。

もうアカン!って思いながら、何か良い方法はと。

データの受け渡し方に問題があるのは確かなので、この最適な方法をと探してみた。

1) AIC HD 1080i (816MB)

2) ProRes HQ 422 1080i (1.63GB)

3) DV NTSC アナモフィック(テロップがズレてしまったw)(234MB)

データの大きさはDVが一番小さかった。そしてAIC HD、そして最大がProRes422。

画質しては、AICが一番良いと感じたが、実は編集時にAICとProResでは問題があった。

この2つ、タイムラインでの音声と画像で同期ズレをしていた。

編集時に音を頼りにインとアウトを入れるしかなかった。

これはアカンわ。

画質としてDVは眠たいが、使えないってことではない。

ノイズが低減されていている。コントラストをアップするしかないのか。

AIC HD 1080i は YouTube でデータが蹴られたのでアップできません。
これがオープニングの画像

 

やっぱりしっかりしているのがAICだが、軽さとしては、NTSCしかない。

データの大きさを見たら一目瞭然。

NTSCに比べたらAICもProRes422は色もコントラストもしっかり出ている。

取り敢えず、音声と映像の同期ズレも考慮したら、DV NTSCアナモで変換するのが確実かも知れんな。

それに2分弱でレンダリングされた。

AICは3分弱、ProRes 422は4分ちょっと必要だったのと、AICだとYouTubeにアップできない。

via Blogger http://ift.tt/28QHmpn

Final Cut Pro 7でMP4データを読み込むには

結論から先に言うと Android と Final Cut Pro は相性が悪い。
いや、Android と Mac の相性が悪いとも言えるかも。
まぁ、MacとiPhoneって言う組み合わせが定番だからね。

さて、以前も手こずったので、またどこをどうしたら良いのか調査してみた。

Android端末で撮影した動画はMPEG4で保存されている。
これがFCP7では読み込めないんですよ。
更に、厄介なことに一度、端末を接続してiPhotoで読み込んだりして。
これも手間がある。

さて、次にFCP7で読み込もうとすると終わらずにエラーとなる。
はいはい、iMovieを利用しているなら読み込めるのは分かってますよ。
しかし、iMovieだと編集がし辛いので敢えてFCP7を利用したい。

さて、そもそも、Xperia Z1なんだが、画質が悪い。
iPhone 5で撮影すればよかったと。
それはともかく、データが読み取れないのが大問題だわ。

まず、MPEG4データをFCPに入っているCompressorでデータを変換。
これをQuicktime H.264 HVフォーマットに変換しました。
この4分弱のデータを30分以上も掛けて変換!

利用しているマシンは MacBook Pro Core i7-2.4GHz です。
スペックは低くはないけど・・・

さて、このマシンでFCPを走らせているのが(いい加減アップグレードしたらと–はい、しますのでちょっとお待ちを)次にこのデータをFCPに取り入れたときに再レンダリングせねば再生できない。
無限RTにすればよいが、このマシンでは確実にパワー不足だわ。
これをレンダリングするだけえ、また1時間くらい!
もう使えんわ〜

何しろ、DV画質は悪い。iPhoneをiOS9.3にしたらFCPでのデータが逆さになる (9.2までOKでした) 、Androidのデータは変換しないと使えない、それも時間の無駄なので、もう二度とAndroidでは撮影しないだろう。

今でも10秒のテロップを入れて3分以上もレンダリングに掛かっているので、ちょっと痛いわ。

これから、DV以外にどのデータ・フォーマットが良いのか調べる必要があるけど、これこそ、無駄な作業。それなら、映像はiMovieで編集した方が楽かも知れない。これならMPEG4をネイティブで扱えるiMovieの方が正統派になってしまいそうだわ。

まず、これが Android Xperia Z1のFaceカメラで撮影したMPEG4の映像
しっかりしているけど、ノイズが多い

これがDVカメラ ソニーDCR-TRV70K(210万画素で録画で35万画素へレンダリング)で1394経由でiVDRにデータを転送し、MOVに変換。一番画質が悪い。0.3xのワイドアングルレンズを取り付けている。

これがiPhone 5のFaceカメラ。
一番シャッキとしている。しかし、FCPでのデータは遅いがMPEG4からQT H.264に変換したモノよりはずっと軽い。

これが比較したもの:

1) Xperia Z1 front camera 2) DVカメラ TRK70K 0.3x
3) DVカメラ TRK70K 0.3x  4)iPhone 5 front camera

Zoom Q2も持っているが、これは自撮りが簡単には出来ない。後ろに鏡を置いて撮影を試みたが、どうもイマイチなのと、0.5xワイドアングルレンズも取り付けているが、画角が足らない。

結論としては、HDVカメラが一番いいのかも知れない。
子どもの記録を撮影していて、これが便利で、データもそれほど重たくない。
そして、持っているワイドアングルレンズとΦが一緒なので、取り付けることも可能だ。

via Blogger http://ift.tt/28Pt22V