预计算
一、功能目标 当文件上传完毕（无论是通过 SDK / API / 控制台上传），系统能够自动触发对应的 后处理动作，例如： 🎞 视频自动转码 🖼 图片缩略图生成 🧠 AI 内容分析（如标签识别、人脸检测） 🪣 元数据同步 / CDN 刷新 / 日志上报 目标是： 解耦上传与后处理； 支持灵活扩展； 支持异步高可用。 二、系统流程图（逻辑架构）┌────────────────────────────┐│ Upload SDK / API │└──────────────┬─────────────┘│ 上传成功回调▼┌──────────────────────┐│ Upload Service ││ (统一上传接入层) │└──────────────────────┘│查询 cloud_process_pre_action│▼┌───────────────────────────────────┐│ PreAction Dispatcher ││ (动作分发模块，匹配触发条件) │└──────...
多云对象管理
背景随着云计算技术的成熟，越来越多的中小型企业（特别是暂无自建：小文件存储体系的公司）采用多云（Multi-Cloud）或混合云（Hybrid-Cloud）战略，以避免被某个供应商锁定，与此同时，也能利用不同云厂商的优势技术。而图片or 视频数据作为企业核心资产之一，常常分散存储在AWSS3、Google Cloud Storage、Azure Blob Storage、阿里云OSS、华为云OBS、火山云tos等多个对象存储服务中。在这种背景下，跨云、跨账号的数据流动和管理变得日益频繁和复杂。 愿景本文旨在打造一个统一、高效、安全的跨云存储管理平台。 1、提供统一前端管理界面，让用户无需关心底层云厂商的API差异，即可通过一个统一的api、界面、播放器、下载器，直观地在不同云存储桶之间浏览、管理和传输文件，实现数据的自由流动，大幅提升数据运维效率。 2、公司若决策从A云迁移到B云时，让上层业务，尽可能的少感知：底层小文件存储的迁移变化，基于此系统，只需简单几步，即可方便地：按照bucket维度实现：数据同步（增量 +存量）、数据回源、数据验证、数据切换上线，数据割接。 3、需设计...
deepseek论文解读
一、背景 二、论文集合 听完：EZ.Encoder Academy：博主讲的部分文章，个人认为讲的还是：非常不错的，收集下相关链接： 1、《EZ撸paper: DeepSeek-R1 论文详解 part 1：比肩 OpenAI-o1，如何做到的？| 论文深度解读+独家分析》：https://www.youtube.com/watch?v=tRuN8xYdETs&t=1610s 2、《R1的黑马之路：它是如何超越O1？小修小改，还是彻底颠覆？》：https://www.youtube.com/watch?v=-9HODvpVD2o 3、
视频切片并行加速
背景在实际业务中，视频处理，大都时候都挺费时的。例如：以下表格是，某中算法，在不同分辨率、帧率下的，cpu计算耗时体系（不包括：上传、下载的耗时）： 分辨率 帧数 处理时长 / 视频时长 720p 30帧 2 720p 60帧 4 1080p 30帧 3 1080p 60帧 6 2k 30帧 3.5 2k 60帧 8 4k 30帧 7 4k 60帧 20 另外，一般情况下，视频越长，所占用的cpu or gpu，也就越久。如此有以下弊端：1、对于用户而言，耗时久，体验非常不好，有可能直接放弃了。2、很容易造成资源负载不均，例如：有些机器比较倒霉，每次分配的都是：长视频（5min以上），有些机器比较luck，分配的大都都是：短视频（30s以内）3、超过1h的视频，单台物理机，基本上不太可能能够处理完毕，姑且不谈cpu，内存都有可能爆满。 视频处理这里面的视频处理，可以是：libx264转码、libx265转码、超分、ai绘画、去除水印、人像增强、去模糊、去躁点等等。 思路梳理资源扩容例如：某一个算法，目前部署在：8核cpu上，可...
算法工程化
背景将相关算法部署，并提供一个 or 多个http接口，服务于业务方。 算法大学中所学的数据结构课本上说：算法是指解决问题或执行任务的有序步骤集合。当然，如此描述的算法，相当准确。但是，对于实际工程落地而言，还是过于：抽象。这里面描述的算法，是指：算法同学所交付的可执行文件 orso库，例如：视频压缩领域的：264算法，交付的产品：集成到ffmepg中的libx264。例如：如下命令，是使用：libx264算法真正去压缩一个视频的命令，那么：对于实际工程落地而言，所提供的带上libx264的ffmpeg可执行程序，可以简单地理解成：算法 1ffmpeg -i source.mov -s 1280x720 -profile:v high444 -c:v libx264 -preset veryslow -crf 30 -r 30 -g 120 -keyint_min 30 -sc_threshold 40 -bf 3 -b_strategy 2 -refs 5 -c:a libfdk_aac -profile:a aac_low -b:a 128k -movflags fastst...
从0到1搭建媒体处理体系
背景作为公有云重要组成部分，云端媒体处理体系，可以通过将图片、视频、音频等的计算处理移至云端，让用户享受到更高效、灵活、可扩展的服务。 业界调研 公有云 缩写 产品名称 备注 阿里云 MPS 媒体处理、媒资库 腾讯云 MPS 媒体处理 百度云 MMS 多模态媒资检索 火山引擎 媒资库、视频库 华为云 MPC 媒体处理 七牛云 智能多媒体服务 又拍云 云处理 其实，无论叫啥名字，它们的本质做的事情是一样的。其整体流程图如下： 怎么搭建经过抽象，想要搭建一套媒体处理，包括以下模块，如下图所示： 说明：1、上述图展示的是：包括了多少个功能模块，并非调用顺序，各个模块的调用顺序，得根据实际功能来定，会有专门的模块来分析。 功能云处理的功能，用公式来表达：媒体s = fn (媒体s，参数)，有以下特点：1、媒体，只是狭义上的媒体，单纯地指：图片 + 视频 + 音频。2、带上s，证明可以是：多个，也可以是0个，入参 + 出参均是如此。3、fn：函数，特指：对入参媒体s做的动作。4、出参：媒体s，可以是文本，例如：包括了met...
版本核对
背景在实际媒体计算的业务场景中，如何确定计算后的图片 or 音频 or视频符合上线标准？最简单的办法：手动跑图，然后，人眼看，主观判断是否符合上线标准。这种方法，随着核对算法越来越多，跑图张数越来越多以后，会变得越来越吃力。 核对流程对于用户而言，其整体工作流程如下： 概念定义1、版本核对，以某个版本的算法的跑图结果作为基准，新开发的算法的跑图结果 与 此基准跑图，做差异性检测。如果有差异，则人工介入分析。 其中，两个版本的算法，跑图必须一样 + 算法入参也必须一样，注意：必须2种结果：以其中一个为基准，确定另一个是否满足预期。 2、版本择优：同一个算法，入参图片一样，但是，算法入参不一样，计算出多种结果，然后，主观选择最好的一种上线。注意：2种以上的结果。 3、画质评测：同一个算法、入参图片一样，算出一种结果，通过人眼主观评测，得出当前结果的画质值，注意：可以只有一种结果。 4、自主跑图：自动调用手机 or 电脑 or api,自动跑出一批图片 or 视频出来。 分类按照跑图媒介进行分类： 名称 分类 说明 备 注 安卓跑图 手机客户端跑图 调度安卓机器，触发...
流程决策
背景流程决策是一种基于规则引擎的业务流程控制方案，通过预先定义的规则集合来自动化决策过程。在复杂的业务场景中，它能够帮助系统根据不同的条件自动执行相应的操作，提高业务处理的效率和准确性。 定义流程决策系统主要包含以下核心概念： 场景（Scene）：特定的业务场景，作为规则集合的容器 规则（Rule）：在特定场景下的判断条件和执行动作的集合 条件（Condition）：规则触发的前提条件，可以包含多个条件元素 条件元素（Element）：构成条件的基本单元，包含参数、操作符和比较值 操作符（Operator）：用于条件判断的比较符号（如：等于、大于、包含等） 动作（Action）：当条件满足时需要执行的具体操作 指令（Instruction）：系统可执行的具体指令集合 参数（Params）：在规则执行过程中需要的参数定义 库表设计 表名 作用 备注 场景表：cloud_process_scene 存储业务场景定义 作为规则的顶层容器 规则表：cloud_process_rule 存储具体规则信息 关联场景表 条件表：cloud_process_rule_con...
媒体处理开放平台
功能定位在互联网时代，将算法、模型的处理能力，封装成一系列业务能理解的接口开放出去，供第三方开发者使用，这种行为就叫做OpenAPI，提供开放API的平台本身就被称为开放平台。 需求梳理如：从0到1搭建媒体处理体系的架构图所示，开放平台包括以下功能： 功能 优先级 功能说明 备注 协议转换 T0 将千变万化的用户协议，转成内部的标准文件处理协议 参数校验 T2 确保入参满足要求 鉴权 T0 确保接入请求都合法，没有所谓的：水平越权 or 垂直越权 计费 T1 统计：调用次数、输入视频时长、使用cpu、gpu的时长等 同步转异步 T0 详见：同步转异步 协议转换业务需求千变万化，很难通过定义一套标准，让所有人都按照固定的方式接入。因此，需要有一个系统去承接：将千变万化的用户个性化报文，转成内部的标准文件处理报文。 网关形态站在用户视角来看：所见即所得，是比较好的用户体验方式。用技术术语来说，就是用户同步等待结果的显示。但是，对于大图片计算，长视频计算，往往也是非常费时的操作，极容易超时，因此，这就产生了2种产品形态：形态1：同步等待结果模式...
数据集市
背景当某个app的DAU呈45°上扬，从百万DAU，到千万DAU，甚至过亿DAU，无论是组织架构，还是：经典的db +缓存策略，会变得越来越无法灵活面对纷繁复杂的业务场景。具体表现如下： 专业人做专业事任何一个团队的成员构成比例，既有资深的，也有新人。一般情况下，都是让新人介入实际业务需求，那么，该新人就得在熟悉业务的前提下，也需熟悉目前的：db +缓存策略。那么，可否让新人刚开始只关注于：业务。等业务熟悉以后，再去关注：db + 缓存策略呢？ 成本优化过五百万dau以后的业务，功能也是非常多的，此时，db +cache策略一般都还在业务代码中，面对如此境遇，单靠2、3个所谓的架构师，想要在确保当前功能不变的情况下，做到：性能优化 or成本优化，其实，还是有很大的挑战的。 多语言下中间件的困境在很多公司的后端工程领域，都有3种以上的语言(例如：php、java、go)，每种中间件都必须提供3种语言的sdk版本，这给中间件带来一定的维护成本，也给业务方的学习成本、升级成本。以redis为例，虽然redis提供了相当丰富的功能，但是，站在业务方的角度上说，它需要关心：redis的ke...