日々の戯言


バックナンバー

1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2016年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

11月2日(水) デジコン委 第60回 傍聴メモ [この記事]

既に Impress AV Watch [URI] と 日経BP IT Pro [URI] で記事になっているけれども、一応今回も傍聴してきたので手抜きモードで傍聴メモを残しておく。

今回の議題は地上デジタル放送の新コンテンツ保護方式の進捗報告ということで、今年の 6 月 1 日に登記された「一般社団法人 地上放送 RMP 管理センター」[参考 : オンライン登記簿から取得 個人住所のみ墨塗 URI] に関しての進捗報告とか、新方式の運用体制とかの説明がメインだった。

まだ総務省のサイトに当日配布の資料が上がっていないようなので、このサーバにスキャンデータ [URI] を置いておく。地上放送 RMP 管理センターについての資料は「資料1 新コンテンツ保護方式導入に向けた進捗状況について」[URI] になる。

この資料で注目すべきは 5 ページ目の導入スケジュールのところ。現段階で既に NHK と在京民放 5 社は新方式対応の為に放送設備改修に着手していて、来年 7 月には本運用開始というあたりが最も重要なところと考えている。

新方式の技術仕様に関しては、既にそこそこ詳しく書いたことがある [URI] ので省略することにして、新方式で何が変わるかというと、B-CAS カードを使わない地上放送の受信機が作れる(ただし、地上放送 RMP 管理センターとの契約が必須で多分個人とは契約してくれない)ようになって、そのかわり放送事業者がもう一つ B-CAS 社を作るのと同じぐらいの費用負担をするというだけのこと。年間費用は B-CAS 社の販管費 3億6千万 と NTT メディアクロスへの業務委託費用 9 億 6 千万を合計した 14 億程度になるんじゃないかなと推測してる。

そんなわけで、新方式が導入されても B-CAS カードがなくなるわけではないので、現在 PC 用受信環境を自力整備している人は b25decoder.dll の仕様実装漏れを除いて特に心配する必要はない。当然ながら新方式を導入したところで friio 等も問題なく利用継続可能だ。新方式を導入して誰が仕合せになるのとか不思議になるかもしれないけれど、B-CAS 社以外に新しい法人ができて、座れる椅子が増えると仕合せな人も世の中にいるのだろう。

◇◆◇

えーデジコン委のお歴々 [URI] は「技術的にはアクセスコントロールの機能しか持たない B-CAS カードにコピーコントロールのエンフォースメントを任せた挙句、まったく実効性を担保できないことが明らかになってしまっている」ということを理解できず、地デジ促進の為に新しくソフトウェア方式を導入しようとしている阿呆のように見えるかもしれませんが、決してそんなことはありません。

その辺に踏み込んでしまうと色々と不都合なことが明らかになってしまうので見て見ぬふりをして「第6次中間答申で合意したことだから」を錦の御旗に前動続行してるのだと私は判断しています。大人の世界って大変ですね。かわいそうですから、暗号化やめれば地上放送 RMP 管理センターの年間費用 14 億 (推定) を節約できるのにとか指摘するのはやめてあげるようにしましょう。


11月15日(火) 文化庁 文化審議会/著作権分科会/法制問題小委員会/第五回 感想 [この記事]

さてさて、本年度の法制問題小委員会が 11/9 に開催され、傍聴してきたので、前回までと同様に非公式議事録 [URI] をでっち上げました。

今回の議題は、第四回と同様で「国会図書館での電子化データを他の図書館に配信するために、著作権法に追加すべき権利制限規定」についてです。「電子書籍の流通と利用の円滑化に関する検討会議」[URI] の報告書では「配信先での利用方法は閲覧のみに制限」となっていたのに対して、前回の法制問題小委員会の議論では「一部分だけのプリントアウトすら認めない場合、知の地域格差は解消されないのでは」という意見が支配的となり、この法制問題小委員会でもう一度議論をするということになりました。結果開催されたのが今回の第五回です。

前回の第四回についての感想は [URI] にあるので、この記事で興味をもった人は参照してみてください。

◇◆◇

第四回で出された意見では「一部分であっても複製が行われるならば著作権者の権利(複製権)を侵すので、対価の還元策(補償金等)も考えておく必要があるのでは」とあったので「あーこうやってぐだぐだと議論がひきのばされていった挙句、余計な補償金制度まで新たに導入されるのか」と嫌ぁな気分になったのですが……。

