FFmpeg社区曾经有过一次针对RTMP扩展HEVC的讨论，最终达成的结论是如果Adobe扩展了RTMP，那么FFmpeg才可以接受HEVC扩展。现状是Adobe更新RTMP协议遥遥无期。
为推进HEVC视频编码格式在直播方案中的落地，经过CDN联盟讨论，并和主流云服务厂商达成一致，规范了HEVC在RTMP/FLV中的扩展…
以上内容摘自金山视频云的文章《FFmpeg代码导读系列(一，下半部)—-HEVC在RTMP中的扩展》
金山云在ffmpeg的源码基础上增加了rtmp h265的支持，并且在github上开源。
所谓工欲善其事，必先利其器。第一步，我们先编译代码，得到可以推拉rtmp h265流的ffmpeg，以及可以播放rtmp h265的ffplay。以便后续学习rtmp h265的协议知识。
本来，金山云ffmpeg的git wiki页《H.265 RTMP推流使用指南》上已经有编译的说明，但是我实际操作时遇到了一些问题，所以写了这篇文章。
另外，我之前还写了几篇和ffmpeg编译相关的文章（如果你在编译时遇到问题，也可以看看）：
之前写过一篇关于编译ffmpeg的文章，地址： linux安装ffmpeg
本文在那篇基础上，讲怎么编译ffmpeg的播放器ffplay。
本次实验环境：
我在一台macOS Catalina 10.15.1的机器上，源码编译ffmpeg，生成的ffmpeg和ffprobe等所有可执行程序都无法正常运行。一运行就报段错误崩溃。就像这样：
之前有前端同学问我，JavaScript中最大的数有多大。
那时就想写一些文章，从整型各种进制的转换，到原码反码补码的形式，最后到浮点数，再加上字符串类型的数字，把计算机世界里与数字相关的内容都说一说。
但由于对相关知识的掌握程度，表达能力，执行力等各方面原因，一直没有动笔。。
今天看到draveness大佬写了一篇《为什么 0.1 + 0.2 = 0.300000004 · Why’s THE Design?》，很好的讲解了浮点数的知识。
所以本文就直接在大佬文章的基础之上讲解就好了。看本文前可以先看看大佬的文章。
JS中Number类型的数字，不管是整数还是小数，底层都使用64位的浮点数形式存储。所以JavaScript中最大的数有多大，等价于64位浮点数最大的数有多大。
事情是这样的，线上一个服务，启动后RSS随任务数增加而持续上升，但是过了业务高峰期后，任务数已经下降，RSS却没有下降，而是维持在高位水平。
那内存到底被谁持有了呢？为了定位问题，我把进程的各项Go runtime内存指标，以及进程的RSS等指标持续采集下来，并以时间维度绘制成了折线图：
最近组内一些Go服务碰到内存相关的问题，所以今天抽时间看了下Go pprof内存指标的含义，为后续查问题做准备。
内容主要来自于Go代码中对这些字段的注释，加自己的理解。理解不对的地方欢迎指正。
