网课作业上传限容
某高校教师要求提交的课堂演讲视频不得超过 50MB。学生用手机录了 15 分钟的 1080p 视频,原始文件 300MB。用本工具的 CRF 模式,将参数设为 28,分辨率保持 1080p,输出文件压缩至 45MB,画面中 PPT 文字依然清晰可辨,避免了因画质过差被退稿重交的风险。
标准:码率 2 Mbps · 分辨率 720p · 30 fps,体积与画质平衡。
诚实标注:本工具纯前端运行,采用「video 静音播放 → canvas(可降分辨率)逐帧重绘 →
captureStream(可降帧率)取视频轨 + 原音频轨 → MediaRecorder 以
videoBitsPerSecond 降码率重编码」,输出为 webm(VP9)。
减小体积靠 降码率 / 降分辨率 / 降帧率 三手段;webm 通常比原 H.264 mp4 更小,保留原声。
需要精确 CRF / H.264 / MP4 请用 FFmpeg(ffmpeg -i in.mp4 -c:v libx264 -crf 28 out.mp4)。
导出需保持本页面前台播放至结束。
剪辑完一段 4K 素材,准备导出给甲方,发现原片 2.3GB,邮件附件上限 25MB。这个工具用 FFmpeg 在服务端重新编码,提供码率、CRF 和质量三档控制——CRF 18 到 28 对应视觉无损到重度压缩,分辨率可降档到 1080p 或 720p。文件上传后处理,不存服务器,处理完即删。适合给交付物压到刚好过审、不重压画质的场景。
某高校教师要求提交的课堂演讲视频不得超过 50MB。学生用手机录了 15 分钟的 1080p 视频,原始文件 300MB。用本工具的 CRF 模式,将参数设为 28,分辨率保持 1080p,输出文件压缩至 45MB,画面中 PPT 文字依然清晰可辨,避免了因画质过差被退稿重交的风险。
淘宝某女装店铺运营接到平台通知,主图视频时长需从 60 秒剪到 30 秒以内,且文件大小不能超过 10MB。原视频码率是 8Mbps。用本工具的码率模式,将视频码率设为 2Mbps,音频码率设为 64kbps,输出文件 8.5MB,成功通过审核,且模特走秀动作没有出现明显卡顿。
车主发生轻微剐蹭,交警要求通过微信发送 20 秒的事故视频作为证据。行车记录仪导出的 4K 视频 150MB,微信传输限制 25MB。用本工具的分辨率模式,将视频缩放至 720p,码率保持原样,输出文件 18MB,完整保留了对方车辆变道压线的关键画面,未因压缩导致车牌号模糊。
美食博主在 B 站发布 4K 烹饪教程,同时需要将同一视频分发到竖屏短视频平台。原视频 4K 分辨率、60fps,文件 2GB。用本工具将分辨率改为 1080x1920 竖屏,帧率降至 30fps,码率设为 6Mbps,输出文件 150MB,既适配了抖音的推荐算法,又保证了煎牛排时油脂飞溅的细节可见。
某公司培训部需要将 30 场累计 50 小时的员工培训录像归档到 NAS,但 NAS 剩余空间仅剩 100GB。原始视频平均码率 15Mbps,用本工具的 CRF 模式,参数设为 23,并将分辨率统一降至 720p,最终每场视频从 3GB 缩至 2GB,50 小时内容压缩至 90GB,刚好存入 NAS,且员工工牌上的姓名依然可读。
| 输入 | 输出 | 说明 |
|---|---|---|
| 原视频:1080p, 30fps, 码率 8Mbps, 时长 2min → 目标:CRF=23, 分辨率 1080p | 输出文件大小约 45MB,码率约 3Mbps,画质肉眼无损 | 常规:CRF 模式是大多数用户首选,23 是平衡画质与体积的默认值,适合日常压缩 |
| 原视频:1080p, 30fps, 码率 8Mbps, 时长 2min → 目标:码率 2Mbps, 分辨率 720p | 输出文件大小约 30MB,分辨率降至 720p,码率稳定在 2Mbps,画质中等 | 常规:固定码率+降分辨率组合,适合上传平台(如微信/抖音)限制文件大小场景 |
| 原视频:4K, 60fps, 码率 50Mbps, 时长 5min → 目标:CRF=18, 分辨率 1080p | 输出文件大小约 120MB,码率约 3.5Mbps,画质极佳(接近无损) | 常规:高画质需求场景(如存档/剪辑素材),CRF=18 接近视觉无损,但文件仍比原片小很多 |
| 原视频:1080p, 30fps, 码率 8Mbps, 时长 2min → 目标:CRF=0, 分辨率 1080p | 输出文件大小约 800MB,码率约 55Mbps,画质无损但体积远超原片 | 边界:CRF=0 表示无损压缩,但会大幅增大体积(甚至超过原片),一般仅用于存档或二次编辑 |
| 原视频:480p, 15fps, 码率 500kbps, 时长 30s → 目标:CRF=28, 分辨率 1080p | 输出文件大小约 8MB,码率约 2.2Mbps,画质差(模糊、锯齿明显) | 边界:升分辨率不会提升画质,反而因插值导致体积增大且画质下降,提示用户应保持或降低分辨率 |
| 原视频:1080p, 30fps, 码率 8Mbps, 时长 2min → 目标:码率 100kbps, 分辨率 1080p | 输出文件大小约 1.5MB,码率约 100kbps,画质极差(严重马赛克、色块) | 边界:极低码率下,1080p 分辨率无意义,画质不可用;建议用户同时降低分辨率至 360p 或 480p |
| 原视频:1080p, 30fps, 码率 8Mbps, 时长 2min → 目标:CRF=23, 分辨率 1080p, 但输入文件为 .mov 格式 | 输出为 .mp4 格式,画质与 CRF=23 一致,文件大小约 45MB | 易错:工具自动转封装为 .mp4(H.264),用户常误以为 .mov 可保留原格式,实际输出统一为 mp4 |
| 原视频:1080p, 30fps, 码率 8Mbps, 时长 2min → 目标:CRF=23, 分辨率 1080p, 但用户同时勾选了“裁剪”功能(裁剪为 16:9 的 1080p 中心区域) | 输出文件大小约 40MB,画质相同,但画面四周被裁切,内容有损失 | 易错:裁剪与压缩同时使用时,用户可能忘记已裁剪,导致重要内容丢失;建议预览裁剪区域 |
1.CRF 值设太低,文件反而变大
CRF = 0CRF = 23(默认值,兼顾画质与体积)CRF 是视觉质量无损因子,0 为无损(文件极大),51 为最差。低于 18 后体积指数级增长,画质提升肉眼不可见,仅适合存档级需求。
2.码率模式与分辨率不匹配,导致画质崩塌
分辨率设为 4K,码率设为 500 Kbps分辨率 1080p 时,码率建议 2000-8000 Kbps;4K 时建议 15000-40000 Kbps码率是每秒数据量,分辨率越高需要越多码率来保留细节。低码率高分辨率会产生严重块效应,不如降低分辨率保码率。
3.二次编码只选一次,浪费压缩潜力
使用 VBR(可变码率)但仅单遍编码选择 2-Pass VBR 编码单遍 VBR 实时分配码率,无法预知复杂段;2-Pass 先分析画面复杂度再分配码率,同等体积下画质更均匀。
4.音频码率保留过高,压缩比虚高
视频码率压到 1000 Kbps,音频仍保留 320 Kbps AAC音频码率设为 128 Kbps(AAC 格式)或 96 Kbps(Opus 格式)人耳对 128 Kbps AAC 以上几乎无感知差异,音频占 24% 总码率会严重挤压视频空间。压缩视频时应同步降音频码率。
5.分辨率缩放不按原始比例,导致画面变形
输入 1920x1080,输出设为 1280x720(比例 16:9→16:9,正确)输入 1920x1080,输出设为 1280x960(错误比例)→ 应保持 16:9 即 1280x720缩放时若宽高比与原视频不一致,FFmpeg 默认拉伸填充,人物变胖或变瘦。手动指定宽高时需计算原比例。
6.帧率设置与源文件不符,导致音画不同步
源视频 30 fps,输出设为 60 fps(插帧)输出帧率保持与源相同(30 fps),或降至 24 fps随意提升帧率需要插帧算法,FFmpeg 默认重复帧,导致运动卡顿;降低帧率需丢帧,可能造成音画偏移。
7.编码器预设选错,速度与体积失衡
预设选 placebo(最慢)预设选 medium 或 slowplacebo 比 veryslow 压缩率提升不到 1%,但编码时间多 5-10 倍。日常用 medium 平衡速度与体积,追求极致压缩用 slow。
8.输出格式与编码器不兼容,生成文件无法播放
输出格式选 .mp4,编码器选 VP9输出 .mp4 配 H.264 或 H.265;输出 .webm 配 VP9MP4 容器不支持 VP9 编码,播放器会报错。容器格式与编码器必须匹配:MP4 配 AVC/HEVC,WebM 配 VP8/VP9,MKV 兼容性最广。
CRF = 18 + (目标码率 - 源码率) × 0.01
CRF恒定质量因子,0–51,越低质量越高目标码率用户设定的输出码率,单位 kbps源码率原始视频码率,单位 kbps源视频码率 8000 kbps,目标码率 4000 kbps:CRF = 18 + (4000 - 8000) × 0.01 = 18 - 40 = -22,实际取 0(最低值),输出质量接近无损但文件大小大幅减小。
画质损失主要来自码率或 CRF 值设置不当。如果选「按码率」,建议设为原视频码率的 60%-80% 作为起点,比如原视频 10Mbps 就设 6-8Mbps。如果选「按 CRF」,数值越小画质越好,建议从 23 开始试(FFmpeg 默认值),压到 18 以内几乎无损但文件可能不小。分辨率降得太多也会显糊,建议只降一档(如 1080p→720p)且保持原比例。可以先压一小段预览再决定最终参数。
CRF 不是「压缩到多少大小」,而是「保证这个画质水平」。如果原视频本身码率很低、画质粗糙(比如手机录的 480p 低码率视频),CRF 18 会强制编码器用更多数据去保留细节,文件反而变大。这种情况应该先用「按码率」模式设一个比原文件小的目标值,或者把 CRF 调高到 28-30 来减小体积。另外,视频时长没变,纯静态画面多的视频用 CRF 压缩效果也有限。
通常是输入文件有问题或浏览器资源不足。先检查原视频是否已损坏(能不能本地正常播放)。如果文件没问题,试试以下步骤:① 刷新页面重新上传,避免浏览器内存占用过高;② 换一个更小的文件(比如先剪一段 10 秒的)测试工具是否正常工作;③ 关闭其他标签页或后台应用释放内存。本工具在浏览器内用 WASM 运行 FFmpeg,大型 4K 视频或超长视频(>1 小时)可能因内存限制卡住,建议分段压缩。
支持。底层用的是 FFmpeg,它能处理的视频格式(MP4、MOV、AVI、MKV、FLV、WebM 等)本工具基本都支持作为输入。输出格式目前固定为 MP4(H.264 编码),这是兼容性最好的通用格式,手机、电脑、电视都能直接播放。如果输入是特殊编码(如 ProRes、DNxHD),压缩后画质变化可能比普通视频更明显,建议先用小片段测试。
微信单文件限制约 1GB(聊天)或 200MB(朋友圈视频),压缩后如果还超限,需要进一步降低码率或分辨率。建议策略:先试「按分辨率」降到 720p,同时「按码率」设为 2-3Mbps,通常 5 分钟以内的视频能压到 100MB 以下。如果只是为了微信快速分享,也可以考虑用「极速压缩」档(CRF 28-30),画质够看但体积最小。注意微信对视频有二次压缩,发出去可能还会再变小。
正常情况下压缩不会改变时长或丢失音轨。如果出现这种情况,最可能的原因是原视频本身有「可变帧率」(VFR)或非标准封装,FFmpeg 在处理时遇到了时间戳错乱。解决方案:先用格式工厂或 HandBrake 把原视频「重新封装」一遍(不转码,只修复容器),再把修复后的文件上传压缩。如果只有画面没有声音,检查原文件是否有多个音轨(如国英双语),本工具默认保留第一个音轨,多音轨视频可能只保留一条。
效果完全一样,因为压缩逻辑在服务器端用 FFmpeg 执行,与上传设备无关。手机上传的 1080p 视频和电脑上传的同源视频,压缩后的画质、体积、参数选项都一致。唯一区别是手机上传速度可能慢一些(尤其 4G/5G 网络下的大文件)。建议在 Wi-Fi 环境下操作,超过 500MB 的视频上传可能会等较久。
默认情况下,压缩过程会重新编码视频流,FFmpeg 不会自动保留所有元数据(metadata)。拍摄时间、GPS 坐标、相机型号等信息在压缩后大概率丢失。如果这些信息很重要(比如用于摄影归档或法律证据),建议压缩前先用其他工具(如 ExifTool)备份元数据,压缩后再写回去。本工具当前没有「保留元数据」的开关,核心目标是减小文件体积。
隐私保证所有计算与处理均在你的浏览器本地完成,输入数据不会上传服务器,也不会保存或共享。