IT瘾视频推荐

为什么短视频对人类大脑和文明有负面影响

Tue, 23 Dec 2025 16:52:30 CST

为什么马斯克认为短视频对人类大脑和文明有负面影响？其实，并不是因为视频短形式，而是因为绝大多数短视频根本不围绕知识、能力和认知展开，而是围绕人性最容易被操控的部分在做内容。它们不提升你，只是利用你。那我们看看是如何操纵你的：第一种，人性里的取悦。这是成本最低、效率最高的流量方式。实体店老板的春天要来了，点不点赞？属猪的人今年一定发财，属猪的点不点赞？穿白衬衣的人都有气质，你点不点赞？善良的女人都会有福报，对婆婆好的女人才会旺家，点不点赞？这些话几乎没有任何信息量，但它们有一个共同点：让你被夸、被肯定、被认同。你做哪部分人的生意，就取悦哪部分人。做宝妈生意，就反复强调宝妈不容易、宝妈最伟大；做中年人生意，就不断渲染中年人的辛苦和不公。只要情绪到位、表情真诚、话说得像是在替你发声，流量就会自动找上门。这不是内容，这是情绪按摩。第二种，人性里的嫉妒。通过对比，制造心理落差。同样是90后，别人已经年入百万，你还在打工。他没学历、没背景，却住上了豪宅。你以为有钱人很累？不，他们过得比你爽多了。这种内容看似励志，实则是在不断提醒你：你不行，你落后了，你被甩开了。它不会让你变得更清醒，只会让你越来越焦虑、越来越拧巴。第三种，人性里的愤怒。这是互动率最高的一类内容。男女对立、阶层对立、城市对立、老板和打工人的对立。立场越极端，语言越刺耳，情绪越爆炸，数据越好看。愤怒会让人失去理性，却极度渴望表达。你会忍不住评论、站队、骂人、转发。平台不关心你是否被撕裂，只关心你有没有参与。第四种，人性里的贪婪。给你一个捷径的幻觉。普通人翻身的唯一机会。我靠这个方法，7天赚了100万。某个币你现在不买，等你看到别人开跑车你就买了。错过这次，你这辈子就没机会了。它不卖能力，也不讲逻辑，它卖的是幻想和侥幸心理。而幻想，是最容易让人上瘾的东西。第五种，人性里的恐惧。不断制造危机感。再不做这个，你马上就被淘汰。普通人已经没有未来了。中年人正在被社会抛弃。恐惧会让人停止思考，只想抓住一根救命稻草。而这正是很多内容真正想要的。这就是为什么说短视频是毒瘤。不是因为形式，而是因为算法把注意力不断推向：取悦、嫉妒、愤怒、贪婪、恐惧。当一个人长期沉浸在这些情绪里，他会越来越情绪化、越来越短视、越来越难进行深度思考。这，才是最可怕的地方。

Instagram 和 Meta 会降低低观看量视频的质量

Mon, 28 Oct 2024 19:05:32 CST

为什么 Instagram 上的部分视频模糊，部分视频明显更清晰？这是因为视频的质量取决于观看次数，Meta 此举可以节省大量流量费用。负责 Instagram 业务的 Meta 高管 Adam Mosseri 解释说，Instagram 通常会尽可能展示高质量（或者高码率）视频，但如果某个视频长期无人观看——因为大部分视频的浏览量来自于刚上线的时候——它会将其替换为低质量（或低码率）视频。如果视频再次火热，那么它会重新更换为高质量视频。Mosseri 称对于视频观看量更多的内容创作者，Instagram 会倾向于展示高质量视频。

短视频对大学生价值观的影响有多大？

Mon, 27 Nov 2023 21:14:35 CST

短视频是一种以秒为计时单位，依托移动终端以生活化的文本逻辑、情感化的叙事手段、多元化的语境呈现，融合文字、语音、图像等素材，进行即时拍摄、实时编辑、同步分享，通过网络媒体传播的网络视频作品。短视频既是一种网络视频作品，也是一种新型传播形式，还是一种网络文化现象。

近年来，以抖音、快手、秒拍、今日头条、小红书、腾讯微视、哔哩哔哩、火山小视频App为代表的短视频平台快速发展，为广大青年大学生获取知识信息、开阔视野眼界、交流生活经验、增强社会交往等提供了新的渠道和途径。但由于短视频内容的良莠不齐以及长期使用短视频所带来的“信息茧房”效应，青年大学生的价值观也深受其影响。

价值观是人的精神世界的深层动力，是对理想信念、价值观念、道德伦理、品行操守、审美情趣等的正确取向与信奉遵循。青年大学生的求学阶段正是价值观形成塑造的关键时期，正确认识和有效应对短视频对大学生价值观产生的潜在风险与影响，是保证大学生健康成长和全面发展的内在要求。

有鉴于此，笔者于2023年3月至6月，选取湖南、湖北、广东、山东、天津等省市的43所高校的10305名大学生（全日制本专科生和硕士研究生）作为调查对象，采用问卷星进行了一次网络调查。

调查对象中，性别结构上，男生占48.87%，女生占51.13%；学历分布上，专科生占17.38%，本科生占77.66%，硕士研究生占4.96%；政治面貌方面，中共党员（含预备党员）占20.79%，团员占76.06%，群众占2.51%，民主党派占0.63%。

一、青年大学生使用短视频的现象透视

短视频开创了“视频+社交”的内容生成与传播格局。青年大学生是短视频用户的主体，在使用时间、使用App类型、内容选择以及使用功能等方面表现出较为鲜明的群体特征。

1. 使用时间：青春的释放隐匿时光的消磨

调查显示，在被调查者中每天观看短视频时长在30分钟以下的占12.85%，30~90分钟的占37.11%，90~120分钟的占23.59%，120分钟以上的占26.45%。

从观看频率来看，选择“只要有时间就看”的占18.05%，“空余时间就观看”的占47.43%，“每天偶尔观看”的占24.75%，而“数天观看一次”的仅占9.77%。

从观看时间段来看，集中在“中午或晚上睡觉前”的占45.31%，“节假日时间”观看的占17.81%，“用餐时间”观看的占12.55%，在“早晨起床后”“下课时间”“上课期间”观看的占比分别为9.18%、8.77%、6.39%。由此可见，使用短视频已占据了大学生的日常时间和生活空间。

短视频作为一种互联网内容传播分享的新型媒介，已经成为青年大学生日常学习和生活的标配。观看短视频并进行点赞、转发、评论是作为网络原住民的当代大学生青春特质的体现，是青年大学生求知欲、表达欲、表现欲的释放，是虚拟网络与现实世界双重身份需求的满足。

但从以上调查数据也可以看出：每天观看短视频时长在90分钟以上的占到了50%以上。同时，“只要有时间就观看”“空余时间就观看”的总计占到了65.48%；在问及“你身边有无沉迷短视频现象”时，选择“有”的占48.82%。这表明，部分大学生在使用短视频的时光消磨中消耗着青春。

2. 使用App类型：青春的聚集隐含无意识集体狂欢

短视频的拍摄、制作和传播依托App等移动网络终端，但由于各类短视频App的用户对象、开发运营、技术资本和审核机制等不尽相同，使得短视频在内容的呈现上表现出差异性。

为了解青年大学生使用短视频App的情况，调查中设置了“您最常使用哪些短视频App”的问题（限选3项以内），结果显示，在列举的7个选项中，位列前3位的是“哔哩哔哩”“抖音”“小红书”，占比分别为59.93%、55.3%、37.96%。其他依次为“其他”“快手”“西瓜视频”“火山小视频”，占比分别为32%、22.88%、12.89%、12.39%。

“哔哩哔哩”“抖音”“小红书”成为最受大学生喜爱的短视频App，是因为其用户对象定位于青年群体。短视频迎合了年轻人的兴趣喜好、情感需求和文化消费特点，带有很强的青春黏性和青春气息，使得短视频App移动终端成为年轻人的网络社区和青春的网络聚集地。

这些App移动终端的短视频主题多元、内容全面，蕴含着一定的生活元素和文化意蕴，能满足青年大学生的好奇心理，引发大学生的情感共鸣；一些短视频在内容选择和叙事手法上迎合了青年大学生情绪宣泄和情感释放的需要，再加上利用大数据和算法技术对用户进行精准推送，使得青年大学生经常在网络空间进行无意识的集体狂欢。

3. 内容选择：多元化与无标准并存

为了解青年大学生对短视频内容的偏好，在“您平常喜欢观看哪类短视频”中，我们设置了“时事新闻类”“热点事件类”“自然风光类”“探险旅行类”“军事科技类”“时尚搭配、美妆类”“搞笑段子类”“学习、生活技能分享类”“综艺、影视剪辑类”“美食类”“游戏类”“其他”等12个选项，要求限选5项以内。

结果显示，排在前5位的为“搞笑段子类”“学习、生活技能分享类”“热点事件类”“综艺、影视剪辑类”“时尚穿搭、美妆类”，选择人数占比分别为47.15%、41.62%、39.71%、34.35%、31.88%。

调查数据显示，青年大学生对9个类别短视频的选择均超过了30%，这些短视频的内容涉及时事政治、军事科技、地理风光、历史知识、生活技能、时尚美妆、休闲娱乐、学习分享等等，呈现出内容多样的特点。这也反映了处于客观社会关系和具有类特征的大学生对时事政治的关切、对社会现实的关注、对学习生活的态度，对自我成长成才和全面发展中各方面知识的多元化追求。

但是，在问及“观看短视频是否对您的价值取向产生影响”时，选择“否”的占43.06%，选择“是”的占41.95%，选择“不清楚”的占14.99%。同时，由于各种短视频App在技术逻辑的主导下对用户对象的需求和爱好等进行框定和测量，不断推送相关内容的短视频，使得大学生对短视频内容的选择缺乏坚持自己价值标准的自主性，表现出多元内容需求与无标准选择的矛盾对峙。

4. 使用功能：满足娱乐、技能和社交的需求

在问及“您使用短视频App的原因是什么”问题时，笔者设置了7个选项并要求限选4项以内。结果显示：选择“娱乐放松”的占73.16%，选择“拓宽自己视野”的占56.09%，选择“打发时间”的占50.57%，选择“拓宽获取知识的渠道”的占46.34%；选择“扩大社交范围”的占24.47%，选择“展现自我”（含发布短视频、评论等）的占21.33%，选择“其他”的占17.77%。

以上数据表明：从使用功能来看，短视频已经成为青年大学生学习生活、拓宽视野、社会交往、休闲娱乐的重要平台，他们使用短视频具有较强的针对性和功能性。

同时，在问及“您认为观看短视频最大的收获是什么”时（限选3项），选择“缓解压力、调节情绪”的占64.8%，选择“娱乐生活、打发时间”的占57.76%，选择“增长才干、开阔视野”的占54.93%，选择“学习知识、培养爱好”的占33.24%，选择“人际交往、沟通交流”的占27.34%。

这说明，短视频能缓解和疏导大学生的心理压力、成长烦恼与焦虑压抑等负面情绪；大学生借助短视频可以不断开阔视野、获取知识、提升技能、发展自我和展示自己。短视频作为一种临场感和情景感极强的媒体已经成为高全息度的社交工具，增强了青年大学生社会交往互动和社会现实的体验感。

二、青年大学生追捧青睐短视频的原因透析

短视频之所以受到青年大学生的追捧和青睐，是因为其形式、内容、创作和传播契合了青年大学生追求时尚的青春个性、多元多样的认知需求、自我意识的身份建构以及社会交往等方面的需要。

1. 短视频的形式：迎合大学生追求时尚的青春特征

“不潮不炫不青春”，是当代青年的个性标签。追求时尚、追赶时髦、追随潮流，易于接受新鲜事物，敢于创造流行话语，是当代青年大学生固有的青春特征。短视频在形式的设计上迎合了大学生追求时尚的青春特征。从时长上看，短视频一般为15~60秒，最长不超过3分钟。根据抖音官方规定，普通用户发布的视频长度一般不超过60秒。

有统计表明，“快手”“抖音”“哔哩哔哩”“小红书”等平台的短视频时长集中为20秒以内。这就使得观看短视频的时间成本低于文字阅读成本。同时，短视频通过可视化情景和拟态化环境表达一定的信息内容，大学生可以随时随地加以接受，这就迎合了青年大学生“快餐式”的文化消费习惯和信息接收方式。

从技术上看，短视频通过美颜、滤镜、拼接、瘦脸、长腿、AI换脸等特效技术，使人物形象更加光鲜，使视频画面更加清晰和具有质感，强化了视觉效果，再配以各种流行音乐背景，这些功能及设置满足了青年大学生敢于展现自我、突破自我、追求个性、新潮时尚的心理情感需求。

从元素上看，短视频广泛运用场景、图片、字幕、语言、音乐、解说等多种元素，人们可以根据自己的性格偏好、兴趣特长、个性需求，通过裁剪、合成和特效编辑，达到情景交融、音景匹配的效果，迎合了大学生的青春心理需求与个性张扬的特点。

2. 短视频的内容：满足了大学生多元多样的认知需求

“人以其需要的无限性和广泛性区别于其他一切动物” ^[2]。认知需求是人的内在动机。青年大学生实现其全面发展和社会角色的认同需要各种知识加以构建，再加上他们对现实世界有着强烈的好奇心，因而具有多元多样的认知需求。

随着短视频平台的发展和智能技术的普及，短视频的内容多种多样、包罗万象，既有新闻资讯、时政要闻、热点评析，又有知识传授、学习经验、专业技能；既有科技创新、地理风光、影视片段，又有人物画像、旅游攻略、生活技巧；既有美容美妆、穿搭打扮，又有美食分享、网红打卡等等，涵盖了青年大学生学习生活全领域的知识信息。

短视频在信息和知识的传递形式与表达方式上更具有感染力和吸引力，既有情景呈现、画面展示、人物写照，又有语音解说、事件回放、现场直播，等等。同时，短视频采用一滑而过的推送形式，使观看者能够对内容进行快速筛选与取舍。因而，短视频的内容能满足青年大学生多元多样的认知需求。

3. 短视频的创作：契合了大学生自我意识的身份建构

“00后”大学生有着较强的主体意识、自我意识和参与意识，在社会交往与人际互动中强调自我意识的身份建构。其鲜明特点就是高度关注自我，在一切社会关系中开始展现自我以掌握和定位自我的社会角色。

虽然短视频的内容创作采用的是UGC，即用户的原创内容模式，但短视频创造门槛低，程序简单，可以随时拍摄、实时编辑，有些甚至预设了背景音乐、情景模板、台词文案，大学生只需要植入相关元素再配以肢体、表情和语言，就能制作出短视频并随手发布。

这就契合了青年大学生敢于表现自我、凸显自我意识的身份建构，尤其是当短视频被大量转发并获得流量和粉丝时，制作者会产生极具获得感的身份认同价值。同时，由于网络世界的开放性和匿名性，为在现实生活中不善于表达、羞于表现的大学生提供了展现自我的平台，他们可以毫无保留地通过短视频来展现自己。

调查结果显示：表示“自己制作过短视频”的占42.83%。在问及“您制作短视频时的想法是什么”时，位列前3位的选项为“记录日常，与朋友互动”“宣泄自己的情绪”“经营账号，获取利益”，占比分别为64.68%、23.37%、20.23%；此外，选择“炫耀自己，获取关注”的占比为18.35%，也可以视为追求自我意识身份构建的具体体现。

4. 短视频的传播：强化大学生虚实交互的社交功能

网络时代，青年大学生的社交领域已经突破现实界限而向网络延伸，虚拟网络与现实世界交互结合的社交功能深刻地改变了青年大学生的社交方式以及交往互动模式。而短视频“不是普通视频的缩略版，而是社交方式的延续，现已成为一种新型的社交途径” ^[3]。

调查中，在问及“您使用短视频App的原因是什么”时，明确表示是“扩大社交范围”的占24.47%。短视频的“一屏共享”“多人共享”突破了交往的时空界域，多人可以在同一时段观看同一视频，也可以在不同时段对同一视频进行评价互动。

同时，短视频拓展了社交领域与方式，作为受众的青年大学生对短视频进行点赞、转发、评论，实际上是一种带有社会属性的交际方式，使大学生的社交范围从现实延展到网络。任何短视频创作发布者都有机会获得关注和浏览，任何用户都可以对任何短视频进行评论、点赞和转发，尤其是私信功能可以建立起符合自身个性、适合自身兴趣的虚拟社交关系。

相对传统的社交平台和社交方式，短视频以动态的情景和音像调动受众的感官体验和情感共鸣，有效增强了信息的传递与接收，提升了青年大学生的社交互动黏性。

三、短视频对青年大学生价值观的影响

短视频以人机共为和人机互动的方式，借助分镜构图、场景再造、特效编辑、音像结合等形式来记录生活、传播信息、传递内容和表达立场，并呈现传播速度快、受众人数多、内容含涉广等特点。

但是，短视频繁荣发展的背后离不开商业利益的驱动，一些短视频创作者为了博取关注而无所不用其极，一些短视频App平台形成了资本、流量和平台的利益闭环，导致短视频出现情境碎片化、内容泛娱乐化、生产创作无序化以及去思维化等不良导向和价值迷思，在很大程度上影响了青年大学生正确价值观的塑造。

1. 短视频情境的碎片化解构青年大学生的价值认知

价值认知是人们对价值观念和价值目标的理性认同，对青年大学生的成长发展以及形成正确的价值判断起着关键作用。价值认知的形成是主体知识经验、思维意识与外在信息内容共同作用并进行认知重构的过程。

作为一种网络文化产品，短视频承载着相关信息内容，隐含和传递着一定的价值立场。毋庸讳言，短视频会影响受众的价值认知。如前所述，调查中在回答“观看短视频是否对您的价值取向产生影响”问题时，选择“是”的占41.95%，选择“说不清”的占14.99%。

相对于平面媒介和文字图片作品，短视频受到青年大学生的青睐，重要原因之一就是短视频能以生动、直观、真实的情境带来沉浸式的感官体验。但是短视频情境呈现所具有的碎片化、片段化特点，也导致信息传递缺乏完整性和系统性。

一方面，受时间限制，短视频的信息内容呈现往往没有背景铺垫，呈现结束后也没有完整的叙事说明；有些视频甚至是相关情境的拼接和裁剪，缺乏整体逻辑；有的短视频还对缺乏关联的事物和事件进行移花接木、混淆视听，编造虚假信息，如“胡某宇事件”“中电科加班事件”“医生倒提婴儿疑似虐待”“婆孙平移插队”等视频，都是为了吸流量、蹭热度而歪曲了事实真相 ^[4]。

调查中在问及“您对短视频中内容的真假、是非所持的态度”时，尽管选择“有自己的辨别标准，会进行甄别”的占56.23%，但选择“不管，纯粹消遣”的占14.97%，选择“从不怀疑短视频的内容”的占9.56%，选择“明显是虚假的内容会滑过”的占19.23%。

这说明，青年大学生对短视频信息内容的真假以及完整性缺乏足够的理性思辨。长此以往，碎片化的信息内容及其所体现的立场观点会解构青年大学生的价值认知。

另一方面，一些短视频往往热衷于对社会热点事件尤其是容易引发公众情绪的公共事件进行评论和直播，但不注重观照事件的前因后果与来龙去脉，往往专注于事件中容易触发负面情绪和引发大众共情的某一情境或事件中的偶然性，迎合受众“吃瓜围观”的看客心态；有的甚至歪曲事实真相，有的对公众人物的观点立场和事件评价进行断章取义，从而诱发网络群体负面情绪，诱导和迷惑受众的价值认知与价值判断。

另外，短视频平台的评论区中隐藏着一定数量的以控制舆论方向为目的的“键盘侠”，故意引导舆论方向，操控公众情绪，使受众难以辨别真伪，如2020年2月张某某在抖音评论区诋毁抗疫医务人员被行政处罚。这些都影响到青年大学生的价值认知。

2. 短视频内容的泛娱乐化冲击青年大学生的价值取向

在流量至上和资本逻辑的加持下，泛娱乐化已成为短视频的隐形标签。为了博取眼球、赚取流量和赢得粉丝，一些短视频调侃嘲讽英雄、戏谑侮辱先烈、解构主流价值，如“暴走漫画”曾发布侮辱董存瑞和叶挺的短视频而被封号，女网红“秋秋老师”在视频中侮辱抗日英雄引发公愤，一些网红到在今年8月京津冀强降雨抢险中牺牲的蓝天救援队队员的家门口直播引起众怒。

一些短视频以制造各种噱头、宣扬娱乐至上、歪曲事实真相、恶搞戏谑生活为流量密码，如以陈×成为代表的家暴“梗”短视频引发怒批，网红“二驴”编造在青岛被殴被绑被埋的视频被封号。还有一些短视频贩卖和炒作低俗、媚俗、恶俗、色情等内容，如“快妖精”短视频App被警方查获淫秽短视频11万部，网红“卷毛重头再来”屡次低俗直播被禁封。

调查中，在回答“您在观看短视频时出现过哪些不良内容”时（多选项），选择“虚假信息”的占60.13%，选择“恶意营销”的占60.89%，选择“价值观不正”的占53.24%，选择“低俗血腥色情暴力”的占33.43%。

短视频内容的泛娱乐化，易使青年大学生沉湎于寻求直观的感官刺激和不良的情感体验，麻醉大学生的精神意志，消解大学生的奋斗精神，侵蚀大学生的正确价值取向，并加剧了他们好奇、刺激、猎奇的心理。

一些短视频戏谑生活、恶意搞怪、嘲弄青春、丑化形象，如“尴尬的小陈”“抖音四公子”“郭言郭语”“六哥和少红”等短视频以夸张搞笑的表现形式、“幼稚化”的语言逻辑、无意识情感化狂欢的叙事方式，解构生活意义和人生价值，在一定程度上降低了道德标尺，消弭了社会正能量。

同时，短视频的内容存在同质化倾向，一些带有“笑点”和“卖点”的娱乐性短视频在获得高关注和高流量后，又有创作者再造场景和变换叙事手法进行模仿，重复性的娱乐内容加剧了对青年大学生价值取向的冲击。

3. 短视频生产创作的无序化影响青年大学生的价值判断

价值判断是形成价值认知和价值取向的基础，是价值观念的内核。随着移动终端的普及和一些App平台定期推出短视频制作模板，人人都是短视频的观看者，也都可以成为短视频的生产创作者；再加上对短视频内容审核、制作监管的机制还不够完善，使得短视频的生产创作没有行业标准，呈现出无序化倾向，导致短视频的内容质量参差不齐。

有的短视频在资本逐利的影响下进行商品销售，有的炫耀高档消费和奢侈生活，有的在视频中情境化推销提前消费理念，如2021年快手、抖音发布某金融视频广告，宣扬过度消费等不正确价值导向被市场监管部门处罚。

有的编造虚假内容、颠倒是非、混淆视听、模糊是非对错标准、扭曲价值观念，如“网红被要求陪酒”“外卖骑手深夜送餐电车被盗”、四川凉山“阿佳”悲惨身世等短视频，后经查实均为造假；有的不顾公共道德和公序良俗，挑战法律底线；有的刻意迎合大众心理，利用大众盲从心理进行点赞关注请求；有的打政策法规的擦边球，进行涉黄打赏，如网信部门曾查处“内涵福利社”“夜都市Hi”“发你视频”等19款背离社会主义核心价值观的网络短视频平台。

还有少数人利用短视频传播散布不当言论，歪曲理解党的路线方针和政策方略。再加上网民的文化认识水平、辨别能力、文明素养、道德修养存在差异性，使得短视频的传播和评论中存在大量鱼龙混杂的信息，干扰青年大学生的价值判断和辨析能力的形成。

调查中，“打赏过视频中的主播”的占16.13%。在问及“您和您身边的同学是否有非理性或高额度打赏主播”时，选择“是”的占12.27%，选择“不清楚”的占29.84%。在问及“您对因为观看短视频产生的消费的看法”时，选择“后悔，以后不会再消费”的占15.62%，选择“发生过通过短视频造成被诈骗的现象”的占27.33%。以上情况的发生，是短视频的不良内容影响了青年大学生价值判断能力而造成的。

4. 短视频的去思维化消解青年大学生的价值理性

短视频作为以动态图像为表达形式的视觉信息产品，叠加声音元素得以呈现，加之商业法则和算法技术的运用，让用户在观看短视频时不需要理性思维的过程。

“北快手南抖音，王者荣耀遍地走”，去思维化的认知和“短平快”的体验感，会让青年大学生沉浸在无须理性思维的信息内容中无法自拔，使他们逐渐不愿回归到需要高投入和思维化的认知模式中，甚至对需要理性思维的知识摄取和专业学习产生倦怠心理，从而逐渐呈现出思想意识浅思维化的趋势，消解青年大学生的价值理性和批判思考能力。

因为青年大学生在短视频去思维化的沉浸中，认知往往停留在事物表面，逐渐养成思维惰性，丧失对专业和理性的深入思考，失去思维活力和真假辨识能力，从而使得青年大学生对价值理性停留在浅层次的感性认知上，逐渐造成价值理性的消解和异化，阻碍青年大学生理性价值观的形成。

调查中，在问及“观看有关重大事件的短视频是否会思考其中的内容或事件的完整性”时，选择“是”的占74%，选择“否”的占26%。这说明，部分青年大学生对短视频的信息内容缺乏深入的理性思考。

同时，短视频的流行构建了一种新的话语方式，也在青年大学生群体中形成一种“模仿流”，短视频的社区化使平台上的内容集中趋同，形成了模仿、复制、循环性的传播，光怪陆离的内容片面追求流量而忽略了价值内涵。

比如“在小小的花园里挖呀挖呀挖......”等爆火视频引得全网争相模仿，“绝绝子”“芭比Q了”到谐音梗、土味情话等等，堆积出大量的网络短视频口癖。再如，平台文化的流行塑造出女性的审美取向，风靡全网的“A4腰”“筷子腿”“精灵耳”成为女性身体美“科学指标”的体现，经由社交平台的文化意识培植，让受众在潜移默化中接受身体工业化审美的合法性 ^[5]。

四、短视频对大学生价值观影响的应对策略

应对短视频对青年大学生价值观的影响，需要因势利导，用社会主义核心价值观抵御泛娱乐化的侵蚀，用价值赋能技术克服短视频传播无序化的负面影响，强化价值引领提升青年大学生的价值认知能力，健全监管机制优化短视频的内容供给，同时要激发青年大学生的主体动能释放其青春能量。

1. 坚持内容至上，用社会主义核心价值观抵御泛娱乐化的侵蚀

短视频作为一种精神文化产品和新兴网络文化形态，应当承载起价值导向的传播和社会正能量的传递功能。短视频创作传播必须坚持内容至上，用社会主义核心价值观有效防止和抵御泛娱乐化对社会主流价值的冲击与侵蚀。

因此，一是将社会主义核心价值观进行青年化阐释，将其内容数字化、网络化、视频化呈现，达到可视化传播的效果，让阐释宣扬社会主义核心价值观的短视频充满屏幕。

二是将社会主义核心价值观有机融入短视频的创作、传播、评论等环节之中，将短视频App移动终端打造为培育社会主义核心价值观的重要阵地。短视频生产制作中要坚持正确的价值导向，培育践行社会主义核心价值观，弘扬社会主旋律，传递社会正能量，祛除和消解“娱乐至上”“娱乐至死”的文化消费心理和感官情感追求。如短视频《二舅》以朴实的叙事手法，传递出人性的温度而红暴全网；网红李子柒通过短视频以微观叙事的方式，致力于传播传统文化和中国形象。

三是以社会主义核心价值观为引领，不断提升青年大学生的网络素养和网络责任感，引导青年大学生客观看待和正确接收短视频所传递的内容和信息，坚持以正确的价值标准和价值立场对短视频进行传播和评论。

2. 价值赋能技术，防止青年大学生囿于短视频的“信息茧房”

短视频集图文、声画、音像于一体，其丰富的表现形式、多元的叙事手法、生动的场景再造以及由此带来的娱乐性、互动性和社交性，再加上智能算法基础上的推送，契合了受众的信息接受心理特点和媒介使用习惯，但也容易形成“信息茧房”。

如何趋利避害，离不开技术的运用和支持。技术具有中立性和可控性，但技术的运用需要坚持一定的价值原则和价值标准。因此，要用价值赋能技术，防止青年大学生囿于短视频的“信息茧房”。

一是设置短视频首推和置顶功能，将价值导向正确、内容质量精良，弘扬主旋律、传递正能量的短视频进行首推和置顶，使青年大学生打开短视频App就能接收正确信息和正能量内容。

二是建立分类推送机制，充分利用智能技术和算法技术，根据短视频的内容将其分门别类，并根据用户注册信息识别不同受众群体；按照内容喜好、兴趣爱好、价值旨趣分类，针对不同年龄段、不同群体进行短视频的精准推送；对不适合青年大学生观看的短视频进行截留和阻推。

三是开发短视频防沉迷软件系统。当前观看短视频没有时间阈值的限制，“抖音五分钟，人间两小时”是受众沉迷于短视频的生动写照，因此短视频App需要开发防沉迷软件系统，根据“用户信息设置不同的上网时间阈值，设置时间提示和时间锁功能” ^[6]，对较长时间连续使用短视频的用户要进行提醒、预警及至关闭。

3. 强化价值引领，提升青年大学生的价值认知能力

价值认知能力是人的精神世界的动力系统，应对短视频对青年大学生价值观念的影响，前提和基础是提升青年大学生价值认知能力；而价值认知能力建立在对科学理论的理性认知之上。

为此，一是进行理论武装，用马克思主义理论擦亮青年大学生的青春底色，以习近平新时代中国特色社会主义思想为青年大学生立德铸魂、浇根润心，使青年大学生能自觉运用马克思主义基本立场、观点和方法去观察和分析事物，自觉抵御各种错误思潮的侵蚀。

二是深化教育引导，积极开展道德教育、精神文明教育、培育践行社会主义核心价值教育，使青年大学生形成完整的思想认知体系和价值认知系统，引导青年大学生正确认识短视频的“两面性”，增强道德鉴别力，做到正确区分对错、是非和美丑，自觉对短视频的内容进行甄别和筛选，理性和有节制地使用短视频，抵制和远离低俗与缺乏价值内涵的短视频。

三是发挥先进典型的示范作用，积极挖掘时代楷模、最美人物、大学生自强之星、年度人物、五四青年奖章获得者等先进典型的价值引领功能与育人功效，将先进典型的先进事迹及蕴含的精神价值通过短视频加以展示和呈现，作为青年大学生思想政治教育的生动素材。

4. 健全监管机制，优化短视频的内容供给

各类App平台等移动终端上的短视频以UCG（用户生产内容）为主，而对短视频内容的审查监管不够，是优化短视频内容供给的堵点和难点。

2019年中国网络视听节目服务协会发布的《网络短视频平台管理规范》明确规定：平台上播出的所有短视频内容均应经审核后方可播出。当前，各类短视频App和网站的内容监控技术，大多采用电脑自动过滤，将要监控的关键词输入后进行搜索。尽管关键词搜索可以过滤出一些包含不良文字内容的短视频，但由于短视频不仅采用了文字的表现形式，还采用了图像、影像等元素，单纯依靠电脑过滤检测无法将所有包含不良内容的短视频过滤出去。

