タグ

フォーマットと解説に関するiwwのブックマーク (6)

  • FAT32ファイルシステム読解

    1. はじめに FAT32 ファイルシステムを実装する必要があった (趣味) ため、記事では FAT ファイルシステム (メインはFAT32) の仕様を出来るだけ分かり易くまとめました。 なぜ FAT32 なのか? 全てのOS (Windows, Linux, MacOS) や Raspberry Pi4 のブート用ファイルシステムでもサポートされおり、非常に使い勝手が良い 少なくともファイルのリード操作だけに限定した場合に実装がとても簡単で、Raspberry Pi4 のデバイスで SD カード上のファイルにリードアクセスする場合に便利 ただし、FAT は暗号系の機能がサポートされていなかったりするので、実際の組み込み機器の Linux 系で利用するファイルシステムだと Ext2/Ext3/Ext4 など他のファイルシステムの利用が多いとは思います。 2. FATファイルシステム概要

    FAT32ファイルシステム読解
  • IETF-syslog(RFC 5424)メッセージフォーマット

    現在、syslogメッセージのフォーマットは以下の2つの標準があります。 BSD-syslogメッセージ(または、legacy-syslogメッセージとも呼ばれています。) IETF-syslogメッセージ BSD-syslogメッセージフォーマットについては、過去記事「BSD-syslogメッセージフォーマット」で紹介しています。合わせてご覧ください。 今回は、IETF-syslogメッセージフォーマットについてご紹介します。 IETF-syslogメッセージフォーマット(RFC 5424)IETF-syslogメッセージフォーマットはRFC 5424※で提唱されており、以下の3つの要素で構成されます。 HEADER STRUCTURED-DATA MSG ※参考: https://tools.ietf.org/html/rfc5424 HEADERHEADER要素は、さらに以下の要素で

    IETF-syslog(RFC 5424)メッセージフォーマット
  • 時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog

    IETFに「New UUID Formats」という提案仕様が提出されています。 これは、時系列順にソート可能なUUID version 6, UUID version 7, UUID version 8を新しく定義するものです。 詳しい背景は提案仕様にゆずりますが、ULIDを始めとして、時系列順にソート可能な一意な識別子を利用したいというユースケースがあります。例えば、データベースのキーとして使えば、ソートせずとも順番に並びますし、書き込む際も順々に書き込めるのでデータアクセスが局所的になります。 今回は簡単に、それぞれのUUIDのフォーマットを眺めていきます。なお、フォーマットは異なりますが、バージョンを示す値は同じ位置にあります。 UUIDv6 UUIDv6は128bit長で、UUIDv1と似てるフォーマットを取ります。 1582年10月15日(グレゴリオ暦)からの100ナノ秒単位で

    時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog
  • Debian JP Project - Debian ポリシーマニュアル - パッケージ間の関連性の宣言

    [ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ] Debian ポリシーマニュアル Chapter 7 - パッケージ間の関連性の宣言 7.1 関係性フィールドの書式 これらのフィールドは統一的な書式を持ちます。 それはコンマで区切られたパッケージ名のリストです。 パッケージの Depends、Recommends、 Suggests、Pre-Depends、Build-Depends 及び Build-Depends-Indep の各コントロールフィールド (他のパッケージに依存関係がある場合に宣言するフィールド) 内に記述するパッケージ

  • VMR9とNV12で嵌る(その3) - Exhaust gas

    かなり間が空いてしまったが、前回の書き込みについて、「何が言いたいのか、よく分からない」と言うメールを受け取ったので、纏めを少し書いておこうと思う。 そもそもの発端は、DXVA1のデインタレース機能の評価を行おうと思って、以下のようなDirectShowフィルタ(以下、ソースフィルタ)を用意すれば良いと考えたことだった。 VMR9に直接接続する。 VMR9に、NV12サーフェス(バッファ)を用意させる。(アロケータはVMR9の物を使う。) NV12サーフェスに、インタレースの画像データを書き込んで、VMR9に表示させる。 ソースフィルタ側で、FPSやフィールドの設定を行えるようにする。 このようなソースフィルタが用意できれば、DXVA1で定義された複数のデインタレースモードで、どのような補間が行われて、出力画像の何が違うのか、確認できるだろうという考えだ。 そういう訳で、「そんなに難しくな

    VMR9とNV12で嵌る(その3) - Exhaust gas
    iww
    iww 2013/11/05
     YUY2とかの解説
  • PNG画像を自力で読む

    このサイトではPNG画像をあちこちで使ってます。 まあ、一番よく使ってるのはJpegですが。 プログラムを組むときも、この二つはよく使われますね。 なんせどちらも無料、かつ使い勝手のいいライブラリ (libpng、libjpeg) が用意されてますし。 てなわけで、普通はPNG画像を自分のプログラムに組み込みたいなら libpng を使えばいいんですが、ちょいと思い立って自力で組んでみることにしました。 D言語ならコードを劇的に減らせますし、MMX化したきゃインラインアセンブラも付いてます。慎重に組めば若干の高速化も期待できるかも。 なによりファイルフォーマットを理解するのは、けっしてマイナスにはなりません。 機能を必要最小限にとどめておけば、たった1,000行程度のコードでPNG画像を読むことが可能ですぞえ。 もっとも実際にネットで配布するようなソフトウェアには安全なライブラリを使った方

  • 1