今回、事務局が「国会図書館では 31 条に従ってどのような処理が行われているのか」という資料 [第五回 資料 1-3 : 「国立国会図書館における複写サービス等について」URI] を用意しており、その中で「遠隔地からの一部複製申し込みを受付て、複製結果を郵送で送付するサービスを(実費のみ/権利者への対価還元なしで)行っている」という実態が紹介されたため、前回までとは多少方向の異なる議論となりました。

今回の議論では、送信データの部分複製に関して委員の方々から出された主な意見は次のようなものです。

上野 達弘 委員:
インターネット経由で部分複製を申し込めば、5 日間程度でコピー結果が送られてくるのに、閲覧画面から直接プリントアウトを禁止しても、利用者に対して不要な手間をかけさせるだけではないか [URI]
現在の部分複製郵送サービスが市場で入手容易な書籍もその対象としている以上「絶版その他それに準ずる」の実際の範囲がある程度広くなったとしても、(部分)プリントアウトを認めてよいのではないか [URI]
茶園 茂樹 委員:
送信先が公立図書館や大学図書館等に限られるのであれば、部分プリントアウトを認めても「送信先で無制限の複製物が作成される事態に繋がる可能性」は低いので、部分プリントアウトを認めても良いのではないか [URI]
中山 信弘 委員:
(部分複製を)国会図書館に申し込んで、4・5日複製を待たせるのは利用者への嫌がらせの効果しかないのでは [URI]
多賀谷 一照 委員:
現在は図書館に置かれた PC 端末での閲覧を考えているのだと思うが、今後 kindle 等でも閲覧できるようになるとしたら、複製の問題についてもっと慎重に考えるべきではないか [URI]
部分複製サービスに関して図書館でどの程度の管理がされているのか懸念がある。図書館の範囲を広げた結果、全部の複製を認めてしまうところが出てくる懸念はないか [URI]
山本 隆司(たかし) 委員:
相当期間重版していないものという配信対象の限定がある場合部分プリントアウトを認めてよいと思うが、複数回部分複製を申し込んで全体の複製ができてしまうことを考えると、対象図書として現に販売されているものが含まれることがないようにすべき [URI]

とこのように、部分複製に関しては一部慎重意見はあるものの、配信先図書館および配信対象書籍が検討会報告書のように制限されている状況では 31 条 1 項 1 号と同等の範囲でのプリントアウトを(対価還元策の整備なしで)認めてよいのではないかという意見が支配的でした。

少し、議論が紛糾したのは「絶版その他これに準ずる理由により一般に入手することが困難な図書館資料」という 31 条 1 項 3 号の規定についてです。国会図書館からの配信を行う対象出版物についてはこの規定を参考にするべしというのが検討会議報告書だったのですが、今回の会議で事務局が用意した資料には、31 条 1 項 3 号の運用例が全く記載されていなかった(国会図書館から他の図書館に対して資料の貸し出しを行う場合の例しか記載されていなかった)ため、この条項の運用例について国会図書館に対して問い合わせを行うべきではないかという意見が出て、今回で法制問題小委員会として意見をまとめきることができませんでした。

国会図書館からの配信対象となる書籍等について、委員の方々から出された主な意見は次のようなものです。

山本 隆司(たかし) 委員:
複数回部分複製を申し込めば全部複製ができてしまう以上、「相当期間重版がない」という条件であれば悪影響は少ないが、現に出版されるものも含まれるようになると問題である [URI]
松田 政行 委員:
31 条 1 項 3 号と同様の規定を設けるとしても、国会図書館が 1 冊ずつ判断していくことは不可能だろうから、国会図書館と書籍出版協会が協議して、一定の要件を満たせば配信を可能とする形にせざるを得ないのではないか [URI]
中山 信弘 委員:
出版社の運用上、公式に絶版とすると著作者が怒るので、絶版ではなく重版されず在庫切れという扱いとするらしい [URI]
「絶版その他これに準ずる理由により一般に入手することが困難な」という曖昧な条文にしておいて、松田委員の意見の運用とするしかないのでは [URI]
道垣内 正人 委員:
重版されなかったものがこの国会図書館の配信に乗ってしまうと、二度と重版されず、市場を奪うことにならないか [URI]
茶園 茂樹 委員:
送信の対象出版物として新刊書も含まれてしまうと、小説のように閲覧だけである程度の需要を満たせる書籍の市場に打撃を与えてしまい、電子書籍の市場を奪うのではないか [URI]
大渕 哲也 主査代理:
絶版やオプトアウトという用語は人によってイメージするところが違うので、抽象的な議論ではなくそれぞれの場合で具体的な影響等をきちんと考えておく必要があるのではないか [URI / URI / URI / URI]