基于此，一是建立准入和退出制度。对入驻短视频App和网站的短视频公众号进行严格的资格审查，对有不良记录和违法违规行为者所持有的公众号以及生产创作的短视频实行禁入制，对制造噱头、歪曲事实、以丑为荣、混淆是非、编造虚假信息、诋毁英雄人物的视频和账号，坚决予以清理取缔；对被受众投诉举报和造成不良社会影响的短视频及时下架删除。

二是健全内容审核机制。各类短视频App和网站除通过电脑过滤和检测软件外，还需要建立专业的人工审核机制，对有违社会主义精神文明、道德规范以及主流价值的短视频坚决不予上线。

三是建立评论区净化机制和不当言论闭屏制度。由于网民的网络素养、道德水准、价值立场各不相同，对同一内容短视频的看法也存在差异，这就导致“网络水军”“键盘侠”“网络喷子”带节奏、搅浑水、挑矛盾、控舆论，因此要通过设置“黑名单”建立起监管机制，规范约束网民的言论，防止借评论互动之名发布不当言论、颠倒是非曲直、贩卖不良情绪，误导青年大学生的价值认知。

5. 激发主体动能，释放青年大学生的青春能量

青年大学生既是短视频的受众主体，也是短视频的创作主体。由于当代青年大学生思维敏捷，敢于尝试，善于接受和运用智能新兴技术，为此，激发他们生产创作、传播互动、欣赏评论短视频的主体积极性，释放出青年大学生的青春能量，是应对短视频对其不良价值影响的重要方式。

一是打造校园“两微一端一抖”的融合媒体矩阵，提升学校官方客户端的吸引力和点击量。一方面在研判学生生活需要、心理需求和文化消费特点的基础上，增强短视频推送的针对性，克服“大而全”的现象；另一方面发挥大学生自主性，定期精选推送大学生自主创作的短视频作品。

二是利用“国庆”“七一”“八一”等具有纪念意义的时间节点和传统节日，设置特定主题，组织青年大学生开展短视频创作，将优质短视频作品向主流媒介和官方App推介和传播。

三是组织青年大学生制作如“大学生年度人物”“最美大学生”“大学生自强之星”等反映榜样典型先进事迹及精神品格的短视频，将优质短视频在相关官方移动终端尤其是共青团系统移动App上加以推送，汇聚起反映大学生精神风貌的网络正能量。

参考文献：

[1]中国互联网络信息中心.第51次中国互联网络发展状况统计报告[R/OL].[2023-03-27].https://cnnic.cn/NMediaFile/2023/0322/MAIN16794576367190GBA2HA1KQ.pdf.

[2]马克思恩格斯全集:第49卷[M].北京:人民出版社，1982:130.

[3]杨国辉.网络短视频对大学生思想政治教育的影响分析[J].思想理论教育导刊，2020(12):133-134. [4]王金虎“.清朗”系列专项行动:守护风清气正网络空间[N].光明日报，2022-03-18(3).

[5]刘瑀钒.身体圈禁:社交媒体环境下青年女性的负面身体意象生成[J].中国青年研究，2023(5):103-110.

[6]骆郁廷，李勇图.抖出正能量:抖音在大学生思想政治教育中的运用[J].思想理论教育，2019(3):88.

本文系2023年度国家社会科学基金项目“新时代青年的信仰塑造研究”（项目编号：23BKS157）的阶段性成果。本文来自微信公众号：中国青年研究（ID：china-youth-study），作者：艾楚君、孙淑雅、马钰莹

AI视频生成卷出新高度：高清电影画质免费无限玩，号称“史上最强”

Sat, 14 Oct 2023 13:36:07 CST

丰色发自凹非寺

量子位 | 公众号 QbitAI

号称“史上最强大的视频生成AI”诞生了。

效果真的还不赖：

一句提示词就能生成，主打一个高清、16:9电影画质。

超现实主义、动漫、奇幻……各种风格全包揽。

最重要的是，免费！加入Discord社区立马就能玩。

它的打造者也很“嚣张”：

知道《星际迷航》中的全息甲板吗？我们的使命就是复刻它。

知道Stable Diffusion、DALL-E或Midjourney吗？我们就是它们的视频翻版！

实测“史上最强”视频生成AI

这个AI名叫 Moonvalley。

目前处于Beta阶段，全免费使用。

进入它的Discord社区（大约是在8月下旬开设），随便一翻，不乏各种有趣作品。

视频时长在1s-6s不等。

有“蝙蝠侠在雨中潜入阿卡姆疯人院潮湿的街道”：

有“耀眼的光笼罩着一个人，现场一片混乱，充满电弧和漩涡能量”：

也有“一个粉蓝色头发戴墨镜，正在跳舞的25岁女子”：

我们也实测了一下。

一共有6个子区，随便选择一个进入。

在聊天框中输入 “/create”，系统就会自动给你格式，提示你填写提示词、风格和时长。

其中 风格有5种可选：从漫画到现实主义，也包括3D动画。

时长则分三档，等待时间从2分钟到12分钟不等。

我们浅浅来一个：

Cells dividing viewed through a microscope（通过显微镜观察细胞分裂），现实主义，中等长度。

结果如约在4分钟后出来了：

和想象的不太一样，但视觉效果还可以。

再来：

In a laboratory filled with equipment, a robot and a human actively shake hands（在一个布满器械的实验室中，一个机器人和一个人类主动握手）。

个人认为，意思准确get到了，但手部刻画在视频领域果然也是个难题。

而总的来看，网友们对Moonvalley的评价不一。

有人觉得比同类竞品runway和pika质量要高一些。

也有人指出了一些似乎是“通病”的东西，比如：

不完全符合提示词。

有很多动漫效果似乎“套路”都比较一致。

但不少人确实都表示，被一些高质量的效果惊到了。

团队介绍

Moonvalley并非“横空出世”。

据介绍，团队此前就已在AIGC领域小有年头，但主要是做文本和图像生成，代表作品是Draft.co。

这是一个从博客到广告文案都包揽的文字AI，按字收费，每字0.1美元（一篇1000字稿子约100美元）。

据称，该产品在两年内帮助公司积累了“数千名用户和数百万经常性收入”。

现在，团队转身视频领域，是因为 “看到市场上文本到视频的进展还不够快”，于是投入所有的时间和资源，Moonvalley诞生了。

Moonvalley的最终目标是：

世界上第一个完全可控的人工智能视频生成模型。

至于团队成员，比较神秘， 全部远程工作。

融资方面，他们已成功拿到3600万美元，同时，正在广募机器学习工程师。

体验地址：
https://discord.com/invite/moonvalley
主页：
https://moonvalley.ai/
参考链接：
[1]https://twitter.com/xiaohuggg/status/1710947745660645514?s=46&t=HBob6gxh8cOfZTIbieKeSA
[2]https://twitter.com/ycombinator/status/1709644560702587151
[3]https://www.sir-apfelot.de/en/moonvalley-ai-54882/

— 完 —

OpenAI Whisper + FFmpeg + TTS：动态实现跨语言视频音频翻译 - 掘金

Tue, 23 May 2023 22:41:18 CST

本文作者系360奇舞团前端开发工程师

摘要：

本文介绍了如何结合 OpenAI Whisper、FFmpeg 和 TTS（Text-to-Speech）技术，以实现将视频翻译为其他语言并更换声音的过程。我们将探讨如何使用 OpenAI Whisper 进行语音识别和翻译，然后使用 FFmpeg 提取视频音轨和处理视频，最后使用 TTS 技术生成新的语音并替换原视频的音轨。通过这种方式，我们可以为视频添加新的语言版本，同时保持其原始视觉内容。

引言：

现如今，全球范围内的视频内容正在迅速增长，跨语言传播和多语言支持成为了一个重要的需求。但是，手动为视频添加不同语言的字幕或配音可能非常耗时且昂贵。本文将介绍一种利用 OpenAI Whisper、FFmpeg 和 TTS 技术的方法，使我们能够将视频翻译为其他语言并更换声音，以满足多语言需求，同时降低成本和时间。

OpenAI Whisper：是一种强大的语音识别模型，能够将语音转换为文本，并支持多种语言。我们将使用 Whisper 将视频中的原始语音提取为文本，并通过翻译服务将其转换为目标语言的文本。
FFmpeg：处理视频和音轨提取接下来，我们使用 FFmpeg 工具处理视频和提取音轨。FFmpeg 是一款功能强大的多媒体处理工具，它支持各种音视频处理操作。我们可以使用 FFmpeg 提取原视频的音轨，以便稍后替换为新生成的语音。
TTS 技术：生成新的语音为了替换原视频的音轨，我们需要生成新的语音。这里我们使用 TTS（Text-to-Speech）技术，将先前翻译得到的目标语言文本转换为对应语言的语音。TTS 技术基于深度学习模型，可以生成自然流畅的语音，使其与原视频的内容相匹配。
结合 Whisper、FFmpeg 和 TTS：实现视频翻译和更换声音最后，我们将 Whisper 生成的目标语言文本与 TTS 生成的新语音结合起来，并使用 FFmpeg 将新语音替换到原视频的音轨中。通过使用 FFmpeg 的音轨替换功能，我们可以确保新语音与视频内容同步，并生成具备目标。

结果展示

原视频： caining0.github.io/statichtml.…

转换后视频： caining0.github.io/statichtml.…

前提与依赖

      pip3 install openai-whisper
pip3 install ffmpeg-python
brew install ffmpeg
pip3 install TTS//https://github.com/coqui-ai/TTS

openai-whisper用法

命令行用法

以下命令将使用 medium模型转录音频文件中的语音：

      whisper audio.flac audio.mp3 audio.wav --model medium

默认设置（选择模型 small）适用于转录英语。要转录包含非英语语音的音频文件，您可以使用以下选项指定语言 --language：

      whisper japanese.wav --language Japanese

添加 --task translate会将语音翻译成英文：

      whisper japanese.wav --language Japanese --task translate

运行以下命令以查看所有可用选项：

      whisper --help

Python 用法

      import whispermodel = whisper.load_model("base")result = model.transcribe("audio.mp3")
print(result["text"])

例子

      whisper test.mp4 --language Chinese --task translate

      [00:00.000 --> 00:03.400]  If the Chinese people come to design a new building, it will be like this[00:03.400 --> 00:06.360]  A new building that has been rebuilt by a Chinese city
[00:06.360 --> 00:09.480]  This is a real city, maybe it's your hometown
[00:09.480 --> 00:12.640]  Let's take a short film with us and show its real face
[00:12.640 --> 00:14.480]  The opening is a one-minute long lens
[00:14.480 --> 00:16.520]  First, the time has changed, the new season has no shadow
[00:16.520 --> 00:18.680]  A sense of depression is born
[00:18.680 --> 00:20.400]  We randomly saw the red tail of it
[00:20.400 --> 00:22.120]  This is the new building in the hundreds of square kilometers
[00:22.120 --> 00:24.480]  The blue protective tent inside the blue sky city in the front
[00:24.480 --> 00:26.080]  As in the front of the crystal ball
[00:26.080 --> 00:28.360]  The back is a larger environmental structure
[00:28.360 --> 00:29.800]  This is the shadow of the new building
[00:29.800 --> 00:30.600]  The lens is far away
[00:30.600 --> 00:32.040]  We see that there is a bandage
[00:32.040 --> 00:33.560]  It is passing through a huge star
[00:33.560 --> 00:35.240]  Those are the stars of the stars
[00:35.240 --> 00:37.280]  The stars do not affect the shape of the bandage
[00:37.280 --> 00:39.240]  This means that their motivation is super
[00:39.240 --> 00:42.040]  At this time, the lens enters the blue protective tent inside the first crystal ball

TTS

      from TTS.api import TTSmodel_name = TTS.list_models()[0]tts = TTS(model_name)
tts.tts_to_file(text="Hello world!", speaker=tts.speakers[0], language=tts.languages[0], file_path="output.wav")#实践中需要把text更换为whisper提取内容

ffmpeg

提取无音频视频

      ffmpeg -i /Users/cnn/Downloads/test.mp4 -an -y output_new.mp4

去噪

      ffmpeg -y -i output_new.wav -af "anlmdn=ns=20" output_clean.wav

合并与剪切

      ffmpeg -i merge1.wav -i a_p1.wav -filter_complex "[0:0] [1:0] concat=n=2:v=0:a=1 [a]" -map [a] -y merge0.wav

其他问题，由于tts生成语音，实际时长与原视频时长不一样，需要动态调整

      # 思路为，获取视频时长和原视频时间的比例，并设置，调整语速
ffmpeg -y -i output.wav -filter:a "atempo=0.8" output_new.wav

前景

结合 OpenAI Whisper、FFmpeg 和 TTS 技术的跨语言视频翻译与语音本地化应用具有广阔的前景与市场潜力。随着全球化的推进，多语言视频内容需求日益增加，教育、媒体、娱乐和商务等领域都需要提供多语言支持。这种应用可以帮助内容创作者快速将视频本地化，满足全球受众的需求，同时降低成本和时间投入。在教育领域，多语言支持可以促进全球学习交流与合作；媒体和娱乐行业可以通过本地化的视频内容吸引更广泛的受众市场。此外，企业在跨国业务和跨文化交流中也可以利用这种应用进行语音本地化，促进全球团队合作和商务沟通。未来，这种应用有望成为视频内容创作工具与服务的一部分，提供高效、自动化的跨语言翻译和语音本地化功能。总之，这种应用在满足多语言视频需求的同时，为各个行业带来商业机会，并推动全球化交流与合作的发展。

不足

TTS略有杂音，后续优化，或者考虑收费版本，如Polly： aws.amazon.com/cn/polly/，

引用

法庭命令成人视频网站删除所有未经被拍摄者同意发布的视频

Thu, 13 Apr 2023 13:30:50 CST

荷兰阿姆斯特丹法庭命令成人视频网站 xHamster 删除所有未经被拍摄者同意发布的业余视频。该裁决是 Expertise Bureau for Online Child Abuse（EOKM）投诉之后做出的。阿姆斯特丹法庭给 xHamster 三周时间执行命令，删除所有未经同意发布的视频，否则它将面临每段视频每天最高 3.2 万美元的罚款。代表 EOKM 的律师表示，这一判决将对整个成人行业产生重大影响，最大的成人网站 Pornhub 已被要求移除多达 1000 万视频。xHamster 表示它只允许专业的成人视频制作者和经过验证的会员才能上传视频，它已经删除了 EOKM 标记的违规视频。但法官表示 xHamster 网站仍然存在大量未经被拍摄者同意的视频。

ChatGPT与剪映：抖音视频制作的终极指南 - 掘金

Sun, 02 Apr 2023 21:03:05 CST

亲爱的读者们，大家好！今天我们要探讨一个非常热门的话题——如何使用ChatGPT和剪映快速制作抖音视频。作为新一代的短视频创作平台，抖音已经成为了许多人表达自我、分享生活的舞台。而在抖音这个竞争激烈的平台上，如何制作出吸引人的视频就显得尤为重要。本文将向大家展示如何利用强大的AI工具ChatGPT和易用的剪映应用，轻松制作出高质量的抖音视频。

一、选题和素材获取

首先，我们需要确定一个有趣且具有吸引力的选题。你可以根据自己的兴趣爱好、专业领域或者是热门话题来选定创作的主题。

在这个阶段，我们可以利用ChatGPT来帮助我们生成一些选题建议。在ChatGPT中输入你的需求，例如：“给我一些有趣的抖音视频创意”。AI将根据你的输入，生成一系列创意供你选择。

在选定主题后，我们需要寻找合适的素材。素材可以包括图片、视频、音乐等。你可以在网上寻找相关的素材资源，也可以自己拍摄。需要注意的是，确保你使用的素材不侵犯他人的版权，以免造成不必要的麻烦。

二、剪映教程：如何进行视频剪辑

接下来，我们来学习如何使用剪映进行视频剪辑。剪映是一款非常实用的手机视频剪辑软件，适合初学者上手。以下是使用剪映的简要教程：

下载安装：在手机应用商店搜索“剪映”，下载并安装到你的手机上。

创建项目：打开剪映，点击“新建项目”，然后选择你需要的素材，如图片、视频等。将它们导入到剪映的轨道中。

剪辑素材：在轨道中，你可以对素材进行剪辑、拼接、调整时长等操作。点击素材，可以调整其位置和长度。长按素材，可以对其进行拖动。此外，剪映还提供了一键剪辑功能，可以帮助你快速剪辑视频片段。

添加特效：剪映内置了丰富的特效资源，你可以为你的视频添加滤镜、转场、字幕等特效。点击屏幕下方的特效菜单，选择你喜欢的特效，然后拖动到轨道中的相应位置。

音乐和音效：音乐和音效对于抖音视频来说非常重要。剪映提供了丰富的音乐库供你选择。点击音乐菜单，选择合适的音乐或音效，然后将其添加到视频中。你还可以调整音量、淡入淡出等音频参数。

导出视频：完成视频剪辑后，点击右上角的“导出”按钮，选择合适的分辨率和帧率，然后导出视频。剪映会自动保存视频到你的手机相册。

请注意，我这里要特别推荐下剪映的电脑版图文成片的这个功能。

生成效果

这里如果有不合适的素材，可以搜索素材直接拖到下面轨道进行替换。

三、ChatGPT辅助：撰写视频描述和标签

在视频制作完成后，我们需要为视频撰写一个吸引人的描述和设置合适的标签。这时，我们可以再次借助ChatGPT的力量。

在ChatGPT中输入你的需求，如：“为我的抖音视频写一个吸引人的描述，视频内容是关于烘焙蛋糕的。”AI将根据你的输入，生成一段有趣的描述文案。同时，你还可以请AI为你生成一些相关的标签，以便提高视频的曝光度。

四、发布抖音视频

最后，我们要将制作好的视频发布到抖音平台。打开抖音，点击“+”按钮，然后选择刚刚制作好的视频。将由ChatGPT生成的描述文案和标签填写到相应的位置，然后点击发布。恭喜你，你的抖音视频已经成功发布！

总结

通过上述步骤，我们已经学会了如何利用ChatGPT和剪映制作一部精彩的抖音视频。从选题、素材获取、剪辑到发布，我们可以看到，AI技术和易用的剪辑工具为我们提供了极大的便利。在未来的创作中，不妨多尝试利用这些工具，让你的抖音视频更具吸引力。希望本文对你的抖音创作之路有所帮助！

————————

BTW，如果想要使用ChatGPT的同学，可以联系我哦！

生成式 AI 的下一个前沿是视频

Tue, 21 Mar 2023 21:30:16 CST

AI 在生成静态图像上取得了显著进步，Dall-E、Stable Diffusion 和 MidJourney 等服务能创造出逼真的令人惊叹的图像。现在一家创业公司 Runway AI 开始进军生成式 AI 的下一个前沿——从文字描述生成视频。Runway 总部位于纽约，该公司周一宣布了 Gen 2 系统，能通过用户的几句文字提示生成简短视频。举例来说，用户输入 a cat walking in the rain，它会据此生成大约 3 秒钟的视频。用户还可以上传图像，作为生成视频的参照点。Gen 2 AI 系统尚未开放测试，而是类似 OpenAI 通过一个等待名单（waitlist）提供了测试者。

YouTube 数据库如何保存巨量视频文件？

Thu, 05 Jan 2023 17:32:35 CST

YouTube 是仅次于谷歌的第二大热门网站。在 2019 年 5 月，每分钟会有超过 500 小时的视频内容上传到该平台。

该视频共享平台有超过 20 亿的用户，每天有超过10亿小时的视频被播放，产生数十亿的浏览量。这些都是令人难以置信的数字。

本文会对 YouTube 使用的数据库和后端数据基础设施进行深入讲解，它们使得该视频平台能够存储如此巨量的数据，并能扩展至数十亿的用户。

那我们就开始吧。

1.引言

YouTube 的旅程开始于 2005 年。随着这家由风险资本资助的技术初创公司不断取得成功，它于 2006 年 11 月被谷歌以 16.5 亿美元收购。

在被谷歌收购之前，它们的团队由以下人员组成：

两名系统管理员
两名可扩展性软件架构师
两名特性开发人员
两名网络工程师
一名 DBA

2.后端基础设施

YouTube 的后端微服务是由Python、数据库、硬件、Java（使用了Guice框架）和 Go 编写的。用户界面是使用JavaScript编写的。

主要的数据库是由 Vitess 支撑的 MySQL，Vitess是一个数据库集群系统，用于 MySQL 的水平扩展。另外，使用 Memcache 实现缓存并使用 Zookeeper 进行节点的协调。

流行的视频通过 CDN 来提供，而一般的、较少播放的视频则从数据库中获取。

每个视频在上传的时候，都会赋予一个唯一的标识符并且会由一个批处理 job 进行处理，该 job 会运行多个自动化的过程，比如生成缩略图、元数据、视频脚本、编码、设置货币化状态等。

VP9 & H.264/MPEG-4 AVC 高级视频编码（Advanced Video Coding codecs）会用于视频压缩，它能够使用其他编码器一半的带宽来编码 HD 和 4K 质量的视频。

视频流则是使用基于HTTP协议的动态自适应流（Dynamic Adaptive Streaming），这是一种自适应比特率的流媒体技术，能够从传统的 HTTP Web 服务器上实现高质量的视频流。通过这种技术，内容可以按照不同的比特率提供给观众。YouTube 客户端会根据观看者的互联网连接速度自动适应视频渲染，从而尽可能减少缓冲时间。

我曾经在一篇专门的文章中讨论过 YouTube 的视频转码过程，参见“YouTube是如何以低延迟提供高质量视频的”。

所以，这里对平台的后端技术有一个快速的介绍。YouTube 主要使用的数据库是 MySQL。现在，我们了解一下 YouTube 的工程团队为什么觉得有必要编写 Vitess？他们在最初的 MySQL 环境中面临的问题是什么，使他们在此基础上实现了一个额外的框架？

3.为何需要 Vitess

网站最初只有一个数据库实例。随着网站的发展，为了满足日益增长的 QPS（每秒查询次数）需求，开发人员不得不对数据库进行水平扩展。

3.1 主-从副本

副本会添加到主数据库实例中。读取请求会被路由到主数据库和副本上，以减少主数据库的负载。添加副本有助于缓解瓶颈，增加读取的吞吐量，并增加系统的持久性。

主节点处理写入的流量，主节点和副本节点同时处理读取流量。

但是，在这种场景中，有可能会从副本中读取到陈旧的数据。如果在主节点将信息更新到副本之前，一个请求读取了副本的数据，那么观看者就会得到陈旧的数据。

此时，主节点和副本节点的数据是不一致的。在这种情况下，不一致的数据是主节点和副本节点上特定视频的观看次数。

其实，这完全没有问题。观众不会介意观看次数上略微有点不一致，对吧？更重要的是，视频能够在他们的浏览器中渲染出来。

主节点和副本节点之间的数据最终会是一致的。

因此，工程师们觉得非常开心，观众们也非常开心。随着副本的引入，事情进展顺利。

网站继续受到欢迎，QPS 继续上升。主-从副本策略现在很难跟上网站流量的增长了。

那现在该怎么办？

3.2 分片

下一个策略就是对数据库进行分片（shard）。分片是除了主-从副本、主-主副本、联盟和反范式化（de-normalization）之外，扩展关系型数据库的方式之一。

数据库分片并不是一个简单的过程。它大大增加了系统的复杂性，并使得管理更加困难。

但是，数据库必须要进行分片，以满足 QPS 的增长。在开发人员将数据库分片后，数据会被分散到多台机器上。这增加了系统写入的吞吐量。现在，不再是只有一个主实例处理写入，写入操作可以在多台分片的机器上进行。

同时，每台机器都创建了单独的副本，以实现冗余和吞吐。

该平台的受欢迎程度持续上升，大量的数据被内容创作者不断添加到数据库中。

为了防止机器故障或者外部未知事件造成的数据丢失或服务不可用，此时需要在系统中添加灾难管理的功能了。

3.3 灾难管理

灾难管理指的是在面临停电和自然灾害（如地震、火灾）时的应急措施。它需要进行冗余，并将用户数据备份到世界不同地理区域的数据中心。丢失用户数据或服务不可用是不允许的。

在世界范围内拥有多个数据中心也有助于 YouTube 减少系统延迟，因为用户请求会被路由到最近的数据中心，而不是路由到位于不同大陆的原始服务器。

现在，你可以想象基础设施会变得多复杂。

经常会有未经优化的全表扫描导致整个数据库瘫痪。数据库必须进行保护，防止受到不良查询的影响。所有的服务器都需要被跟踪以确保服务的高效性。

开发人员需要有一个系统来抽象系统的复杂性，能够让他们解决可扩展性的挑战，并以最小的成本管理该系统。这一切促使 YouTube 开发了 Vitess。

4.Vitess：用于水平扩展 MySQL 数据库集群的系统

Vitess是一个运行于 MySQL 之上的数据库集群系统，能够使 MySQL 进行水平扩展。它有内置的分片特性，能够让开发人员扩展数据库，而不必在应用中添加任何的分片逻辑。这类似于 NoSQL 的做法。

Vitess 架构，图片来源

Vitess 还会自动处理 故障转移和备份。它能够管理服务器，通过智能重写资源密集型的查询和实现缓存来提高数据库性能。除了 YouTube，该框架还被业界的其他知名厂商使用，如 GitHub、Slack、Square、New Relic 等。

当你需要 ACID 事务和强一致性的支持，同时又希望像 NoSQL 数据库一样快速扩展关系型数据库时，Vitess 就会大显身手。

在 YouTube，每个 MySQL 连接都有 2MB 的开销。每一个连接都有可计算出来的成本，而且随着连接数量的增加，还必须增加额外的 RAM。

通过基于 Go 编程语言并发支持构建的连接池，Vitess 能够以很低的成本管理这些连接。它使用 Zookeeper来管理集群，并使其保持最新状态。

5.部署到云中

Vitess 是 云原生的，很适合云中部署，因为就像云的模式一样，容量是逐步添加到数据库的。它可以作为一个 Kubernetes 感知（Kubernetes-aware）的云原生分布式数据库运行。

在 YouTube，Vitess 在容器化环境中运行，并使用 Kubernetes作为容器编排工具。

在如今的计算时代，每个大规模的服务都在分布式环境的云中运行。在云中运行服务有许多好处。

Google Cloud Platform是一套云计算服务，它的基础设施与谷歌内部的终端用户产品（如谷歌搜索和 YouTube）所用的基础设施是相同的。

每个大规模的在线服务都有一个多样化（polyglot）的持久性架构，因为某一种数据模型，无论是关系型还是 NoSQL，都无法处理服务的所有使用场景。

在为本文展开的研究中，我无法找到 YouTube 所使用的具体谷歌云数据库的清单，但我非常肯定它会使用 GCP 的特有产品，如 Google Cloud Spanner、Cloud SQL、Cloud Datastore、Memorystore 等来运行服务的不同特性。

这篇文章详细介绍了其他谷歌服务所使用的数据库，如Google Adwords、Google Finance、Google Trends等。

6.CDN

YouTube 使用谷歌的全球网络进行低延迟、低成本的内容传输。借助全球分布的 POP 边缘点，它能够使客户能够更快地获取数据，而不必从原始服务器获取。

所以，到此为止，我已经谈到了 YouTube 使用的数据库、框架和技术。现在，该谈一谈存储问题了。

YouTube 是如何存储如此巨大的数据量的呢（每分钟上传 500 小时的视频内容）？

7.数据存储：YouTube 是如何存储如此巨大的数据量的呢？

视频会存储在谷歌数据中心的硬盘中。这些数据由 Google File System 和 BigTable 管理。

GFS Google File System是谷歌开发的一个分布式文件系统，用于管理分布式环境中的大规模数据。

BigTable是一个建立在 Google File System 上的低延迟分布式数据存储系统，用于处理分布在成千上万台机器上的 PB 级别的数据。60 多个谷歌产品都使用了它。

因此，视频被存储在硬盘中。关系、元数据、用户偏好、个人资料信息、账户设置、从存储中获取视频所需的相关数据等都存储在 MySQL 中。

7.1 即插即用的商用服务器

谷歌数据中心拥有同质化的硬件，软件则是内部构建的，管理成千上万的独立服务器集群。

谷歌部署的服务器，能够增强数据中心的存储能力，它们都是商用服务器（commodity server），也被称为商用现成的服务器（commercial off-the-shelf server）。这些服务器价格低廉，可广泛使用和大量购买，并能以最小的成本和代价替换或配置数据中心的相同硬件。

随着对额外存储需求的增加，新的商用服务器会被插入到系统中。

出现问题后，商用服务器通常会被直接替换，而不是进行修理。它们不是定制的，与运行定制的服务器相比，使用它们能够使企业在很大程度上减少基础设施成本。

7.2 为数据中心设计的存储磁盘

YouTube 每天都需要超过一个 PB 的新存储。旋转硬盘驱动器是主要的存储介质，因为其成本低，可靠性高。

SSD 固态硬盘比旋转磁盘具有更高的性能，因为它们是基于半导体的，但大规模使用固态硬盘并不划算。

它们相当昂贵，也容易随着时间的推移逐渐丢失数据。这使得它们不适合用于归档数据的存储。

另外，谷歌正在开发一个适用于大规模数据中心的新磁盘系列。

有五个关键指标可用来判断为数据存储而构建的硬件的质量：

硬件应该有能力支持秒级的高速度输入输出操作。
它应该符合组织规定的安全标准。
与普通存储硬件相比，它应该有更高的存储容量。
硬件采购成本、电力成本和维护费用应该都是可以接受的。
磁盘应该是可靠的，并且延迟是稳定的。

END

【WebRTC 跨端通信】React + React Native 双端视频聊天、屏幕共享

Tue, 27 Dec 2022 16:41:42 CST

大家好，我是杨成功。

之前介绍过 WebRTC，简单来说它是一个点对点的实时通讯技术，主要基于浏览器来实现音视频通信。这项技术目前已经被广泛应用于实时视频通话，多人会议等场景。

不过 WebRTC 因为其过于优秀的表现，其应用范围已经不限于 Web 端，移动 App 也基本实现了 WebRTC 的 API。在跨平台框架中，Flutter 和 React Native 都实现了对 WebRTC 的支持。

我们以 App（React Native）为呼叫端，Web（React）为接收端，分别介绍两端如何进行视频通话。

接收端 React 实现

React 运行在浏览器中，无需引用任何模块，可以直接使用 WebRTC API。下面分几个步骤，逐步介绍在 Web 端如何获取、发送、接受远程视频流。

1. 获取本地摄像头流，并保存。

  const stream = null;
const getMedia = async () => {
  let ori_stream = await navigator.mediaDevices.getUserMedia({
    audio: true,
    video: true,
  });
  stream = ori_stream;
};

2. 创建 video 标签用于播放视频。

创建两个 video 标签，分别用于播放本地视频和远程视频。

  const local_video = useRef();
