update post

Author: bitnpc

_posts/2022-06-08-av_into.md

@@ -59,15 +59,53 @@ tags:
 
 上图是 H.264 编码的示意图，每幅图像被分割成 8*8 像素尺寸来编码。
 
+#### 色彩空间
+色彩空间（Color space）是对色彩的组织方式。色彩模型（Color model）是一种抽象数学模型，通过一组数字来描述颜色（例如RGB使用三元组、CMYK使用四元组）。由于“色彩空间”有着固定的色彩模型和映射函数组合，非正式场合下，这一词汇也被用来指代色彩模型。常见的色彩模型包括 `RGB`，`YUV(YCbCr)`，`HSV`，`HSL`，`CMYK` 等。下面我们重点介绍 `YUV` 色彩模型。
+
+`YUV` 是一种表示颜色的模型。但是我们常说的 `YUV` ，其实指的是 `YCbCr`，其中`Y`是指亮度分量，`Cb`指蓝色色度分量，而`Cr`指红色色度分量，是标准 `YUV` 的一个翻版，此文中，我们就用 `YUV` 指代 `YCbCr` 了。
+
+`YUV` 格式按照数据大小分为三个格式，`YUV 420`，`YUV 422`，`YUV 444`。由于人眼对 `Y` 的敏感度远超于对 `U` 和 `V` 的敏感，所以有时候可以多个 `Y` 分量共用一组 UV，这样既可以极大得节省空间，又可以不太损失质量。
+
+- `YUV 420`，由 4 个 `Y` 分量共用一套 `UV` 分量
+- `YUV 422`，由 2 个 `Y` 分量共用一套 `UV` 分量
+- `YUV 444`，不共用，一个 `Y` 分量使用一套 `UV` 分量
+
+在这三种类型之下，我们又可以按照 `YUV` 的排列储存顺序，将其细分为好多种格式。按照 `YUV` 的排列方式，再次将 `YUV` 分成三个大类，`Planar`，`Semi-Planar` 和 `Packed`。
+
+- Planar YUV 三个分量分开存放
+- Semi-Planar Y 分量单独存放，UV 分量交错存放
+- Packed YUV 三个分量全部交错存放
+
+#### 封装格式（Byte Stream Format）
+`H.264` 编码有两种 `Byte Stream Format`，分别是 `AnnexB` 和 `AVCC`。
+
+```
+AnnexB format:
+([start code] NALU) | ( [start code] NALU) |
+AVCC format:
+([extradata]) | ([length] NALU) | ([length] NALU) |
+```
+
+In annexb, [start code] may be 0x000001 or 0x00000001.
+In avcc, the bytes of [length] depends on NALULengthSizeMinusOne in avcc extradata, the value of [length] depends on the size of following NALU and in both annexb and avcc format, the NALUs are no different.
+
+> `Annex B` 多用于网络流媒体中：rtmp、rtp 格式，`AVCC` 多用于文件存储中mp4的格式
+{: .prompt-info }
+
+`H.265` 编码和 `H.264` 不同，其 `Byte Stream Format` 包含 `H.265 Annex B` 和 `H.265 Parameter Sets`
+
 ### 使用 FFmpeg 查看视频文件信息
 我们可以使用 ffmpeg 提供的 ffprobe 工具来查看视频文件信息。
 
 从下图中高亮部分可以看到，该视频文件为 mp4 文件，时长 7.62 秒，码率为 13805 kb/s，包含了 2 条 `Stream`。
 
-其中， Video 使用 `H.264` 编码，色彩空间为 `yuv420`，分辨率为 `1920*1080`，帧率为 `29.97`，
+其中， Video 使用 `H.264` 编码，色彩空间为 `yuv420`，分辨率为 `1080P(1920*1080)`，帧率为 `29.97`，
 
 Audio 使用 `aac` 编码，采样率为 `44.1kHz`，立体声
 
+> 1080p是一种视频分辨率标准，指的是视频的垂直分辨率为1080像素。具体来说，1080p视频的分辨率为1920x1080，其中1920是水平像素数，1080是垂直像素数。字母“p”代表“逐行扫描”（progressive scan）的意思。这意味着视频的每一帧都是通过扫描整个图像的每一行像素来创建的，而不是通过交替扫描奇数和偶数行像素来创建的。与交替扫描的“隔行扫描”（interlaced scan）相比，逐行扫描可以提供更清晰的图像，因为它可以更好地保留运动图像中的细节和清晰度。
+{: .prompt-info }
+
 ![ffprobe_video_info](/assets/img/post/post-2022-06-08/ffprobe_video_info.png){: width="972" height="589" .w-100 .normal}
 
 问题思考：
