FFmpeg 之FFM

FFmpeg 提供了ffm muxer和demuxer， 从ffmpeg和fferver的code看， ffm是作为缓冲来使用的，即起到漏斗的作用。

ffm muxer 和 demuxer的实现是不完整的， 从 ffserver.c 可以看出来， 在使用过程中需要更新write_index,  真是一个蛋疼的实现。

注意： ffm的IO文件要位于ramfs之上， 比如tmpfs，不能是真实的磁盘文件系统。

实际使用过程中就碰到RTP出去的数据无法正常解码。

stream 流： v4l2(h264) -> ffm(muxer) ffm(demuxer) ->rtp(muxer)

通过VLC观看， 第一帧可以正常显示出来， 后续RTP一直有数据发送， 但VLC没能解出video。

通过tcpdump查看UDP数据包， 看不出异常。

trace了一下ffm write (av_write_frame) 的时间，发现每帧耗时在100～300ms之间， 这个时间太长了（fps为30）.

因为ffm的write 是同步做的，所以肯定会导致V4L2丢帧;  对H264来说，丢帧就会导致很长一段时间不能正常解码。

当前ffm的IO文件位于 /tmp/h264.ffm, 对于tmpfs来说，写的速度应该非常快才对。

使用df命令查看了当前OS的文件系统挂载情况：

 /dev/sda1 33032012 8790252 22563784 29% /
udev 922740 4 922736 1% /dev
tmpfs 186308 1948 184360 2% /run
none 5120 0 5120 0% /run/lock
none 931536 152 931384 1% /run/shm

问题找到了。tmpfs 挂载于 /run, 而不是/tmp.

修改ffm的IO文件位置， OK， 问题解决。

后记： 发现在系统memory资源紧张的情况下， tmpfs会被交换到swap 分区， 所以tmpfs不是太安全，应该使用ramfs