const remote_video = useRef();
const Player = () => {
  return (
    <div>
      <video ref={local_video} autoPlay muted />;
      <video ref={remote_video} autoPlay muted />;
    </div>
  );
};
// stream 是上一步获取的本地视频流
if (local_video.current) {
  local_video.current.srcObject = stream;
}

3. 创建 RTC 连接实例。

每一个使用 WebRTC 通信的客户端，都要创建一个 RTCPeerConnection 连接实例，该实例是真正负责通信的角色。WebRTC 通信的实质就是 RTCPeerConnection 实例之间的通信。

  // 1. 创建实例
let peer = new RTCPeerConnection();
// 2. 将本地视频流添加到实例中
stream.getTracks().forEach((track) => {
  peer.addTrack(track, stream);
});
// 3. 接收远程视频流并播放
peer.ontrack = async (event) => {
  let [remoteStream] = event.streams;
  remote_video.current.srcObject = remoteStream;
};

实例创建之后，别忘记将上一步获取的摄像头流添加到实例中。

当两端连接完全建立之后，在 peer.ontrack 之内就能接收到对方的视频流了。

4. 连接信令服务器，准备与 App 端通信。

WebRTC 的通信过程需要两个客户端实时进行数据交换。交换内容分为两大部分：

交换 SDP（媒体信息）。
交换 ICE（网络信息）。

因此我们需要一个 WebSocket 服务器来连接两个客户端进行传输数据，该服务器在 WebRTC 中被称为 信令服务器。

我们已经基于 socket.io 搭建了信令服务器，现在需要客户端连接，方式如下。

（1）安装 socket.io-client：

  $ yarn add socket.io-client

（2）连接服务器，并监听消息。

连接服务器时带上验证信息（下面的用户 ID、用户名），方便在通信时可以找到对方。

  import { io } from 'socket.io-client';
const socket = null;
const socketInit = () => {
  let sock = io(`https://xxxx/webrtc`, {
    auth: {
      userid: '111',
      username: '我是接收端',
      role: 'reader',
    },
  });
  sock.on('connect', () => {
    console.log('连接成功');
  });
  socket = sock;
};
useEffect(() => {
  socketInit();
}, []);

经过上面 4 个步骤，我们的准备工作已经做好了。结下来可以进行正式的通信步骤了。

5. 接收 offer，交换 SDP。

监听 offer 事件（呼叫端发来的 offer 数据），然后创建 answer 并发回呼叫端。

  // 接收 offer
socket.on('offer', (data) => {
  transMedia(data);
});
// 发送 answer
const transMedia = async (data: any) => {
  let offer = new RTCSessionDescription(data.offer);
  await peer.setRemoteDescription(offer);
  let answer = await peer.createAnswer();

  socket.emit('answer', {
    to: data.from, // 呼叫端 Socket ID
    answer,
  });
  await peer.setLocalDescription(answer);
};

6. 接收 candidate，交换 ICE。

监听 candid 事件（呼叫端发来的 candidate 数据）并添加到本地 peer 实例，然后监听本地的 candidate 数据并发回给呼叫端。

上一步执行 peer.setLocalDescription() 之后，就会触发 peer.onicecandidate 事件。

  // 接收 candidate
socket.on('candid', (data) => {
  let candid = new RTCIceCandidate(data.candid);
  peer.addIceCandidate(candid);
});
// 发送 candidate
peer.onicecandidate = (event) => {
  if (event.candidate) {
    socket.emit('candid', {
      to: data.from, // 呼叫端 Socket ID
      candid: event.candidate,
    });
  }
};

至此，整个通信过程就完成了。如果没有意外，此时在第 3 步的 peer.ontrack 事件内拿到的对端视频流开始传输数据，我们可以看到对端的视频画面了。

呼叫端 React Native 实现

在 React Native 端并不能直接使用 WebRTC API，我们需要一个第三方模块 react-native-webrtc 来实现，它提供了和 Web 端几乎一致的 API。

幸运的是，React Native 可以复用 Web 端的大多数逻辑性资源，socket.io-client 可以直接安装使用，和 Web 端完全一致。

不幸的是，App 开发少不了原生的环境配置、权限配置，这些比较繁琐，接下来介绍如何实现吧。

1. 创建 React Native 项目。

创建项目之前需要配置开发环境，我们以 Android 为例，具体的配置可以看这篇文章。

配置完成之后，直接通过 npx 命令创建项目，命名为 RnWebRTC：

  $ npx react-native init RnWebRTC --template react-native-template-typescript

提示：如果不想使用 TypeScript，将 --template 选项和后面的内容去掉即可。

我安装的最新版本如下：

react: "18.1.0"
react-native: "0.70.6"

创建之后，查看根目录的 index.js 和 App.tsx 两个文件，分别是入口文件和页面组件，我们就在 App.tsx 这个组件中编写代码。

我们以安卓为例，直接用手机数据线连接电脑，打开 USB 调试模式，然后运行以下命令：

  $ yarn run android

执行该命令会安装 Gradle（安卓包管理）依赖，并编译打包 Android 应用。第一次运行耗时比较久，耐心等待打包完成后，手机上会提示安装该 App。

该命令在打包的同时，还会单独启动一个终端，运行 Metro 开发服务器。Metro 的作用是监 JS 代码修改，并打包成 js bundle 交给原生 App 去渲染。

单独启动 Metro 服务器，可运行 yarn run start。

2. 安装 react-native-webrtc。

直接运行安装命令：

  $ yarn add react-native-webrtc

安装之后并不能直接使用，需要在 android 文件夹中修改两处代码。

第一处：因为 react-native-webrtc 需要最低的安卓 SDK 版本为 24，而默认生成的最低版本是 21，所以修改 android/build.gradle 中的配置：

  buildscript {
  ext {
      minSdkVersion = 24
  }
}

第二处：webrtc 需要摄像头、麦克风等权限，所以我们把权限先配齐喽。在 android/app/src/main/AndroidManifest.xml 中的 <application> 标签前添加如下配置：

  <uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.autofocus" />
<uses-feature android:name="android.hardware.audio.output" />
<uses-feature android:name="android.hardware.microphone" />

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
<uses-permission android:name="android.permission.INTERNET" />

接着执行命令重新打包安卓：

  $ yarn run android

现在就可以在 App.tsx 中导入和使用 WebRTC 的相关 API 了：

  import {
  ScreenCapturePickerView,
  RTCPeerConnection,
  RTCIceCandidate,
  RTCSessionDescription,
  RTCView,
  MediaStream,
  MediaStreamTrack,
  mediaDevices,
} from 'react-native-webrtc';

3. 连接信令服务器，准备与 Web 端通信。

因为 React Native 可以直接使用 socket.io-client 模块，所以这一步和 Web 端的代码一致。

  $ yarn add socket.io-client

连接信令服务器时，只是传递的验证信息不同：

  import { io } from 'socket.io-client';
const socket = null;
const socketInit = () => {
  let sock = io(`https://xxxx/webrtc`, {
    auth: {
      userid: '222',
      username: '我是呼叫端',
      role: 'sender',
    },
  });
  sock.on('connect', () => {
    console.log('连接成功');
  });
  socket = sock;
};
useEffect(() => {
  socketInit();
}, []);

4. 使用 RTCView 组件播放视频。

创建两个 RTCView 组件，分别用于播放本地视频和远程视频。

  import { mediaDevices, RTCView } from 'react-native-webrtc';
var local_stream = null;
var remote_stream = null;
// 获取本地摄像头
const getMedia = async () => {
  local_stream = await mediaDevices.getUserMedia({
    audio: true,
    video: true,
  });
};
// 播放视频组件
const Player = () => {
  return (
    <View>
      <RTCView style={{ height: 500 }} streamURL={local_stream.toURL()} />
      <RTCView style={{ height: 500 }} streamURL={remote_stream.toURL()} />
    </View>
  );
};

5. 创建 RTC 连接实例。

这一步与 Web 端基本一致，接收到远端流直接赋值。

  // 1. 创建实例
let peer = new RTCPeerConnection();
// 2. 将本地视频流添加到实例中
local_stream.getTracks().forEach((track) => {
  peer.addTrack(track, local_stream);
});
// 3. 接收远程视频流
peer.ontrack = async (event) => {
  let [remoteStream] = event.streams;
  remote_stream = remoteStream;
};

6. 创建 offer，开始交换 SDP。

App 端作为呼叫端，需要主动创建 offer 并发给接收端，并监听接收端发回的 answer：

  // 发送 offer
const peerInit = async (socket_id) => {
  let offer = await peer.createOffer();
  peer.setLocalDescription(offer);
  socket.emit('offer', {
    to: socket_id, // 接收端 Socket ID
    offer: offer,
  });
};
// 接收 answer
socket.on('answer', (data) => {
  let answer = new RTCSessionDescription(data.answer);
  peer.setRemoteDescription(answer);
});

7. 监听 candidate，交换 ICE。

这一步依然与 Web 端一致，分别是发送本地的 candidate 和接收远程的 candidate：

  // 发送 candidate
peer.onicecandidate = (event) => {
  if (event.candidate) {
    socket.emit('candid', {
      to: socket_id, // 接收端 Socket ID
      candid: event.candidate,
    });
  }
};
// 接收 candidate
socket.on('candid', (data) => {
  let candid = new RTCIceCandidate(data.candid);
  peer.addIceCandidate(candid);
});

至此，App 端与 Web 端的视频通话流程已经完成，现在两端可以互相看到对方的视频画面了。

搭建 socket.io 信令服务器

在 Web 和 App 两端视频通话时用到了信令服务器，该服务使用 socket.io 实现，代码并不复杂，下面介绍下信令服务器如何编写：

1. 创建项目，安装需要的依赖。

创建 socket-server 文件夹，并执行以下命令生成 package.json：

  $ npm init

接着安装必要的模块：

  $ npm install koa socket.io

2. 创建入口文件，启动 socket 服务。

创建 app.js 文件，写入以下代码：

  const Koa = require('koa');
const http = require('http');
const SocketIO = require('socket.io');
const SocketIoApi = require('./io.js');

const app = new Koa();

const server = http.createServer(app.callback());

const io = new SocketIO.Server(server, {
  cors: { origin: '*' },
  allowEIO3: true,
});
app.context.io = io; // 将socket实例存到全局

new SocketIoApi(io);

server.listen(9800, () => {
  console.log(`listen to http://localhost:9800`);
});

代码中使用 Koa 框架运行一个服务器，并且接入了 socket.io，一个基本的 WebSocket 服务器就写好了。接着将它运行起来：

  $ node app.js

此时 Koa 运行的 HTTP 服务器和 socket.io 运行的 WebSocket 服务器共享 9800 端口。

3. 创建 io.js，编写信令服务器逻辑。

上一步在入口文件 app.js 中引用了 io.js，该文件导出一个类，我们来编写具体的逻辑：

  // io.js
class IoServer {
  constructor(io) {
    this.io = io;
    this.rtcio = io.of('/webrtc');
    this.rtcio.on('connection', (socket) => {
      this.rtcListen(socket);
    });
  }
  rtcListen(socket) {
    // 发送端｜发送 offer
    socket.on('offer', (json) => {
      let { to, offer } = json;
      let target = this.rtcio.sockets.get(to);
      if (target) {
        target.emit('offer', {
          from: socket.id,
          offer,
        });
      } else {
        console.error('offer 接收方未找到');
      }
    });
    // 接收端｜发送 answer
    socket.on('answer', (json) => {
      let { to, answer } = json;
      let target = this.rtcio.sockets.get(to);
      // console.log(to, socket)
      if (target) {
        target.emit('answer', {
          from: socket.id,
          answer,
        });
      } else {
        console.error('answer 接收方未找到');
      }
    });
    // 发送端｜发送 candidate
    socket.on('candid', (json) => {
      let { to, candid } = json;
      let target = this.rtcio.sockets.get(to);
      // console.log(to, socket)
      if (target) {
        target.emit('candid', {
          from: socket.id,
          candid,
        });
      } else {
        console.error('candid 接收方未找到');
      }
    });
  }
}

module.exports = IoServer;

上面代码的逻辑中，当客户端连接到服务器，就开始监听 offer， answer， candid 三个事件。当有客户端发送消息，这里负责将消息转发给另一个客户端。

两个客户端通过唯一的 Socket ID 找到对方。在 socket.io 中，每一次连接都会产生一个唯一的 Socket Id。

4. 获取已连接的接收端列表。

因为每次刷新浏览器 WebSocket 都要重新连接，因此每次的 Socket ID 都不相同。为了在呼叫端准确找到在线的接收端，我们写一个获取接收端列表的接口。

在入口文件中通过 app.context.io = io 将 SocketIO 实例全局存储到了 Koa 中，那么获取已连接的接收端方式如下：

  app.get('/io-clients', async (ctx, next) => {
  let { io } = ctx.app.context;
  try {
    let data = await io.of('/webrtc').fetchSockets();
    let resarr = data
      .map((row) => ({
        id: row.id,
        auth: row.handshake.auth,
        data: row.data,
      }))
      .filter((row) => row.auth.role == 'reader');
    ctx.body = { code: 200, data: resarr };
  } catch (error) {
    ctx.body = error.toString();
  }
});

然后在呼叫端使用 GET 请求 https://xxxx/io-clients 可拿到在线接收端的 Socket ID 和其他信息，然后选择一个接收端发起连接。

注意：在线上获取摄像头和屏幕时要求域名必须是 https，否则无法获取。因此切记给 Web 端和信令服务器都配置好 https 的域名，可以避免通信时发生异常。

TURN 跨网络视频通信

前面我们实现了 App 端和 Web 端双端通信，但是通信成功有一个前提： 两端必须连接同一个 WIFI。

这是因为 WebRTC 的通信是基于 IP 地址和端口来找到对方，如果两端连接不同的 WIFI（不在同一个网段），或是 App 用流量 Web 端用 WIFI，那么两端的 IP 地址谁都不认识谁，自然无法建立通信。

当两端不在一个局域网时，优先使用 STUN 服务器，将两端的本地 IP 转换为公网 IP 进行连接。STUN 服务器我们直接使用谷歌的就可以，但是因为防火墙等各种原因，实际测试 STUN 基本是连不通的。

当两端不能找到对方，无法直接建立连接时，那么我们就要使用兜底方案 ——— 用一个中继服务器转发数据，将媒体流数据转发给对方。该中继服务器被称为 TURN 服务器。

TURN 服务器因为要转发数据流，因此对带宽消耗比较大，需要我们自己搭建。目前有很多开源的 TURN 服务器方案，经过性能测试，我选择使用 Go 语言开发的 pion/turn 框架。

1. 安装 Golang：

使用 pion/turn 的第一步是在你的服务器上安装 Golang。我使用的是 Linux Centos7 系统，使用 yum 命令安装最方便。

  $ yum install -y epel-release # 添加 epel 源
$ yum install -y golang # 直接安装

安装之后使用如下命令查看版本，测试是否安装成功：

  $ go version
go version go1.17.7 linux/amd64

2. 运行 pion/turn：

直接将 pion/turn 的源码拉下来：

  $ git clone https://github.com/pion/turn ./pion-turn

源码中提供了很多案例可以直接使用，我们使用 examples/turn-server/simple 这个目录下的代码：

  $ cd ./pion-turn/examples/turn-server/simple
$ go build

使用 go build 编译后，当前目录下会生成一个 simple 文件，该文件是可执行文件，使用该文件启动 TURN 服务器：

  $ ./simple -public-ip 123.45.67.89 -users ruidoc=123456

上面命令中的 123.45.67.89 是你服务器的公网 IP，并配置一个用户名和密码分别为 ruidoc 和 123456，这几项配置根据你的实际情况设置。

默认情况下该命令不会后台运行，我们用下面的方式让它后台运行：

  $ nohup ./simple -public-ip 123.45.67.89 -users ruidoc=123456 &

此时，该 TURN 服务已经在后台运行，并占用一个 3478 的 UDP 端口。我们查看一下端口占用：

  $ netstat -nplu

从上图可以看出，该服务已经在运行中。

3. 配置安全组、检测 TURN 是否可用。

上一步已经启动了 TURN 服务器，但是默认情况下从外部连接不上（这里是个坑），因为阿里云需要在安全组的入方向添加一条 UPD 3478 端口（其他云服务商也差不多），表示该端口允许从外部访问。

安全组添加后，我们就可以测试 TURN 服务器的连通性了。

打开 Trickle ICE，添加我们的 TURN 服务器，格式为 turn:123.45.67.89:3478，然后输入上一步配置的用户名和密码：

点击 Gather candidates 按钮，会列出以下信息。如果包含 relay 这一条，说明我们的 TURN 服务器搭建成功，可以使用了。

4. 客户端添加 ICE 配置。

在 App 端和 Web 端创建 RTC 实例时，加入以下配置：

  var turnConf = {
  iceServers: [
    {
      urls: 'stun:stun1.l.google.com:19302', // 免费的 STUN 服务器
    },
    {
      urls: 'turn:123.45.67.89:3478',
      username: 'ruidoc',
      credential: '123456',
    },
  ],
};
var peer = new RTCPeerConnection(turnConf);

现在关闭手机 WIFI，使用流量与 Web 端发起连接，不出意外可以正常通信，但是延迟好像高了一些（毕竟走中转肯定没有直连快）。此时再打开手机 WIFI 重新连接，发现延迟又变低了。

这就是 WebRTC 智能的地方。它会优先尝试直连，如果直连不成功，最后才会使用 TURN 转发。

App 端屏幕共享

视频通话一般都是共享摄像头，然而有的时候会有共享屏幕的需求。

在 Web 端共享屏幕很简单，将 getUserMedia 改成 getDisplayMedia 即可。然而在 App 端，可能因为隐私和安全问题，实现屏幕共享比较费劲。

安卓原生端使用 mediaProjection 实现共享屏幕。在 Android 10+ 之后，如果想正确共享屏幕，必须要有一个持续存在的“前台进程”来保证屏幕共享的进程不被系统自动杀死。

如果没有配置前台进程，则屏幕流无法传输。下面我们来介绍下在如何 App 端共享屏幕。

1. 安装 Notifee。

Notifee 是 React Native 实现通知栏消息的第三方库。我们可以启动一个持续存在的消息通知作为前台进程，从而使屏幕流正常推送。

使用命令安装 Notifee：

  $ yarn add @notifee/react-native@5

注意这里安装 Notifee 5.x 的版本，因为最新版的 7.x 需要 Android SDK 的 compileSdkVersion 为 33，而我们创建的项目默认为 31，使用 5.x 不需要修改 SDK 的版本号。

2. 注册前台服务。

在入口文件 index.js 中，我们使用 Notifee 注册一个前台服务：

  import notifee from '@notifee/react-native';
notifee.registerForegroundService((notification) => {
  return new Promise(() => {});
});

这里只需要注册一下，不需要其他操作，因此比较简单。接着还需要在 Android 代码中注册一个 service，否则前台服务不生效。

打开 android/app/src/main/AndroidManifest.xml 文件，在 <application> 标签内添加如下代码：

  <service
   android:name="app.notifee.core.ForegroundService"
   android:foregroundServiceType="mediaProjection|camera|microphone" />

3. 创建前台通知。

注册好前台服务之后，接着我们在获取屏幕前创建前台通知，代码如下：

  import notifee from '@notifee/react-native';
const startNoti = async () => {
  try {
    let channelId = await notifee.createChannel({
      id: 'default',
      name: 'Default Channel',
    });
    await notifee.displayNotification({
      title: '屏幕录制中...',
      body: '在应用中手动关闭该通知',
      android: {
        channelId,
        asForegroundService: true, // 通知作为前台服务，必填
      },
    });
  } catch (err) {
    console.error('前台服务启动异常：', err);
  }
};

该方法会创建一个通知消息，具体 API 可以参考 Notifee 文档。接着在捕获屏幕之前调用该方法即可：

  const getMedia = async () => {
  await startNoti();
  let stream = await mediaDevices.getDisplayMedia();
};

最终经过测试，可以看到 App 端和 Web 端的屏幕都实现了共享。App 端效果如下：

Web 端效果如下：

摄像头与屏幕视频混流

在一些直播教学的场景中，呼叫端会同时共享两路视频 ——— 屏幕画面和摄像头画面。在我们的经验中，一个 RTC 连接实例中只能添加一条视频流。

如果要同时共享屏幕和摄像头，我们首先想到的方案可能是在一个客户端创建两个 peer 实例，每个实例中添加一路视频流，发起两次 RTC 连接。

事实上这种方案是低效的，增加复杂度的同时也增加了资源的损耗。那么能不能在一个 peer 实例中添加两路视频呢？其实是可以的。

总体思路：在呼叫端将两条流合并为一条，在接收端再将一条流拆分为两条。

1. 呼叫端组合流。

组合流其实很简单。因为流是由多个媒体轨道组成，我们只需要从屏幕和摄像头中拿到媒体轨道，再将它们塞到一个自定义的流中，一条包含两个视频轨道的流就组合好了。

  var stream = new MediaStream();
const getMedia = async () => {
  let camera_stream = await mediaDevices.getUserMedia();
  let screen_stream = await mediaDevices.getDisplayMedia();
  screen_stream.getVideoTracks().map((row) => stream.addTrack(row));
  camera_stream.getVideoTracks().map((row) => stream.addTrack(row));
  camera_stream.getAudioTracks().map((row) => stream.addTrack(row));
};

代码中为一个自定义媒体流添加了三条媒体轨道，分别是屏幕视频、摄像头视频和摄像头音频。记住这个顺序，在接收端按照该顺序拆流。

接着将这条媒体流添加到 peer 实例中，后面走正常的通信逻辑即可：

  stream.getTracks().forEach((track) => {
  peer.addTrack(track, stream);
});

2. 接收端拆解流。

接收端在 ontrack 事件中拿到组合流，进行拆解：

  peer.ontrack = async (event: any) => {
  const [remoteStream] = event.streams;
  let screen_stream = new MediaStream();
  let camera_stream = new MediaStream();
  remoteStream.getTracks().forEach((track, ind) => {
    if (ind == 0) {
      screen_stream.addTrack(track);
    } else {
      camera_stream.addTrack(track);
    }
  });
  video1.srcObject = camera_stream; // 播放摄像头音视频
  video2.srcObject = screen_stream; // 播放屏幕视频
};

这一步中，定义两条媒体流，然后将接收到的混合流中的媒体轨道拆分，分别添加到两条流中，这样屏幕流和摄像头流就拆开了，分别在两个 video 中播放即可。

总结

本篇比较系统的介绍了 App 端和 Web 端使用 WebRTC 通信的全流程，可以看到整个流程还是比较复杂的。尤其是我们前端不擅长的地方，比如 TURN 搭建和连通，App 端的各种版本权限问题，坑还是很多的。

如果有小伙伴在这个流程中遇到了问题，欢迎加我微信 ruidoc 拉你进入跨端与音视频讨论群提问，或者关注我的公众号程序员成功查看更多文章。

再次感谢您的阅读～

短视频运营该如何考核？

Wed, 12 Oct 2022 17:34:29 CST

近年来，短视频行业不断崛起，不少企业都纷纷入局短视频行业。但对于该行业的岗位管理，许多企业仍然不知道如何运营管理，制定相应的模板和结果，驱动员工自发成长，从中获取更大利益。那么短视频运营的绩效应该如何制定？

近年来短视频行业快速崛起，市场规模持续扩大，加之疫情“宅家”的要求，间接加速了短视频用户规模的强势增长。

据统计，我国短视频用户规模由2016年的1.9亿人增长至2021年8.97亿人。以当下最火热的两个平台举例：视频号月活用户达到8亿，抖音月活用户达到6.8亿。

在这样的行业背景下，越来越多的企业和个人都开设起短视频账号，想要从中获取流量红利。

而对许多传统企业的老板而言，他们根本不懂短视频，也不知道如何运营管理，如何制定合理有效的考核标准，最后的结果差强人意。

所以绩效考核对于企业管理的重要性不言而喻，有效制定目标和结果，可以驱动员工自我成长，实现企业和员工的双赢。

那么短视频运营的绩效应该如何制定？

01 短视频运营的工作内容

首先要界定公司里短视频运营的工作内容是什么，确定岗位职责后再制定具体的绩效考核内容。

通常一个完整的短视频团队架构包括：编导、摄像、剪辑、演员、运营等。但大部分企业的短视频团队并不成熟，很多时候需要一人身兼多职，尤其对运营岗位提出了更高的要求。

boss直聘某企业短视频运营要求

短视频运营，需要负责以下核心的工作内容：

1）内容产出。负责内容的选题、脚本的撰写、视频的拍摄、后期剪辑、道具准备等；

2）账号维护。负责账号的定位、日常运营维护、广告投放等；

3）粉丝运营。对粉丝量、评论数、意向用户等指标负责；

4）数据复盘。能够对播放量、点赞量、分享量等视频数据进行分析优化。

当然，最终企业要招多少人，招什么样的人，要取决于企业本身的业务需求和目标来决定。

每家短视频公司对绩效考核的理解都不同，但关键在于不能为了考核而考核。下面说说具体如何来制定考核标准。

02 绩效考核如何制定？

每个账号在不同阶段，考核重点也不一样，例如：

账号刚起步1-3个月属于孵化期，应该重点关注视频的更新数量、播放量；
3-6个月属于账号的运营期，应该重点关注粉丝增长量；
6个月以上属于变现期，多关注直播的数据；

运营的薪资结构建议比例是：70%底薪+30%绩效，再把绩效分为两部分：

KPI（可以衡量的，业绩数据），占比80%。
KCI（不可衡量的，工作态度），占比20%。

做到既看结果，也看过程。

可衡量的关键绩效指标KPI，主要包括以下内容（仅供参考，实际根据账号体量来定）：

1）制作视频数量

按照视频发布的数量进行打分，例如：数量≥10条，100分；数量≥5条<10条，80分；数量<5条，30分。

2）视频作品数据

播放量：总播放量≥300万；要求至少有3条播放量破10万；达到以上任意1条，100分；低于任意1条，80分
点赞数：点赞总量高于10万；至少3条点赞量破1万；达到以上任意1条，100分；低于任意1条，80分
分享数：总分享量≥1万，100分；总分享量<1万，80分

3）账号用户量

粉丝量：粉丝净增长量≥10万，100分；粉丝净增长量<10万，80分
评价数：意向评价数≥100条，100分；意向评价数<100条，80分
私信数：向咨询用户≥50条，100分；意向咨询用户<50条，80分
官网链接（蓝V账号）：表单有效报名信息≥50条，100分；表单有效报名信息<50条，80分

不可衡量的关键胜任能力指标KCI，主要包括以下内容：

1）工作态度（上级主观评价）

一般包括：

基本素质：处理问题能力；沟通能力；执行力

日常纪律：出勤；提交日报、周报、月报

2）部门贡献

总结输出、培训、提供可执行方案等

03 绩效考核的注意事项

1. 什么时候考核变现？

变现是每个企业老板最关心的问题，也是企业做账号的最终目的，但是如果过早的去追求变现，是难的，变现的前提条件是：有一定的粉丝量；粉丝粘性高；

如果均不具备，请一定要花时间精力是做好内容，内容是本质。垂直类账号建议粉丝量在5万以上，非垂直类账号建议粉丝量在10万以上（仅供参考）。

2. 考核要注重奖罚分明

员工的绩效考核指标抓取不准、量化程度低、没有明确的评分标准和数据来源，导致次月初绩效考评的时候上级主观凭评分多。

公司花了大量精力和时间得到的结果就是大家绩效考核分“都很好”，流于形式，没有奖罚，大家不重视，导致恶性循环。

3. 制定合理工资标准

通常短视频运营，尤其和直播或变现挂钩，工资都会有较大的浮动。所以在和员工签订合同时，要制定合理的工资标准，避免后期产生纠纷。

4. 绩效没有过程检查与辅导

有些企业没有对绩效指标建立跟进与辅导机制，到月底的时候才把考核表拿出来评分，那个时候没有完成的也来不及完成了。

有的过程数据没有记录下来，导致月底的时候自己都忘记了考核数据的实际情况，就凭印象打个分。

绩效考核的目的是促进公司、部门、岗位的目标的达成，绝对不是为了绩效考核而考核。

作者：晏涛三寿；微信公众号：晏涛三寿；

本文由@晏涛三寿原创发布于运营派，未经作者许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

Meta 宣布文本视频生成器 Make-A-Video

Fri, 30 Sep 2022 16:53:40 CST

在文本图像生成器流行之后，Meta 宣布了文本视频生成器 Make-A-Video，可通过文本或图像提示生成视频内容。Meta 演示了利用一段文字描述或一幅静态图像生成视频的效果，比如一幅海龟图像在处理之后变成了海龟游泳视频。Make-A-Video 是基于现有的文本图像生成模型，如 OpenAI 的 DALL-E。Meta 在今年 7 月发布了自己的文本图像模型 Make-A-Scene。该公司还没有透露何时向公众提供 Make-A-Video，感兴趣的用户现在可以先注册。

谷歌向 TikTok 发起挑战，YouTube 短视频作者可获得 45% 的广告收入分成

Wed, 21 Sep 2022 07:06:45 CST

北京时间 9 月 21 日早间消息，谷歌旗下视频平台 YouTube 正试图在短视频市场上追赶 TikTok，为此该公司宣布，将开始向热门短视频创作者提供更大份额的广告收入。

在美国当地时间周二举行的“Made on YouTube，”年度创作者活动上，YouTube 首席产品官尼尔・莫汉（Neal Mohan）表示，从明年开始，该公司将拿出短视频收入的一部分，将其分给高点击量视频的创作者。

莫汉表示：“这是我们第一次大规模地向短视频创作者提供真正的收入分成。”

目前还不清楚这个机会能给短视频创作者带来多少收入，原因是 YouTube 提供的分成相关信息还比较有限。YouTube 表示，该公司每个月都会将短视频的广告收入汇集成一个资金池，并将其中一部分收入分配给创作者（但并未披露具体的百分比），然后 YouTube 将把其中的 45% 支付给创作者。

长期以来，热门视频创作者一直都能在 YouTube 的主网站上通过在视频中投放广告并保留一部分收入来赚钱。早在 2007 年，谷歌就推出了 YouTube 合作伙伴计划（YPP）以实现这一目标。

但到目前为止，通过做短视频在 YouTube 上赚钱的唯一途径是通过该公司去年推出的 1 亿美元的“短视频基金”（Shorts Fund）。

YouTube 周二发布博文称：“从 2023 年初开始，专注于短视频的创作者可以申请加入 YouTube 合作伙伴计划，条件是在 90 天内达到 1000 名订阅者和 1000 万短视频浏览量的门槛。”

莫汉表示：“短视频基金是我们迈出的第一步，但随着短视频领域令人难以置信的增长，这个创作者基金已经跟不上需求了。”

YouTube 感受到了来自 TikTok 的压力，后者为人们提供了一个配乐制作病毒式短视频的渠道，从而获得了越来越多的市场份额。今年第二季度，YouTube 的季度营收增速下降到了自谷歌母公司 Alphabet 于 2019 年第四季度开始公布视频部门销售额以来的最低水平。

Alphabet 表示，该公司正在测试短视频的盈利模式，首席财务官露丝・波拉特（Ruth Porat）此前表示，YouTube 正在受到人们变得越来越青睐短视频这一消费者行为变化所带来的挑战。