かなり錯綜した議論だったので上の要約は不完全なものです。議論が錯綜したのは中山委員の「絶版て存在しないらしいね」という不用意な発言からだったのですが、まあ、その後議論を立て直すためにかなりの努力を払っていたので、責めるつもりはありません。

ただ、道垣内委員や茶園委員、大渕主査代理の意見は正直あまり感心しませんでした。この辺りについては、開催当日に twitter 上に次のような感想を残したりもしています。

道垣内委員[*] からは絶版だからということで国会図書館で電子化して配信されたら電子出版の市場がなくなってしまうのではとのトンデモ意見まで出る始末。電子版が配信されていれば当然「絶版その他」に該当しなくなるというのが検討会報告書の趣旨じゃなかったの? [URI]
[* 茶園委員の間違い / 他の意見と混同していた]

大渕委員は大渕委員[*]で「国会図書館の電子化配信があるせいで重版がかからなくなってしまうのでは」という趣旨の意見を出したり。いや、青空文庫があっても芥川・漱石作品は文庫出版が続いてますがな。 [URI]
[* 正確には道垣内委員と大渕主査代理の混合意見]

特に、大渕主査代理の意見がこう……そもそも……「電子書籍の流通と利用の円滑化に関する検討会議」と「法制問題小委員会」の双方に重複して委員として参加している方でありながら、この期に及んで「抽象的な議論ではなく具体的な検討を」ですからねぇ。利害関係当事者が集まって [URI] いた検討会議で一体何をしていたんでしょう。

ただ、この感想は大渕主査代理がかなり話し言葉よりの構文で発言をされる方で、発言を文字化するのに苦労する (四つの意見中、後半二つは力尽きたので、発言そのままで文章を切らずに載せてしまった) という個人的な感情が悪影響を与えている可能性もあるので……公式議事録が出たら邪念の入っていないであろうそちらを参照して大渕主査代理の意見の妥当性を検証してあげてください。


11月18日(金) MPEG-2 Video VFAPI Plug-In ver. 0.7.5a [この記事]

インタレース 420 の色差補間を何とかしてからの更新にできれば良かったのですが、今回の更新はコンパイラを変更してビルドしなおしただけです。ダウンロードは [mpeg2] のページからどうぞ。

発端は、POP 4bit さんから ver. 0.7.5 が遅くなっていると教えてもらった [URI] ところからです。私の手元環境では再現しなかったものの、AMD のプロファイラ (AMD CodeAnalyst [URI] でデータを取っていただいて原因らしきものに行き着いたので今回の更新となりました。

結局リビルドだけの更新になっているので判ってしまうかもしれませんが、コレという原因の特定にまでは至りませんでした。0.7.2 と 0.7.5 のプロファイル結果から、dct_coefficient.c の log2() 関数がインライン展開されずに、しかもそれなりの負荷で実行されているということは理解できたのですが、手元環境で 0.7.5 と同じバイナリを作ることができなくなっていたので、原因特定と自信を持って言えるレベルまで情報を集めることができませんでした。

◆◇◆

……いや、手元で同じバイナリを作れない DLL ってどうなんだという話は当然あると思います。一応言い訳をしておくと、0.7.3〜0.7.5 にかけては比較的最近の Intel Compiler が過去のものと浮動小数点の扱いを変えていたので、コンパイラオプションを変更しつつ、同じ挙動にするにはどうすればよいか調べていたあたりなので、バイナリのサイズを見る限り、0.7.4 で何か失敗して、その後 0.7.5 リリース前に make clean をサボったのが悪影響を及ぼしているのだろうと推測はしているのですが……

同じバイナリを作れないと手元で再現試験をするにもアレなのと、最新コンパイラで作り直したら問題が解消してるのに、これ以上原因調査するのも熱意が持たなかったので……はい、見苦しい言い訳です。ごめんなさい。原因に何か思いつくことがある方は教えてください。賞品はなにもありませんが、私が喜びます。


1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2016年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

[TOP]