コグノスケ

アイス履歴

アイス履歴を10個ほど増やしました（リンク）。これで55種類かな。そろそろカウントが面倒になってきました…。

最近はパピコやモナカのような棒アイス以外にも手を出しているので、アイスの袋の増え方が激しくアップロードしきれていません。そのうち載せます。

夏、秋は果実系のさわやかなアイスがおいしい季節でしたが、冬は味濃い系が恋しくなります。個人的にまた発売してほしいなー、と思うアイスは、

• 赤城乳業 ミルクレア スイーツ ラムレーズン
• 明治 ゴールドライン フランボワーズ
• ロッテ カスタードとろけるほろにがカラメルのプリンアイスバー

辺りですね。他のアイスもおいしいです。ぜひ見かけたら食べてみてください、と言いたいところですが、アイスは商品の入れ替わりが激しくて、すぐにお店から消えるんですよねえ……。

その反面、アイスはほぼ毎週と言って良いほど、新商品が出ていてマンネリとは無縁です。メーカーさんの努力は素晴らしいです。

テレビの栄枯盛衰

一応、テレビ向けのSoCを作るお仕事をしていますので、たまに電器屋さんにテレビを見に行ってますが、どこに行ってもテレビのコーナーは年々狭くなっています。

土曜日に梅田ヨドバシに行きましたが、一時期は3Fをテレビが支配していたのに、今や1/3位です。ホームシアターを除いて純粋にテレビだけでカウントしたら、もっと狭いかもしれません。テレビを家電の1つと見れば、フロアの1/3を占めているのは破格の待遇と言えますが、つい過去の栄光と比べてしまいます。

同じ階にはオーディオコーナーと、キャンプ用品コーナーがありました。テレビはオーディオコーナーと同じか、やや負けてるくらいの広さでしょうか？この先、テレビの面積が復活することは無いでしょうから、そのうちオーディオと合併して、オーディオ・ビジュアルコーナーになるんでしょう、たぶん。

レコーダーはどこ？

レコーダーは悲惨で棚2つしかありませんでした。BD-RとかDVD-Rみたいなメディアそのものを売っている棚の方が多いように見えますけど、バランスおかしくないです？？

番組を録画する文化は日本特有らしく、もともとレコーダーは日本でしか流行っていません。海外でも販売していますが、プレーヤーの方が好まれるようです。頼みの日本がこの状態だと、そのうちレコーダーという製品は無くなるかもしれません。

プレーヤーは細々と続くと思います。とはいえ、黒物家電メーカーは全員ボロボロで、次世代の光ディスク規格を作るほどの元気は無いでしょう。BDを8K規格まで延命して、ネットにバトンタッチして終わりか、下手したら4Kで燃え尽きて終わりかもね……。

Kindle Fireの変なフォントが直っていた

目次: Kindle

いつのまにかKindleがアップデートされており、フォントが変になる問題（2017年10月13日の日記参照）が直っていました。あとストアアプリのメニューがダブって表示される問題（2017年10月12日の日記参照）も直っていました。

直してくれてありがとう。やっぱりおかしいってわかってたんだね……。

ポケモンGO

ポケモンGOのアプリはいつまで経ってもバグだらけです。新しく実装された機能（ジムバトル）は当然バグバグで、通信周りが弱くハングしまくります。

• ジムで木の実投げるときにジムから離れると操作不能
• 木の実を投げたときに対象のポケモンが別のプレーヤに倒されると操作不能
• ジムバトルの開始時にハング、勝利時にもハング
• ログイン画面でWiFiから3G/4Gに切り換えるとログイン不能
• ポケモン捕獲時にハングする
• キャラクターが真っ黒になる
• 地図が一面海になる

操作不能になったり、ハングされたりするとアプリを再起動するしかないですが、ハイエンド機じゃないせいか起動も動作も遅くてイライラします。

1日15分もやってないのにこの有様なので、もっと長時間遊んでいる人はイライラで憤死するんじゃなかろうか？

折角面白いのにアプリが残念すぎる……。

Androidメディア処理

昨日（2017年11月8日の日記参照）の続きです。

本来見たかった道をざっくりまとめておくと、

• デコード終わり
• コールバックOMXNodeInstance::OnFillBufferDone()
• instance->owner()->OnFillBufferDone() → OMX::OnFillBufferDone()
• OMX::CallbackDispatcher::post()

これが 2017年11月6日の日記の前半で分かった部分。

• OMX::CallbackDispatcher::loop()
• OMX::CallbackDispatcher::dispatch()
• mOwner->onMessages() → OMXNodeInstance::onMessages()
• mObserver->onMessages() → ？

これが 2017年11月6日の日記の後半で分かった部分。

• mObserver->onMessages() → CodecObserver::onMessages()

これが 2017年11月7日の日記で分かった部分。