在新的短视频收入分成模式中，无论创作者的短视频是否包含受版权保护的音乐，都将获得相同数额的分成，而这就需要 YouTube 支付授权费。

“这可以让我们摆脱所有涉及音乐授权的传统复杂性。”莫汉表示。

一般来说，YouTube 视频创作者有 55% 的收入来自在视频开头或中间播放的广告。在短视频中，广告不会附加到特定的视频上，而是在两个视频之间以及短视频信息流中播放。

莫汉表示，目前 YouTube 短视频的每日浏览量为 300 亿次，每月有 15 亿登录观众观看，与该公司此前在 4 月公布的数据相比持平。

vivo 短视频推荐去重服务的设计实践

Wed, 06 Apr 2022 01:34:55 CST

一、概述

1.1 业务背景

vivo短视频在视频推荐时需要对用户已经看过的视频进行过滤去重，避免给用户重复推荐同一个视频影响体验。在一次推荐请求处理流程中，会基于用户兴趣进行视频召回，大约召回2000~10000条不等的视频，然后进行视频去重，过滤用户已经看过的视频，仅保留用户未观看过的视频进行排序，选取得分高的视频下发给用户。

1.2 当前现状

当前推荐去重基于Redis Zset实现，服务端将播放埋点上报的视频和下发给客户端的视频分别以不同的Key写入Redis ZSet，推荐算法在视频召回后直接读取Redis里对应用户的播放和下发记录（整个ZSet），基于内存中的Set结构实现去重，即判断当前召回视频是否已存在下发或播放视频Set中，大致的流程如图1所示。

（图1：短视频去重当前现状）

视频去重本身是基于用户实际观看过的视频进行过滤，但考虑到实际观看的视频是通过客户端埋点上报，存在一定的时延，因此服务端会保存用户最近100条下发记录用于去重，这样就保证了即使客户端埋点还未上报上来，也不会给用户推荐了已经看过的视频（即重复推荐）。而下发给用户的视频并不一定会被曝光，因此仅保存100条，使得未被用户观看的视频在100条下发记录之后仍然可以继续推荐。

当前方案主要问题是占用Redis内存非常大，因为视频ID是以原始字符串形式存在Redis Zset中，为了控制内存占用并且保证读写性能，我们对每个用户的播放记录最大长度进行了限制，当前限制单用户最大存储长度为10000，但这会影响重度用户产品体验。

二、方案调研

2.1 主流方案

第一，存储形式。视频去重场景是典型的只需要判断是否存在即可，因此并不需要把原始的视频ID存储下来，目前比较常用的方案是使用布隆过滤器存储视频的多个Hash值，可降低存储空间数倍甚至十几倍。

第二，存储介质。如果要支持存储90天（三个月）播放记录，而不是当前粗暴地限制最大存储10000条，那么需要的Redis存储容量非常大。比如，按照5000万用户，平均单用户90天播放10000条视频，每个视频ID占内存25B，共计需要12.5TB。视频去重最终会读取到内存中完成，可以考虑牺牲一些读取性能换取更大的存储空间。而且，当前使用的Redis未进行持久化，如果出现Redis故障会造成数据丢失，且很难恢复（因数据量大，恢复时间会很长）。

目前业界比较常用的方案是使用磁盘KV（一般底层基于RocksDB实现持久化存储，硬盘使用SSD），读写性能相比Redis稍逊色，但是相比内存而言，磁盘在容量上的优势非常明显。

2.2 技术选型

第一，播放记录。因需要支持至少三个月的播放历史记录，因此选用布隆过滤器存储用户观看过的视频记录，这样相比存储原始视频ID，空间占用上会极大压缩。我们按照5000万用户来设计，如果使用Redis来存储布隆过滤器形式的播放记录，也将是TB级别以上的数据，考虑到我们最终在主机本地内存中执行过滤操作，因此可以接受稍微低一点的读取性能，选用磁盘KV持久化存储布隆过滤器形式的播放记录。

第二，下发记录。因只需存储100条下发视频记录，整体的数据量不大，而且考虑到要对100条之前的数据淘汰，仍然使用Redis存储最近100条的下发记录。

三、方案设计

基于如上的技术选型，我们计划新增统一去重服务来支持写入下发和播放记录、根据下发和播放记录实现视频去重等功能。其中，重点要考虑的就是接收到播放埋点以后将其存入布隆过滤器。在收到播放埋点以后，以布隆过滤器形式写入磁盘KV需要经过三步，如图2所示：第一，读取并反序列化布隆过滤器，如布隆过滤器不存在则需创建布隆过滤器；第二，将播放视频ID更新到布隆过滤器中；第三，将更新后的布隆过滤器序列化并回写到磁盘KV中。

（图2：统一去重服务主要步骤）

整个过程很清晰，但是考虑到需要支持千万级用户量，假设按照5000万用户目标设计，我们还需要考虑四个问题：

第一，视频按刷次下发（一刷5~10条视频），而播放埋点按照视频粒度上报，那么就视频推荐消重而言，数据的写入QPS比读取更高，然而，相比Redis磁盘KV的性能要逊色，磁盘KV本身的写性能比读性能低，要支持5000万用户量级，那么如何实现布隆过滤器写入磁盘KV是一个要考虑的重要问题。
第二，由于布隆过滤器不支持删除，超过一定时间的数据需要过期淘汰，否则不再使用的数据将会一直占用存储资源，那么如何实现布隆过滤器过期淘汰也是一个要考虑的重要问题。
第三，服务端和算法当前直接通过Redis交互，我们希望构建统一去重服务，算法调用该服务来实现过滤已看视频，而服务端基于Java技术栈，算法基于C++技术栈，那么需要在Java技术栈中提供服务给C++技术栈调用。我们最终采用gRPC提供接口给算法调用，注册中心采用了Consul，该部分非重点，就不详细展开阐述。
第四，切换到新方案后我们希望将之前存储在Redis ZSet中的播放记录迁移到布隆过滤器，做到平滑升级以保证用户体验，那么设计迁移方案也是要考虑的重要问题。

3.1 整体流程

统一去重服务的整体流程及其与上下游之间的交互如图3所示。服务端在下发视频的时候，将当次下发记录通过统一去重服务的Dubbo接口保存到Redis下发记录对应的Key下，使用Dubbo接口可以确保立即将下发记录写入。同时，监听视频播放埋点并将其以布隆过滤器形式存放到磁盘KV中，考虑到性能我们采用了批量写入方案，具体下文详述。统一去重服务提供RPC接口供推荐算法调用，实现对召回视频过滤掉用户已观看的视频。

（图3：统一去重服务整体流程）

磁盘KV写性能相比读性能差很多，尤其是在Value比较大的情况下写QPS会更差，考虑日活千万级情况下磁盘KV写性能没法满足直接写入要求，因此需要设计写流量汇聚方案，即将一段时间以内同一个用户的播放记录汇聚起来一次写入，这样就大大降低写入频率，降低对磁盘KV的写压力。

3.2 流量汇聚

为了实现写流量汇聚，我们需要将播放视频先暂存在Redis汇聚起来，然后隔一段时间将暂存的视频生成布隆过滤器写入磁盘KV中保存，具体而言我们考虑过N分钟仅写入一次和定时任务批量写入两种方式。接下来详细阐述我们在流量汇聚和布隆过滤器写入方面的设计和考虑。

3.2.1 近实时写入

监听到客户端上报的播放埋点后，原本应该直接将其更新到布隆过滤器并保存到磁盘KV，但是考虑到降低写频率，我们只能将播放的视频ID先保存到Redis中，N分钟内仅统一写一次磁盘KV，这种方案姑且称之为近实时写入方案吧。

最朴素的想法是每次写的时候，在Redis中保存一个Value，N分钟以后失效，每次监听到播放埋点以后判断这个Value是否存在，如果存在则表示N分钟内已经写过一次磁盘KV本次不写，否则执行写磁盘KV操作。这样的考虑主要是在数据产生时，先不要立即写入，等N分钟汇聚一小批流量之后再写入。这个Value就像一把“锁”，保护磁盘KV每隔N分钟仅被写入一次，如图4所示，如果当前为已加锁状态，再进行加锁会失败，可保护在加锁期间磁盘KV不被写入。从埋点数据流来看，原本连续不断的数据流，经过这把“锁”就变成了每隔N分钟一批的微批量数据，从而实现流量汇聚，并降低磁盘KV的写压力。

（图4：近实时写入方案）

近实时写入的出发点很单纯，优势也很明显，可以近实时地将播放埋点中的视频ID写入到布隆过滤器中，而且时间比较短（N分钟），可以避免Redis Zset中暂存的数据过长。但是，仔细分析还需要考虑很多特殊的场景，主要如下：

第一，Redis中保存一个Value其实相当于一个分布式锁，实际上很难保证这把“锁”是绝对安全的，因此可能会存在两次收到播放埋点均认为可以进行磁盘KV写操作，但这两次读到的暂存数据不一定一样，由于磁盘KV不支持布隆过滤器结构，写入操作需要先从磁盘KV中读出当前的布隆过滤器，然后将需要写入的视频ID更新到该布隆过滤器，最后再写回到磁盘KV，这样的话，写入磁盘KV后就有可能存在数据丢失。

第二，最后一个N分钟的数据需要等到用户下次再使用的时候才能通过播放埋点触发写入磁盘KV，如果有大量不活跃的用户，那么就会存在大量暂存数据遗留在Redis中占用空间。此时，如果再采用定时任务来将这部分数据写入到磁盘KV，那么也会很容易出现第一种场景中的并发写数据丢失问题。

如此看来，近实时写入方案虽然出发点很直接，但是仔细想来，越来越复杂，只能另寻其他方案。

3.2.2 批量写入

既然近实时写入方案复杂，那不妨考虑简单的方案，通过定时任务批量将暂存的数据写入到磁盘KV中。我们将待写的数据标记出来，假设我们每小时写入一次，那么我们就可以把暂存数据以小时值标记。但是，考虑到定时任务难免可能会执行失败，我们需要有补偿措施，常见的方案是每次执行任务的时候，都在往前多1~2个小时的数据上执行任务，以作补偿。但是，明显这样的方案并不够优雅，我们从时间轮得到启发，并基于此设计了布隆过滤器批量写入的方案。

我们将小时值首尾相连，从而得到一个环，并且将对应的数据存在该小时值标识的地方，那么同一小时值（比如每天11点）的数据是存在一起的，如果今天的数据因任务未执行或执行失败未同步到磁盘KV，那么在第二天将会得到一次补偿。

顺着这个思路，我们可以将小时值对某个值取模以进一步缩短两次补偿的时间间隔，比如图5所示对8取模，可见1:00~2:00和9:00~10:00的数据都会落在图中时间环上的点1标识的待写入数据，过8个小时将会得到一次补偿的机会，也就是说这个取模的值就是补偿的时间间隔。

（图5：批量写入方案）

那么，我们应该将补偿时间间隔设置为多少呢？这是一个值得思考的问题，这个值的选取会影响到待写入数据在环上的分布。我们的业务一般都会有忙时、闲时，忙时的数据量会更大，根据短视频忙闲时特点，最终我们将补偿间隔设置为6，这样业务忙时比较均匀地落在环上的各个点。

确定了补偿时间间隔以后，我们觉得6个小时补偿还是太长了，因为用户在6个小时内有可能会看过大量的视频，如果不及时将数据同步到磁盘KV，会占用大量Redis内存，而且我们使用Redis ZSet暂存用户播放记录，过长的话会严重影响性能。于是，我们设计每个小时增加一次定时任务，第二次任务对第一次任务补偿，如果第二次任务仍然没有补偿成功，那么经过一圈以后，还可以得到再次补偿（兜底）。

细心一点应该会发现在图5中的“待写入数据”和定时任务并不是分布在环上的同一个点的，我们这样设计的考虑是希望方案更简单，定时任务只会去操作已经不再变化的数据，这样就能避免并发操作问题。就像Java虚拟机中垃圾回收一样，我们不能一边回收垃圾，一边却还在同一间屋子里扔着垃圾。所以，设计成环上节点对应定时任务只去处理前一个节点上的数据，以确保不会产生并发冲突，使方案保持简单。

批量写入方案简单且不存在并发问题，但是在Redis Zset需要保存一个小时的数据，可能会超过最大长度，但是考虑到现实中一般用户一小时内不会播放非常大量的视频，这一点是可以接受的。最终，我们选择了批量写入方案，其简单、优雅、高效，在此基础上，我们需要继续设计暂存大量用户的播放视频ID方案。

3.3 数据分片

为了支持5000万日活量级，我们需要为定时批量写入方案设计对应的数据存储分片方式。首先，我们依然需要将播放视频列表存放在Redis Zset，因为在没写入布隆过滤器之前，我们需要用这份数据过滤用户已观看过的视频。正如前文提到过，我们会暂存一个小时的数据，正常一个用户一个小时内不会播放超过一万条数据的，所以一般来说是没有问题的。除了视频ID本身以外，我们还需要保存这个小时到底有哪些用户产生过播放数据，否则定时任务不知道要将哪些用户的播放记录写入布隆过滤器，存储5000万用户的话就需要进行数据分片。

结合批量同步部分介绍的时间环，我们设计了如图6所示的数据分片方案，将5000万的用户Hash到5000个Set中，这样每个Set最多保存1万个用户ID，不至于影响Set的性能。同时，时间环上的每个节点都按照这个的分片方式保存数据，将其展开就如同图6下半部分所示，以played:user:${时间节点编号}:${用户Hash值}为Key保存某个时间节点某个分片下所有产生了播放数据的用户ID。

（图6：数据分片方案）

对应地，我们的定时任务也要进行分片，每个任务分片负责处理一定数目的数据分片。否则，如果两者一一对应的话，将分布式定时任务分成5000个分片，虽然对于失败重试是更好的，但是对于任务调度来说会存在压力，实际上公司的定时任务也不支持5000分分片。我们将定时任务分为了50个分片，任务分片0负责处理数据分片0~100，任务分片1负责处理数据分片100~199，以此类推。

3.4 数据淘汰

对于短视频推荐去重业务场景，我们一般保证让用户在看过某条视频后三个月内不会再向该用户推荐这条视频，因此就涉及到过期数据淘汰问题。布隆过滤器不支持删除操作，因此我们将用户的播放历史记录添加到布隆过滤器以后，按月存储并设置相应的过期时间，如图7所示，目前过期时间设置为6个月。在数据读取的时候，根据当前时间选择读取最近4个月数据用于去重。之所以需要读取4个月的数据，是因为当月数据未满一个月，为了保证三个月内不会再向用户重复推荐，需要读取三个完整月和当月数据。

（图7：数据淘汰方案）

对于数据过期时间的设置我们也进行了精心考虑，数据按月存储，因此新数据产生时间一般在月初，如果仅将过期时间设置为6个月以后，那么会造成月初不仅产生大量新数据，也需要淘汰大量老数据，对数据库系统造成压力。所以，我们将过期时间进行了打散，首先随机到6个月后的那个月任意一天，其次我们将过期时间设置在业务闲时，比如：00:00~05:00，以此来降低数据库清理时对系统的压力。

3.5 方案小结

通过综合上述流量汇聚、数据分片和数据淘汰三部分设计方案，整体的设计方案如图8所示，从左至右播放埋点数据依次从数据源Kafka流向Redis暂存，最终流向磁盘KV持久化。

（图8：整体方案流程）

首先，从Kafka播放埋点监听到数据以后，我们根据用户ID将该条视频追加到用户对应的播放历史中暂存，同时根据当前时间和用户ID的Hash值确定对应时间环，并将用户ID保存到该时间环对应的用户列表中。然后，每个分布式定时任务分片去获取上一个时间环的播放用户数据分片，再获取用户的播放记录更新到读出的布隆过滤器，最后将布隆顾虑其序列化后写入磁盘KV中。

四、数据迁移

为了实现从当前基于Redis ZSet去重平滑迁移到基于布隆过滤器去重，我们需要将统一去重服务上线前用户产生的播放记录迁移过来，以保证用户体验不受影响，我们设计和尝试了两种方案，经过对比和改进形成了最终方案。

我们已经实现了批量将播放记录原始数据生成布隆过滤器存储到磁盘KV中，因此，迁移方案只需要考虑将存储在原来Redis中的历史数据（去重服务上线前产生）迁移到新的Redis中即可，接下来就交由定时任务完成即可，方案如图9所示。用户在统一去重服务上线后新产生的增量数据通过监听播放埋点写入，新老数据双写，以便需要时可以降级。

（图9：迁移方案一）

但是，我们忽略了两个问题：第一，新的Redis仅用作暂存，因此比老的Redis容量小很多，没法一次性将数据迁移过去，需要分多批迁移；第二，迁移到新的Redis后的存储格式和老的Redis不一样，除了播放视频列表，还需要播放用户列表，咨询DBA得知这样迁移比较难实现。

既然迁移数据比较麻烦，我们就考虑能不能不迁移数据呢，在去重的时候判断该用户是否已迁移，如未迁移则同时读取一份老数据一起用于去重过滤，并触发将该用户的老数据迁移到新Redis（含写入播放用户列表），三个月以后，老数据已可过期淘汰，此时就完成了数据迁移，如图10所示。这个迁移方案解决了新老Redis数据格式不一致迁移难的问题，而且是用户请求时触发迁移，也避免了一次性迁移数据对新Redis容量要求，同时还可以做到精确迁移，仅迁移了三个月内需要迁移数据的用户。

（图10：迁移方案二）

于是，我们按照方案二进行了数据迁移，在上线测试的时候，发现由于用户首次请求的时候需要去迁移老的数据，造成去重接口耗时不稳定，而视频去重作为视频推荐重要环节，对于耗时比较敏感，所以就不得不继续思考新的迁移方案。我们注意到，在定时批量生成布隆过滤器的时候，读取到时间环对应的播放用户列表后，根据用户ID获取播放视频列表，然后生成布隆过滤器保存到磁盘KV，此时，我们只需要增加一个从老Redis读取用户的历史播放记录即可把历史数据迁移过来。为了触发将某个用户的播放记录生成布隆过滤器的过程，我们需要将用户ID保存到时间环上对应的播放用户列表，最终方案如图11所示。

（图11：最终迁移方案）

首先，DBA帮助我们把老Redis中播放记录的Key（含有用户ID）都扫描出来，通过文件导出；然后，我们通过大数据平台将导出的文件导入到Kafka，启用消费者监听并消费文件中的数据，解析后将其写入到当前时间环对应的播放用户列表。接下来，分布式批量任务在读取到播放用户列表中的某个用户后，如果该用户未迁移数据，则从老Redis读取历史播放记录，并和新的播放记录一起更新到布隆过滤器并存入磁盘KV。

五、小结

本文主要介绍短视频基于布隆过滤器构建推荐去重服务的设计与思考，从问题出发逐步设计和优化方案，力求简单、完美、优雅，希望能对读者有参考和借鉴价值。由于文章篇幅有限，有些方面未涉及，也有很多技术细节未详细阐述，如有疑问欢迎继续交流。

作者：vivo互联网服务器团队-Zhang Wei

如何用FFMpeg生成视频

Wed, 09 Feb 2022 09:09:14 CST

前言

FFMpeg读做“FF Mpeg”， “FF”指的是 “Fast Forward”，而“Mpeg”指的是 Moving Picture Experts Group（动态图像专家组）。

根据官方介绍，FFMpeg是一个完整的、跨平台的音频和视频录制、转换和流媒体解决方案。简单来说，只要涉及 音视频开发，基本绕不开这个工具。

一、快速入门

FFMpeg快速入门的话，建议查看阮一峰老师的《 FFmpeg 视频处理入门教程》，里面讲述了音视频处理的一些基本概念，比如FFMpeg支持的容器、 编码格式以及 编码器；还有就是讲述 FFMpeg的常见用法，比如查看文件信息、转换编码格式、提取音频等。

二、音视频基础知识

我自己在使用FFMpeg的时候发现，想要把FFMpeg用得明白，一些基本的音视频基础知识的了解还是很有必要的，所以在这里做下总结。

现在短视频那么火，相信大家也是常看，而一个视频的构成其实也不复杂，就是 图像、音频、字幕的一个组合。

对于图像，它有两个概念需要区分好，分别是 图像格式和 色彩空间。图像格式就是图片压缩编码以及存储的方式，比如我们常见的 JPEG和 PNG。色彩空间是颜色的数学描述方式，根据不同的表示方法分为不同的色彩模型，最常用的色彩模型有三类， RGB(用于计算机图形学)， YUV(用于视频系统), CMYK(用于彩色印刷)。（后面会经常看到YUV）

对于音频，也有两个概念比较重要，一个是采集到的原始音频数据（比如PCM），另一个是压缩后的音频数据，比如AAC，后面也会经常看到。

对于字幕，常见的有三种格式，分别是 srt、 ssa和 aas。

srt字幕即文本格式字幕，它算是最简单的字幕了，因为它仅由 时间和字幕内容构成，比如下面：

  # 第一行是编号，表示第几个字幕
# 第二行是时间范围，精确到毫秒
# 第三话就是显示的文本内容

0
00:00:00,000 --> 00:00:01,000
假设张三携带10万美刀进行投资

1
00:00:02,000 --> 00:00:03,000
兑换成人民币后，银行就多了10万美刀的外汇

ssa字幕是比srt字幕更先进的字幕文件格式，而与它比较类似的ass字幕其实就是ssa字幕的plus版本，ass字幕的实质是 SSA v4.00+，是基于SSA 4.00+编码构建的。下面是ass字幕的具体内容：

  # 这是从上面的srt字幕转换得到的ass字幕
# Script Info：包含脚本的头部和总体信息
# V4+ Styles：包含了所有样式的定义
# Events：包含了所有脚本的事件，有字幕、注释、图片等
[Script Info]
; Script generated by FFmpeg/Lavc58.91.100
ScriptType: v4.00+
PlayResX: 384
PlayResY: 288
ScaledBorderAndShadow: yes

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,16,&Hffffff,&Hffffff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:01.00,Default,,0,0,0,,假设张三携带10万美刀进行投资
Dialogue: 0,0:00:02.00,0:00:03.00,Default,,0,0,0,,兑换成人民币后，银行就多了10万美刀的外汇

三、一个视频的构建

我之所以要用FFMpeg，源于我想通过图片生成视频，并加上音频和字幕，从而构成一个完成的视频，所以下面我主要说说在构建时的一些心路历程（坑）。

3.1 项目结构

本次实践生成的音视频都会上传到Github，可以点击这里查看：

  # 项目结构
$ tree -l -L 1
.
├── add_audio  # 添加音频
├── add_caption # 添加字幕
└── img_to_video # 图片转视频

3.2 图片生成视频

为了方便展示，我从网上随便找了一张图片：

图片转视频的命令如下：

  $ ffmpeg -r 25 -i img001.jpg -vcodec libx264 -pix_fmt yuv420p one_img_to_video.mp4
...
[libx264 @ 0x7faf5b809200] i8c dc,h,v,p: 65% 19%  9%  7%
[libx264 @ 0x7faf5b809200] kb/s:8960.40

下面是各个参数的逐个解析：

-r：rate，用于设定 视频帧率。视频帧率即每秒显示帧数，常见的有30FPS、25FPS或者24FPS。本次设定为25FPS，即每秒有25张图片。
-i：input，即输入源文件。
-vcodec：video codec，即视频的编码格式，常见的有H.264，即 libx264。
-pix_fmt：pixel formats，即像素格式， yuv420p是上文提到的YUV中的一种。
one_img_to_video.mp4：最后输出的文件名。

生成之后的视频，可以看到 时长非常短（0秒），这是因为帧率设定是25，但是只输入了一张图片，图片数不够，所以生成的视频时长非常短。

解决办法有两种：一是降低帧率（不推荐），二是增加图片数量（推荐）。

我一开始是通过降低帧率来提高时长（我的需求是同一张图片要显示10秒左右），因为25FPS就是一秒25张图片，那如果设置为0.1FPS，等同于 1张图片10秒，测试如下：

  $ ffmpeg -r 0.1 -i img001.jpg -vcodec libx264 -pix_fmt yuv420p one_img_to_video_small_rate.mp4

通过下图，可以看到 延长时长的目的确实达到了，但是这种方式生成的MP4其实是有问题的，不仅剪辑软件无法支持（比如剪映），在添加音频、字幕的时候也非常奇怪（血的教训）。

第二种方式是增加图片数量，这也是我使用剪映之后发现的，因为 与剪映拖动图片增加视频长度的原理是一致的：

批量增加图片可以随便写个脚本就可以得到，但是图片的数量需要计算一下，比如一个时长10秒，帧率25FPS的视频就需要 10 x 25 = 250张图片：

  # 输入为多张图片时，可使用这种写法
# %03d 其实就是 001、002、003...100
$ cd img_to_video

$ ffmpeg -r 25 -i img/img%03d.jpg -vcodec libx264 -pix_fmt yuv420p multi_img_to_video.mp4

这里可能有人会疑惑，为什么每次我都会带上 -pix_fmt yuv420p参数？这其实也是一个坑，因为如果不加这个参数，有些软件没办法识别生成的MP4文件，比如Mac 的 QuickTime Player。

原因可以从官方文档得到，因为我们生成视频的方式其实是通过图像序列（一系列的图片）的方式，对应的编码类型为 image2，这也是为什么有时在一些文章上可以看到他们的命令比上述命令多了 -f image2参数（加不加都无所谓）。在这种编码下，默认的 pix_fmt参数并不是 yuv420p，而是通过第一张图片得到，而JPG图片用的都是 RGB，所以最终生成的视频无法识别。

3.2 视频添加音频

通过上面的方式生成的视频是没有声音的，所以我们需要通过FFMpeg为其加上音频。

有时候我们得到的音频格式并不是 MP3，而是 WAV，这时我们可以通过下面的命令进行转换：

  $ ffmpeg -i input.wav -vn -ar 44100 -ac 2 -b:a 192k output.mp3

-i： 上文也提到过，即我们的输入文件

-vn：禁用视频，确保没有视频被包括在内

-ar：设置音频采样频率。对于输出流，它默认设置为相应的输入流的频率。对于输入流，这个选项只对音频抓取设备和原始解复用器有意义，并被映射到相应的解复用器选项中。

-ac：设置音频通道的数量。这里为2是为了确保它是立体声（2个通道）。对于输出流，它默认设置为输入音频通道的数量。对于输入流，这个选项只对音频抓取设备和原始解复用器有意义，并被映射到相应的解复用器选项中。

-b:a：将音频比特率（audio bitrate）转换为精确的192kbit/秒

上面的解释涉及到 解复用这个术语，那什么是解复用呢？当我们打开一个多媒体文件之后，第一步就是解复用，称之为Demux。为什么需要这一步，这一步究竟是做什么的？我们知道在一个多媒体文件中，既包括音频也包括视频，而且音频和视频都是分开进行压缩的，因为音频和视频的压缩算法不一样，既然压缩算法不一样，那么肯定解码也不一样，所以需要对音频和视频分别进行解码。虽然音频和视频是分开进行压缩的，但是为了传输过程的方便，还是将压缩过的音频和视频捆绑在一起进行传输。所以我们解码的第一步就是将这些绑在一起的音频和视频流分开来，也就是传说中的**解复用。**简单来说，解复用这一步就是将音频流和视频流分开，方便后续解码。

转换之后就可以为视频添加音频了，这里使用的视频是上文生成的图片视频（注意添加音频也能用wav格式，只不过我习惯用mp3）

  # 拷贝视频
$ cp img_to_video/multi_img_to_video.mp4 add_audio/input.mp4

# 添加音频有多种方式：
# 方式一：流拷贝（不推荐）
# 这种方式没有编解码的过程，只有解复用，所以速度很快，目前亲测不成功，不太建议
$ ffmpeg -i input.mp4 -i input.mp3 -codec copy audio_copy.mp4

# 方式二：手动选择特定流（不推荐，亲测无效）
$ ffmpeg -i input.mp4 -i input.mp3 -map 0:v -map 1:a -c copy audio_manually.mp4

# 方式三：重新编码（亲测有效）
$ ffmpeg -i input.mp4 -i input.mp3 -c:a aac -c:v libx264 audio_recode.mp4

# 有时候我们的音频长度大于视频长度，比如本次音频长度为20s，视频长度为10s，使用上面的命令会把视频长度拉长到20s
# 如果想要音频长度与视频长度保持一致，可加上 -shortest 参数
$ ffmpeg -i input.mp4 -i input.mp3 -c:a aac -c:v libx264  -shortest audio_recode_short.mp4

3.3 视频添加字幕

添加完音频后，就可以添加字幕了，关于字幕转换工具，可以自己手写一个，也可以用现成的，比如下面这个：

TXT to SRT Converter

使用起来也非常方便，每一行就是一行字幕，最后设置好起始时间就可以了（不一定与实际朗读匹配）：

添加srt字幕的命令如下：

  # 拷贝之前生成好的视频
$ cp add_audio/audio_recode.mp4 add_caption/input.mp4

# 添加字幕
$ ffmpeg -i input.mp4 -vf subtitles=input.srt video_with_srt.mp4

# 有时候可能会遇到下面的报错：Too many packets buffered for output stream 0:1
# 该异常抛出的原因是有些视频数据有问题，导致视频处理过快，容器封装时队列溢出
# 可以通过增大容器封装队列大小来解决，比如设置最大封装队列的大小为1024
$ ffmpeg -i input.mp4 -vf subtitles=input.srt -max_muxing_queue_size 1024 video_with_srt.mp4

有时候我们需要自定义字幕的样式，或者字幕的位置，这时可以先把srt字幕转换为ass字幕，再做调整。如果你安装了FFMpeg，一行命令就能完成转换，如果没有安装，也可以用一些在线工具实现，比如字幕酱。

FFMpeg转换命令:

  $ ffmpeg -i input.srt output.ass

添加ass字幕命令：

  
$ ffmpeg -i input.mp4 -vf "ass=output.ass" video_with_ass.mp4

最终效果如下：

如果想要控制字幕使用的文字、文字大小、以及显示位置等，则需要修改 [V4+ Styles]里面的内容：

  # 一共分为两行，第一行是字段名，第二行是字段值
# Fontname：字型
# Fontsize：字体大小
# MarginL：字幕距左边的距离，取值范围是0-PlayResX的数值
# MarginR：字幕距右边的距离，取值范围是0-PlayResX的数值
# MarginV：字幕高度，取值范围是0-PlayResY的数值
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,16,&Hffffff,&Hffffff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0

注：其他参数的说明可参考这篇文章

