“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
如何使用流分析仪进行数字电视广播：一份实用指南
写在前面：为什么你需要懂流分析
运营一个数字电视网络，远不止是“让频道保持播出”那么简单。你得保证观众能获得他们预期的画质，同时还得在问题升级成事故之前把它扼杀在摇篮里。直播的时候一旦出岔子，每一秒都像在烧钱——观众不会等你，领导也不会。
但问题来了：当画面卡顿、音频不同步、某些老机顶盒死活播不了你的流的时候，你怎么快速判断是编码器设置的问题、传输流结构的问题、还是时间元数据在搞鬼？答案就是——你需要一套专业的流分析工具。
这系列文章会带大家走一遍广播工程师日常会遇到的真实场景，以及怎么用实际工具一步步诊断和解决。今天这篇是第一篇，重点讲GOP结构、标准合规性和码率分析。
文件分析为什么是诊断利器
直播监控能实时抓问题，但文件级别的分析才是你的“显微镜”。通常的工作流是这样的：制作环节出了某种故障，工程师抓取几分钟有问题的流保存成文件，然后像做病理切片一样去分析它到底哪儿坏了。
文件分析器主要有三个用途：
- 故障排查：找到广播问题的根因
- 编码器调优：微调压缩参数，在画质和码率之间找到最佳平衡
- 质量控制：验证流是否符合行业标准和规范
下面我们用实际案例来展开。
典型问题：GOP结构导致的兼容性翻车
想象一下这个场景：你刚上线了一个新频道，编码器跑得很欢，监控大屏上一切正常。但没过多久，运维电话就响了——用户投诉说家里的老机顶盒要么没画面，要么画面一卡一卡的，要么音频正常但视频断断续续。
这种问题十有八九出在GOP（Group of Pictures，图像组）结构上。
H.264从2003年到现在已经服役超过20年了，几乎所有的设备都支持它。但注意，是“几乎”。那些老旧的机顶盒、十年前的电视、甚至某些嵌入式设备，对特定配置就是会罢工。而其中最敏感的变量之一就是 B帧的数量。
为什么B帧这么关键？
B帧（双向预测帧）通过参考前后帧的信息来压缩数据，能在同样码率下带来更好的画质。但代价是帧之间的参考关系变得复杂。解码器需要缓存更多的帧、做更多的运算。对于硬件能力有限的老设备来说，B帧太多就是灾难。
诊断步骤
- 把有问题的流文件丢进分析器（比如 Elecard StreamEye 或者类似工具）
- 直接看 GOP 结构。不要只看 GOP 长度和是不是 closed GOP，一定要看具体的 B 帧数量
- 如果看到连续三个 B 帧，而你的目标设备是十年前的机顶盒，那基本就破案了
- 尝试把 B 帧降到两个，再不行降到1个，重新编码测试
分析器还能让你可视化整个帧参考结构——哪个 I 帧被哪些 P 帧引用，B 帧是怎么双向预测的，一目了然。这种级别的细节，靠打log或者猜是永远得不到的。
举个实际例子：我曾经处理过一个客户的问题，他们的流在主流设备上完全正常，但某个特定品牌的老机顶盒就是花屏。抓了流一看，B帧设了3个，而那个机顶盒的硬件解码器只支持最多2个B帧。改成2之后，一切正常。
标准合规性检查：别让你的流“违法”
除了结构问题，你还得确认流本身符合 H.264 规范。一个好的分析器应该能做到：
- 完整解码整个流，不只是解析头部信息
- 逐帧展示，带缩略图预览，方便肉眼对比
- 在专门的错误窗口里标出所有违反标准的地方
- 显示缓冲区溢出条件，这是很多“莫名其妙”崩溃的根源
举个例子：如果你的流出现了**缓冲区溢出（buffer overflow）**错误，在 Elecard StreamEye 里你可以：
- 看到精确到帧的偏移位置——哪个帧、第几毫秒出的问题
- 双击错误条目，分析器直接跳转到那一帧
- 同时查看码率图，看看那个时刻的瞬时码率是不是飙到了天上
这种功能在调试编码器配置的时候简直救命。
码率分析：CBR还是VBR，一眼看穿
码率是广播里最基础也最容易出问题的参数之一。标准做法是用1秒的时间窗口来计算平均码率。但有时候你需要更灵活的窗口大小。
比如你计划给一批老旧的机顶盒播4K内容。这些机顶盒的硬件缓冲区是固定的——它们能承受多高的瞬时码率是写死在芯片里的。你不能假设“平均8 Mbps就够用”，因为如果瞬时码率飙到20 Mbps，解码器直接溢出，画面就黑了。
文件分析器允许你：
- 用任意大小的窗口重新计算码率（比如100ms、500ms）
- 把计算出的峰值码率和设备文档里标明的能力做对比
- 在正式上线之前就发现潜在的解码器溢出风险
我之前见过一个案例：某直播流宣称是8 Mbps CBR（恒定码率），但用分析器一看码率图，波形像过山车一样——最低4 Mbps，最高16 Mbps。这哪是CBR，分明是VBR（可变码率）没配好。这种问题如果不提前发现，上线后老设备必然会出问题。
下期预告
这一篇我们聊了文件级别的分析，重点在H.264的GOP结构、标准合规性和码率问题。但说实话，大部分“诡异”的广播问题其实藏在传输流（Transport Stream）的结构里，尤其是时间元数据。
下一篇文章我会讲一个真实的案例：一个持续了18小时的图文电视（Teletext）音画不同步问题。你猜最后问题出在哪儿？跟码率、编码器都没关系，纯粹是时间戳的锅。
敬请期待。