Facebookが新たな時間単位「flick」を提唱 41
ストーリー by hylom
NTCSの闇 部門より
NTCSの闇 部門より
Facebookが新たな時間の単位を提唱している（PC Watch）。
この時間単位は「flick（flicks）」と名付けられており、1flickは705600000分の1秒に相当する。これを実装したC++コードもすでにGitHubで公開されている。
昨今ではさまざまなフレームレートの動画やサンプリング周波数の音声がコンピュータで取り扱われているが、1flickをこのように定義することでさまざまなフォーマットにおいて扱いやすい形で時間を管理できるという。たとえば毎秒24フレームの動画においては、1フレームの時間は29400000flicks、毎秒30フレームの動画の場合は1フレームは23520000flicksとなる。
ただし、毎秒29.97フレームであるNTSCについてはflicksでも正確には扱えないとのこと。
時間単位と聞いて (スコア:1)
スウォッチの腕時計に「インターネット時間」組み込み [impress.co.jp]
こんなのもアリましたけどね程度に。
＠その後どーなったかは知らん。興味もないので追っかけナシ。
Re:時間単位と聞いて (スコア:2)
一瞬「脊髄反射」の時間単位もあるのかと脊髄反射した。
Re:時間単位と聞いて (スコア:1)
PSOとか待ち合わせに使われてましたな。
PSOBBではボスの攻撃力と外観が変わるとかそういうのにもつかわれてたもよう。
最近はどうなんだろうな。
Re: (スコア:0)
インターネット時間が特定の条件を満たすと特殊攻撃が発動したり攻撃力が変動したりするレア武器もありましたね
しかし、後継のPSU・PSO2ではインターネット時間非対応になったので時間を使ったギミックはなくなりました
（特殊攻撃自体なくなったのでレア武器の個性が薄くなりましたけど）
Re: (スコア:0)
実はフランス革命では時刻も十進にしていて、Swatchの1ビートは1十進分と同じです。
あまりに不評だったのか、大本のフランス革命暦よりもかなり前に廃止になっています。
毎秒29.97フレームであるNTSCについてはflicksでも正確には扱えない (スコア:1)
ダメじゃん
分数で管理するのはダメなのか
Re:毎秒29.97フレームであるNTSCについてはflicksでも正確には扱えない (スコア:3, 参考になる)
実はできます♪
https://pc.watch.impress.co.jp/docs/news/1102480.html [impress.co.jp]
1001/30000 (~29.97) fpsの1フレーム: 23,543,520 flicks
＃記事の訂正が反映されてないだけで～す
Re: (スコア:0)
どうせ訂正されないんだろうな
スラドは窓の社以下か
Re:毎秒29.97フレームであるNTSCについてはflicksでも正確には扱えない (スコア:2, すばらしい洞察)
どう考えてもスラドのほうが泡沫サイトだと思うんですが？
Re: (スコア:0)
比べるなんてインプレスに失礼だったわ
Re: (スコア:0)
1001/30000≒0.0333667なんですが？
# 最近「≒」は使わなくなったのだろうか
Re: (スコア:0)
1/705600000が有限小数だとでも思いましたか?
Re: (スコア:0)
1001/30000 じゃなくて
30000/1001 だろうって話なんじゃ？
Re: (スコア:0)
放送であったりビデオデッキ、ゲーム機等から出力されるNTSC映像のものは表現できても、
それらをエンコードしたAVI資産は大概strhに 2997/100 と書かれていて表現できないでしょ
Re:毎秒29.97フレームであるNTSCについてはflicksでも正確には扱えない (スコア:1)
分数で管理することにして、よく使う分数の分母で通分して分母を固定すれば、
分子という一つの整数だけで時刻を正確に管理できる、というのが今回のflicksのアイデアでしょう。
flicksの分母が705,600,000なわけですが、「705,600,000=44,100×16,000=48,000×147,000」と考えると、公倍数感がすごくありますよ。
29.97については別のコメントもありますが、見た目通りの「1/29.97秒」という時間はこのflicksでは表現出来ませんが、
実際のNTSCのフレームレートは30×1000÷1001 = 29.9700299700…fpsです。
「毎秒○フレーム」という表記だと循環小数になってしまい正確な表現ができない感じがしますが、
1フレームの時間を分数で表した場合は1001/30000秒。分母は30000というきりがいい数値なので、正確にflicksで表現できます。
Re: (スコア:0)
そうそう。
44.1kHz-48.0kHzのサンプリングレート変換をまじめにやると出てくるオーバーサンプリング周波数7,056kHzが正確、簡潔に表現できるのは有難い。
std::chrono (スコア:1)
細かいこと言うけど、ここはスラドなんだから、
C++と書くより C++11/14 と拘って欲しかったかな。 >タレコミ
C++11で導入されたstd::chronoを利用しているらしいけど
github の readme 上では "-std=c++14" と コンパイラオプションを指定してるから
C++14導入の何かも利用しているのかな？
std::chronoは正直面倒くさいイメージしか無かったけど
こういうハック的な概念を実装するときには便利だね。
ちょっと見直したのでもう1回ちゃんと勉強しようかな・・・
Re: (スコア:0)
なんで?
ただC++と書くとC++17を意味するから?
Re: (スコア:0)
C++17ではダメということはboolの変数を++してたりするのかな?
Re: (スコア:0)
C++って書いたら、普通は 03かそれ以前の処理系でしょ。
C++17なんて使ってるとこまだまだ少ないよ。
昨今のC++案件は圧倒的に過去のリプレースばかりだし、現場のおっさんどもは
だいたい C++11ナニソレっていう古い知識しか持ってない連中だよ。
C++って書いたら17を意味するってどんな先進的な職場だよ。うらやましいよ。
もとい、03以前と11以降じゃ大きめな互換性の問題があるからね。
一口にC++って言われても、どっちだよって気になってしまう。
オーディオ・ビデオライブラリは古いやつもいっぱいあるから
少なくともC++11に上げられないとこのライブラリと共存できないじゃん。
Re: (スコア:0)
老害の脳内の普通の話なんぞ聞いてないよ
Re: (スコア:0)
> C++って書いたら17を意味するってどんな先進的な職場だよ。
C++ が通じる時点で先進的じゃない気すらするよ
30の倍数系列だとフレーム長がfloatになり丸め誤差が生じる (スコア:0)
じゃあフレームレートの公倍数で新しい単位を作ればいいじゃん! などと意味不明の供述をしており、慎重な捜査を…
精度は？ (スコア:0)
単位を決めたところでハードウェアがそれに見合う精度を提供できないのでは？(特にx86)
単にプログラマの脳内で切が良く感じられる以上の意味はなさげ。
Re:精度は？ (スコア:1)
TSCとLocalAPICに何か問題でも？
Re: (スコア:0)
LocalAPICは知らんがTSCはCPUのパワーセーブが当然になった昨今ではまったく当てにならんな
Re: (スコア:0)
再生時間が伸びた時に浮動小数点数の丸め方の違いでフレーム番号が決定不能になることがなくなる
フレームの表示順がカノニカルになる
Re: (スコア:0)
ナノ秒を扱える環境で使えれば十分なのでは？
複数のフォーマットのデータを同時に扱う編集環境の内部で有用なのではないかと思います。
ユーザがそれを意識する必要はなさげ。
Re: (スコア:0)
ノンリニア編集でのアドレス決定に不確定性が無くなるのがメリットなのだから、ハードウェアの精度とか関係ないんじゃないの？
基本的に映像のプロ用途でしょコレ。
いずれビデオ編集のタイムコードとかに使われるようになるんじゃないかね。
Re: (スコア:0)
周波数で言うとflickは705MHzだから遅いほうでしょ。
将来的にもこれで表現できるの？ (スコア:0)
705600000分の1っていうのはきっと今使われている29.97fpsみたいな数値を全部集めて、その最大公約数的なものを算出してその値にしたのでしょ。
既存の数値はこれで表現できるとしても、今後どういった理由で中途半端な数値が採用されるかもわからず、そしてそれがflickで表現できない可能性が残ると思うんだけど・・・
Re: (スコア:0)
割とありそうな数字だと
11fps,13fps,17fps,19fpsみたいな素数fpsが無理ですね。
実質既存の物である程度目星をつけてるんだから、選択肢から選べるようにするか、逆数や分数に対応すれば十分な気がします。
アイデアとしては面白く多少使えそうではありますが。
Re: (スコア:0)
プランク時間（真空のプランク長を光子が通過する時間、プランク自然単位系の時間単位）なら、今後発明される物を含め大抵の時間の公約数。
定義 (スコア:0)
スマホを1回フリックするのにかかる時間かと思った
44100/1.001≒44056Hz (スコア:0)
初期のPCMオーディオで使われたサンプリング周波数なんだけど、対応出来てるんですね(16016 flicks)。
# そんな古い素材を持ってる人は限られるんだろうけど。
# 2chステレオなのにA/Dコンバータ1つで済ませてた変態仕様なのがあったらすぃｗ
384KHz (スコア:0)
どうして、あと一声、半分にして 1/1411200000 にしなかったんだろう？
今だもハイレゾ音源とかって 384KHz とか普通にあるよね。
Re: (スコア:0)
ミリflick を使えばいい
部門名 (スコア:0)
❌NTCSの闇
⭕NTSCの闇
地味にボーレートに使える (スコア:0)
今さらだけどレガシーなシリアル通信の様々なボーレートに対応できそう。
意味わからないんですけど？ (スコア:0)
なんで秒３０コマのどうがで何億分の１の精度が必要なのでしょうか？
せいぜい１００分の１程度の精度でいいのでは？
Re:意味わからないんですけど？ (スコア:2)
おそらくこのflickが想定しているのは映像編集ソフトなど。
この場合、必要なのは「1/30秒の絶対的な精度」ではなく
「1/30秒・44.1kHzなどのさまざまなレートを統一的に扱う時の、相対的な誤差のなさ」です。
秒30コマの映像と秒24コマの映像、
秒44100サンプルの音声と秒48000サンプルの音声
などを混在させて相対誤差なく編集できるかどうかの問題。
たとえば、「100分の１程度の」精度だと、「たった1分40秒のムービーで、絵と音が1秒ずれる」というまったく使いものにならないレベル。
「2時間のムービー(秒30コマ=33.3ms/コマで216,000コマ)で、ズレは1コマ程度」の精度を出そうとしたら、「20万分1程度の精度」が必要になります。
「1/30秒を20万分の1の精度」で表現するには、十進小数形式だと、マイクロ秒の整数で表すレベルではまだ足りず、ナノ秒レベルが必要です。
「十進表記で循環小数になるものを、十進ベースのまま必要な精度が出るまで桁数を増やす」ような場当たり的な対応ではなく、「すべての情報が正確に表現できるように、最小公倍数分母の分数で表現する」方がいいんじゃないの、ってのがflickのアイデアです。