假设我要把字幕大小改为20、且字幕往上移动，则对应的改动如下：

  [V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&Hffffff,&Hffffff,&H0,&H0,0,0,0,0,100,100,0,0,1,1,0,2,10,10,50,0

最后重新添加即可：

  $ ffmpeg -i input.mp4 -vf "ass=new.ass" video_with_new_ass.mp4

最终效果如下：

写在最后

以上就是如何用FFMpeg构建完成视频的全流程了，希望对大家有所帮助！

参考教程

FFmpeg 视频处理入门教程
 FFmpeg Formats Documentation
ffmpeg图片视频互转
 Convert audio files to mp3 using ffmpeg
FFMPEG深入理解
 TXT to SRT Converter
在线字幕格式转换工具
 解决FFmpeg抛出的"Too many packets buffered for output stream 0:1."

基于 HLS 创建 Golang 视频流服务器

Mon, 29 Nov 2021 13:51:20 CST

HLS 是 HTTP Live Streaming 的缩写，是苹果开发的一种基于 HTTP 的自适应比特率流媒体传输协议, 并于 2009 年。HLS 流媒体已经成为应用最广泛的实时视频协议。它是一种将流分解成基于文件小段的格式, 可以通过 HTTP 下载，HLS 可以通过标准的 HTTP 或代理服务器等，这和基于 UDP 的协议（例如 RTP）不同。既然 HLS 现在如此受欢迎，那么它有那些优点和缺点呢。

优点

应用广泛
首先，刚才已经提到过，HLS 是应用最惯犯的实时视频协议。虽然最初苹果是为了自己的生态设计的，例如 IOS，Safari 浏览器等，但是背靠苹果，有强大的生态和研发能力，现在它几乎在所有浏览器上实现了。虽然现在的主流浏览器都支持一个类似的标准，称为 MPEG DASH，但是由于苹果 Safari 浏览器和 IOS 设备不支持它，个人认为 HLS 是一个更好的选择。
自适应比特率
HLS 另一个巨大的优势是，它允许客户端根据可用带宽，从各种质量流中选出合适的。HLS 分解成一个个大约 10 秒的文件小段，通过分解，客户端应用程序只需要提前缓冲 10 秒。为用户节约了大量潜在带宽。

缺点

糟糕的延迟
虽然 HLS 设计出来是为了高效的处理多质量的流，但它并不是为了快速传输视频设计的。实际上，HLS 在流中引入流相当长的延迟，一般 20 秒左右，甚至更久。
说到这里，你可能想问为什么？HLS 需要三个片段在队列中才允许回放，片段被视频中的关键帧分割。用 HLS 创建超低延迟流的唯一方法就是每 250 毫秒出现一个关键帧的视频进行编码，HLS 播放列表窗口将是四项长度，增加正在发生的 HTTP 调用频率，并给服务器增加额外的压力。
未发布
HLS 是一个仅供用户使用的协议。不像 WebRTC 有从浏览器发布的规范，HLS 仅支持播放流，如果你想发布一个设备的实时视频流，你只需要寻找其他的 SDK ，国外的例如 Red5 Pro（场景较为单一，巨贵）, 来创建使用 RTP 的发布应用程序，然后通过 HLS 中继这些流，让人们在浏览器中查看。
国内有几个较为成熟的音视频 SDK，例如声网等平台，提供很多场景的音视频解决方案。

HLS 简单介绍完了，接下来演示一个小 Demo, 使用 FFmpeg，可以很轻易的将 mp3 文件转换为 HLS 格式，它由多个文件组成，其中一个包含元数据（.m3u8），元数据告诉客户端从哪里获取每个数据文件，以及数据文件中包含什么内容。数据文件拓展名是.ts，通常包含 10 秒的音频。

首先准备一个 mp3 文件。然后安装 FFmpeg，在 Mac 上安装 FFmpeg，如果速度很慢可以尝试切换镜像。

  1 brew install ffmpeg
2

成功安装后，进入 mp3 所在文件夹，执行以下指令。

  1 ffmpeg -i 江南.mp3 -c:a libmp3lame -b:a 128k -map 0:0 -f segment -segment_time 10 -segment_list outputlist.m3u8 -segment_format mpegts output%03d.ts
2

执行完毕后应该会看到一些结果，大致内容如下.

  1 output000.ts  output008.ts  output016.ts  output024.ts
2 output001.ts  output009.ts  output017.ts  output025.ts
3 output002.ts  output010.ts  output018.ts  output026.ts
4 output003.ts  output011.ts  output019.ts  outputlist.m3u8
5 output004.ts  output012.ts  output020.ts  江南.mp3
6 output005.ts  output013.ts  output021.ts
7 output006.ts  output014.ts  output022.ts
8 output007.ts  output015.ts  output023.ts
9

到这一步你已经完成了文件格式转换，接下来进入 Coding 阶段。

项目结构

代码如下

  1 package main
2 
3 import (  
4   "fmt" 
5   "log" 
6   "net/http"
7 )
8
9 func main() {  
10  // 设置文件目录
11  const songsDir = "song"  
12  const port = 8888
13
14  http.Handle("/", http.FileServer(http.Dir(songsDir)))  
15  log.Printf("Serving %s on HTTP port: %v\n", songsDir, port)
16
17  log.Fatal(http.ListenAndServe(fmt.Sprintf(":%v", port), nil))
18 }
19

运行代码

  1 go run main.go
2

打开浏览器地址

  1 http://127.0.0.1:8888/outputlist.m3u8
2

恭喜你，你可以听到这段 mp3 动人的旋律了。但是如果你想进一步进行商业开发，或者个人开发，推荐使用比较成熟的解决方案，一是音视频不分家，音频需求往往伴随着视频需求，音视频往往是开发过程中的某一个子需求，如果在上面耗费大量时间，往往会耽误项目进度，而且处理起多个平台时往往有一些细节上的坑。使用市面上的 SDK，能够很大程度上节约开发成本。我个人在使用的声网，能够支持跨平台，最最最关键，每个月能够白嫖一定的额度，对于个人开发者来说十分友好。当然了，费用其实是一方面，还有相当重要的一点就是能够几行代码即可接入，大大较少了踩坑量！

总结

正如你所见，HLS 广泛应用在各种平台，移动端，浏览器的普遍支持，让它成为开发者分发流给用户的一个很好的选择。但是，凡事都有但是，因为 HLS 是一个比较慢的协议，虽然苹果的规则似乎相当严格，当涉及到 IOS 流媒体需求时，实际上还是比较灵活的。如果你想通过它去构建一些实时通信的程序，那么它可能不太适合你。最后，如果想要实现比较实时的通信系统，最好借助于市面上其他比较成熟的解决方案，它更适合实时性要求不那么高的场景，在苹果的生态体系下构建的应用。

视频剪辑软件「剪映」的学习笔记

Wed, 20 Oct 2021 00:19:12 CST

介绍

有了吉宝之后，最近偶尔会上传她的视频到抖音上，为了让视频更好玩儿，开始利用空闲时间学习视频剪辑。抖音官方有一个视频剪辑软件「剪映」，功能挺强大，因此，立个小目标，下半年持续学习输出它的使用笔记。

学习教程

胖姐的迷糊小生活一位自媒体妈妈，出了很多关于剪映的视频剪辑教程。
B站/史上最精简最全的剪映教程【基础篇】比较系统，但是介绍的比较基础，入门还可以

界面

可以在设置中关闭自动添加片尾

比例

首页菜单下，调整视频的比例。

背景

首页菜单下，用于填充比例的视频空余的部分，下面的选项是单选，不叠加的：

画布颜色
画布样式
画布模糊

设置画布的效果默认是给时间轴上那段视频片段设置，如果要将画布样式设置给所有的视频，那么，点击界面上的「应用到全部」按钮即可。

剪辑

首页菜单下，剪辑中提供了很多功能，可以点击「剪辑」进入剪辑状态，此外，单击视频也会自动进入剪辑状态。

分割
变速
音量
变声
删除
降噪：对录制的视频中音频进行降噪处理
复制
倒放
定格：就是选取了视频中指定时间点画面持续几秒钟，类似于截图。

美化

美化下提供了两个主要的功能：美颜和美体

美颜：
- 磨皮
- 瘦脸
美体：
- 瘦身
- 长腿
- 瘦腰
- 小头

音频

首页菜单下

音乐

导入音乐：在音频-》音乐-》导入音乐下，支持输入一段音乐的链接地址进行导入。用这个功能就可以实现将网易云音乐的分享链接粘贴到这里，作为视频的背景音乐了。

音效

这个菜单下提供了很多音效，例如：

综艺：
- 疑问-啊？：那种黑人问号的场景使用
- 震惊
- “喂”
- 屏蔽脏话
- 土拨鼠大吼：啊！
- 剧场欢呼
- 口哨
- 尴尬
- 无语
- 打嗝
- 放屁声
- 黑线
- 亲
- 悲伤长叹
笑声
- 多人大笑
- 观众笑声
机械声
- 打字声
- 机械键盘打字声
- 系统警告
- 时钟滴答
- 门铃
BGM
- Hello it’s me
- 小朋友你是否有很多问号
- 疑惑
人声
- 我太难了
- 什么？（日文）
游戏
- 一杀
美食

录音

可以给视频通过自己录音的方式进行配音。

音频编辑

当点击添加的音频时，会自动进入音频编辑的状态。

踩点

提供了「自动踩点」的功能，能够在音频的时间轴上进行踩点标记，这样的话，就可以在一些音频点上进行照片的添加、转场等，这样会使视频效果更具有节奏感。

变声

例如可以将自己录制的配音进行变声处理，提供了一些选项：

大叔
萝莉
女生
男生
怪物

文本

新建文本

给视频配上文本，充当字幕

识别字幕

针对视频里的声音或者你给视频添加的录音进行识别，自动生成字幕。

文本编辑

点击添加的文本，会自动进入文本编辑状态

文本朗读

针对自己添加的文本，进入文本编辑状态，选择文本朗读，提供了很多特效声音来朗读你的文本：

动漫小新
说唱小哥
台湾女生
动漫海绵
小萝莉
东北老铁

贴纸

首页菜单下，提供了贴纸的菜单。

点击添加的贴纸，四个角的功能有所不同，提供了缩放、编辑、删除、复制的功能。

选中贴纸，进入编辑状态，提供了若干动画效果的设置：

入场动画
出场动画
循环动画：
- 心跳：这个效果不错，比如结合一个手指，心跳效果可以起到引人注目效果。
- 旋转

滤镜

首页菜单下，提供了滤镜的菜单。

调节

首页菜单下，提供了调节的选项。在该菜单下提供了如下的功能：

亮度
对比度
饱和度
光感
锐化
高光
阴影
色温
色调
褪色
暗角
颗粒

特效

人脸道具

这个功能很赞，可以实现针对拍摄的视频自动识别人脸，然后用选择的道具替换，避免露脸了。

画面特效

画面特效中提供了很多选择，例如：

基础-》开幕：这个在很多视频的开场可以使用一下
动感-》抖动：有种画面抖动效果
动感-》灵魂出窍：有种画面抖动效果
动感-》毛刺：有种画面抖动效果
边框-》录制边框：有种正在摄影的感觉
自然-》玫瑰花瓣：很唯美
复古-》复古DV：给画面一种老电影的感觉
分屏-》三屏

转场

点击 2 个视频片段之间的分隔键，会弹出转场的选项：

基础转场
- 左移
- 右移
- 上移
- 下移
运镜转场
- 推近转场
- 拉远
特效转场
MG转场
幻灯片
遮罩转场

大规模视频内容理解：淘宝视频内容标签的结构化分析和管理

Fri, 10 Sep 2021 09:38:48 CST

▐ 为什么要做标签？

在这种亟需深入理解视频内容的大背景下，不同的表征形态涌现。包括：

embedding表征
标签表征

其中embedding表征常用的方法包括多模态预训练模型、基于用户行为的deep match模型等等，集团内在这方面有大量优秀的工作，使用embedding表征视频内容最大的问题在于不可解释性，只能完成机器对视频的理解。

使用标签对内容进行表征的优势在于，标签是一种高度概括的自然语言，不仅完成了机器对视频内容的理解，同时完成了人到视频内容的理解。同时，标签库量级上百万，组合方式多样，保证了内容表征的多样性。

综上，对视频完成了标签挂载，可以完成以下目标：

用户可理解
算法可解释
运营可干预

▐ 我们需要什么样的标签？

为了回答这个问题，需要拆解成两个子问题。

我们需要什么样的标签库？

视频是一种分别非常不均匀的数据形态，其拍摄方式、包含物体、拍摄手法、表达重点均非常丰富，为了描述丰富多彩的视频，需要维护海量级、描述维度全面的标签库。由于视频热点更新速度非常快，因此标签库需要自动挖掘、更新，完成标签库的动态扩充。同时，由于标签是一种自然语言，标签和标签之间天然有一种推理关系，因此，标签不应割裂和独立，而是存在一种结构化的数据结构。

因此，标签库需要的特性总结如下：

标签量级大、标签维度全面；
可动态扩展
标签间有关联（结构化）

对于一个视频来说，需要打出什么样的标签？

对于一个视频，必然存在拍摄此视频的核心原因，我们将此原因概括为核心主旨标签，给出核心主旨标签，即可联想到此视频大致的描述方向。同时，视频中必然出现很多相关标签，这类标签可帮助了解视频细节内容。结合核心主旨标签和相关标签，就可以对视频内容进行全局到局部、总体到细节的理解，这也是符合人类认知习惯的。

以下面这个淘宝中常见的视频为例，其核心想表达的是一个复古清纯风格的服饰搭配教程，核心主旨为：白月光穿搭、复古清纯穿搭等；而如何穿搭才能展现这种风格？需要穿白色连衣裙、带发箍等等，因此其相关标签应为：白色连衣裙、可爱发箍、vintage等等。

视频1 一种典型的淘内视频打标的结果

标签体系框架设计

按照1.2中的分析，为完成对视频内容全面的理解，我们需要从标签库和打标算法两个大方向对整体标签体系框架进行设计，即：

（1）标签库动态维护，包括标签的动态挖掘和标签结构化

（2）视频内容打标算法

完成标签库维护和打标流程后，即可完成数据服务的对外输出和下游的业务应用。数据的对外输出包括数据生产和实时/离线的服务输出；业务应用包括运营工具、下游投放算法和标签外透等。我们设计的标签体系框架如下图所示。

图2 标签体系设计架构大图

经过标签体系算法流程，内容标签目前对视频内容进行打标、标签库进行动态管理取得的结果如下图所示。在后续章节中，我会根据 标签库动态管理、 视频内容打标算法流程、 下游应用三个大模块进行详细的介绍。

标签库动态管理

▐ 标签挖掘

为保证挖掘标签词的时效性、全面性，我们设计了两套互补的标签挖掘算法流程，再将挖掘出的标签融合起来进行人工审核。

基于autophrase的半监督新词挖掘算法流程

如下图所示，将内容语料库和置信的标签集送入autophrase模型，通过半监督的方式获取标签后，再经过一个判别标签是否有效的二分类模型得到最终挖掘出的标签。此方法挖掘标签的特点在于：

过审率较高（80%+）
新标签和置信集标签pattern相似
无法获取热门标签

基于标签pattern挖掘的新词挖掘算法流程

如下图所示，这是一种无监督的标签挖掘流程，先从内容语料库中挖掘出标签组合的pattern，再用pattern在语料库中进行匹配，获取挖掘的标签。此方法挖掘标签的特点在于：

过审率较低
标签pattern更加灵活多样
可以获取热门标签

目前，我们基于海量的站内/站外数据挖掘出500w+标签，通过数据清洗后的标签量为110w+，其中原子标签数量90w+，短语标签数量130w+，短语型标签每周增量约5000+。

▐ 标签结构化

高效地维护标签库，不仅在于标签地动态挖掘，更在于挖掘出标签后，如何结构化地管理这些标签。好的标签结构化引入了标签间信息，为标签推理认知的提供了基础知识。首先，我们按照词语粒度将标签分为原子标签和短语标签，其中原子标签是不可继续分词的标签，短语标签为原子标签组合而成的标签。

原子标签分类体系

我们首先为原子标签设计了一套分类体系，可对每个原子标签进行树状结构的划分，一级类目包括“时间”、“地点”、“人物/动植物”、“事情”、“物品”、“IP”、“机构名”、“数值”等8个大类，在一级类目中还有二级、三级、四级的树状延伸等50个小类。

通过原子标签分类体系，不仅可以细分管理每个原子标签，将短语标签拆解为原子标签进行理解，同时可以分析每个分类下原子标签情况，如发现短缺的情况可以及时补充，保证标签集合的完整充分。

短语标签分维度结构化

由于短语标签包含各种不同的高层语义信息，因此仅通过组成短语标签的原子标签进行理解是远远不够的，基于此，我们从不同语义维度设计了四种不同的短语标签结构化方法，包括：内容/商品标签、热门趋势标签/长期标签、人群兴趣标签/视频内容标签、问题型/陈述型标签。在应用中，可按照不同的需求选取不同类型的短语标签。

图4 短语标签分类体系

▐ 标签管理目前核心进展

目前标签库已实现动态管理、结构化，具体的指标如下图所示。

视频内容打标算法

▐ 视频内容打标算法流程设计

在确定视频内容打标算法流程之前，需要确定目前视频内容打标面临的困难和挑战，我对其总结如下：

标签库规模巨大：目前维护的标签库达百万，且长尾分布严重，无法使用多标签分类模型等常规打标签的解决方案。
标签库不断增长、动态扩充：目前标签库处在动态扩展的状态，标签经常变动，打标算法需要非常灵活&可扩展。
需对多模态信息进行理解：视频是一种多模态的内容形式，包括文本/图像/音频等多种模态的信息。对于不同的视频，不同模态的重要程度也不同，因此需要对多模态的信息进行综合全面的向量表征。
需区分不同标签在内容的权重：如上几条中讨论，对于一个视频，需要给出其核心主旨标签和相关标签。对算法来说，即最终标签结果需给出和视频内容的相关性分数排序。
人工标注非常困难：一个视频具体改打什么标签是一个非常主观的问题，对于不同的标注者，其对内容标签的标注结果会有巨大的差异。因此在打标算法流程设计中，需减少对标注的依赖。

综合上述对视频内容打标算法流程难点和挑战的分析，我们设计了基于“ 召回-排序”的两段式算法流程，召回是视频和标签粗粒匹配过程，排序是视频和标签细粒度匹配过程，调整标签的排序。此算法流程可以很好地解决视频内容打标过程中的难点。

图5 视频标签挂载流程大图

召回阶段

其的核心目标在于召回尽可能多、尽可能全的候选标签。为保证召回标签的全面，我按照以下四个维度进行召回：

内容信息

即内容自带的信息，包括创作者编辑的文本、语音识别结果（ASR）、文本识别结果（OCR）、画面信息。

以上面这个制作芝士烤土豆片的食谱教程视频为例：

商品信息

由于淘内视频的独特性，视频的目的是为了卖货，因此，商品信息也作为描述视频的一个维度。视频下挂载的商品、商品query、同款商品等信息作为商品信息维度的文本召回。

用户行为信息

淘内视频和用户有着大量的交互，用户行为本身也可以作为标签候选词集。因此内容搜索点击日志清洗出的query可作为表述用户行为的召回候选词。

关联内容信息

候选词集不仅应包括内容自带的信息，还应该包括关联信息，这一路召回主要通过检索方法实现：

跨模态检索模型：向量化视频和标签库直接进行跨模态检索，获取最有可能作为视频标签的词。
相似视频检索模型：需要打标的视频作为query，在千万级视频库中检索出topN相似视频，将相似视频的候选词共享到query视频。

在后续小节中，会对两种检索方法做更详细的介绍。

排序阶段

在排序阶段中，主要目标在于对视频和候选词集进行更细粒度匹配和对齐，完成候选词集的相关性排序，保留和视频相关的标签，去除不相关的词。排序模型的具体建模方式接下去会进行详细的介绍。

▐ 核心技术点

在上一部分中，除了常规模型ASR、OCR等，需要核心解决的技术目标为：

召回模块中的相似视频检索
召回模块中的跨模态检索模型
排序模块中使用的跨模态相关性判别模型

对于这三个需要解决的核心技术目标，我们抽象出三个需攻坚的核心技术点：

视频多模态内容表征模型
跨模态检索模型
跨模态相关性判别模型

在接下去几部分中，会对这三个核心技术点进行详细拆解和介绍。

▐ 视频多模态内容表征

我们目前提取的embedding基于自研的通用视频内容预训练模型。这个视频内容预训练模型借鉴了VilBert的自监督训练方法，继承了更多通用性强的预训练任务，包括内容挂载商品的一级、二级分类，内容的文本和视觉信息是否匹配。同时，由于淘系内容业务与推荐任务息息相关，因此，我们进行了大幅度的改造，对于推荐大场景改良了预训练网络和特异性预训练任务。

参考[5]LXMERT的预训练网络结构，具体输入：

visual branch图文内容：

（1）图文包含的所有图像经过Resnet抽取的1536维特征序列。维度为101536（2）图像帧位置信息序列：维度为110，表示图像处于图像序列位置视频视频：（1）视频关键帧经过Resnet抽取的1536维特征序列。101536（2）图像真位置信息序列：维度为110，表示图像处于帧序列位置

Language branch图文内容：

（1）title+body content经过中文bert编码的字id序列，维度为1128（2）字位置信息序列：维度1128，表示字在句子序列中的位置视频内容：（1）title+summary经过中文bert编码的字id序列，维度为1128（2）字位置信息序列：维度1128，表示字在句子序列中的位置

图6 视频理解基础模型网络框架

目前共5个预训练task：

图像序列随机mask掉图像序列的feature，最后用以visual为主的cross-modality feature进行mask掉的feature回归预测。
序列随机mask掉字序列的feature，最后用以Language为主的cross-modality feature进行mask掉的文字id分类预测。
内容挂载商品的110个一级类目分类
内容挂载商品的3807个叶子类目分类
visual信息和language信息是否匹配的二分类（即图像序列和文字序列是否来自同一内容）

同时，由于同时mask视觉/文本侧特征可能导致信息过度损失，参考[9]UNITER模型中的mask策略，优化训练策略，如下图所示。

经过10个epoch，使用100+块GPU，经过5天的训练，将6000w+淘内视频数据完成训练。预训练模型的参数更新参考了海量的视频数据，被上亿的标注数据进行了约束，最终产出的checkpoint可以作为后续跨模态检索、排序模型的Backbone网络，产出的768维向量可作为相似视频检索的视频向量。在视频内容的标签挂载算法流程中，这个pretrain model发挥了重要的作用。

内容表征的好坏是根据下游算法性能的提高作为衡量指标的，使用视频标题bert向量、LXMERT向量、UNITER向量在下游的跨模态检索模型、跨模态相关性模型中进行对比实验。

跨模态检索模型使用不同向量表征模型的对比结果

跨模态相关性判别模型使用不同向量表征模型的对比结果

相似视频检索模型

视频多模态预训练模型中最后一层768维fc可作为视频内容多模态的表征向量，对视频有很强的表征能力，因此可以使用此向量在视频库中检索出相似视频，用来扩充标签候选集。

使用相似视频检索对视频标签候选集进行扩充是一种非常有效的方式，使用相似视频检索的思路如下图所示，一个视频可以基于相似embedding检索的方法，在上千万的视频库中检索出最相似的N个视频，将这些相似视频的标签扩充此视频候选词集合。

基于相似视频检索方案的视频内容打标case如下所示：

图5 相似视频检索在标签召回的应用流程

▐ 跨模态检索

跨模态检索模型

如果视频和话题的向量分布被处理到相同分布空间，那么视频可以直接在标签库中检索到与其最相关的N个标签。因此我们设计了融合Graph的跨模态检索模型结构，完成视频直接到标签的检索。网络结构如下图所示。该模型主要包括文本编码模型、视频多模态编码模型、图网络算法模型、度量学习模型。

图7 融合Graph的跨模态检索模型网络框架

为了环节样本稀疏和均衡问题，单模态和跨模态端到端的度量学习进一步保证不同模态的语义一致性和单模态的判别性，我们引入了图网络构建。

我们根据用户点击行为构建文本-视频、文本-文本、视频-视频的同构图，但考虑到仅使用用户点击行为构建的图较为稀疏，因此同时引入了基于语义相似度建图，将相似的文本和相似的视频之间构建边，最终形成的图结构如下所示。

实验结果

检索衡量指标采用检索召回准确率Top1，Top5，Top20 以及Mean Rank值。

1K淘宝样本对检索性能如下：

MSCOCO Retrieval数据集的5K检索任务性能结果对比，其中对比方法主要限定采用双塔模型结构、特征提取无需相互计算，适用于大规模检索的方法。本文工作达到了与同期前沿工作具有竞争力的性能。

case展示

主题标签在千万级首猜精品视频池进行向量检索，手淘全屏页[3]主题标签召回示例case：

▐ 跨模态相关性判别

完成了最大程度的候选词集召回后，需要一个可以更加更精确判别视频和词语相似度的排序模型，从而将候选词从按照和视频的相关性分数进行排序，剔除掉不相关的词语。

此时的排序模型和上一小节的跨模态检索模型不同之处在于，跨模态检索模型目的是从上百万标签库中快速检索到和视频可能相关的词语，因此在训练过程中，视频侧和标签侧的网络结构不能融合。而在排序模型中，目的在于更精细化判断视频和候选词的相关性，且候选词数量有限，无需过度在乎时间复杂度，因此两模态之间可以进行充分融合，我们设计的网络结构如下图所示。

图8 视频标签排序模型网络框架

可以根据目的将网络结构分成三个较为独立的模块，即：

表征模块

如何对视频、候选词进行表征，可以全面刻画视频、候选词内容。这里我们主要讨论和调整了视频侧表征方式，使用视频标题、LXMERT多模态特征、UNITER多模态特征进行了对比实验，实验AUC结果如下所示。

融合模块

如何对两路特征进行融合，我们主要使用了两种融合策略，一种是最后一层MLP融合的late fusion策略，一种是使用attention metric进行attention fusion的策略，对比实验AUC如下所示。

对齐模块

两路特征表征和充份融合后，需要将两种分布在不同特征空间的模态（视频内容&标签）对齐到相同的空间分布中，才能完成不同模态的相关性度量。在这里，我们使用了融合了难样本挖掘的对比学习TripletLoss，以及将两种模态尽可能混合的Adversarial Loss。

我们对Triplet Loss和Adversarial Loss进行了对比实验，对比实验的AUC结果如下图所示，可以看到加入生成Loss后，由于增加了使两模态尽可能混合的目标，对最终相关性判别能力是有提高的。

加入用户反馈数据

由于标签数据在全屏页全量，每天有新增1w的用户点击数据，这部分数据往往更加精准，将这部分数据加入训练数据构造一个动态的训练数据集，相比于不加入这部分数据，相关性判别模型的AUC有将近3%的提升。

▐ 视频标签挂靠结果

通过我们设计的召回+排序的视频标签挂载流程，目前视频内容打标结果的统计数据如下所示。同时我们也按照标签不同分类对打标结果做了更加精细的分析：

业务应用

▐ 下游推荐算法链路

图11 标签在淘宝不同场景投放算法中的应用

全屏页召回链路

全屏页召回链路应用 （均已全量）：

冷启动：增加原子标签+短语标签召回路，完播率+18%
冷启动：增加短语标签相似关系召回，完播率+3%
主链路：增加原子标签+主题标签召回，有效vv+2%, 七天新视频vv+3%
主链路：增加短语标签相似关系，有效vv+1.5%, 七天vv提升3%, 商家视频占比+5%

逛逛召回链路

语义向量召回 (已全量)

使用视频标签、title作为视频侧表征训练视频召回深度语义DeepV2V，指标如下：

pctr +1.04% uctr +0.4% 人均时长持平，人均点击+1.1%，人均曝光+0.5%；

整体指标：pctr +1.2% uctr +0.45% 人均点击+1.36% 人均曝光+0.4%；

新鲜度指标：30d+发布的视频数量 +2%, 1-7d -4%；

曝光度指标：0-200vv视频数量：+16%，200-2k: +4%，20w+: -2%；

多样性指标：唯一视频数量+4.2%。

▐ 标签的前台透出

在首猜全屏页中，我们使用话题对视频进行圈选，在全屏页透出，基于认知主题知识，构建底bar话题标签体系，目前线上投放话题 12w，覆盖视频vv 58%，覆盖uv 1000w+, uv_ctr 1.4%。目前已全量。

图12 短语标签在淘宝不同场景透出的效果展示

▐ 用户的数据反馈

在完成全屏页全量后，每天会产生10w左右的视频-话题点击pair对，我们将上线后的点击反馈数据收集起来，形成线上透出，线下收集数据重新训练模型。

图13 线上用户数据反馈到排序模型数据流向图

最终在排序模型中，加入线上反馈数据后，AUC有3%的提升。

总结与展望

在视频内容标签接近两年的建设中，完成标签库的结构化管理，维护百万级别标签库，同时形成了“召回+排序”的算法打标流程。在下游搜索推荐算法、标签外透产品、运营圈选工具都取得了不错的业务效果。未来希望完成标签更全面的图谱化结构设计，不仅完成标签的识别，更能做到标签、内容、用户之间的认知和推理，相信有了关系、节点丰富多样的图谱化结构，会使视频内容理解如虎添翼。

Reference

[1] Peter Anderson, Xiaodong He, Chris Buehler, Damien Teney, Mark Johnson, Stephen Gould, andLei Zhang. Bottom-up and top-down attention for image captioning and visual question answering. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, pp.6077–6086, 2018.

[2] Hao Tan and Mohit Bansal. Lxmert: Learning cross-modality encoder representations from transformers. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language

Processing, 2019.

[3] Liunian Harold Li, Mark Yatskar, Da Yin, Cho-Jui Hsieh, and Kai-Wei Chang. Visualbert: A simple

and performant baseline for vision and language. arXiv preprint arXiv:1908.03557, 2019b.

[4] Gen Li, Nan Duan, Yuejian Fang, Daxin Jiang, and Ming Zhou. Unicoder-vl: A universal encoder

for vision and language by cross-modal pre-training, 2019a.

[5] Su W, Zhu X, Cao Y, et al. Vl-bert: Pre-training of generic visual-linguistic representations[J]. arXiv preprint arXiv:1908.08530, 2019.image-20191107143317330.pngimage-20191107151306644.png

[6] Chen Y C, Li L, Yu L, et al. UNITER: Learning UNiversal Image-TExt Representations[J]. arXiv preprint arXiv:1909.11740, 2019.

[7] Zhou L, Palangi H, Zhang L, et al. Unified Vision-Language Pre-Training

for Image Captioning and VQA[J]. arXiv preprint arXiv:1909.11059, 2019.

[8] Peng, Y. , and J. Qi . "CM-GANs." ACM Transactions on Multimedia Computing, Communications, and Applications (TOMM) 15.1(2019):1-24.

[9] Portillo-Quintero J A , Ortiz-Bayliss J C , H Terashima-Marín. A Straightforward Framework For Video Retrieval Using CLIP[J]. 2021.

[10] Xu, R. , et al. "A Proposal-based Approach for Activity Image-to-Video Retrieval." (2019).

[11] Tan, M. , and Q. V. Le . "EfficientNetV2: Smaller Models and Faster Training." (2021).

[12] Miech, Antoine , et al. "Thinking Fast and Slow: Efficient Text-to-Visual Retrieval with Transformers." (2021).

[13] Li, W. , et al. "UNIMO: Towards Unified-Modal Understanding and Generation via Cross-Modal Contrastive Learning." (2020).

[14] Chen, S. , et al. "Fine-grained Video-Text Retrieval with Hierarchical Graph Reasoning." IEEE (2020).

[15] Wray M , Doughty H , Damen D . On Semantic Similarity in Video Retrieval[J]. 2021.

[16] Yuan, L. , et al. "Tokens-to-Token ViT: Training Vision Transformers from Scratch on ImageNet." (2021).

作者 |云未
编辑|橙子君 出品|阿里巴巴新零售淘系技术

END,入群👇备注： 视频

视频场景下新用户的内容推荐策略

Mon, 28 Jun 2021 10:13:29 CST

欢迎关注公众号：薛慧卿。

前言

憋了很久，终于打算开始切入这个话题了。最近一直在思考，伴随着拉新成本越来越高，对于以视频为载体的内容平台而言，就需要更加细致的为新用户提供起到留存价值的内容，将新用户有效的激活、留存，让自己少花一些冤枉钱。因此，新用户冷启动内容推荐变成为“拉新内卷”时代的重要议题。

通常意义下，我们所说的视频行业有按视频时长划分的如长视频、短视频还是最近奇奇怪怪硬炒作的“中视频”，也有按照版权形式进行划分如PPC（版权采买）、PGC（平台分成）、UGC等。本文更希望将目前的市面上的视频内容性质拆分为版权视频（采买或分成）、用户视频两种视频形式。

一、版权视频和用户视频内容差异

1.1内容成本

众所周知，国内版权采买目前是一个非常昂贵的状态，因此内容数量和平台资金呈现正相关。用户视频目前除了大多头部MCN及创作者之外，绝大多数视频都是免费状态，当然也存在视频平台补贴所有创作者的状态出现。因此从内容成本而言，版权视频内容成本远高于用户视频。

1.2内容体量

这里的内容体量包含两个方面：数量及多样性。

先说数量，版权视频中的每一个内容都是通过花重金采买的，因此从供给端的资金成本而言，头部PPC、PGC平台内容数量就会低于UGC视频平台。

再说多样性，版权视频从制作到上线，大体流程是制片人选择ip-编剧编撰-剧本敲定-导演引入及选角-内容拍摄-剪辑-送检审核-上线8大步骤。用户视频的诞生主要步骤是有创意-拍摄（剪辑）-安全审核-上线这4大步骤。通过以上步骤我们可以发现每一步都是在降低内容多样性，版权视频需要8大步骤，而用户视频仅需要4大步骤。因此在内容多样性方面看，用户视频的多样性大幅领先版权视频。

1.3内容质量

可以延续1.2的视频漏斗模型，通常而言，经过步骤越多，审核人员和制作人员专业性越强，对于内容质量的把控也更高，专业制作水平也更强。因此从平均单一内容质量而言，版权内容的内容质量绝大概率由于用户视频。

1.4内容维护精细度

通过前面三小部分的介绍，我们可以了解到版权视频和用户视频在视频体量、视频质量、视频成本三个方面的不同。因此我们可以知道，版权视频和非版权视频中，平均每个独立视频的内容维护精细度也是相差很大的。两者相似的地方包括视频标题、封面图、视频时长、标签分类之外，版权视频（长视频）对于视频封面、视频标题、参演人员、标签分类、内容赛道、内容评级会有更加详细的信息维护，其中视频封面、视频标题更是会有多套信息维度并打上消费喜好的标签。短视频（用户视频）则会更加在视频分发时强调视频作者，作者信息会更强的表露出来，如头像、昵称、作者简介、联合创作之类的信息。

二、内容推荐

在这里不在详细阐述推荐系统的的由来和工作原理，有需要可以看《推荐系统实践》这本书。众所周知，产品经理在做推荐时着重需要对两个步骤进行分析：召回和排序。

2.1内容召回

常用有效召回包括三种类型：

个性化内容召回
通用优质内容召回
个性化内容召回+通用优质内容召回

2.2内容排序

常用的排序方案主要是三种方式

1、个性化排序：根据内容与用户相似性，将匹配度高越高的内容排在推荐流的前面

2、定制规则化排序：根据一定规则对召回的内容进行排序，其中包含3种排序的方式

a、纯人工排序

b、制定一定的规则进行排序（如根据VV进行排序）

c、人工+规则排序

3、综合性排序：结合个性化+定制规则排序进行推荐排序。主要是通过在个性化排序的基础上通过各类规则干扰个性化排序的结果，从而达到提升推荐核心指标的作用。

2.3推荐的核心指标

2.3.1推荐服务的对象：

谈到推荐，我们可以想到的是精准推送；个性化分发；让用户上瘾等。如果从业务的角度出发来看，推荐的核心是通过直接或间接的途径提升整体业务的北极星指标。

2.3.2常见的视频业务与推荐指标

当下的视频形式大的方面是版权视频和用户视频，对应的北极星指标也各有千秋。从用户视频占比较多的平台看，抖音和快手的北极星指标是DAU；版权视频里传统的长视频平台爱腾优、Netflix的北极星指标是总营收；因此面对不同北极星指标，推荐在之中发挥的作用也各不相同。

以DAU作为北极星指标的推荐：

DAU的组成为新增用户+留存用户两个方面，推荐在这种主要的用处是让新增用户留存和活跃用户留存都得到提升，因此最终目标指向了留存。用户如何能够留下来？主要取决于用户认为这个视频平台的内容有意思，因此整体推荐的指标指向了查看率和互动率两个大指标。查看了主要是由CTR、平均播放完成率组成；互动率则是主要由点赞率、评论率组成。

以总营收为北极星指标的推荐：

版权视频视频平台营收当下主要是由三大部分组成：用户付费、广告收入和版权分销。推荐的核心作用是降低用户的选片成本，提升用户体验价值，同时平衡平台收益。不讨论广告推荐的前提下，推荐的核心在于用户付费。RPU=DAU*ARPU，因此推荐的核心指标在于提升ARPU及DAU，同时找到这两者的最大平衡点。DAU上面已经说明了，ARPU的核心在于会员充值率、单独点播内容购买率等指标。

三、新用户的构成

我们在此将新用户定范围广泛的划定为第一次打开app的用户。用户如何才能知道一款app？主要的方式有如下几种：

1、朋友推荐

2、app商检索（ASO）

3、明星网红推荐

4、其他app推荐

……

通过几种常见的新增方式，从平台的角度而言，拉新用户主要是通过两大来源：

1、渠道拉新

2、自然拉新

3.1渠道拉新用户

渠道拉新用户顾名思义即平台通过渠道投放、换量的方式，将平台推广给用户，让用户下载投放的产品，从而起到提升整体新增的用户获取类型。

常见的渠道拉稀用户如：网红/明星微博推荐；应用商店推荐；国外的FB/Google国内的BAT广告；相似或关联平台的换量等。因此，在渠道拉新的用户中我们可以发现，针对于视频平台而言，可以发现有些内容有些用于投放的内容我们是可控的，有些投放的内容是不可控。因此，在渠道拉新中，渠道可以分为可控投放渠道和不可控投放渠道。

3.2自然拉新用户

自然拉新用户对于平台而言，也可以定位为自然增长的流量，通常通过自然流量进入平台的用户有两种类型。其一是用户很明确的知道他想寻找的内容仅在当前平台存在，如希望寻找周杰伦内容用户会倾向于到快手，希望寻找《半泽直树》的用户会第一件事想到小破站，我们称这部分用户为强搜索型用户。其二是通过某些渠道搜索推荐或者其它的方式接触到平台的用户，往往这部分用户接触平台以后并不清楚自己希望观看的内容具体是什么，观看内容主要是通过平台的内容推荐机制给出用户可能喜欢的内容，因此我们称这部分用户为推荐型用户。

3.3总结

新用户有两大类，渠道拉新用户和自然拉新用户。

其中不可控渠道拉新用户、自然新增用户两部分可以视为无关键信息新增用户，可控渠道拉新用户可以视为有关键信息新增用户。后续在冷启动推荐时这两者推荐中是可以存在不同之处的。

四、新用户的内容推荐

内容推荐的核心在于内容池建立与优化、内容的召回和排序两个部分。新用户新内容池决定了新增用户能够获取内容的基础质量和内容广度，内容召回和排序则决定了新用户与平台建立信任的速度。

4.1 新用户推荐内容池

前文提到了，新用户可以分为有关键信息的新增用户和无关键信息的新增用户，因此在新用户内容池构建中可以确定思路为内容池由基础内容池和补充内容池两部分组成。补充内容池主要是由有关键信息的的内容及关联内容进行填充，基础内容池则是新用户内容池最难的部分。

4.1.1 新用户基础内容池建立及优化

新用户内容池面对的用户是主要是没有和平台接触过的用户，因此用户并不清楚平台的调性，平台内容的引导性。因此，平台在面对新用户时，需要紧密围绕当前平台的北极星指标，将北极星指标管理路径上表现优质的内容筛选出来，作为新用户的冷启动内容池。

伴随平台内容的不断增多，时事热点内容的不断革新，这个时候冷启动内容池需要引入当前平台的新热内容，并将已经过时久远的实时性内容移除出冷启动内容池。同时需要根据社会变化，需要将已经不符合平台、社会主流价值观的内容淘汰出冷启动内容池。

冷启动内容池的组成：大致可以分为经典内容+实效内容。

经典内容：经典内容=平台内容用户观看体验较好的内容。如B站芳斯塔芙、小文哥吃吃吃、老师好我叫何同学等up主创作的一些经典内容。

经典内容的筛选指标：以B站用户视频为例，vv超过10万以上的内容，主要查看内容的点赞率、投币率、收藏率、三连率、评论率、近一周播放、创作时间等信息。当这里面能和北极星指标关系度最高的某几个指标找出，在划定冷启内容池中，将这些内容优质内容不断添加进入冷启内容池中，并在在后续将数据表现不那么好的且所在分类下内容数量较多的内容逐步淘汰出内容池。

时效内容：顾名思义是和当下热点内容息息相关的。这部分内容主要特点是效性高，热度散得快。因此这部分内容讲求的是需要以最快的方式进入到冷启动内容池之中，在热度大幅衰减（如VV、点赞等）出现后一段时间，移出冷启内容池。

4.1.2新用户补充内容池的内容补充规则及方法

所谓补充内容，即当平台了解到用户在站外是通过哪些内容被吸引后打开平台时出现的操作。那么这部分主要是用户在站外看大的投放内容，和当前投放内容相关性较强的内容以及和投放内容用户观看行为上相关的内容。在针对于知道用户在站外观看内容而言，可以将这部分内容放入推荐池中。

当知道用户在站外被哪些内容引流以后，经过算法的筛选，可以获取相似（内容相似&行为相似）内容，将整体内容作为用户进入平台后冷启动的内容池承接用户浏览，可以进一步获取某一渠道用户的内容偏好，从而可以指导做投放同学进行某一渠道内容筛选，从而实现系统级的推荐循环。整体流程图如下：

4.2 视频推荐机制

4.2.1常用的视频推荐机制

内容推荐主要来自于两个步骤，召回和排序。对于新用户而言，内容池均为冷启动用户内容池，因此在整体的内容召回中，需要根据不同产品的交互形态，一次性召回多种类型的站内优质内容，以保证用户对于内容选择的多样性。

排序则是在召回的内容后按照一定的机制实施调整已召回内容的排序，由于面对的是新用户，获得内容消费信息较少，因此在排序中变回存在有两种状态下的排序规则：

冷启动内容的内容初始化排序主要集中在品类权重和内容权重两个方面。品类权重则指定的是历史上某个地区范围内，哪些内容品类消费数据较好，对留存的影响较大，那么这个品类的权重就会相对较高。为了适应用户的广泛性碎片化内容需求，品类需要做到尽可能的全面。品类中的视频需要按照与北极星指标中相依系数最大的指标做排序，由此确定品类内视频的排序。最终将品类内部所有的内容打散，通过算法做多品类内容综合排序，来确定新用户无行为时查看到的第一波视频。

4.2.2长短视频在推荐中的侧重点

前文提到，由于各家平台内容成本和用户的不同，因此在推荐中会强调很强的差异性。

1、以用户视频为主的平台推荐：

由于这类平台内容数量巨大，细分场景下视频覆盖度广，因此这类平台在推荐时聚焦于视频内容本身的推荐。如抖音油管的交互形式为单页播放，快手传统的双列也主要聚焦于视频内容没有对封面图、推荐语做特殊的内容维护和推荐拓展。

2、以版权视频为主的平台推荐：

版权视频由于内容成本很高，热门内容实效性强的特点。因此在纯内容推荐中更加侧重于人工维护+自动化内容补充的方式进行推荐，其中人工维护的内容为平台更加侧重的上新+热门内容。由于版权内容内容池相对于用户内容池远远偏低，且内容广度相比用户视频覆盖度小的多的特点，因此版权视频对于内容壳的推荐会更加注重。如在推荐版权内容时，会根据用户画像的标签、平台属性等特征，呈现给用户的内容会有多种一句话推荐、视频标题、视频封面图等因素。目前这方面Netflix是全球版权内容做的最先进的，Bilibili是笔者认为国内做的最先进的。

4.3产品经理在冷启动推荐的工作

一直以来，推荐产品经理都是相对神秘的角色。神秘之处在于丧失实体产品功能输出后，没有接触过这项工作的人会觉得一时之间无从下手。如果将推荐的内容当作自己实际输出的产品，将更多的内容召回排序的算法交给研发，通过这样进行产品创意提出、需求完善、上线优化，这就是推荐产品在整个工作中所要担任的角色。

根据推荐产品的角色和所处的业务形态大致，新用户内容推荐的产品工作大致可以拆解成3类：

4.3.1 指标对齐

主要是根据现有北极星指标，拆解出来当前产品形态中推荐需要保证的最终指标。在找到每个目标的转化漏斗的前提下，根据全新的业务指标，制定下一阶段推荐将需要达到的每项指标。连同研发一起评估指标增长的合理性，与研发一起对齐指标，后续产品经理可以通过策略的思维对功能进行设计，已完成制定的指标。

4.3.2 优化模型

在新用户冷启动的推荐的时候，通常的做法是由运营在站内挑选一些优质高留存的内容，由产品和运营一起评估这些内容的合理性，当确认内容可行后，会将内容输出给算法同学进行学习，算法会扩大相似内容的召回及排序结果给到产品经理，此时产品经理需要对算法给出的结果进行评估，将自己对于内容的问题输出给算法，同时需要了解当前算法模型涉及的维度及主要维度的权重，可以提出自己对于维度补充和权重变更的想法，配合算法一起优化模型。

4.3.3 制定规则

以上两种方式比较适合应用于视频类型多、内容量大的用户视频推荐。对于版权内容而言，由于热门内容、上新内容数量有限，因此产品经理更多要做的事情在于制定规则方面，如基于用户消费的过滤规则（用户看完整部电视剧以后，一段时间不要给用户再推荐了）。通过规则制定，让用户尽可能的对版权视频完成追更、付费，从而提升平台的北极星指标。

五、总结

本文主要普及新用户冷启动场景下视频平台的推荐方法及产品经理在这之中需要的做的事情和角色设定。整体而言在推荐中需要根据自己平台用户、内容的特色进行合理的推荐，以达到最大收益。产品经理在整体新用户冷启动内容推荐中主要的工作包含指标对齐、优化模型、制定规则三个方面，通过这三个方面不断优化产品的推荐模型，获得最大的收益，直接或间接提升业务的北极星指标。

千人万面奇妙自见：爱奇艺短视频推荐技术中多兴趣召回技术的演变

Fri, 23 Apr 2021 17:28:46 CST

导语

推荐系统的本质是信息过滤，多个信息漏斗将用户最感兴趣的内容逐步呈现在用户面前，如图1所示（《爱奇艺短视频推荐之粗排模型优化历程》）。召回阶段作为首个漏斗从多个维度将海量视频中用户可能感兴趣的内容滤出交给后续排序技术处理，它直接决定着后续推荐结果的效果上限。本文主要介绍爱奇艺随刻推荐团队多兴趣召回技术的发展历程。相比于其他召回技术，多兴趣召回技术能够同时挖掘出用户的多个潜在兴趣，在个性化推荐系统中突破传统的“千人千面”而达到“千人万面”效果。

图1 视频推荐系统主要流程[1]

01技术背景：如何召回“好苗子”，打破信息茧房

优秀的视频推荐系统可以精准地将视频分发给兴趣相匹配的用户，这个过程可以类比为优秀运动员经过层层选拔最终在世界大赛成功登顶，而召回阶段则相当于运动员年少时期的初次面对的市队选拔。

优秀的国家队教练固然业务水平精湛，但若没有天赋迥异的好苗子，也难以培养出世界级冠军选手；排序技术固然能够通过大量特征和精巧网络将效果提升，但若召回的所有视频本身质量不佳，那排序技术效果的上限将会提前锁死。因此，国家队教练需要多个省市的运动人才作为选拔来源，排序技术需要多个召回源作为待排序内容。

谈到召回技术，熟悉推荐的同学将举出诸多策略与算法，例如策略包括考虑内容关联的频繁项集挖掘Apriori等、考虑用户与内容相关性的召回itemCF等、基于协同过滤的召回SVD等；算法包括将内容变为embedding后再进行近邻检索的item2vec和node2vec、应用内容理解的CDML召回以及近年来兴起的GNN召回等。

图2 多兴趣召回主要流程[2]

如图2所示，多兴趣召回技术类似其他召回技术都依赖着用户过往的历史行为，但不同点在于多兴趣召回技术可以学习到用户的多个兴趣表示，将个性化推荐的“千人千面”升级为“千人万面”，每一个兴趣表示都能根据最近邻搜索得到相应的视频成为召回源。一方面，多兴趣召回技术符合多数用户拥有不同志趣和爱好的现实情况，能够让推荐结果精准且丰富，能够防止内容同质化带来观感疲劳；另一方面，除了挖掘用户的已有兴趣，多兴趣召回技术不断挖掘出用户自己从未发现的潜在新兴趣，防止传统推荐算法造成的“信息茧房”现象，让爱奇艺线上海量的文化资源呈现给用户。

同时，由于爱奇艺旗下丰富的产品矩阵，往往一个用户会同时使用包括爱奇艺基线、随刻、奇异果等多种产品。在多端用户行为混合训练的情况下，往往能够抽取出用户在不同端的不同兴趣、不同端用户的共同兴趣。这些兴趣往往能够帮助用户找到自己喜爱的社区与圈子，完成产品间的渗透打通和爱奇艺产品矩阵的复合生态建设。爱奇艺短视频推荐现在使用到的多兴趣召回技术有聚类多兴趣召回、MOE多兴趣召回、单激活多兴趣召回。本文将依次进行介绍。

02聚类多兴趣召回

聚类多兴趣召回的主要优点在于不用训练复杂的神经网络，只需利用线上其他深度学习的embedding即可形成多个兴趣向量（例如较为成熟的node2vec，item2vec等video embedding空间），时间和空间代价都较小。主要理论依据为KDD2020提出的兴趣聚类方法PinnerSage[3]。（是不是和PinSage名字很像，但它与图神经网络没有太大关系）。

PinnerSage聚类多兴趣召回是传统ii召回基础上结合聚类方法的新型策略。传统的ii召回中往往有两种做法：1，选择用户短期历史行为的每个视频，进行多次ANN查找选出近邻视频，这样的做法不仅时间成本高而且推出视频同质化严重。2，将用户短期历史行为的所有视频embedding进行pooling形成代表用户的user embedding，再进行ANN近邻查找，这样的方式能一定程度的融合信息减少时间空间代价，但很容易造成信息损失， pooling出的embedding如图3所示很可能差了十万八千里。

图3

PinnerSage则取两者之长，对用户历史行为中的视频进行聚类分组，pooling形成多个兴趣向量。聚类既避免了多次ANN带来的压力，也能一定程度上避免信息损失。PinnerSage 聚类多兴趣召回分为两步走：

a. 聚类过程。如图4所示，对用户观看过的所有视频进行聚类操作，Pinnersage聚类采用了hierarchical clustering聚类方法，并不需要像K-Means设置初始类别数，而是首先将每一个视频均看作一类，接下来每两类开始合并，若合并后组内variance增加最少则可以将两类合并为一类，直到variance超过阈值即停止。

图4

b. 取出embedding过程。PinnerSage依然不对类内视频embedding 取平均，而是选择类内的一个视频embedding作为类（兴趣簇）的代表，该视频embedding需满足与类内所有视频embedding距离之和最小。再利用这些代表用户兴趣的embedding们进行ANN即可。

聚类多兴趣召回通过简单的策略便形成了用户多个兴趣，时间代价较少。但由于依赖其他算法形成的embedding空间，学习到的多个兴趣embedding很容易有偏，推出内容趋于高热难以满足个性化。因此，团队继续向深度学习领域的多兴趣网络进发。

03MOE多兴趣召回

双塔模型是业界比较主流的召回模型，但是双塔模型在实际场景中效果有限。因此团队将双塔中的用户侧的塔结构进行修改，引入类似于MOE[4]的结构，提取多个向量表示用户潜在的兴趣，从而获得了极大提升。其中MOE是多目标学习中使用广泛的经典结构，根据数据进行分离训练多个专家模型，我们最终将多个专家模型的输出作为用户兴趣向量，通过与视频侧提取的向量分别计算内积得到最相似的一个用户向量参与损失的计算。

图5

MOE多塔结构如图5所示，左边为用户侧MOE多塔部分，右边为视频侧单塔部分。模型的实现细节包括：

a. 用户侧的输入主要是用户的偏好序列，包括用户偏好的视频id序列、上传者id序列与内容标签(tag)序列，序列特征经过embedding处理与average pooling操作后得到不同的向量，拼接之后组成MOE多塔的输入，经过MOE多塔计算后得到多个向量表示用户潜在的多个兴趣。

b. 视频侧为单塔结构，输入为用户交互过的视频id、上传者id与内容标签(tag)特征，经过embedding提取和拼接之后使用单塔结构提取信息。

c. 在loss计算上，由于召回是从千万级的视频库中寻找出用户可能感兴趣的几百条视频，因此实际样本中负样本空间十分巨大。为了增加模型对负样本的筛选能力和提升模型负采样的效率，我们在模型中使用batch内负采样，将batch内其他样本作为当前样本的负样本，同时使用focal loss损失函数来提升模型对难样本的识别能力。

经过修改之后的MOE多塔模型上线之后，单召回源的点击率和人均观看时长得到极大提升（全端CTR提升0.64%，召回源推出视频CTR比全端高出28%，展均播放时长比全端高出45%）。

经过修改之后的MOE多塔模型上线之后，单召回源的点击率和人均观看时长得到极大提升。但是MOE多塔共享底层的输入，仅仅使用简单的DNN网络提取不同的向量，导致多个塔之间的区分度比较低，多向量中冗余较多难以优化；此外用户序列特征中实际包含的位置信息对用户比较重要，当前模型难以利用，因此我们希望通过其他的网络来加以利用。

04单激活多兴趣召回

单激活多兴趣召回从19年开始便被工业界使用，其中最绕不开的是阿里提出的MIND[3]，其利用胶囊网络对用户序列进行动态路由收集多兴趣的方法在测试集上取得爆炸效果，激起了整个工业界对多兴趣网络的探索热情。随刻推荐团队也进行了探索。

4.1 单激活多兴趣召回初版

基于MIND等网络的启发，团队进行了单激活多兴趣网络的初版探索，网络结构如图5所示。在MIND网络中，采用了胶囊网络来抓取用户的兴趣，胶囊网络可以很好地同时捕捉观看的序列顺序信息和视频间的相关性，但由于结构较为复杂计算开销较大，且观看顺序仅单个维度即可表示不需要网络对位置信息太过敏感，因此团队选择transformer结构进行代替以保证训练速度。

图6

大致流程为：

a. 截取用户观看视频id序列{V1,…VN}作为sample，第N+1个视频作为target输入网络，经过video embedding层后形成embedding序列E={E1,E2,..EN}。

b. E经过transformer构造的兴趣抽取层得到多个兴趣向量M，取|Mi|最大的兴趣向量与target视频的embedding进行sampled softmax loss负采样，因此每次训练实际上只激活一个通道的兴趣向量。

c. 模型训练好后在推理阶段，取出用户所有兴趣向量，逐个进行ANN检索得到召回结果。

初版虽然结构简单，但上线后效果较好，极大提升消费指标、视频覆盖度和多样性。然而初版也存在着不同兴趣向量召回结果重复度较高、特征较少、即时性差等问题，因此也产生了多个版本的演变。

4.2disagreement-regularzation多兴趣召回

4.2中兴趣向量间无任何约束，因此容易出现兴趣向量过于相似的问题，因此在损失函数上需要施加正则项。鉴于初版多兴趣召回主要部分为transformer，团队在不改变网络结构的情况下使用三种正则函数进行探索[4]。

图7

如图7所示，分别对学习到的视频embedding(公式1)，Attention(公式2)，兴趣向量（公式3）进行正则化约束。在实际生产环境中发现，直接对兴趣向量进行正则化约束能达到最优效果。

4.3 容量动态化多兴趣召回

不同用户往往呈现不同的兴趣发散性，因此兴趣向量数应该是一个弹性指标而非超参数，在4.1与4.2的基础上，如图8所示在网络结构中引入兴趣激活记录表。

图8

训练过程中每当用户有任何兴趣向量被激活时，记录表均会记录这次激活。推理阶段，回溯激活表情况，将用户未激活或激活较少的兴趣向量剔除，以达到兴趣数动态化的目的，从而匹配不同用户兴趣发散性存在差异的现实情况。

4.4 多模态特征多兴趣召回

4.1-4.3中，多兴趣召回仅使用到视频id特征，学习效果依然有限，因此在后续版本的发展中，将上传者和内容标签(tag)融入训练成为主要方向。如图9所示，为网络主要结构。

Transformer部分与4.1-4.3中大致相同，不同点在于训练样本加入上传者和内容标签(tag)特征后经过embedding和pooling部分再进入transformer中。值得注意的有两点：

loss部分依然只对视频id的embedding进行负采样（与MIND等结构不同），这样的目的是让视频id的全部embedding可以进入负采样中，而不用折中使用batch内负采样，能够让最终推理阶段主要使用video id embedding更加精准（推理阶段ANN部分不会使用tag与uploader）。一个视频往往有多个内容标签(tag)，因此在对内容标签(tag)做embedding时需要对所有内容标签(tag)做embedding操作后进行一次pooling。

图9

4.5小结

如4.1-4.4所示，单激活多兴趣网络进行了多次演变过程，一次次改进后的应用带来了非常显著的效果，全端CTR显著提升2%，全端时长提升1.5%，人均播放提升1.5%；特别是在推出视频的多样性上，直接提升4%以上。

同时作为一个老少皆宜的内容平台，在爱奇艺一直存在着以家庭为单位，不同年龄段用户使用同一账号的情况，因此同一账号下的历史行为往往来自各个年龄阶段，用户历史行为的复杂性给推荐带来了难题。而单激活多兴趣网络的兴趣向量在学习过程的采样中具随机性、在数学呈现上具正交性，这就使得兴趣向量的搜索范围能够召回不同年龄段所喜爱的海量视频。

单激活多兴趣网络现在也是学术热点之一，希望能够有更多的研究者提出新的idea让推荐技术继续大放异彩。

05总结与展望

本文已经大致展现了爱奇艺短视频推荐召回技术中多兴趣召回的发展情况。多兴趣召回最大的亮点，在于可以抽取一个用户的多种兴趣，让曾经“千人千面”的画像迈入“千人万面”的高维空间，让推荐结果同时提升精准度和丰富度，同时也有兴趣试探，避免用户走入信息茧房。同时该技术也在爱奇艺产品矩阵复合生态建设与用户历史行为复杂性问题解决方案的前路上一直探索。

本文也认为多兴趣召回依然有可以优化的方向：

在行为序列的选取上，大部分的多兴趣策略与网络依然只考虑到用户的观看历史，如果能够运用事件知识图谱，将用户在平台上的搜索、订阅等行为一起纳入训练数据中，应该可以抓取用户更多的兴趣与倾向。在负反馈信息的处理上，多兴趣召回尚无应对之策。视频中的许多点踩、消极评论、不喜欢、取消关注等行为尚且未融入到多兴趣召回中，这些信息对指导兴趣网络的也至关重要，后期该方向将成为重点工作。在用户的静态信息与偏好特征的整合上，亦有很大的应用空间。这部分特征的组合能够很好地和排序目标对齐，提升召回源质量和排序效果上限。

参考文献

[1] 2021-2-26期，如何提升链路目标一致性？爱奇艺短视频推荐之粗排模型优化历程

[2] AdityaPal, et al. PinnerSage: Multi-Modal User Embedding Framework for Recommendations at Pinterest. KDD 2020

[3] Jiaqi Ma, et al. Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts. KDD 2018

[4] Yukuo Cen, et al. Controllable Multi-Interest Framework for Recommendation.KDD 2020.

[5] Chao Li, et al.Multi-Interest Network with Dynamic Routing for Recommendation at Tmall. CIKM 2019.

[6] Jian Li, et al. Multi-Head Attention with Disagreement Regularization. EMNLP 2018

网页音视频通话大火，WebRTC 正式成为 W3C 和 IETF 标准

Sun, 14 Feb 2021 23:29:44 CST

IT之家2月14日消息外媒 Neowin 报道，万维网联盟 (W3C)和互联网工程任务组 (IETF)宣布，网络实时通信 (WebRTC)现在是一个正式的网络标准，可以在网络上任何地方进行音频和视频通信。虽然 WebRTC 才刚刚成为一个标准，但它已经被流行的网络浏览器支持多年。

IT之家获悉，在技术层面上，WebRTC 是一个框架，允许开发人员将点对点的音频和视频聊天添加到他们的项目中。如果你曾经使用过 Facebook Messenger、Discord 或其他众多服务来进行视频或音频通话，那么你已经使用过 WebRTC。

IETF 主席 Alissa Cooper 表示，

“IP 语音和视频彻底改变了人们在世界各地的通信方式。将这些技术整合到网络平台中，极大地扩大了它们的影响力。得益于 IETF 和 W3C 之间的密切合作，使这些技术标准化。WebRTC 使数十亿人在 COVID-19 疫情期间能够相互联系和接触，无论设备或地理环境如何。”

通过对 WebRTC 技术进行标准化，任何想要在未来实现该功能的软件项目都将有一套明确的指导方针，他们可以遵循这些指导方针，以确保软件的 WebRTC 实现可以正确完成，并满足所有要求。

群晖发布可人脸识别、车辆识别、人员统计的本地视频监控解决方案 DVA3221

Fri, 06 Nov 2020 21:41:21 CST

群晖 Synology 最近发布了一款新硬件：本地视频监控解决方案 DVA3221，这是一台专门用来进行视频监控的机器，可以进行人脸识别、人员及车辆检测、人数统计、入侵检测。@Appinn

那个买软件送硬件的群晖这次发布的是专有设备，其他群晖机器无法使用这几个功能。

人脸识别

群晖提供了几个经典场景：

智能办公室：监控人员出入，当非员工进入时，自动通知管理员
校园安全性：当黑名单出现时通知安保
智能零售业：记录 VIP 资讯（姓名、偏好等），识别盗窃犯

人员和车辆检测

人数统计

入侵检测

入侵检测这个有意思，当有人翻越栏杆时，发送警报。

DVA3221 是一台配置了 Intel Atom C3538 的机器，还有一块 NVIDIA GeForce GTX 1650 显卡，支持最多 32 个监控摄像头，以及可处理 6 路影响分析任务，最大人脸注册人数 10000 人。

其实青小蛙对这台设备的兴趣不大，只是在微博发布之后，@sushiyoo 同学的一个简短的回复，触动了青小蛙，他的回复是：

The Machine

不知道还有多少同学记得这个画面：

视频面试传输协议到底是 TCP 还是 UDP

Wed, 02 Sep 2020 00:00:00 CST

背景

又是一年一度的秋季校招开始了，以往的校招各个公司都会在公司现场或者学校现场安排学生进行现场面试？但是今年由于疫情的原因，不允许让同学在现场进行一个面试，所以今年的面试形式就从线下转到了线上，面试形式的转变，但是我们考核学生的方式依旧没有转变。

校招的同学和社招的同学有很大的不同，他们没有丰富的工作经验，没有太多的项目经历，那么我们如何去衡量一个校招的同学呢？那就是基础和潜力，怎么去理解基础呢？俗话说不积跬步,无以至千里,不积小流,无以成江海，如果没有一个好的基础那么怎么才能成为一个优秀的工程师呢。如何去考察一个学生基础的好坏呢？我觉得有三个方面比较重要，计算机网络，操作系统以及算法和数据结构，通常来说计网考察得特别多，常见的一些问题：

网络模型分层
TCP和UDP的区别
TCP三次握手和四次挥手
HTTP各版本的区别

上面列举的问题只是其中一部分，这些问题基本在上课的书本中找到答案，如果你这些都不会那么只能说基础算是比较差了。由于这次是视频面试，我通常会问你觉得牛客网的视频面试是用的TCP还是UDP呢？在我揭晓答案之前大家也可以想想使用的是哪个网络协议，在面试的过程中所有的同学都回答了应该是使用的是UDP。我问为什么使用UDP?基本都会回答道UDP是一个无连接的协议，不用保证可靠性，传输速度快。我又问道如果UDP不保证可靠性，咱们在视频面试的时候我问你问题，如果你回答问题的视频流丢包了，那么你的答案我就听不见了，那视频面试的体验将会非常低。不少同学在这个时候就会改答案说那应该使用的是TCP吧，我这是又会问道TCP由于需要保证可靠性，但是在公网的复杂环境下，想必应该经常会出现缓冲或者卡顿的现象吧，很多同学这个时候就会哑口无言了。

其实这个问题的答案不难想出，我们可以将TCP和UDP的特性互相结合起来，让这个协议既可以保证可靠性，又可以保证实时性，这也就是我们所说的RUDP（(Reliable UDP），常见的RUDP协议有QUIC,WebRTC,Aeron等等，我这里主要介绍谷歌提出的QUIC，带大家领略一下RUDP的精彩，看看他们是如何既能做到可靠又能保证效率。

QUIC

QUIC(Quick UDP Internet Connection)是Google公司提出的基于UDP的高效可靠协议，他和HTTP一样同样是应用层协议。

为什么高效呢？是因为其基于无连接的UDP而不是基于TCP去实现的。

为什么可靠呢？因为其模仿TCP协议的可靠性，在应用层上做了可靠性的保证。

为什么需要QUIC?

互联网已经发展了几十年了，但是一提到网络协议，传输层使用得最多的还是TCP协议，应用层使用得最多的是HTTP协议，当然HTTP底层也是使用得TCP协议。虽然互联网已经发展这么久了但是对于TCP来说发展依旧缓慢，要说最大的改进应该是Google 在 ACM CoNEXT会议上发表的用于改善 Web 应用响应延时TCP Fast Open，通过修改 TCP 协议利用三次握手时进行数据交换，这个在Linux内核 3.7.1 以及更高版本可以支持。由于修改TCP协议必然会修改内核从而导致系统升级，这个推动的难度非常之大。

既然我们修改内核不行，那么Google就提出了在应用层协议上修改的办法，也就有了QUIC。

谁在使用它？

首先使用它的人肯定是谷歌，据说谷歌有50%的请求都是QUIC协议，微博也在全面使用QUIC协议，同时还有一些视频云服务比如七牛也在使用，在腾讯内部也有很多部门在大量使用QUIC，所以不需要担心这个协议使用的问题。

QUIC为什么这么牛？

0RTT 建立链接

RTT((Round-Trip Time)顾名思义就是往返时延的意思，0RTT的话意思就是QUIC可以在第一次发送的时候就带上数据，熟悉我们TCP的同学应该知道，TCP会有一个三次握手那么实际上也就是会有1次RTT:

如果是HTTPS的话还会使用SSL/TLS的额外握手，就会有3次RTT：

那么0RTT的建立链接QUIC是怎么做到的呢？这里得先说一下QUIC的0RTT并不是完全的0RTT,他同样需要1RTT去做一次秘钥协商，在QUIC中使用的是Diffie-Hellman密钥交换，该算法是一种建立密钥的方法，并非加密方法，但其产生的密钥可用于加密、密钥管理或任何其它的加密方式，这种密钥交换技术的目的在于使两个用户间能安全地交换密钥(KEY)以便用于今后的报文加密。DH算法用了离散对数的相关知识，这里就不扩展讲解，有兴趣的可以下来搜索这种算法。QUIC通过DH算法创建一个安全的连接后，客户端会缓存起来原始的连接信息等。在后续的过程中只要和同一个服务器建立链接都是直接发送数据，不需要再次协商秘钥，从而实现了后续的0RTT。

更为出色拥塞控制

TCP的拥塞控制的算法特别多，比如基于丢包反馈的（Tahoe、Reno、New Reno、SACK）, 基于延时反馈的（Vegas、Westwood），其中的Reno也就是我们最为熟悉的，它分为四个阶段：慢启动，拥塞避免，快速重传，快速恢复。

而在QUIC中使用了更为优秀的机制来控制拥塞控制，它可以针对不同业务，不同网络制式，甚至不同的RTT，使用不同的拥塞控制算法。同时也会采用了packet pacing来探测网络带宽，来提升网络使用率。

更好的重传机制

在重传的机制中有一个比较重要的名词，那就是RTO(Retransmission Timeout) 重传超时时间，一般这个数据会根据RTT去进行计算，那么我们有一个更精确的RTT肯定就可以有一个更好的RTO。

在TCP中重传的时候序列号不变，会导致我们的RTT算得不准确，比如重传的时候你不知道你这次请求到底是和原始请求匹配还是和重试请求匹配，就会导致我们的采样RTT不准确。

在QUIC中序列号都是递增的，并且通过offset来确定在包中的真实位置，这样就可以得到更为准确的RTT。

在TCP中计算RTT的方法就是发出的时间和响应回来的时间相减，但是这样算出的时间不准确，在QUIC中会减去服务端Ack Delay的时间，这样的话就更为精准。

同样的在TCP中有个SACK选项，该选项打开时用于记录传输过程中一些没有被确认的数据的范围，便于后续定向重传多组丢失数据，而不是全部重传，所以更多的范围便于更多的选择重传，也意味着更少的重传包频率。但TCP最多支持3个SACK范围，而QUIC能支持255个。

没有队头阻塞的多路复用

熟悉HTTP2.0的同学应该知道在2.0中如果访问同一个服务器只会有一个TCP连接，所有的请求都会走这条连接：

而每个请求在Connection中叫做Stream,一个Connection中可以有多个Stream，这里有个问题是在TCP中的包是保证时序的，如果某个Stream丢了一个包，他同时也会影响其他的Stream，在更为严重的时候反而多路复用还不如HTTP1.1的多个链接。

而在QUIC中，因为底层是基于UDP,UDP不需要保证包的时序，只会在接收包的时候对包进行重组，所以不会存在这个问题。这也就是为什么Google提议在HTTP3中使用QUIC的原因。

更优秀的流量控制

上面说了QUIC是多路复用的，在QUIC中可以针对Stream和Connection都进行流量控制。

QUIC 的流量控制和 TCP 有点区别，TCP 为了保证可靠性，窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包，就算接收到了更大序号的 Segment，窗口也无法超过这个序列号。
但 QUIC 不同，就算此前有些 packet 没有接收到，它的滑动只取决于接收到的最大偏移字节数。

最重要的是我们可以进行动态配置，可以在内存不足或者上游处理性能出现问题时，通过流量控制来限制传输速率，保障服务可用性。

连接迁移

现在在手机上移动流量和wifi的切换是一个比较常见的事，每次切换ip地址都会发生变化，如果是TCP的话连接就会中断从而进行重新建立链接。

在QUIC不再以 IP 及端口四元组标识，而是以一个 64 位的随机数作为 ID 来标识，通过这样的方式可以进行连接重复利用，不会重新建立新的连接。

其他

在QUIC中还有更多的其他的特性，比如：

通过header stream保证流顺序
底层保证连接持久
源地址令牌防止地址欺骗
握手时压缩证书避免放大攻击这里就不一一介绍了

这里就不详解介绍了，大家可以自行查阅资料搜索。

总结

其实这篇帖子也算是一个扫盲贴，相信有很多朋友没有听说过RUDP相关的一些东西，或者说听说过但是一直以为他是一个很复杂，很难理解的东西，其实在这里摊开来讲RUDP就是一个UDP+应用层可靠协议组成的，希望大家看完这篇文章后，能有所收获。

参考文章：

QUIC协议是如何做到0RTT加密传输的: https://blog.csdn.net/dog250/article/details/80935534
技术扫盲-新一代基于UDP的低延时网络传输层协议——QUIC详解 :http://www.52im.net/thread-1309-1-1.html
QUIC协议的分析，性能测试以及在QQ会员实践:https://www.cnblogs.com/wetest/p/9022214.html

如果大家觉得这篇文章对你有帮助，你的关注和转发是对我最大的支持，O(∩_∩)O:

一行命令，搞定常见图片、音频、视频、文本格式转换 - 少数派

Sat, 20 Jun 2020 08:30:28 CST

工作时我常常需要把一个图片、视频或文本文件转换成其他格式，或者需要把一大堆同样后缀名的文件转换成其他格式，这时，再打开一个软件要么有点得不偿失，要么一个个点按非常繁琐。几番寻找，我发现了下面这些全平台命令行工具，安装后，只要一行命令，就能搞定简单的文件格式转换。

图片：ImageMagick

ImageMagick是一款几乎全能的图片处理套件，它能完成图片的创建、编辑、对比工作，当然，转换格式也不在话下。软件开源、免费，并且全平台覆盖，在官方网站下载安装对应版本后，在终端输入 magick有返回值说明安装成功。推荐使用软件包管理器安装：

# macOS 需要安装 Ghostscript fonts 
$ brew install ghostscript 
$ brew install imagemagick 
# Windows 两条命令二选一，需要安装对应的包管理器 
$ scoop install imagemagick 
$ choco install imagemagick

该工具可以转换所有常用图片格式，例如 PNG、JPG、ICO、SVG。命令行使用非常简单，格式是 magick 待转换图片路径输出图片路径.后缀名，举例来说，将 A.png，转换成后缀为 jpg 的文件，在文件所在目录打开终端，命令为：

$ magick A.png A.jpg

对于 Windows 用户，可以使用 clipboard:变量表示剪贴版，下面这个命令表示将剪贴板中的图片输出为 B.jpg：

$ magick clipboard: B.jpg #执行此命令请确认剪贴板首位是图片

你也可以使用一些参数对图片进行处理，例如，-resize 表示缩放，-quality 表示输出质量，下面这行命令将 A.jpg 缩小 50%，并以 50% 的质量输出，对图片进行了压缩；

$ magick A.jpg -resize 50% -quality 50 B.jpg

音频、视频：FFmpeg

鼎鼎大名的 FFmpeg 是许多视频播放、剪辑软件的基石。软件本身也能完成视频的录制、转换、串流等一系列工作，你可以从官方网站下载安装包，但同样推荐使用软件包管理器安装，只需要把前文 install 后面的参数改成 ffmpeg 即可。

下面这行命令把 A.mkv 转换成为了 A.mp4，这样才能拖进某些剪辑软件的媒体库进行剪辑：

$ ffmpeg -i A.mkv A.mp4

「-i」后面输入待转换文件，最后填上输出文件名称、格式即可。除了视频格式以及音频格式的的转换，你还可以将视频文件转换为音频文件，这样就可以不用在剪辑软件中「分离音频轨」然后单独保存了，在处理一些 MV 或者语言类节目时非常实用:

$ ffmpeg -i .\Revenge.webm demo.mp3 #将 Revenge.webm 这个 MV 转换成了 mp3 歌曲

文本：Pandoc

想必你可能在其他文本处理软件中看到过它的身影，这是一款专门转换文本格式的命令行工具。支持的格式非常之多，常用的有 txt、docx、html、pdf、md、pptx，官方还画了一个巨大网状图详细展示了其所有支持的格式。下载地址在这里。

转换命令为 pandoc 待转换文件 -o 输出文件.后缀名,下面两行命令，将 sspai.md 转换成了 word 文档，又把 word 文档转换成了网页文件：

$ pandoc sspai.md -o sspai.docx $ pandoc sspai.docx -o sspai.html

转换效果如下，右边是转换后的 Word 文档：

软件还支持读取网页并转换成其他格式，例如，将少数派编辑器使用指南这篇文章转换为本地的 sspai.md，会保留页眉页脚等信息，对于下载一些结构简单的博客十分有用：

$ pandoc https://sspai.com/post/37790 -o author.md

PDF 格式处理需要 LaTeX 辅助，可以按需求下载。但不建议使用 Pandoc 进行 PDF 转换，体验不太好。简单需求使用电脑自带的打印功能即可。

结语

此外，这些工具都支持批量文件处理，可以使用一些通配符（*，%d 等）表示待转换文件，这样就能快速完成一些重复的工作。

文本介绍的是这些软件初级的用法，对于轻量使用已经足够了，复杂需求依靠有 UI 的专业软件会更好，他们可调试，可实时预览效果，体验更佳。如果想要学习进阶内容，可以翻看官方文档：

imagemagick： https://imagemagick.org/script/command-line-processing.php
ffmpeg： https://ffmpeg.org/ffmpeg.html
Pandoc： https://pandoc.org/MANUAL.html。

（文章头图： https://imagemagick.org/image/wizard.png）

爱奇艺视频后台从“单兵作战”到“团队协作”的微服务实践

Sat, 13 Jun 2020 16:54:49 CST

前言

系统越做越大，功能越加越多，我们是否有如下经历：

一次小的需求，评估由此产生的影响成本超过开发需求本身。
系统几经交接或升级，接口文档丢失或跟代码严重不符。
每天疲于排查线上问题和修复线上数据，没有精力代码优化。
由于创建/开发/部署新服务的成本，不断的将无关的功能添加到臃肿的服务。
线上服务一个功能或者中间件的中断，导致整个系统不能提供服务。
每次新功能的技术选型总需要迎合现有系统的技术架构做让步。

本文结合爱奇艺视频后端开发团队的微服务实践，分享推进微服务化落地过程中遇到的问题及思考。分别从以下三个方面展开。

微服务化是什么？

设计模式中有单一职责，算法理论中有分治思想，微服务化的思路大体一样，将传统大而全的单体应用，拆分成多个职责清晰、独立部署的服务。微服务化带来的好处是直观的，更快的开发效率，更清晰的系统边界，更好的扩展性和应对变化的能力；但是，随之而来是大量重复性工作和分布式带来的新的挑战。所以微服务化概括起来要做两件事，一是拆分服务，二是解决拆分服务带来的重复性问题和分布式问题。

怎样进行微服务化？

这部分介绍在微服务化落地过程中，我们遇到的问题及解决思路。主要从以下三个方面展开：

如何拆分服务，服务拆分时，主要考虑的因素
如何选择微服务框架，微服务技术选型时，主要考虑的因素
我们选用的微服务框架/公共组件原理及解决的问题

如何拆分服务？

微服务的拆分方式，没有固定的模式，粒度太粗，微服务化不彻底，粒度太细，开发运维成本高。微服务拆分不是一蹴而就的，而是随着需求迭代逐渐演化的，微服务的拆分结果应该是系统边界更清晰，需求迭代更快，开发效率更高，而不是相反，使问题复杂化。概括起来，可以从业务划分，重要程度，代码复用三个方面考虑是否要拆分服务。

业务拆分，微服务化的核心目标之一是业务逻辑内聚，系统边界清晰，便于需求迭代、代码重构和应对变化。所以，大部分时候，服务拆分基于业务划分，如果两个业务模块拆分后，频繁交互，相互依赖，接口定义复杂，则不适合拆分。
重要程度，服务重要程度不同，可用性要求，技术架构，保障级别都会不同。例如，同样是修改视频的操作，控制视频上下线的播控服务和记录视频历史修改的操作记录系统，放到两个独立的服务里，会更合适。
代码复用，对于相同的代码逻辑，不同于公共JAR包依赖，微服务是以独立部署的方式实现代码复用，当公共逻辑发生改变时，只需要升级一个服务而不是所有依赖该JAR包的服务。例如，统一网关服务，作为所有服务的访问入口，为微服务体系内所有服务提供统一鉴权和过滤逻辑。

如何选择微服务框架？

拆分服务的直接副作用是服务个数变多，开发运维成本线性增加。另外，由单体应用内方法调用变为不同服务间跨网络访问，给微服务化带来了新的挑战，比如，数据一致性保证，跨系统问题定位等。为此，我们需要引入一系列的框架、组件来管理服务，简化开发，减少运维。实际技术选型过程中，我们主要考虑了以下几个因素。

历史包袱，微服务化不可回避的问题是，遗留系统如何微服务化。鉴于我们大部分系统都是Spring MVC项目或者Spring Boot项目，所以，我们选用Spring Cloud作为微服务框架，对于遗留系统接入成本和开发人员学习成本都很低。另外，对于少量老的RPC服务，我们通过代理服务统一封装，将其纳入微服务体系内，降低服务调用成本。
核心诉求，有关微服务访问协议，以Spring Cloud为代表的HTTP和以gRPC为代表的二进制协议各有利弊，HTTP规范通用，使用成本低；二进制协议性能更高，节省带宽。我们结合自身的业务特点，相比对性能的严苛要求，更看重较高的开发效率和更快的需求迭代，所以，选择更适合我们的Spring Cloud。
框架成熟度，Spring Cloud在业界也有很多成功企业案例，文档丰富，社区活跃，而且提供了包括服务注册与发现，负载均衡，声明式接口调用，服务熔断，链路跟踪等组件的微服务化完整解决方案。相比之下，近两年新兴起的基于服务网格的微服务框架值得期待，但在成功落地案例和生态成熟度方面，还稍显不足。
使用成本，技术选型另一个要考虑的因素是使用成本，包括使用新技术的学习成本，独立部署服务的运维成本等。我们推进微服务化落地同时，公司服务云的同学提供了大量公共服务组件。其中包括基于Zipkin的链路跟踪系统Rover，基于Flume+ES+Kibana的日志收集系统Venus，基于携程Apollo的分布式配置中心等。为此，我们通过集成他们（而不是重复造轮子）解决微服务化过程中的部分公共问题。

所以，我们最终选用的微服务架构以Spring Cloud为基础，集成了服务云包括配置中心，日志收集，链路跟踪，奇眼Metrics监控等在内的公共组件，最终部署在公司QAE（iQIYI App Engine，基于Docker的应用引擎）上。另外，为了提升开发效率和解决分布式系统的常见问题，我们还提供了一些常用组件的实现，具体包括分布式锁，分布式限速，分布式调度等。

微服务框架包括哪些公共组件？

下面简单介绍我们微服务框架中的核心组件原理以及解决的问题。

注册中心&负载均衡，服务提供方在注册中心动态注册和注销服务，服务调用方从注册中心发现服务提供方实例列表，并通过负载均衡策略，从中选择一个实例进行访问。我们使用Eureka实现服务注册和发现，使用Ribbon提供客户端负载均衡和重试。通过选用区域感知的负载均衡策略，实现同机房优先访问的跨机房高可用部署方案。
分布式配置中心，微服务通过接入公司配置中心实现配置的集中管理和动态刷新。集中管理一方面可以实现同一服务内，不同实例间的配置共享，另一方面，可以实现不同服务间公共配置的统一管理，比如注册中心的访问地址，框架相关的默认配置等。动态刷新实现服务不重启的情况下，修改配置后，配置立即生效，比如根据实时流量，动态调整分布式限速和Hystrix线程池参数等。
统一网关服务，网关服务作为整个微服务体系的统一入口，提供动态路由配置，资源访问控制和接口级限速。所有注册到注册中心的服务，都可以通过网关，提供对外一致的服务，体系内服务的升级和重构，对服务调用方透明。
接口文档生成，为简化服务提供方编写接口文档的工作，支持需求快速迭代和拥抱变化，我们通过集成Swagger用于接口文档自动生成。开发人员只需定义接口和接口对象，就可以自动生成接口文档并可以直接发起测试，同时支持通过添加注解进行参数校验。
声明式接口调用，微服务化的副作用之一是服务调用更加频繁，为简化服务调用，我们使用Feign支持声明式接口调用。服务调用方只需声明本地接口或者直接引用远端服务定义的接口，无需编写实现，就可以像调用本地方法一样，调用远端服务。
服务熔断，微服务使用Hystrix实现链路熔断和降级服务，使用Hystrix dashboard实时监控Hystrix监控项。所有对外发起调用的地方，都使用HystrixCommand进行包装，防止因为单个服务故障导致其他服务级联故障。我们通过自动内置或使用注解的方式，降低使用Hystrix的门槛。
容器化部署，容器化是微服务的最佳载体，也是云原生应用的标配。我们使用Spring boot开发微服务，并部署到私有云QAE容器中，简化服务开发部署成本的同时，支持横向弹性扩容。公共组件选型时，我们通过选择云原生组件（比如Prometheus）或者简单改造适配（比如XXL-JOB），不破坏整个服务的云原生特性。
持续集成/部署，微服务通过对接公司持续集成工具QCI支持一键构建和部署。提交代码到gitlab后，自动触发构建打包，并上传至QAE应用，节省持续集成时间。
日志收集，日志是我们排查故障和检查程序运行状态的最主要的手段。我们使用统一的日志工具类格式化日志输出，无缝对接Venus日志收集，并将日志引流到专有ES集群，最终在Kibana集中展示和统计分析。
链路跟踪，链路跟踪用于快速定位跨系统调用问题。我们通过集成Spring Cloud Sleuth和公司链路追踪系统Rover，实现跨系统链路跟踪。对于体系内最常用的2种交互方式，Http同步调用和RocketMQ异步消息，自动内置链路跟踪功能。
Metrics监控，Mettics监控用于了解服务运行情况和线上流量分布，可以发现系统潜在问题，并为后续需求迭代和业务决策提供参考。我们引入奇眼/Kibana用作基于日志的Metrics监控统计，同时基于Prometheus实时监控报警也在落地实践中。
健康检查&报警，Metrics监控是基于日志的，如果应用本身有问题，没有产生日志或日志收集本身有问题（断流或延迟），基于日志的监控、统计、报警都会失效。为此，我们针对使用服务云提供的奇眼指针探测，定时检查服务health端点，服务不可用时，第一时间报警通知。
分布式一致性，服务拆分带来的分布式事务复杂性是微服务化最大副作用之一。业界有很多解决方案，比如2PC，TCC，消息事务等，我们结合业务特点，选用基于消息的最终一致性方案，简单有效，只需各个事务参与方保证业务幂等。
分布式限速&分布式锁&分布式调度，我们开发了基于Redis的分布式限速组件，用于在服务入口和资源受限的场景保护我们的系统。基于ZooKeeper的分布式锁，用于解决分布式场景下相同资源的访问冲突题。引入XXL-JOB，用于解决分布系统中的定时调度问题。

最佳实践总结？

这部分介绍我们微服务化过程形成的最佳实践。

提升效率&降低成本，微服务化的目标之一是提升效率和降低成本。微服务化过程中，不同的服务，业务上虽然是相互独立的，但是具有很多相同的横切性关注点。为此我们在微服务的全生命周期的各个阶段，引入多个公共组件来解决这些共性问题。比如，创建服务时，我们使用脚手架，一键生成项目原型；开发服务时，大量使用Spring Boot的自动配置和起步依赖简化开发；提供服务时，使用Swagger自动生成接口文档；调用服务时，使用Feign的声明式接口调用……
服务幂等&重试，分布式系统中，服务调用是最常见的操作。因为两方面的原因，服务调用失败的情况在所难免：一是当服务生产者状态由可用变为不可用，由于各种原因，服务消费者并不能立刻感知到；二是由于各种原因，例如网络抖动，JVM GC，资源受限等导致的访问超时。也就是说，我们不可能保证服务调用百分百成功。服务调用失败后，简单有效的补偿方案是，客户端增加重试。另一方面，服务调用方访问超时，服务提供方处理未必是失败的，为了避免生产者多次处理同一请求产生错误数据，服务提供方必须要做到业务幂等。
资源隔离&限制，我们在进行系统设计和编码时，必须意识到，任何资源都是有限的。比如数据库连接数量，线程数量，接口QPS限速，如果存在多个使用方共享资源的情况，就会出现一个使用方耗尽资源导致其他使用方无资源可用。对于常规的资源隔离，业界有好多最佳实践，比如Hystrix隔离，线程池，连接池使用等，对于系统中使用的其他资源，为避免因为共用资源而相互影响，最好也使用独立的资源。比如大到独立的存储，中间件，小到独立的队列等。
服务监控&数据可视化，微服务化的团队中，比较直接的职责划分方式是，按照服务进行划分，每个人对服务的全生命周期负责，从服务构建，开发测试，打包部署，到运维监控。开发人员编码阶段就应该为后期运维监控做必要的日志埋点，系统上线后，开发人员也应该关注线上运行情况和数据分布，并以此作为后期系统优化和需求迭代参考，促进DevOps形成闭环。
服务高可用&自修复，随着微服务化推进，每个人可能负责几个甚至更多微服务，因为各种原因，单次服务调用失败，甚至短时间内个别服务不可用不可避免，我们不应该每天疲于修复由于服务不可用而出现的数据不一致。提高服务的可用性以及实现故障恢复后系统自修复，总是值得的。为此，我们从存储到中间件，从提供服务到调用服务，从资源隔离到跨机房部署，多个维度进行了高可用方案选型和设计。

总结

微服务化过程，是服务拆分和消除服务拆分副作用的过程，为此我们引入大量公共服务和组件，用于解决分布式系统共性问题。服务拆分是随着业务发展逐步进行的，微服务框架是根据实际需要逐步演化的，公共组件也需要持续完善补充进来。但是，无论怎样变化，提高开发效率，提高系统可用性，减少运维成本的原则不会变。后续我们会对微服务相关框架、技术、方法论（比如服务网格，云原生，领域驱动设计等）保持关注，适时引入新的技术组件解决实际问题，进一步形成DevOps完整闭环。

原文链接： https://mp.weixin.qq.com/s/Pr7J546caebAQJkdf3NByA

优酷安卓短视频秒播优化

Sat, 16 May 2020 11:58:16 CST

一、背景介绍，短视频关注秒播

近几年，短视频一直处于流量的风口，各大平台纷纷涉足。不同的业务形态对技术有不同的述求，传统长视频关注的是减少播放中的卡顿，降低用户 seek 的耗时；直播关注的是如何保证实时性；而短视频关注的是秒播。

为什么短视频关注的是秒播？一是因为短视频通常只有十几秒，一是短视频的消费带有很大的探索性和随机性。如果用户花几秒钟等待十几秒的视频，很有可能起播后还不是用户喜欢看的，这个代价对用户来说太大了，久而久之，就是用户流失的时候。

二、现状与目标

短视频播放相关的核心技术指标有两个：缓存命中率和秒播率。通常情况，缓存命中率越高，响应的秒播率也就越高。短视频秒播专项优化项目启动时，关于缓存命中率和秒播率，结合现状，目标为缓存命中率提升 40%，200 毫秒秒播率提升 150%，400 毫秒秒播率提升 25%。

三、困难和挑战

首先，我们是短视频分发消费场，属于上层业务，底层播放器链路和预加载模块对我们都是黑盒的，无法直接在底层从根本去优化；

其次，短视频分发消费场，用户诉求是随机的，当用户滑到不感兴趣的视频时，会立即滑走，以便快速探索下一个视频。这会造成用户停留时间很短（通常不到 1 秒），大大挤压了预加载下一个视频的时间，造成滑出来的视频大概率在线起播，如果恰逢网络不稳定，很容易造成起播慢；

再次，优酷的长视频和短视频共用一个播放器。长视频场景下，更关注的是起播之后的流畅度。故播放器为了保证起播之后的流畅度，有如下播放优先策略。

1）播放前，由于不确定本地缓存的视频流是否足够起播，所以开始播放时，为了防止预加载任务抢网络带宽，此时会暂停所有的预加载任务，以优先保证起播。起播之后，在当前播放视频缓存的视频流达到配置的水位，才恢复被暂停调的预加载任务；

2）配置的时间阈值（300 毫秒）内无法起播，则会等待缓存的视频流加载到指定水位（指定时长或者指定大小），才会开始起播。

播放器以上两点播放优先策略，放到在短视频场，就不适用了，甚至是矛盾的，这无形中大大增加了短视频秒播优化的难度。

四、行业做法

在开始优化之前，很有必要花些时间对行业做法深入调查一番。主要集中在两个方面，一个是货，即视频源；一个是预加载策略。

如下表所示，从数据上可以看出，优酷和快手两家的货大同小异，而抖音在视频编码上支持 H.265。

平台	时长(s)	分辨率	码率(mbps)	大小(mb)
优酷	18	720p	2.45	5.6
抖音	15	540p	1.11	1.8
快手	20	720p	2.07	5.0

五、优化策略

视频起播耗时，主要有两个方面，一个是播放器准备耗时，一个是从网络加载视频流耗时。所以优化原则简单粗暴，就是在播放前，想尽一切办法，准备好播放器和将视频流加载到本地。

下拉刷新优化

feed 视频列表请求成功后，扣留列表中最后一个视频到内存中，然后预加载其视频流；下拉刷新时，将上次扣留到内存中的视频放在下拉刷新列表的第一个位置，同时扣留下拉刷新列表的最后一个视频，如此往复，保证下拉刷新播放的视频是本地起播。

feed 场景下，向下滑动出来的视频都是算法推荐，没有传统列表的分页概念。所以 feed 场景下，用户通常是一直向下滑动以获取新的推荐内容，用户没有下拉刷新的心智，故此优化项在此业务场景下收益甚微。

按需预加载视频流

现有预加载模块，如果业务方不设置预加载 buffer 大小，则统一为 400k，通过线上开关控制。优化后，业务方动态计算预加载 buffer 大小，计算原则就是预加载 3 秒的视频流。如果在视频播放时，3 秒视频流全部加载到本地，则既能保证起播，又能保证起播后的顺畅。

此项优化，收效同样甚微，按需预加载，只在一定程度上避免造成预加载任务阻塞，并没有从根本上提高预加载效率。

闲时任务

在视频播放超过 5 秒或者重复播放时，认为当前播放的视频流已全部加载完成，此时网络是空闲的，利用此网络空闲的时间，串行预加载后面的视频。

小视频业务大盘数据统计用户平均每个视频的消费时长为 6 秒，加上 1/3 的播放为重复播放，所以此优化项对于缓存命中率有较大提升。

预加载时机提前

利用滑动切换视频时，在滑动松手到滑动停止这段时间（300 毫秒），在保证滑动帧率的前提下，开启子线程预加载后面的视频，利用这 300 毫秒，预加载后面的视频流，保证本地起播。相比原先预加载时机是在滑动停止，当前视频起播后才预加载后面的视频，假设视频起播时间为 500 毫秒，则相比优化前，预加载时机提前了至少 800 毫秒，这是非常可观的提升。最后测试下来，也是此优化项对于缓存命中率的提升是最为明显的。

至此，关于缓存命中率的优化已经收尾，上线后大盘数据也验证了优化的效果，缓存命中率提升了 38%。

双播放器

上述的四项优化，都是业务层在有限的时间和空间里抠细节，在预加载策略上做文章，经过一系列优化手段，缓存命中率达成目标。

虽然缓存命中率完成目标了，但是核心的技术指标秒播率并没有完成，距离目标还有一定差距。这时候我们只能硬着头皮，想平时不敢想，做平时不敢做的，开始实施双播放器方案，空间换时间。双播放器方案原理比较简单，就是在当前视频起播之后，预准备下一个视频的播放器，两个播放器循环使用。

下一个视频的播放器一旦准备好，加上视频流已加载到本地，则起播非常快，几乎是视频直出的效果。但由于播放器准备更耗时，用户滑到下一个视频时，并不能百分百保证此视频的播放器已准备好。双播放器方案上线后，效果显著，200 毫秒秒播率提升 178%，400200 毫秒秒播率提升 29%。

至此，缓存命中率和秒播率圆满完成任务。

注解

1）秒播：1 秒内完成播放，后来常用于泛指起播速度；

2）秒播率：指定时间内起播的次数占全部播放次数的比例，比如 200 毫秒秒播率指的就是 200 毫秒内起播的次数占全部播放次数的比例；

3）缓存命中率：开始播放时，本地有播放视频的视频流，哪怕本地缓存的视频流只有一个字节，也认为是缓存命中，缓存命中率指的就是缓存命中的播放次数占全部播放次数的比例；

4）编码格式：又称视频编码规范，视频压缩格式。通常原始视频非常大，不方便存储和传输，所以需要将原始视频进行压缩。视频编码格式很多，这里不累述，优酷场主要的视频编码格式有 H.264 和 H.265，H.264 和 H.265 的详细区别这里也不累述，总的来说就是，H.265 的压缩效率更高，传输码率更低，视频画质也更清晰。

作者 | 阿里文娱高级开发工程师乐想

竞争性毁灭的长视频市场

Mon, 04 May 2020 20:02:40 CST

文/一念

要避免因此而在公开报价拍卖会上付出愚蠢的价格，最佳的办法是巴菲特的简单做法：别去参加这些拍卖会。——查理·芒格

看爱奇艺的年报，让人感慨万千。我觉得它其实并不算互联网企业，而是重资产的竞争性毁灭型企业，就像曾经的伯克希尔纺织厂。

我们看到，从2015年开始，它的成本都远远大于收入，加上其他成本费用，更是连年亏损。2019年收入290亿，亏损103亿。

互联网企业最核心的特征是规模效应，即生产成本是固定的，但增加一个用户的边际成本忽略不计。这也是大部分互联网企业开始时不惜成本也要快速占领市场的原因。

但我觉得爱奇艺等长视频的参与者却处在一个竞争性毁灭的市场中，赚的钱不得不全部投回去，就像钢铁、纺织等行业：

内容提供者集中且议价能力极强

其他的互联网企业面对的是分散的商家，议价能力都很强。想想淘宝卖家、美团商家、阅文作家等等时不时发牢骚就知道了。这些公司被人描绘成黑心资本家，正说明他们的议价能力强。

相反，电影和电视剧是一个很成熟的市场。内容提供方是非常专业的公司和演员，在加上其他播放渠道、其他参与者的竞争，让参与者沦为打工者，而且短期看不到尽头。

对用户来说，大家追的是剧。平台几乎没有粘性可言，它们只能被动抢拍热剧。芒格说“公开叫价拍卖就是把大脑变成一团糨糊：你已经得到了社会证据，另一个家伙正在出价，你产生了回馈倾向，你还会得被剥夺超级反应综合征，而那件物品即将被拍走……我的意思是，这绝对只是为了操纵他人，让他们做出愚蠢的行为。”

我们可以预计，哪怕今后爱奇艺取得规模优势，好处也会被内容提高者拿走大部分，爱奇艺等所剩无几。

同质化竞争明显

虽然爱奇艺在竞争中暂时领先，但和腾讯视频相差无几，后面优酷仍然没有放弃。而且这个市场同质化特征很强，芒果、B站、西瓜等虎视眈眈，随时可以加入血战，我们根本看不到这场战争的尽头。

这点比其他的互联网市场差很多。比如在游戏市场，运营商的重要性远远比开发商重要得多，腾讯等运营商就是比其他的强。

爱奇艺在年报中强调它的优势是AI、大数据分析等，说实话我没看出有什么区别（We distinguish ourselves in the online entertainment industry by our technology platform powered by advanced AI, big data analytics and other core proprietary technologies.）

视频时效性强，长尾效应弱

视频时效性很强，大家通常是和朋友同事一起追同一部热剧，以便在茶余饭后、在朋友圈交流讨论。但过时的老剧看得人就少得多，长尾效应弱。

所以，历史上买的积累的版权库能带来的收益极其有限。稍有例外的可能是纪录片、儿童动画片等。

这点貌似与数字阅读市场相似，其实不然。读书是相对个性化私人化的事，大家会根据自己的兴趣选择，而且一本书可能十多年后仍然有人读，因此是有累积效应、规模效应的。

另外大家也倾向于书库丰富的平台（重要性77%排名第一），和追剧时的选择不同。

短视频的分流

这点大家已经讨论很多了，不再展开。

$爱奇艺(IQ)$ $腾讯控股(00700)$ $阿里巴巴(BABA)$

微信公众号：一念小书房

本话题在雪球有5条讨论，点击查看。
雪球是一个投资者的社交网络，聪明的投资者都在这里。
点击下载雪球手机客户端 http://xueqiu.com/xz

在科普视频方向，B站不能只有一个“罗翔”

Sat, 02 May 2020 11:10:00 CST

刑法学教师罗翔，图片来源@bilibili

文丨锋科技（ID：feng_keji）

2020年的春天，在哔哩哔哩弹幕网（下称“B站”）上，“罗老师”火了，此罗老师不是罗永浩，而是一位名叫罗翔的中国政法大学教授。

从去年开始，罗翔老师的刑法讲课视频就上传到了B站，其风趣幽默但又不失正气的讲课风格，让原本只有法学生才会观看的法考视频，吸引了来了一大批非本专业的年轻人。B站UP主在一年的时间内，孜孜不倦地将罗翔老师讲课中的段子进行剪辑上传，最终在疫情居家期间迎来了一场爆发。

三月份，罗老师在B站上开设了自己的官方账号，投稿的第一个视频，几天时间内就达到了两百万的播放。虽然现在回顾来看，罗老师的拍摄设备和技巧明显生疏，整个人显得很“颓”，和视频网课中那个意气风发的讲师形象差距较大，但依旧抵挡不住学生的欢迎。

属于PUGC（专业用户生产内容）的时代，到来了。

“知识时代”的机遇

疫情对于B站来讲是一个千载难逢的机遇， 由于疫情导致的“长期放假”，24岁以下的年轻人有更多的时间沉浸在视频软件中。根据Questmobile的统计，疫情期间视频工具的同比增长率达到了169.5%，仅次于效率办公和短视频的类别之后。

从B站核心用户“Z世代”的用户画像来看，求知欲强是对他们最好的注脚，年轻人渴望知识，但不渴望深层讲解，罗翔的出现就很好的迎合了这一现象。

从B站公布的营销通案上，可以找到关于这些年轻人的精确描述，这些人大部分都来自一二线城市，本科率达到50%，可支配收入为3500元（全国居民月平均支配收入为2300元）。

随着B站核心用户的逐渐成长，高学历、高消费能力成为了他们的重要标签，Z世代对于娱乐之外的知识性学习逐渐有了要求。2019年，B站学习类UP主数量同比增长151%，学习视频播放量也同比增长274%。泛知识学习类内容的观看用户数则突破5000万。

不仅是B站，在别的视频APP中，PUGC内容的优先度也在被迅速前置：知乎在自己的短视频业务失败之后，选择和快手合作推出“快知计划”，希望让快手的团队来丰富自身的短视频底蕴；字节跳动旗下的西瓜视频高薪更是直接从B站挖角，敖厂长、痒局长、渔人阿峰等知名UP都在西瓜开设了自己的账号。

但在一些UP“告别”B站的时候，有些用户会一针见血的指出“我不是因为某个UP，而是因为这个平台才会去观看”，B站的超高黏度可见一斑。

将知识UP“B站化”

在一次关于如何维护B站黏度的探讨下，董事长陈睿说了关键的一句话 “B站一直是community first而不是user first，满足社区比满足用户更重要” 。换言之，与其用精准推送去尽善尽美地服务每一个用户，不如建立一个区块化的年轻人的社交集群，这才是B站的终极目标。

而在笔者看来， 如何将知识型UP，打造成与B站社区息息相关的形象，是B站相比其他平台最具有优势的地方。

我们以罗翔老师为例，B站敏锐地捕捉到了罗老师身上的几个“梗”：讲课举例常用的张三，被称为“法外狂徒张三”；罗老师讲到上头，迟迟不用身边的水杯喝水，被B站网友戏称“喝水中止”；最后是网课上的蓝色背景“厚大法考”。这些梗也成为了罗翔老师相关的二创视频中的关键要素。

在罗翔老师入驻B站的两周后，他的“自拍风”科普就摇身一变，成为和之前一样的“蓝色背景、水杯在手”的状态，考虑到罗老师自身没有团队，这次风格变化很可能是B站和厚大法考的手笔。 B站为了迎合罗翔老师身上的“梗”，特地以一种最无缝的方式植入到B站的社群文化中，这是其他网站很难做到的。

随着B站和罗翔老师的合作加深，在后期上传的视频中，可以看到拍摄的手段和风格都有了质的提升。单从视频封面的提升就可以看出来，B站在背后下了不少功夫，更别提和番剧区UP进行的“跨界合作”了。

不过，相比较跨年晚会、买进影视版权、明星入驻等吸引流量的手段来看，B站对于科普类视频的支持力度还远远不够。

视频科普的死穴

回到文章开头，罗翔老师刑法讲课视频的爆火，在网上也引起了一些不和谐的声音。譬如知乎上就有部分网友认为，刑法段子固然可以作为调剂，但不能作为公众普法的主菜。而笔者也看到，互联网上最近的公共话题讨论中，罗翔老师的段子里的“名言”也常常被曲解误用。

比曲解毋庸更为可怕的，则是没有收入，根据一些跨平台视频主的介绍中，B站虽然有着极高的社区黏度，但靠视频变现的力度并不大 。而要促使“职业”知识类UP的形成，视频变现恰恰是最重要的。

Youtube可以给前电气工程师、医学专家、化学教授充分的盈利前景，只要你的视频上线，就能靠默认广告来赚钱（1000播放就能拿到5美元）。但B站目前只能依靠罗翔这类有正规职业的UP主为兴趣科普，百万播放也只有几千元人民币。Youtube的体量以及资金扶持，是国内任何一家视频网站难以达到的，更何况是没有贴片广告的B站。

更深层的原因，在于国内版权以及营销号的污染情况严重，B站对侵权现象的反馈也很消极。哪怕是津津乐道的“年轻人在B站学习”，主要内容也都是具有版权争议性质的网课视频，甚至还有直接“翻拍”知名Youtuber的科普视频在B站逍遥过市。科普类视频的文案和视频制作没有保障，B站就很难建立起真正的“科普生态”

要知道，罗翔老师的爆火，一个重要原因就是背后的厚大法考。厚大法考的主业是图书销售和考试培训，课件视频的收费很低，B站UP的上传行为对厚大起不到绝对性的利益侵害。而且在众合和柏社等法考机构的打压下，厚大也经历了一波法考讲师流失，才会和B站合作主推罗老师。

不客气地讲，罗翔老师的“成功案例”更像是B站钻了一个版权和商业上的空子，“先盗版引流，后正版合作”对于厚大可行，但不是一个可持续的模式。

B站离知识布局还有很远

用户群体安全意识淡薄，加上B站对于版权的消极应对，最终伤害到了B站试点的正版网课。罗翔的成功似乎给了B站错觉，认为“知名大V+流量推广”就等于大获全胜，也放松了针对自身社群的本土化改造。

从价格上看，B站网课的价格都在100元左右，但付费率并不高。B站红人“局座”张召忠开设的国际战略课程，每集平均付费观看量只有四万。

笔者能找到的最高播放量网课是一个Pr剪辑教程，可以看到，在前两集的试看结束后，付费内容就出现了断崖式的下跌，每集也只有十万左右——这也是B站课堂上线后的第一个课程，原价99元打八折，附赠一堆素材包换来的。

而B站显然也有自知之明，网课功能上线半年，依然还挂着“beta”字样，app端和网页端都没有课程入口，只有很精确的搜索才能显示，B站网课的前景比科普还要惨淡。

除了版权和营收问题外，B站对于知识大V的“利用率”也不是很好。在4月23日的世界读书日活动中，B站创立的的知识型账号手握朱一旦、纪连海等资源，举办了一场推书活动，但也仅止步于账号联动，导致播放量极为惨淡。

更为奇怪的是，在“世界读书日”相关Tag下拥有百万播放量的的papi酱、陈睿等B站老UP，官方却没有与他们进行任何形式的特殊合作。 这次“知识推广”的失败，代表着B站没有利用好复学前的最后一批学生群体，放过了数十万的用户增长机会。

作为今年B站重点发力的新赛道，如果B站不对知识类进行收入和版权的“重点关照”，依然按照传统的流量思路去和明星互搏，显然是行不通的。

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App

技术资讯 | 浅谈相似视频检索技术

Sun, 19 Jan 2020 00:00:00 CST

前言

近几年视频成为了人们记录和分享生活的主要手段。

像抖音、快手等视频应用，越来越受到年轻人的喜爱。无论是活跃用户的数量，还是用户的视频创作量，每年都在显著增加。据相关统计，每分钟视频网站就要增加近400小时的内容[1]。

在这些新上传视频中，相似的视频往往不在少数。如果能够检测出其中相似的视频，对实现 视频去重、 版权保护、 热门视频推荐等具有重要的意义。

本篇文章将分享一些 相似视频检索最新的进展，包括：

1） 相似视频 定义；

2） 公开数据集；

3） 代表性 方法。

定

义

相似视频又称为 Near-Duplicate-Video(NDV)[2]。字面意思就是接近复制的视频。

相比于图像：

视频包含了 时间维度，使得视频包含了极为丰富的 信息量。这也使得从内容上衡量两个视频变得比较困难。

为此学术界对 NDV类型的视频做了一个定义，即相似视频是在原始视频上，在光度、 画面编辑、以及编码等方面进行了修改。具体如下：

比如下面的图像中，右边的视频在左边视频的基础上增加了滤镜和 文字操作。

而在下面的图片中：左边的视频和右边的视频拍摄的同一个场景，但是由不同的用户在不同时刻拍摄的，不符合相似视频的定义。

1)Frame Level 方法

Frame Level的方法对视频的每一帧图像提取特征，然后 通过逐帧计算图像相似性的方式来计算整个视频的相似度。

典型的代表方法是 循环时间编码(circulant temporal encoding)[3]。这种类型，对每帧图像提取SIFT特征并做PCA降维后，采用循环时间编码和频域变换来表达视频的特征向量，以此在数据库中检索。此外还有 空间核匹配(temporal matching kernel)[4]等方法。

基于freme level的方法运行 开销比较大， 很难应用在实际的场景中。

2)Video Level方法

Video Level的方法，大多对视频 提取全局特征，并计算各个相似度来判断是否相似。尤其是随着深度学习的发展，大多数视频特征的提取采用深度学习模型来取视频特征。主要是 先对视频中的图像帧提取卷积特征， 再进行特征融合。

2.1) 图像帧特征提取

