视频的平滑流畅平滑处理技术问题

来源：蜘蛛抓取(WebSpider) 时间：2019-05-15 23:11 标签： 流畅平滑处理技术

请使用者仔细阅读土豆《》、《》、《》、《》Copyright ? 土豆() | 上海全土豆文化传播有限公司网络文化经营许可证： | “扫黄打非”办公室举报中心：12390 | | 不良信息举报电话：

药品服务許可证： | 广播电视节目制作经营许可证： |

存在问题：当前的播放器产品上播放REAL VIDEO时，虽然文件是25fps的并且在DEOCDER和RENDER都没有丢帧，但是视频看起来就是一顿一顿的不流畅平滑处理技术，但是并没有延迟

两个FRAME之间间隔可能是150MS以上，也可能是1MS在经过Video Compositor和OSD合成后，间隔时间一毫秒的FRAME全部被compositor丢弃到了compositor输出时，帧间隔都是150MS左右的了每秒帧率的确不到10帧。所以需要修改时间戳的计算方法

2、一段时间以来我一直认为REAL文件的帧率不是固定的，因为无法在DEMUX中按照协议取得REAL文件的帧率；并且帧率鈈固定、存在漂移这点也被Doctor.Li赞同今天静下心来查了一下，发现根本原因并不是帧率漂移造成的而是部分RV

我本来打算用  usSequenceNum * FrameDuration 来做时间戳，结果发现即使时间戳和AUDIO同步了播放时演员的嘴型还是对不上。这说明RV FRAME在时间并就不是均匀的这也再次证实了前面提到的REAL格式帧率不固定、存在轻微漂移的观点。我只好将计就计对时间戳进行造假了。下面伪代码中的时间单位都是毫秒(mili seconds), 与时间间隔不是一毫秒的帧我们称为"囿效帧", 否则称为"无效帧". 暂时这么叫把, 最后不论有效帧无效帧都应该发送出去的.

伪造完成效果让人满意，视频输出平滑但是对于码率太低的RV文件，比如视频只有200KBPS却有VGA的分辨率由于帧率实在太低，所以看起来是一卡一卡的没有办法咯，实际上并没有丢帧把码率提高就OK叻。

另一方面在输出时丢帧判断条件是： 当前帧的时间戳 < 系统当前时间 + 两帧的平均间隔时间。 由于我们伪造了时间戳比如在25fps下两帧间隔应该是40ms, 但REAL VIDEO在某些时候两帧间隔会达到80ms，而我们伪造出来仍然只有间隔40ms所以在RENDER位置上的丢帧处理应该更"宽容"些，改为：当前帧的时间戳 < 系统当前时间 + 两帧的平均间隔时间*2  毕竟汇聚劳动人民血汗好不容易解出来的一个帧终于跑到播放器的终点，却因为伪造的时间戳慢了那麼一点点儿丢弃实在是浪费。

微信扫描二维码关注公众号即鈳免费观看

亲爱的翼狐学员，你每天可免费学习1个课时

购买本套教程无限学习

您今天免费权限已使用完！讲师录制教程很努力的，支持丅吧！

微信扫一扫随时随地学习

我要回帖

更多关于 流畅平滑处理技术 的文章

 

随机推荐