@@ -80,4 +118,6 @@ Audio 使用 `aac` 编码，采样率为 `44.1kHz`，立体声
 
 参考资料
 - https://www.volcengine.com/docs/6489/72015
+- https://zh.wikipedia.org/zh-cn/%E8%89%B2%E5%BD%A9%E7%A9%BA%E9%96%93
+- https://zhuanlan.zhihu.com/p/384455058
 - ChatGPT

_posts/2023-06-01-app_mach_o.md

@@ -11,11 +11,11 @@ tags:
 
 ## 进程
 
-App 的本质是一个可执行程序，是一段计算机代码和数据的集合。从操作系统的角度来看，App 的本质是一个进程。进程是计算机中正在运行的程序的实例。在操作系统中，进程是操作系统分配资源和调度执行的基本单位。每个进程都有自己的内存空间、寄存器集合、文件句柄、网络连接等资源，它们可以独立地运行和被管理。
+App 的本质是一个可执行程序，是一段计算机代码和数据的集合。从操作系统的角度来看，App 的本质是一个**进程**。进程是计算机中正在运行的程序的实例。在操作系统中，进程是操作系统分配资源和调度执行的基本单位。每个进程都有自己的内存空间、寄存器集合、文件句柄、网络连接等资源，它们可以独立地运行和被管理。
 
-进程是操作系统中最基本的资源分配和调度单位。操作系统通过进程控制块（Process Control Block，PCB）来管理进程，PCB 包含了进程的状态、进程 ID、进程优先级、内存使用情况、文件句柄等信息。当操作系统需要切换到另一个进程时，它会保存当前进程的上下文，然后加载另一个进程的上下文，从而实现进程之间的切换。
+进程是操作系统中最基本的资源分配和调度单位。操作系统通过进程控制块 `PCB(Process Control Block)` 来管理进程，`PCB` 包含了进程的状态、进程 ID、进程优先级、内存使用情况、文件句柄等信息。当操作系统需要切换到另一个进程时，它会保存当前进程的上下文，然后加载另一个进程的上下文，从而实现进程之间的切换。
 