深度学习在图像领域中的大多数任务是基于图片。在面向视频任务时，先提取视频的帧，接着利用预训练的分类模型进行正向传播，取其分类器之前的各层特征向量，作为图像的特征。

大多数方法采用inamgenet上预训练的 VGG、 inception或者 resnet模型来 直接提取图像的特征向量，特征维度视模型的层数而定。

2.2)视频特征融合

对视频的图像帧分别提取了卷积特征之后需要进行特征融合，得到视频层面的全局特征。针对这个过程研究人员提出了很多种方式，主要包括 pooling法、 BOW(bag of words)、 度量学习以及 哈希编码等。

2.2.1)pooling

Pooling方法的思想是将视频中每帧的特征向量，在时间维度进行max pooling或者average pooling，从而 将多帧的特征转换为整个视频的特征。

往往视频的长度是非固定的，将视频的多帧特征采用pooling的方式融合为全局特征向量，实现时间维度的特征压缩。这种方式 速度上有优势，但很大程度上 降低了特征的准确性。

2.2.2)BOW词袋向量

词袋向量的典型方法是 CNNL[2]为代表。这种方式在提取到每帧特征的基础上，将特征提取网络中每层特征向量经过事先预训练的词袋模型，得到每层特征对应的词袋直方图， 将不同层的特征向量拼接在一起，形成整个视频的表达特征。

