‘壹’ ffmpeg-python中文文档（三）——API参考
表示上游节点的传出边缘；可以用来创建更多的下游节点。
输入文件 URL （ffmpeg -i option）
在一个 ffmpeg 命令行中包含所有给定的输出
输出文件地址
不询问就覆盖输出文件（ffmpeg -y 选项）
在指定文件上运行 ffprobe 并返回输出的 JSON 表示。
构建用于调用 ffmpeg 的命令行。
构建要传递给 ffmpeg 的命令行参数。
为提供的节点图调用 ffmpeg 。
参数
为提供的节点图异步调用 ffmpeg。
参数
例子
运行和流式输入：
运行并捕获输出：
使用 numpy 逐帧处理视频：
通过重新混合颜色通道来调整视频输入帧。
连接音频和视频流，将它们一个接一个地连接在一起。
筛选器适用于同步视频和音频流的片段。所有段必须具有每种类型的相同数量的流，这也是输出时的流数。
参数
裁剪输入视频。
参数
在输入图像上绘制一个彩色框。
参数
使用 libfreetype 库从视频顶部的指定文件中绘制文本字符串或文本。
要启用此过滤器的编译，您需要使用 --enable-libfreetype . 要启用默认字体回退和字体选项，您需要使用 --enable-libfontconfig . 要启用 text_shaping 选项，您需要使用 --enable-libfribidi
参数
· box - 用于使用背景颜色在文本周围绘制一个框。该值必须是 1（启用）或 0（禁用）。框的默认值为 0。
· boxborderw – 使用 boxcolor 设置要在框周围绘制的边框宽度。boxborderw 的默认值为 0。
· boxcolor - 用于在文本周围绘制框的颜色。有关此选项的语法，请查看 ffmpeg-utils 手册中的“颜色”部分。 boxcolor 的默认值为“white”。
· line_spacing – 使用 box 设置要在框周围绘制的边框的行间距（以像素为单位）。line_spacing 的默认值为 0。
· borderw – 使用边框颜色设置要在文本周围绘制的边框宽度。边框的默认值为 0。
· bordercolor – 设置用于在文本周围绘制边框的颜色。有关此选项的语法，请查看 ffmpeg-utils 手册中的“颜色”部分。边框颜色的默认值为“黑色”。
· 扩展- 选择文本的扩展方式。可以是 none、strftime（已弃用）或 normal（默认）。有关详细信息，请参阅下面的文本扩展部分。
· basetime – 设置计数的开始时间。值以微秒为单位。仅适用于已弃用的 strftime 扩展模式。要在正常扩展模式下进行模拟，请使用 pts 函数，提供开始时间（以秒为单位）作为第二个参数。
· fix_bounds - 如果为 true，检查并修复文本坐标以避免剪切。
· fontcolor - 用于绘制字体的颜色。有关此选项的语法，请查看 ffmpeg-utils 手册中的“颜色”部分。fontcolor 的默认值为“黑色”。
· fontcolor_expr – 与文本相同的扩展字符串以获得动态字体颜色值。默认情况下，此选项具有空值并且不被处理。设置此选项时，它会覆盖 fontcolor 选项。
· font - 用于绘制文本的字体系列。默认情况下无。
· fontfile – 用于绘制文本的字体文件。必须包含路径。如果禁用了 fontconfig 支持，则此参数是必需的。
· alpha – 绘制应用 alpha 混合的文本。该值可以是介于 0.0 和 1.0 之间的数字。该表达式也接受相同的变量 x、y。默认值为 1。请参阅 fontcolor_expr。
· fontsize – 用于绘制文本的字体大小。字体大小的默认值为 16。
· text_shaping – 如果设置为 1，则在绘制文本之前尝试对文本进行整形（例如，反转从右到左文本的顺序并加入阿拉伯字符）。否则，只需按照给定的方式绘制文本。默认为 1（如果支持）。
· ft_load_flags –用于加载字体的标志。这些标志映射了 libfreetype 支持的相应标志，并且是以下值的组合：
默认值为“默认”。有关更多信息，请参阅 FT_LOAD_* libfreetype 标志的文档。
· shadowcolor – 用于在已绘制文本后面绘制阴影的颜色。有关此选项的语法，请查看 ffmpeg-utils 手册中的“颜色”部分。shadowcolor 的默认值为“黑色”。
· shadowx – 文本阴影位置相对于文本位置的 x 偏移量。它可以是正值或负值。默认值为“0”。
· shadowy – 文本阴影位置相对于文本位置的 y 偏移量。它可以是正值或负值。默认值为“0”。
· start_number – n/frame_num 变量的起始帧号。默认值为“0”。
· tabsize - 用于呈现选项卡的空格数大小。默认值为 4。
· timecode – 以“hh:mm:ss[:;.]ff”格式设置初始时间码表示。它可以带或不带文本参数使用。必须指定 timecode_rate 选项。
· rate – 设置时间码帧率（仅限时间码）。
· timecode_rate – 的别名rate。
· r – 的别名rate。
· tc24hmax – 如果设置为 1，时间码选项的输出将在 24 小时左右回绕。默认值为 0（禁用）。
· text -- 要绘制的文本字符串。文本必须是 UTF-8 编码字符序列。如果没有使用参数 textfile 指定文件，则此参数是必需的。
· textfile – 包含要绘制的文本的文本文件。文本必须是 UTF-8 编码字符序列。如果没有使用参数 text 指定文本字符串，则此参数是必需的。如果同时指定了 text 和 textfile，则会引发错误。
· reload – 如果设置为 1，文本文件将在每一帧之前重新加载。一定要自动更新它，否则它可能会被部分读取，甚至失败。
· x – 指定将在视频帧内绘制文本的偏移量的表达式。它相对于输出图像的左边框。默认值为“0”。
· y - 指定将在视频帧内绘制文本的偏移量的表达式。它相对于输出图像的上边框。默认值为“0”。有关接受的常量和函数的列表，请参见下文。
表达式常量：
x 和 y 的参数是包含以下常量和函数的表达式：
· dar：输入显示纵横比，同 (w / h) * sar
· hsub：水平色度子样本值。例如，对于像素格式“yuv422p”，hsub 为 2，vsub 为 1。
· vsub：垂直色度子样本值。例如，对于像素格式“yuv422p”，hsub 为 2，vsub 为 1。
· line_h：每个文本行的高度
· lh：别名为line_h.
· main_h：输入高度
· h: 的别名main_h。
· H： 的别名main_h。
· main_w：输入宽度
· w: 的别名main_w。
· W： 的别名main_w。
· ascent：对于所有渲染的字形，从基线到用于放置字形轮廓点的最高/上网格坐标的最大距离。这是一个正值，因为网格的 Y 轴向上。
· max_glyph_a: 的别名ascent。
· 下降：对于所有渲染的字形，从基线到用于放置字形轮廓点的最低网格坐标的最大距离。由于网格的方向，这是一个负值，Y 轴向上。
· max_glyph_d: 的别名descent。
· max_glyph_h：最大字形高度，即渲染文本中包含的所有字形的最大高度，相当于上升-下降。
· max_glyph_w：最大字形宽度，即渲染文本中包含的所有字形的最大宽度。
· n：输入帧数，从0开始
· rand(min, max)：返回一个包含在 min 和 max 之间的随机数
· sar：输入样本纵横比。
· t：时间戳，以秒为单位，如果输入时间戳未知，则为 NAN
· text_h：渲染文本的高度
· th： 的别名text_h。
· text_w：渲染文本的宽度
· tw: 的别名text_w。
· x：绘制文本的 x 偏移坐标。
· y：绘制文本的 y 偏移坐标。
这些参数允许 x 和 y 表达式相互引用，因此您可以例如指定 y=x/dar.
应用自定义过滤器。
filter通常由更高级别的过滤器函数使用，例如 hflip ，但如果缺少过滤器实现 ffmpeg-python ，您可以 filter 直接调用以 ffmpeg-python 将过滤器名称和参数逐字传递给 ffmpeg 。
参数
函数名称后缀_是为了避免与标准 pythonfilter 函数混淆。
例子
替代名称 filter ，以免与内置的 pythonfilter 运算符冲突。
应用具有一个或多个输出的自定义过滤器。
这 filter 与过滤器可以产生多个输出相同。
要引用输出流，请使用 .stream 运算符或括号简写：
例子
水平翻转输入视频。
修改输入的色调和/或饱和度。
参数
将一个视频叠加在另一个视频之上。
参数
更改输入帧的 PTS（表示时间戳）。
FFmpeg里有两种时间戳：DTS（Decoding Time Stamp）和PTS（Presentation Time Stamp）。 顾名思义，前者是解码的时间，后者是显示的时间。
参数
修剪输入，使输出包含输入的一个连续子部分。
参数
垂直翻转输入视频。
应用缩放和平移效果。
参数
‘贰’ python 怎么获取mp4的分辨率
获得H.264视频分辨率的方法
From: http //www cnblogs.com/likwo/p/3531241.html
在使用ffmpeg解码播放TS流的时候（例如之前写过的UDP组播流），在连接时往往需要耗费大量时间。经过debug发现是av_find_stream_info（已抛弃，现在使用的是avformat_find_stream_info）这个方法十分耗时，而且是阻塞的。av_find_stream_info方法主要是获得相应的流信息，其中对我的应用最有用的就是视频的分辨率。在av_find_stream_info中是要不断的读取数据包，解码获得相应的信息，而其中除了分辨率信息以外的东西对我的应用中是无用的。所以，考虑自己手动从H.264码流中解析出视频的分辨率信息。
以下内容主要参考了这篇文章：http //www myexception.cn/internet/586390.html
H.264码流的流信息都存储在了特殊的结构中，叫做SPS(Sequence Parameter Set)。要解析SPS就需要知道一些H.264码流的格式信息。
在H.264码流中，都是以0x00 0x00 0x01 或者 0x00 0x00 0x00 0x01为开始码的（在我的应用中为后者），之后通过检测开始码后第一个字节的后五位是否为7（00111）来判断其是否为SPS。得到SPS之后，就可以解析出视频的分辨率。SPS中有两个成员，pic_width_in_mbs_minus1和pic_height_in_map_units_minus_1，分别表示图像的宽和高，但是要注意的是它们都是以16为单位（在面积上就是以16*16的块为单位）再减1，所以实际的宽是(pic_width_in_mbs_minus1 + 1)*16，高为(pic_height_in_map_units_minus_1+1)*16。
欢迎转载，转载请注明出处：http //guoyb.com/Tech/34.html
以下是解析宽高的代码：
转载http //guoyb.com/Tech/34.html
以下部分 转自 http //blog.csdn.NET/pkueecser/article/details/7367641
使用RTP传输H264的时候,需要用到sdp协议描述,其中有两项:Sequence Parameter Sets (SPS) 和Picture Parameter Set (PPS)需要用到,那么这两项从哪里获取呢?答案是从H264码流中获取.在H264码流中,都是以"0x00 0x00 0x01"或者"0x00 0x00 0x00 0x01"为开始码的,找到开始码之后,使用开始码之后的第一个字节的低5位判断是否为7(sps)或者8(pps), 及data[4] & 0x1f == 7 || data[4] & 0x1f == 8.然后对获取的nal去掉开始码之后进行base64编码,得到的信息就可以用于sdp.sps和pps需要用逗号分隔开来.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
如何解析SDP中包含的H.264的SPS和PPS串
http //www pernet.tv.sixxs.org/thread-109-1-1.html
SDP中的H.264的SPS和PPS串，包含了初始化H.264解码器所需要的信息参数，包括编码所用的profile，level，图像的宽和高，deblock滤波器等。
由于SDP中的SPS和PPS都是BASE64编码形式的，不容易理解，附件有一个工具软件可以对SDP中的SPS和PPS进行解析。
用法是在命令行中输入：
spsparser sps.txt pps.txt output.txt
例如sps.txt中的内容为：
Z0LgFNoFglE=
pps.txt中的内容为：
aM4wpIA=
最终解析的到的结果为：
Start mping SPS:
profile_idc = 66
constrained_set0_flag = 1
constrained_set1_flag = 1
constrained_set2_flag = 1
constrained_set3_flag = 0
level_idc = 20
seq_parameter_set_id = 0
chroma_format_idc = 1
bit_depth_luma_minus8 = 0
bit_depth_chroma_minus8 = 0
seq_scaling_matrix_present_flag = 0
log2_max_frame_num_minus4 = 0
pic_order_cnt_type = 2
log2_max_pic_order_cnt_lsb_minus4 = 0
delta_pic_order_always_zero_flag = 0
offset_for_non_ref_pic = 0
offset_for_top_to_bottom_field = 0
num_ref_frames_in_pic_order_cnt_cycle = 0
num_ref_frames = 1
gaps_in_frame_num_value_allowed_flag = 0
pic_width_in_mbs_minus1 = 21
pic_height_in_mbs_minus1 = 17
frame_mbs_only_flag = 1
mb_adaptive_frame_field_flag = 0
direct_8x8_interence_flag = 0
frame_cropping_flag = 0
frame_cropping_rect_left_offset = 0
frame_cropping_rect_right_offset = 0
frame_cropping_rect_top_offset = 0
frame_cropping_rect_bottom_offset = 0
vui_parameters_present_flag = 0
Start mping PPS:
pic_parameter_set_id = 0
seq_parameter_set_id = 0
entropy_coding_mode_flag = 0
pic_order_present_flag = 0
num_slice_groups_minus1 = 0
slice_group_map_type = 0
num_ref_idx_l0_active_minus1 = 0
num_ref_idx_l1_active_minus1 = 0
weighted_pref_flag = 0
weighted_bipred_idc = 0
pic_init_qp_minus26 = 0
pic_init_qs_minus26 = 0
chroma_qp_index_offset = 10
deblocking_filter_control_present_flag = 1
constrained_intra_pred_flag = 0
rendant_pic_cnt_present_flag = 0
transform_8x8_mode_flag = 0
pic_scaling_matrix_present_flag = 0
second_chroma_qp_index_offset = 10
/////////////////////////////////////////////////////////////////////////////////////////////////
这里需要特别提一下这两个参数
pic_width_in_mbs_minus1 = 21
pic_height_in_mbs_minus1 = 17
分别表示图像的宽和高，以宏块（16x16）为单位的值减1
因此，实际的宽为 (21+1)*16 = 352
spsparser.rar
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
http //krdai.info.sixxs.org/blog/mp4-sps-pps-data.html
最近在做跟 h264 encode/decode 相关的研究，目标是希望可以从 Android 的 MediaRecorder 当中取出 h264 的资讯。目前问题是在于 SPS 以及 PPS 到底要怎样得到。由于 MediaRecorder 是写入 mp4 档案中，所以不得已只好来去分析一下 mp4 的档案格式，发现没有想象中的困难. 主要是参照 ISO/IEC 14496-15 这部份. 在 mp4 的档案之中, 找到 avcC 这个字串, 之后就是接上 AVCDecoderConfigurationRecord. AVCDecoderConfigurationRecord 的 format 如下:
aligned(8) class AVCDecoderConfigurationRecord {
unsigned int(8) configurationVersion = 1;
unsigned int(8) AVCProfileIndication;
unsigned int(8) profile_compatibility;
unsigned int(8) AVCLevelIndication;
bit(6) reserved = '111111'b;
unsigned int(2) lengthSizeMinusOne;
bit(3) reserved = '111'b;
unsigned int(5) numOfSequenceParameterSets;
for (i=0; i< numOfSequenceParameterSets; i++) {
unsigned int(16) sequenceParameterSetLength ;
bit(8*sequenceParameterSetLength) sequenceParameterSetNALUnit;
}
unsigned int(8) numOfPictureParameterSets;
for (i=0; i< numOfPictureParameterSets; i++) {
unsigned int(16) pictureParameterSetLength;
bit(8*pictureParameterSetLength) pictureParameterSetNALUnit;
}
}
对照一下这样就可以找到 SPS 和 PPS
+++++++++++++++++++++++++++++++++++++++++++++
vlc没有收到pps和sps
2010-10-08 16:16
问题 packetizer_h264 packetizer warning: waiting for SPS/PPS
是因为解码器只是在第一次执行编码的时候，才编码出 SPS、PPS、和I_Frame；
h264 packetizer has set so, that it sends sps/pps only first keyframe,
I'm trying to figure what breaks if that is changed so sps/pps is written in every keyframe.
[出自| http //trac.videolan.org/vlc/ticket/1384]
解决办法：
1、编码器编码出每个关键帧都加上SPS、PPS ，据说通常情况编码器编出的 SPS、PPS是一样的，所以这种方法耗费资源。
2、在服务器接收到客户端请求时，发送第一个package 加上 SPS、PPS。
具体如下：
1、在 VideoOpenFileSource 添加一个变量 isFirstFrame；
2、构造时初始化 isFirstFrame = true;
3、在int VideoOpenFileSource::readFromBufferChain() 修改如下：
1 if(isFirstFrame == true)
2 {
3 memcpy(fTo, h264_header, sizeof(h264_header)); /* h264_header = pps +sps*/
4 offset = sizeof(h264_header);
5 framesize = BufferChain_get(fInput.video_bufs, fTo + offset);
6 offset += framesize;
7 isFirstFrame = false;
8 printf("this is the first fime\n");
9 sleep(1);
10 }
11 else
12 {
13 framesize = BufferChain_get(fInput.video_bufs, fTo + offset);
14 offset += framesize;
15 }
1
[http //topic.csdn.net/u/20100801/17/ef35e664-92ff-4144-a35f-3984dcf11da3.html| 参考]
========================================================================
sdp 关于pps和sps的疑问：
packetization-mode 主要是定义包的模式，单一 NALU单元模式（0）；非交错(non-interleaved)封包模式（1）；交错(interleaved)封包模式（2）
sprop-parameter-sets 等于H.264 的序列参数集和图像参数 NAL单元，base64转换；（即＝ sps+pps）
profile-level-id 这个参数用于指示 H.264 流的 profile 类型和级别。这知道这个是啥东东
ffmpeg decode 关于pps sps问题：
stackoverflow.com/questions/3493742/problem-to-decode-h264-video-over-rtp-with-ffmpeg-libavcodec/3500432#3500432
如何用C语言取出H.264ES文件里的nal(sps,pps)信息。比如width, height, profile等等
请高手指点指点。。。 http //www oschina.net/question/225813_35707
解析sps,pps的代码在ffmpeg里面就有, 抄出来就行了, 我以前也自己写过...
ffmpeg的libavcodec/h264_parser.c,
h264_ps.c
函数
ff_h264_decode_seq_parameter_set
ff_h264_decode_picture_parameter_set
自己可以看代码.
H264参数语法文档： SPS、PPS、IDR http //blog.csdn.net/heanyu/article/details/6205390
H.264码流第一个 NALU 是 SPS（序列参数集Sequence Parameter Set）
对应H264标准文档 7.3.2.1 序列参数集的语法进行解析
‘叁’ 基于Python快速整理微信视频与图片
作为超级APP，微信已经成了移动互联网的入口。而我们也早已习惯通过微信收发图片与视频等多媒体文件。身为一名屌丝通信狗，经常出差海外，跟家人的沟通方式主要就靠微信了，每当累了或抑郁了，银早打开微信看看媳妇儿和孩子的视频照片，就觉得开心多了。最终，微信变得越来越臃肿，视频与图片也必须早点保存到手机或锋亮雀者电脑。但是最终导出的文件命名是让人相当崩溃的。。。
是能忍 孰不能忍 ，作为一名有(xia)抱(zhe)负(teng)的屌丝，是绝不能容忍这么杂乱的文件命名的，也绝不可能因此就对这些文件逐一手动重命名的。
作为批量处理文件的利器，当然非Python莫属了，而且有一堆优质库可供调用，基本搜索一下能解决90%需求。对于这个需求初始想法是直接通过os库获取文件的创始时间，依此来重新命名文件，可是最终发现os库获取的是文件第一次拷贝到系统的时间，并非文件的初始创建时间。比如，2016-09-10日19：00：23拷贝2016-06-16日10：00：00拍摄的视频文件到系统硬盘，系键拆统就记录其时间为2016-09-10日19：00：23，并非6月16日。
上网搜了很久，发现使用exif与ffmpeg可以分别对照片与视频提取初始创建时间：
Exif是用来存储数码照片的属性信息与拍摄数据的，可以附加于JPEG、TIFF、RIFF等文件之中，为其增加有关数码相机拍摄信息的内容和索引图或图像处理软件的版本信息 。
使用exif工具查询当前目录下的pic1.png文件可以得到如下信息：
MacBook:BaiYun meixuhong$ exif -i pic1.png
显然获取到照片拍摄时间为2016:03:08 21:22:46。
ffmpeg自然不用多说，一款开源的牛逼哄哄的绝大多数开发者与公司都在用的音频解码软件。使用它解析视频文件自然也不在话下。如使用它解析1.mov文件，则会输出如下信息：
MacBook:BaiYun meixuhong$ ffmpeg -i 1.mov
获取到视频文件拍摄于2016-07-10 09:36:54。
这俩工具当然无懈可击，可是要想用python解析的话就得使用进程调用它们，而且只能将输出结果保存在文本中，那如果有300个文件就得要输出300个文本文件，很复杂，显然不是我要的结果，需要换思路。
Hachoir is a Python library to view and edit a binary stream field by field. In other words, Hachoir allows you to “browse” any binary stream just like you browse directories and files.
即是说使用Hachoir可以直接查看文件的二进制文件，提取文件的 metadata 即可获取到数码照片与视频的初始创建时间了。
实现过程到还是到我的项目主页 Github 一览吧。
执行完Python脚本，再来看各个文件名，以具体拍照时间格式严格命名并排序，感觉整个世界瞬间变得美好了。
‘肆’ python拼接视频不渲染
您要问的是python拼接视频不渲染怎么办吗？确枯锋认视频编码格式、添加必要的视频流参数、确认视频分辨率、帧率等参数。
1、确认视频编码格式：拼接视频时，需要确保所有视频的编码格式相同，否则会导致视频不渲染的问题。
2、添加必要的视频流参数：视频编码格式需要添加必没铅晌要的视频流参数，以便正确解码和渲染视频。
3、确认视频分辨率、帧率等参数：拼接视频时，需要确保所有视频的分辨率、帧率等参数相同，否则会导致视频不渲染的激念问题。
‘伍’ Python文件处理里encoding和encode有事区别，bytes类型是什么意思
python问题我来回答你。
首先你要知道的是，字符串在Python内部的表示是unicode(统一码、万国码)编码，很多编程语言都是这么设计的，各个国家通用编码，因此，在做编码转换时，通常需要以unicode作为中间编码，即先将其他编码的字符串解码（decode）成unicode，再从unicode编码（encode）成另一种编码。
decode的作用是将其他编码的字符串转换成unicode编码，如str1.decode('gb2312')，表示将gb2312编码的字符串str1转换成unicode编码。
encode的作用是将unicode编码转换成其他编码的字符串，如str2.encode('gb2312')，表示将unicode编码的字符串str2转换成gb2312编码。
因此，转码的时候一定要先搞明白，字符串str是什么编码，然后decode成unicode，然后再encode成其他编码。
bytes类型是 Python 3.x版本新增的数据类型，在 Python 2.x 中是不存在的。字符串是以字符为单位进行处理的，bytes类型是以字节为单位处理的。
bytes 只负责以字节序列的形式（二进制形式）来存储数据，至于这些数据到底表示什么内容（字符串、数字、图片、音频等），完全由程序的解析方式决定。
说白了，bytes 只是简单地记录内存中的原始数据，至于如何使用这些数据，bytes 并不在意，你想怎么使用就怎么使用，bytes 并不约束你的行为。
bytes 类型的数据非常适合在互联网上传输，可以用于网络通信编程；bytes 也可以用来存储图片、音频、视频等二进制格式的文件。
举个例子：
b = b'' # 创建一个空的bytes
b = byte() # 创建一个空的bytes
b = b'hello' # 直接指定这个hello是bytes类型
b = bytes('string',encoding='编码类型') #利用内置bytes方法，将字符串转换为指定编码的bytes
b = str.encode('编码类型') # 利用字符串的encode方法编码成bytes，默认为utf-8类型
bytes.decode('编码类型')：将bytes对象解码成字符串，默认使用utf-8进行解码。
‘陆’ 一篇文章带你深度解析Python线程和进程
使用Python中的线程模块，能够同时运行程序的不同部分，并简化设计。如果你已经入门Python，并且想用线程来提升程序运行速度的话，希望这篇教程会对你有所帮助。
线程与进程
什么是进程
进程是系统进行资源分配和调度的一个独立单位 进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位。每个进程都有自己的独立内存空间，不同进程通过进程间通信来通信。由于进程比较重量，占据独立的内存，所以上下文进程间的切换开销（栈、寄存器、虚拟内存、文件句柄等）比较大，但相对比较稳定安全。
什么是线程
CPU调度和分派的基本单位 线程是进程的一个实体，是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位.线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。线程间通信主要通过共享内存，上下文切换很快，资源开销较少，但相比进程不够稳定容易丢失数据。
进程与线程的关系图
线程与进程的区别：
进程
现实生活中，有很多的场景中的事情是同时进行的，比如开车的时候 手和脚共同来驾驶 汽车 ，比如唱歌跳舞也是同时进行的，再比如边吃饭边打电话；试想如果我们吃饭的时候有一个领导来电，我们肯定是立刻就接听了。但是如果你吃完饭再接听或者回电话，很可能会被开除。
注意：
多任务的概念
什么叫 多任务 呢？简单地说，就是操作系统可以同时运行多个任务。打个比方，你一边在用浏览器上网，一边在听MP3，一边在用Word赶作业，这就是多任务，至少同时有3个任务正在运行。还有很多任务悄悄地在后台同时运行着，只是桌面上没有显示而已。
现在，多核CPU已经非常普及了，但是，即使过去的单核CPU，也可以执行多任务。由于CPU执行代码都是顺序执行的，那么，单核CPU是怎么执行多任务的呢？
答案就是操作系统轮流让各个任务交替执行，任务1执行0.01秒，切换到任务2，任务2执行0.01秒，再切换到任务3，执行0.01秒，这样反复执行下去。表面上看，每个任务都是交替执行的，但是，由于CPU的执行速度实在是太快了，我们感觉就像所有任务都在同时执行一样。
真正的并行执行多任务只能在多核CPU上实现，但是，由于任务数量远远多于CPU的核心数量，所以，操作系统也会自动把很多任务轮流调度到每个核心上执行。 其实就是CPU执行速度太快啦！以至于我们感受不到在轮流调度。
并行与并发
并行（Parallelism）
并行：指两个或两个以上事件（或线程）在同一时刻发生，是真正意义上的不同事件或线程在同一时刻，在不同CPU资源呢上（多核），同时执行。
特点
并发（Concurrency）
指一个物理CPU(也可以多个物理CPU) 在若干道程序（或线程）之间多路复用，并发性是对有限物理资源强制行使多用户共享以提高效率。
特点
multiprocess.Process模块
process模块是一个创建进程的模块，借助这个模块，就可以完成进程的创建。
语法：Process([group [, target [, name [, args [, kwargs]]]]])
由该类实例化得到的对象，表示一个子进程中的任务（尚未启动）。
注意：1. 必须使用关键字方式来指定参数；2. args指定的为传给target函数的位置参数，是一个元祖形式，必须有逗号。
参数介绍：
group：参数未使用，默认值为None。
target：表示调用对象，即子进程要执行的任务。
args：表示调用的位置参数元祖。
kwargs：表示调用对象的字典。如kwargs = {'name':Jack, 'age':18}。
name：子进程名称。
代码：
除了上面这些开启进程的方法之外，还有一种以继承Process的方式开启进程的方式：
通过上面的研究，我们千方百计实现了程序的异步，让多个任务可以同时在几个进程中并发处理，他们之间的运行没有顺序，一旦开启也不受我们控制。尽管并发编程让我们能更加充分的利用IO资源，但是也给我们带来了新的问题。
当多个进程使用同一份数据资源的时候，就会引发数据安全或顺序混乱问题，我们可以考虑加锁，我们以模拟抢票为例，来看看数据安全的重要性。
加锁可以保证多个进程修改同一块数据时，同一时间只能有一个任务可以进行修改，即串行的修改。加锁牺牲了速度，但是却保证了数据的安全。
因此我们最好找寻一种解决方案能够兼顾：1、效率高（多个进程共享一块内存的数据）2、帮我们处理好锁问题。
mutiprocessing模块为我们提供的基于消息的IPC通信机制：队列和管道。队列和管道都是将数据存放于内存中 队列又是基于（管道+锁）实现的，可以让我们从复杂的锁问题中解脱出来， 我们应该尽量避免使用共享数据，尽可能使用消息传递和队列，避免处理复杂的同步和锁问题，而且在进程数目增多时，往往可以获得更好的可获展性（ 后续扩展该内容 ）。
线程
Python的threading模块
Python 供了几个用于多线程编程的模块，包括 thread, threading 和 Queue 等。thread 和 threading 模块允许程序员创建和管理线程。thread 模块 供了基本的线程和锁的支持，而 threading 供了更高级别，功能更强的线程管理的功能。Queue 模块允许用户创建一个可以用于多个线程之间 共享数据的队列数据结构。
python创建和执行线程
创建线程代码
1. 创建方法一:
2. 创建方法二:
进程和线程都是实现多任务的一种方式，例如：在同一台计算机上能同时运行多个QQ（进程),一个QQ可以打开多个聊天窗口（线程）。资源共享：进程不能共享资源，而线程共享所在进程的地址空间和其他资源，同时，线程有自己的栈和栈指针。所以在一个进程内的所有线程共享全局变量，但多线程对全局变量的更改会导致变量值得混乱。
代码演示:
得到的结果是：
首先需要明确的一点是GIL并不是Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。就好比C++是一套语言（语法）标准，但是可以用不同的编译器来编译成可执行代码。同样一段代码可以通过CPython，PyPy，Psyco等不同的Python执行环境来执行（其中的JPython就没有GIL）。
那么CPython实现中的GIL又是什么呢？GIL全称Global Interpreter Lock为了避免误导，我们还是来看一下官方给出的解释：
主要意思为:
因此，解释器实际上被一个全局解释器锁保护着，它确保任何时候都只有一个Python线程执行。在多线程环境中，Python 虚拟机按以下方式执行:
由于GIL的存在，Python的多线程不能称之为严格的多线程。因为 多线程下每个线程在执行的过程中都需要先获取GIL，保证同一时刻只有一个线程在运行。
由于GIL的存在，即使是多线程，事实上同一时刻只能保证一个线程在运行， 既然这样多线程的运行效率不就和单线程一样了吗，那为什么还要使用多线程呢？
由于以前的电脑基本都是单核CPU，多线程和单线程几乎看不出差别，可是由于计算机的迅速发展，现在的电脑几乎都是多核CPU了，最少也是两个核心数的，这时差别就出来了：通过之前的案例我们已经知道，即使在多核CPU中，多线程同一时刻也只有一个线程在运行，这样不仅不能利用多核CPU的优势，反而由于每个线程在多个CPU上是交替执行的，导致在不同CPU上切换时造成资源的浪费，反而会更慢。即原因是一个进程只存在一把gil锁，当在执行多个线程时，内部会争抢gil锁，这会造成当某一个线程没有抢到锁的时候会让cpu等待，进而不能合理利用多核cpu资源。
但是在使用多线程抓取网页内容时，遇到IO阻塞时，正在执行的线程会暂时释放GIL锁，这时其它线程会利用这个空隙时间，执行自己的代码，因此多线程抓取比单线程抓取性能要好，所以我们还是要使用多线程的。
GIL对多线程Python程序的影响
程序的性能受到计算密集型(CPU)的程序限制和I/O密集型的程序限制影响,那什么是计算密集型和I/O密集型程序呢?
计算密集型：要进行大量的数值计算，例如进行上亿的数字计算、计算圆周率、对视频进行高清解码等等。这种计算密集型任务虽然也可以用多任务完成，但是花费的主要时间在任务切换的时间，此时CPU执行任务的效率比较低。
IO密集型：涉及到网络请求(time.sleep())、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。
当然为了避免GIL对我们程序产生影响，我们也可以使用，线程锁。
Lock&RLock
常用的资源共享锁机制：有Lock、RLock、Semphore、Condition等，简单给大家分享下Lock和RLock。
Lock
特点就是执行速度慢，但是保证了数据的安全性
RLock
使用锁代码操作不当就会产生死锁的情况。
什么是死锁
死锁：当线程A持有独占锁a，并尝试去获取独占锁b的同时，线程B持有独占锁b，并尝试获取独占锁a的情况下，就会发生AB两个线程由于互相持有对方需要的锁，而发生的阻塞现象，我们称为死锁。即死锁是指多个进程因竞争资源而造成的一种僵局，若无外力作用，这些进程都将无法向前推进。
所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。
死锁代码
python线程间通信
如果各个线程之间各干各的，确实不需要通信，这样的代码也十分的简单。但这一般是不可能的，至少线程要和主线程进行通信，不然计算结果等内容无法取回。而实际情况中要复杂的多，多个线程间需要交换数据，才能得到正确的执行结果。
python中Queue是消息队列，提供线程间通信机制，python3中重名为为queue，queue模块块下提供了几个阻塞队列，这些队列主要用于实现线程通信。
在 queue 模块下主要提供了三个类，分别代表三种队列，它们的主要区别就在于进队列、出队列的不同。
简单代码演示
此时代码会阻塞，因为queue中内容已满，此时可以在第四个queue.put('苹果')后面添加timeout，则成为 queue.put('苹果'，timeout=1)如果等待1秒钟仍然是满的就会抛出异常，可以捕获异常。
同理如果队列是空的，无法获取到内容默认也会阻塞，如果不阻塞可以使用queue.get_nowait()。
在掌握了 Queue 阻塞队列的特性之后，在下面程序中就可以利用 Queue 来实现线程通信了。
下面演示一个生产者和一个消费者，当然都可以多个
使用queue模块，可在线程间进行通信，并保证了线程安全。
协程
协程，又称微线程，纤程。英文名Coroutine。
协程是python个中另外一种实现多任务的方式，只不过比线程更小占用更小执行单元（理解为需要的资源）。为啥说它是一个执行单元，因为它自带CPU上下文。这样只要在合适的时机， 我们可以把一个协程 切换到另一个协程。只要这个过程中保存或恢复 CPU上下文那么程序还是可以运行的。
通俗的理解：在一个线程中的某个函数，可以在任何地方保存当前函数的一些临时变量等信息，然后切换到另外一个函数中执行，注意不是通过调用函数的方式做到的，并且切换的次数以及什么时候再切换到原来的函数都由开发者自己确定。
在实现多任务时，线程切换从系统层面远不止保存和恢复 CPU上下文这么简单。操作系统为了程序运行的高效性每个线程都有自己缓存Cache等等数据，操作系统还会帮你做这些数据的恢复操作。所以线程的切换非常耗性能。但是协程的切换只是单纯的操作CPU的上下文，所以一秒钟切换个上百万次系统都抗的住。
greenlet与gevent
为了更好使用协程来完成多任务，除了使用原生的yield完成模拟协程的工作，其实python还有的greenlet模块和gevent模块，使实现协程变的更加简单高效。
greenlet虽说实现了协程，但需要我们手工切换，太麻烦了，gevent是比greenlet更强大的并且能够自动切换任务的模块。
其原理是当一个greenlet遇到IO(指的是input output 输入输出，比如网络、文件操作等)操作时，比如访问网络，就自动切换到其他的greenlet，等到IO操作完成，再在适当的时候切换回来继续执行。
模拟耗时操作：
如果有耗时操作也可以换成，gevent中自己实现的模块，这时候就需要打补丁了。
使用协程完成一个简单的二手房信息的爬虫代码吧！
以下文章来源于Python专栏 ，作者宋宋
文章链接：https://mp.weixin.qq.com/s/2r3_ipU3HjdA5VnqSHjUnQ
‘柒’ Python之OpenCV把一个视频切分成多个等长视频
import cv2
cap = cv2.VideoCapture('E:/极乐净土.mp4')#导入路径
j=1
i=1
fourcc = cv2.VideoWriter_fourcc(*'XVID')
fps =cap.get(cv2.CAP_PROP_FPS)
size = (int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)), int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)))
out = cv2.VideoWriter('E:/新建文件夹 (3)/' + str(j) + '.avi', fourcc,fps, size)#输出路径都是可以自己改的
while (True):
ret, frame = cap.read() # 捕获一帧图像
i = i + 1
out.write(frame) # 保存帧
if (i % 200== 0): # 每n帧切割为一个新的视频
j = j + 1
out = cv2.VideoWriter('E:/新建文件夹 (3)/' + str(j) + '.avi', fourcc, fps, size)#路径都是可以自己改的
cv2.imshow('frame', frame) # 显示帧
# 判断按键，如果按键为q，退出循环
if cv2.waitKey(25) & 0xFF == ord('q'):
break
cap.release()
out.release()
cv2.destroyAllWindows()