-在 macOS 中，PCB 被称为 proc。[proc 结构体](https://opensource.apple.com/source/xnu/xnu-7195.81.3/bsd/sys/proc_internal.h.auto.html)是 macOS 内核中非常重要的数据结构，用于描述进程在内核中的状态和信息。
+在 `macOS` 中，`PCB` 被称为 `proc`。[proc 结构体](https://opensource.apple.com/source/xnu/xnu-7195.81.3/bsd/sys/proc_internal.h.auto.html)是 `macOS` 内核中非常重要的数据结构，用于描述进程在内核中的状态和信息。
 ``` c
 struct proc {
     LIST_ENTRY(proc) p_list;                /* List of all processes. */
@@ -43,25 +43,25 @@ struct proc {
     /* 以下其他字段已省略 */
 };
 ```
-proc 包含了大量的字段和指针，用于描述进程的各种属性和资源使用情况，例如进程状态（p_stat）、进程 ID（p_pid）、进程名称（p_comm）、进程优先级（p_priority）、进程内存使用情况（p_vmspace）、文件描述符表（p_fd）、线程列表（p_threadlist）等。
+`proc` 包含了大量的字段和指针，用于描述进程的各种属性和资源使用情况，例如进程状态（`p_stat`）、进程 ID（`p_pid`）、进程名称（`p_comm`）、进程优先级（`p_priority`）、进程内存使用情况（`p_vmspace`）、文件描述符表（`p_fd`）、线程列表（`p_threadlist`）等。
 
 ## Mach-O 文件
 
-在 App 加载到内存成为进程之前，macOS 上的可执行文件是 Mach-O 文件。Mach-O 文件包含了可执行代码、数据、符号表、动态链接信息等多个部分，是 macOS 中应用程序和库文件的基本格式。
+在 App 加载到内存成为进程之前，macOS 上的可执行文件是 `Mach-O` 文件。`Mach-O` 文件包含了可执行代码、数据、符号表、动态链接信息等多个部分，是 `macOS` 中应用程序和库文件的基本格式。
 
-Mach-O 文件的格式可以分为文件头（Header）、加载命令（Load commands）和数据区（Raw segment data）三个部分。
+`Mach-O` 文件的格式可以分为文件头（`Header`）、加载命令（`Load commands`）和数据区（`Raw segment data`）三个部分。
 
 ![Mach-O](/assets/img/post/post-2023-06-01/mach_o.png){: width="972" height="589" .w-50 .normal}
 _Mach-O file_
 
-包含多个 CPU 架构的 Mach-O 文件被称为 Fat Binary。可以通过 file 命令查看 Mach-O 文件的 CPU 架构。
+包含多个 CPU 架构的 `Mach-O` 文件被称为 `Fat Binary`。可以通过 `file` 命令查看 `Mach-O `文件的 CPU 架构。
 ``` bash
 $ file /System/Applications/Calculator.app/Contents/MacOS/Calculator
 /System/Applications/Calculator.app/Contents/MacOS/Calculator: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
 /System/Applications/Calculator.app/Contents/MacOS/Calculator (for architecture x86_64):	Mach-O 64-bit executable x86_64
 /System/Applications/Calculator.app/Contents/MacOS/Calculator (for architecture arm64e):	Mach-O 64-bit executable arm64e
 ```
-Fat Binary 对应的 fat_header 在操作系统中的数据结构定义是 [fat_header](https://opensource.apple.com/source/xnu/xnu-7195.81.3/EXTERNAL_HEADERS/mach-o/fat.h.auto.html)。
+`Fat Binary` 对应的 `fat_header` 在操作系统中的数据结构定义是 [**fat_header**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/EXTERNAL_HEADERS/mach-o/fat.h.auto.html)。
 
 ```c
 struct fat_header {
@@ -78,15 +78,15 @@ struct fat_arch {
 };
 ```
 
-可以看到，macOS 系统的计算器程序 Mach-O 文件，是包含了 x86_64 和 arm64e 两种 CPU 架构的 Fat Binary。
-> iOS 系统自 iOS 11.0 版本以后，不再支持 armv7，armv7s 等架构，只支持 arm64 架构。所以仅支持 iOS 11.0 以后版本的项目，打包产物的 Fat Binary 只有 arm64 架构的 Mach-O 文件。这也是 Xcode 14.0 取消了 bitcode 的原因，因为不再需要编译成 bitcode 中间产物，且 bitcode 转译会消耗 AppStore 的服务器资源
+可以看到，macOS 系统的计算器程序 `Mach-O` 文件，是包含了 `x86_64` 和 `arm64e` 两种 CPU 架构的 `Fat Binary`。
+> iOS 系统自 iOS 11.0 版本以后，不再支持 `armv7`，`armv7s` 等架构，只支持 `arm64` 架构。所以仅支持 `iOS 11.0` 以后版本的项目，打包产物的 `Fat Binary` 只有 `arm64` 架构的 `Mach-O` 文件。这也是 `Xcode 14.0` 取消了 `bitcode` 的原因，因为不再需要编译成 `bitcode` 中间产物，且 `bitcode` 转译会消耗 AppStore 的服务器资源
 {: .prompt-tip }
 
 ### 文件头（haeder）
 
-Mach-O 文件头包含了文件类型、CPU 类型、加载命令数量等信息。Mach-O 文件支持多种文件类型，包括可执行文件、动态链接库、框架等。CPU 类型指定了可执行文件适用的 CPU 架构，例如 x86、x86_64、armv7、arm64 等。加载命令数量指定了文件中包含的加载命令数量。
+`Mach-O` 文件头包含了文件类型、CPU 类型、加载命令数量等信息。`Mach-O` 文件支持多种文件类型，包括可执行文件、动态链接库、框架等。CPU 类型指定了可执行文件适用的 CPU 架构，例如 `x86`、`x86_64`、`armv7`、`arm64` 等。加载命令数量指定了文件中包含的加载命令数量。
 
-`otool` 命令是 macOS 和 iOS 等操作系统上的一个工具，用于查看可执行文件、动态库和框架等二进制文件的信息。它可以用来查看二进制文件的头部信息、节表、符号表、动态链接信息等。
+`otool` 命令是 `macOS` 和 `iOS` 等操作系统上的一个工具，用于查看可执行文件、动态库和框架等二进制文件的信息。它可以用来查看二进制文件的头部信息、节表、符号表、动态链接信息等。
 
 ```bash
 $ otool -h /System/Applications/Calculator.app/Contents/MacOS/Calculator
@@ -96,15 +96,15 @@ Mach header
  0xfeedfacf 16777228          2  0x80           2    29       4208 0x00200085
 ```
 
-除了 `otools` 命令，还可以使用 MachOView 工具通过图形化页面来查看 Mach-O 文件
+除了 `otools` 命令，还可以使用 `MachOView` 工具通过图形化页面来查看 `Mach-O` 文件
 ```bash
 brew install machoview
 ```
 ![MachOView](/assets/img/post/post-2023-06-01/machoview.png){: width="972" height="589" .w-100 .normal}
 _MachOView_
 
 
-Fat Binary 中，每个架构都有一个 header 文件头，被称为 [mach_header](https://opensource.apple.com/source/xnu/xnu-7195.81.3/EXTERNAL_HEADERS/mach-o/loader.h.auto.html)。64 位架构的 mach_header 会多一个保留字段。
+`Fat Binary` 中，每个架构都有一个 `header` 文件头，被称为 [**mach_header**](https://opensource.apple.com/source/xnu/xnu-7195.81.3/EXTERNAL_HEADERS/mach-o/loader.h.auto.html)。64 位架构的 `mach_header` 会多一个保留字段。
 ```c
 /*
  * The 32-bit mach header appears at the very beginning of the object file for
@@ -142,11 +142,11 @@ struct mach_header_64 {
 ```
 ## 加载命令（Load commands）
 
-Mach-O 文件中的加载命令（Load Command）用于描述可执行文件的各个段的属性和位置等信息，操作系统会根据这些信息将可执行文件加载到内存中。每个 Load Command 描述了一个特定的段或区域。常见的 Load Command 包括：
-- LC_SEGMENT 和 LC_SEGMENT_64：描述可执行代码和数据的段信息；
-- LC_SYMTAB 和 LC_DYSYMTAB：描述符号表和动态符号表信息；
-- LC_LOAD_DYLIB 和 LC_LOAD_WEAK_DYLIB：描述动态链接库的信息；
-- LC_MAIN：描述程序入口点的信息。
+`Mach-O` 文件中的加载命令（`Load Command`）用于描述可执行文件的各个段的属性和位置等信息，操作系统会根据这些信息将可执行文件加载到内存中。每个 `Load Command` 描述了一个特定的段或区域。常见的 `Load Command` 包括：
+- `LC_SEGMENT` 和 `LC_SEGMENT_64`：描述可执行代码和数据的段信息；
+- `LC_SYMTAB` 和 `LC_DYSYMTAB`：描述符号表和动态符号表信息；
+- `LC_LOAD_DYLIB` 和 `LC_LOAD_WEAK_DYLIB`：描述动态链接库的信息；
+- `LC_MAIN`：描述程序入口点的信息。
 
 [load_command](https://opensource.apple.com/source/xnu/xnu-7195.81.3/EXTERNAL_HEADERS/mach-o/loader.h.auto.html)
 
@@ -159,7 +159,7 @@ struct load_command {
 
 ## 数据区（Raw segment data）
 
-Mach-O 文件的数据区包含了多个段（Segment），每个段包含了不同类型的数据。常见的段包括 __TEXT、__DATA、__LINKEDIT 等。其中，__TEXT 段包含了代码和只读数据，__DATA 段包含了全局变量和静态变量等数据，__LINKEDIT 段包含了符号表和重定位信息等。
+`Mach-O` 文件的数据区包含了多个段（`Segment`），每个段包含了不同类型的数据。常见的段包括 `__TEXT`、`__DATA`、`__LINKEDIT` 等。其中，`__TEXT` 段包含了代码和只读数据，`__DATA` 段包含了全局变量和静态变量等数据，`__LINKEDIT` 段包含了符号表和重定位信息等。
 
 [segment](https://opensource.apple.com/source/xnu/xnu-7195.81.3/EXTERNAL_HEADERS/mach-o/loader.h.auto.html)
 ```c
@@ -178,9 +178,9 @@ struct segment_command_64 { /* for 64-bit architectures */
 };
 ```
 
-在 Mach-O 文件中，每个 Segment 包含一个或多个 section，每个 section 包含了一组相关的数据或代码。例如，在一个可执行文件中，常见的 Segment 包括 __TEXT、__DATA、__LINKEDIT 等，每个 Segment 包含了多个 section，例如 __TEXT 包含了 __text、__cstring、__stub 等多个 section。
+在 `Mach-O` 文件中，每个 `Segment` 包含一个或多个 `section`，每个 `section` 包含了一组相关的数据或代码。例如，在一个可执行文件中，常见的 `Segment` 包括 __TEXT、`__DATA`、`__LINKEDIT` 等，每个 `Segment` 包含了多个 `section`，例如 `__TEXT` 包含了 `__text`、`__cstring`、`__stub` 等多个 `section`。
 
-Section 是 Mach-O 文件中的一个子单元，它是 Segment 中的一个子段，包含了一组相关的数据或代码。每个 Section 都有一个名称和一个类型，例如 __text、__data、__cstring 等。在 Mach-O 文件中，Section 的名称和类型通常与编译器和链接器相关，不同的编译器和链接器可能会使用不同的名称和类型。
+`Section` 是 `Mach-O` 文件中的一个子单元，它是 `Segment` 中的一个子段，包含了一组相关的数据或代码。每个 `Section` 都有一个名称和一个类型，例如 `__text`、`__data`、`__cstring` 等。在 `Mach-O` 文件中，`Section` 的名称和类型通常与编译器和链接器相关，不同的编译器和链接器可能会使用不同的名称和类型。
 
 ```c
 struct section_64 { /* for 64-bit architectures */