论文中词袋的产生是每层取30万个特征样本进行聚类，得到1000个类中心，每层特征经过对应词袋时选择最近的聚类中心。

此外，此论文还提到也 直接将每一层的原始卷积特征拼接后，再经过相应的词袋，得到每帧的直方图。从而形成视频的直方图向量(CNNV)，以此进行两个视频相似性的度量。

经过词袋模型对每帧图像特征的变换，相比于pooling的方式能更好的 保留视频中各个帧的特征，同时随着特征维度的降低，也会加快视频的检索过程。

2.2.3) 测量学习法

这种方法代表为 DML(Deep Metric Learning)[5]。对视频的每帧提取特征，和上面的方法类似，接着采用average pooling的方式融合多帧的特征，并采用多层全连接网络将特征转换到可度量的欧式空间中，再以此计算相似度。

论进行特征空间映射的全连接网络需要 额外训练。论文中提出构建三元组的方式作为训练样本，每个三元组包含待查询的视频、相似的视频以及不相似的视频，三元组里两个相似视频的特征欧式距离要小于非相似视频间的距离。

因此每个 三元组的 loss函数如下图所示：

通过最小化训练样本中所有三元组的 loss函数之和，训练出最佳的全连接特征映射网络，从而实现视频特征到度量空间的 最佳映射。