• mObserver->onMessages() → CodecObserver::onMessages()
• notify->post() → AMessage::post()
• looper->post() → ？

これが 2017年11月8日の日記で分かった部分です。そのあとはlooperとは何ぞや？という点を追いかけていましたが、まだわからない状態です。

• looper->post() → ？
• looper = AMessage::mLooper
• mLooper = handler->getLooper()
• handlerはAMessage() の2番目の引数
• notify = mNotify = AMessage(kWhatOMXMessageList, mCodec) だから、handler = ACodec::BaseState::mCodec
• looper->post() → mCodec->getLooper()->post() のはず

再開

肝心のACodec::BaseState::mCodecに何が入っているのか？についてはUninitializedStateを手掛かりに見ていきます。

//android/frameworks/av/media/libstagefright/ACodec.cpp

struct ACodec::BaseState : public AState {
    BaseState(ACodec *codec, const sp<AState> &parentState = NULL);

...

    ACodec *mCodec; //★★これが知りたい★★


//★★UninitializedStateを手掛かりに見てみる★★

struct ACodec::UninitializedState : public ACodec::BaseState {

...

ACodec::UninitializedState::UninitializedState(ACodec *codec)
    : BaseState(codec) { //★★BaseStateに丸投げ★★
}


//★★BaseStateを見てみる★★

struct ACodec::BaseState : public AState {
    BaseState(ACodec *codec, const sp<AState> &parentState = NULL);

...

ACodec::BaseState::BaseState(ACodec *codec, const sp<AState> &parentState)
    : AState(parentState),
      mCodec(codec) { //★★引数をそのまま設定しているだけ★★
}


//★★UninitializedStateの生成個所を探す★★

ACodec::ACodec()
    : mQuirks(0),
...
      mDescribeHDRStaticInfoIndex((OMX_INDEXTYPE)0) {
    mUninitializedState = new UninitializedState(this); //★★thisが指すものはACodec★★
    mLoadedState = new LoadedState(this);

つまりACodec::BaseState::mCodecは、UninitializeStateを生成したACodecです。もう一つの謎getLooper() が何を返すのか？も見てみます。

//android/frameworks/av/include/media/stagefright/foundation/AHandler.h

struct AHandler : public RefBase {

...

    wp<ALooper> getLooper() const {
        return mLooper; //★★mLooperを返すだけ★★
    }

...

    inline void setID(ALooper::handler_id id, wp<ALooper> looper) {
        mID = id;
        mLooper = looper; //★★mLooperはsetIDの引数そのまま★★
    }


//android/frameworks/av/include/media/libstagefright/foundation/ALooperRoster.cpp

ALooper::handler_id ALooperRoster::registerHandler(
        const sp<ALooper> looper, const sp<AHandler> &handler) {
    Mutex::Autolock autoLock(mLock);

    if (handler->id() != 0) {
        CHECK(!"A handler must only be registered once.");
        return INVALID_OPERATION;
    }

    HandlerInfo info;
    info.mLooper = looper;
    info.mHandler = handler;
    ALooper::handler_id handlerID = mNextHandlerID++;
    mHandlers.add(handlerID, info);

    handler->setID(handlerID, looper); //★★setIDを呼んでいる個所はここだけ★★

    return handlerID;
}


//media/libstagefright/foundation/ALooper.cpp

ALooperRoster gLooperRoster;

...

ALooper::handler_id ALooper::registerHandler(const sp<AHandler> &handler) {
    return gLooperRoster.registerHandler(this, handler);
}

ALooper::registerHandlerはALooperをAHandlerに登録する仕組み、AHandler::getLooper() はAHandlerに登録されたALooperを返す仕組みのようです。取得 / 設定が一致しないのでややこしいです。設計を失敗したのかなあ？

例えばAHandler *hogeとALooper *fugaがあってfuga->registerHandler(hoge) としたならば、hoge->getLooper() は先ほど登録したfugaを返します。

• looper->post() → ？
• looper = AMessage::mLooper
• mLooper = handler->getLooper()
• handlerはAMessage() の2番目の引数
• notify = mNotify = AMessage(kWhatOMXMessageList, mCodec) だから、handler = ACodec::BaseState::mCodec
• looper->post() → mCodec->getLooper()->post() のはず
• ACodec::BaseState::mCodecは、UninitializeStateを生成したACodecだから
• looper->post() → ACodec::getLooper()->post() のはず

ちなみにACodecはAHandlerを継承しているのでgetLooper() 関数を持っています。

ここまで分かればALooper::registerHandler() を呼んでいる個所を見て、引数がACodecオブジェクトであろう場所を見つければ、looperが指しているのが、どのALooperなのか？がやっと判明します。

しかしregisterHandler() の呼び出し箇所は非常に多くて、追いきれません。うーん、別のアプローチが必要でしょうか……？