相比于BOW这种方式需要较多的先验参数，通过测量学习的方式有 更好的泛化能力。这种方式同样将视频的多帧特征转换到了低维，可以 更快的检索。

2.2.4)效果对比

文章[1]在不同数据集上对比了上面的几种方法。

测量学习的方法虽然总体最好，但是随着视频变化程度的增加(如增加黑边、旋转等)，所有方法的效果大幅度下降。

3)视频检索方法

相似视频检索的目的是 从大量的数据库中检索出与当前视频相似的视频。

通过上面的方式获取视频的全局特征后，计算两个视频全局特征的距离可以判断视频的相似程度。因而可以逐个计算数据库中所有视频与当前视频的相似程度，找到相似度最高的那个视频，但是这种 暴力检索的方式，很难应对大规模的数据库。

另一种方式就是 哈希编码，在提取到视频的全局特征的基础上，对其进行哈希编码，基于哈希值可以大大提升视频检索的速度。

目前已经有不少哈希编码方法都可以对加速检索的过程。如：

locality sensitive hashing(LSH)

iterative quantization(ITQ)

isotropic hashing(IsoH)

Hamming distance metric learning(HDML)等

论文[1]在采用pooling的方式获取视频全局特征后，基于不同哈希编码的视频检索 效果对比如下：

在论文中采用的数据集上哈希编码的查询方法， 准确度要低于上面的几种方法。也可以看出哈希编码虽然可以加速视频检索的过程，但也会伴随着查询精度的下降。

除了上述的这些方法，其他诸如 3D卷积网络的视频提取方式也在逐步得到应用。相比于2d卷积融合的方法也有一定的优势，但是仍然面临 较大的时间开销。

总

结

相似视频检索， 对视频业务来说其重要程度不言而喻。学术界将对图像提取特征的卷积网络，逐步应用到对视频特征提取上面，在诸如相似视频的检索方面，已经有了一定的成效。

但是在实际业务中视频的巨大数量以及繁多的内容类别，采用面向图片提取特征的手段，迁移到视频特征层面时仍然难以取得较好的效果，视频检索任务离真正落地应用还有很长的路要走。

参考文献：

[1]Jiang Q Y, He Y, Li G, et al. SVD: A Large-Scale Short Video Dataset for Near-Duplicate Video Retrieval[C]//Proceedings of the IEEE International Conference >

[2]Kordopatis-Zilos G, Papadopoulos S, Patras I, et al. Near-duplicate video retrieval by aggregating intermediate cnn layers[C]//International conference >

[3] J´erˆome Revaud, Matthijs Douze, Cordelia Schmid, and Herv´e J´egou. Event retrieval in large video collections with circulant temporal encoding. In CVPR, pages 2459–2466, 2013.

[4] S´ebastien Poullot, Shunsuke Tsukatani, Phuong Anh Nguyen, Herv´e J´egou, and Shin’ichi Satoh. Temporal matching kernel with explicit feature maps. In MM, pages 381–390, 2015

[5]Kordopatis-Zilos G, Papadopoulos S, Patras I, et al. Near-duplicate video retrieval with deep metric learning[C]//Proceedings of the IEEE International Conference >

投稿 | 内容标签团队

编辑 | sea

排版 | sea

往期推荐

在看点一下大家都知道

腾讯视频 Node.js 服务是如何支撑国庆阅兵直播高并发的？

Tue, 29 Oct 2019 00:00:00 CST

导语 | 上个月，我有幸参与了腾讯视频国庆阅兵直播页面开发的相关工作，最终，累计观看2.38亿人次，经受住了高并发的考验。在参于Glama框架的开发维护及平时基础建设相关讨论实践中，对高并发有一些部分实践心得，正好老友也想了解腾讯视频这边的经验，特撰写本文，对相关经验进行梳理总结，与大家探讨。（本文作者：Lucienduan，腾讯视频Web前端高级工程师）

本文将从 服务可用性、缓存、日志三个维度总结视频侧开发高并发Nodejs服务的一些经验。

一、 视频前端网络结构

先介绍腾讯视频前端网络结构，网络架构如下图所示。

腾讯视频Node.js服务的网络示意图

流程简述如下:

用户首先请求GSLB，找到最佳接入IP，就近访问CDN节点；
CDN缓存命中时，直接响应缓存，如果有CDN缓存失效或未配缓存，会直接回源到TGW(Tencent Gateway), TGW主要处理容灾、负载匀衡；
请求从TGW(STGW)转发到业务层Nginx，在Nginx中也会有简单的容灾策略（主要由 max_fails， fail_timeout两个设置配置）和缓存机制，最后到达Node服务；
在Node中用cluster模板转发到对应的worker进程处理，worker中会跑具体的业务，请求对应的后台服务器。

这里TGW主要功能：负载均衡、容灾、IP收敛、多通接入。

系统整体的可靠性需要各个节点相互配合，本文主要针对由前端开发的负责的模块， Node和业务这一节点为中心从可用性，缓存和日志发散来说高并发服务需要关注的点。

二、可用性

运维老司机说： 没有绝对可靠的系统，局部故障是常态。

但通过一些方法兜底和保护，可以保证核心业务无异常。

保证业务可用首先需要保证相关的进程工作正常，进程异常时能容灾兜底。

进程守护

Node.js主进程守护，腾讯视频这边用shell脚本来描述执行：

通过 crontab 命令，定时1min钟去检查一次进程(用ps指令)和端口(用nc指令)是否正常，异常时重启服务。

在Nodejs Cluster模块，主进程会把TCP分配给worker进程处理，worker进程主要三个问题，僵尸进程，内存泄露和进程异常退出。

僵尸(无响应)进程：当程序运行到死循环，就不再响应任何请求了，需要及时重启：

在Master进程定时向worker进程发心跳包，当worker进程在一段时间多次不回包时，杀死重启。
内存监听：主要为了兜底内存泄露问题，当worker进程达到阈值时，杀死重启
进程退出：进程异常退出时，需要重启。

目前社区有比较多的工具可以实现进程守护，比如pm2。

页面静态化/预渲染

最安全的进程是没有进程……即整个请求链中不依赖的Node.js服务。

静态化示意图

对于一些只有少数的几个运营同学更新数据且可用性要求极高的页面，可以直接由运营的发布动作触发页面更新的CDN。

整个请求链环节少，无回源请求，异常的概率最低。

即使Node.js有多级的守护，但还是有可能进程内的分支逻辑或接口出现异常，当分支逻辑或接口异常出现时，合理的容灾策略可以提供降级服务让核心业务无影响，用户无感知。

三、三层容灾策略

如果上面守护异常，或是底层的依赖服务挂了，H5页面有三层容灾策略。

容灾策略示意图

1. 接口容灾

接口容灾主要应对依赖的底层接口异常。当后台接口正常返回时，把数据缓存到redis，异常时，用redis的旧数据兜底。

2. 页面HTML

兜底思路与口容灾差不多，当页面渲染异常时，中间件检测到返回5xx，同样用正常的缓存在redis的旧HTML兜底。

3. NodeJS容灾

主要应对NodeJS工作异常，当NodeJS进程正常响应时，把静态的HTML推到CDN作为备份文件, 如果NodeJS返回5xx时，在Nginx代理层重定向到静态备份文件。

从实践来看，上面的进程worker的守护和容灾兜底，可以很好的保证源站业务的稳定性，对于高并发业务，缓存和告警必不可少。

四、缓存

缓存在高并发的系统扮演着至关主要的角色，除了用户态、推荐等少数业务场景不能用缓存外，缓存是应对流量冲击简单有效的方式，目前视频侧主要有三级缓存， CDN缓存，代理层Nginx缓存，应用层redis缓存。

三级缓存示意图

图片来源：《Web前端与中间层缓存的故事》

CDN 缓存

CDN的OC节点不但可以减少用户的访问延时，也可以减少源站的负载，但Node.js站点在用CDN抗量时同时需要注意两个问题。

1. 更新时间

由于CDN一般用于缓存静态文件或更新粒度比较小的页面，默认的缓存时间比较长，在接口上使用时需要注意更新时间，同时接口不能带有随机参数。

在70周年阅兵主持人页面中，轮询请求量非常大，接口用了CDN缓存，由于没有太关注更新时间，导致接口更新不及时，对于自建CDN，需要注意 cache-control和 last-modified字段的更新，或是关注 status头查看回源状态。

2. 缓存穿透、雪崩

目前自建CDN缓存没有缓存锁，当缓存失效到下一次缓存更新这一小段时间(一般在40~500ms)，所有的请求都回源到源站，并发比较高时，会有大量穿透到源站，底层没有保护的话可能引起雪崩，所以需要多级缓存。

Nginx自带缓存锁，通过简单的配置就可以解决这个问题。

Nginx代理层缓存

Nginx除了提供基本的缓存能力外，还提供缓存锁、缓存容错能力，

proxy_cache_use_stale可以配置，错误，超时，更新中和其它异常状态时，使用旧缓存兜底和避免过多的的流量穿透到源站。

同时proxy_cache_lock配置，可以防止配置没有预热时，缓存的穿透的问题。

当proxy_cache_lock被启用时，当多个客户端请求一个缓存中不存在的文件（或称之为一个MISS），只有这些请求中的第一个被允许发送至服务器。其他请求在第一个请求得到满意结果之后在缓存中得到文件。如果不启用proxy_cache_lock，则所有在缓存中找不到文件的请求都会直接与服务器通信。

所以Nginx通过正常的配置，可以大大减少回源的请求，减轻源站的负载。

页面缓存

在应用层或框架层，可以用redis实现第三层缓存，这层的redis缓存也是HTML渲染异常时兜底的基础。实现思路比较简单，需要关注两个问题：

页面缓存版本不同步时，有无适配问题，如果需要识别版本，版本不匹配的缓存直接失效。
是否需要设计缓存锁来避免穿透问题，如果上层已处理(比如Nginx)，或下层能抗量流量可以忽略不加锁。

整页缓存粒度比较大，可以针对业务场景做拆分，比如针对部分推荐数据的页面拆分页面片缓存或接口缓存。

从CDN、Nginx到redis，每一层的工作量、业务侵入性，粒度不一样，业务需要根据自身场景，选用适合自己业务的缓存即可。

五、日志与告警

告警和日志，对故障早发现早处理，复盘根本原因至关重要。

目前视频除了基础平台提供的CDN、TGW和机器的物理资源的监控外，在用户侧和代理层，源站均有不同维度的告警和监控。

监控示意图

客户端提供了前端监控和告警，提供用户侧的监控，比如页面质量，CGI质量，用户流水及手动上报的能力。
反向代理层 由Nginx上报监控，监控访问波动，错误量占比(4xx， 5xx)时耗时。
请求日志主要记录原站的总请求数，请求失败数据及平均耗时。
Nodejs进程日志主要进程异常退出，内存泄露，僵尸进程等进程日志，对业务稳定运行，非常重要。
Node请求流水日志主要记录请求维度的开发自定义日志，用于问题的定位复盘，进程状态观测。
模调监控监控请求方和服务方的错误和响应时间的情况，当前模块与底层依赖模块的接口实时接口质量。

每层的监控和日志可以帮助业务快速了解业务状态，定位业务异常。

总结来说：单个用户异常，查看客户端啄木鸟流水和Node请求流水日志，服务大概率异常查模调和请求日志，Node进程异常查看代理层日志和进程日志，响应时间异常可以从客户端、代理层、源站及模调的耗时逐步分析。

六、总结

可用性永远是做框架和业务的同学需要关心重要指标，但是现状如文初所说： 没有绝对可靠的系统。

除了关注Node.js的业务开发质量，如何在流程和架构层面避免局部异常不影响整体业务和用户体验更值得更进一步思考。腾讯视频在架构和框架的设计层面防呆，故障前进程守护，监控告警等方法避免和发现问题；故障中通过多级容灾兜底提供降级服务；故障后通过各个节点的日志定位问题改进回顾。保证质量参差不齐业务都能抗住高并发且高可用。

---------下方更多精彩----------

活动推荐

（点击图片即可跳转）

关注云加社区，回复 3 加读者群

点在看，分享给身边的开发者