2,543
社区成员
发帖
与我相关
我的任务
分享网络播放MPEG1图像，存在数据丢包的情况如何处理？
我编写了两个程序，一个是MPEG1采集UDP发送，一个是接收播放，播放采用pull模式。
程序运行正常。
但是，现在有个问题，存在数据丢包的情况（可能网络不稳定，当然UDP协议下丢包是正常的）。在数据丢包后，图像播放会变得不流畅，越来越慢，各位大侠有没有遇到，如何解决（不考虑重发）？
程序运行正常。
但是，现在有个问题，存在数据丢包的情况（可能网络不稳定，当然UDP协议下丢包是正常的）。在数据丢包后，图像播放会变得不流畅，越来越慢，各位大侠有没有遇到，如何解决（不考虑重发）？
...全文
请发表友善的回复…
发表回复
shenming123 2004-12-31
- 打赏
- 举报
是有这种问题,因为MPEG-1读到错误数据就会停止播放.
估计是和时间戳有关系,我也不是很清楚.
如果是vcd文件文件,丢了也可以顺畅播放下去.
我是播文件,如果丢了就重新seek,这样可以顺畅播放了
qrlvls 2004-12-28
- 打赏
- 举报
感觉用UDP是否有点...
fengge8ylf 2004-12-28
- 打赏
- 举报
mark
cryptonym 2004-12-24
- 打赏
- 举报
楼主啊，我引用一个人的原话给你看看啊，很有帮助的。
本文获得 3枚
正在读取评价信息...主题 写给进行 “MPEG4视频流 网络传输” 编程的同仁们
gpgu
Creator 发表于 2003-6-6 11:00:37
--------------------------------------------------------------------------------
现在好像有不少的人正在编写 MPEG4 网络传输的程序，下面就这个谈谈我个人的看法：
1。在网上看了许多帖子，其中有几个共同点，那就是 客户端的PUSH SOURCE FILTER 是需要写的，这一点毋庸置疑，当然 PULL 的也可以用，但感觉好像没有PUSH的来的直观。另外，就我个人的观点，DX的PUSH 与 PULL 历程，PUSH历程远远要比PULL简单！push 例程在dx9.0 sdk中的..\DXSDK\Samples\C++\DirectShow\Filters\PushSource中的PushSourceBitmapSet。
2。在服务器端，有一点是值得注意的。有许多人提到自己的FILTER 流程如下：
采集卡-->...->MPEG4 压缩--->Grab Sample ,然后通过网络发送出去，这个想法很正常，但是在实际的情况中会行不通（除非网络带宽能够得到保证，不发生拥塞）。为什么呢？因为mpeg4压缩编码是具有帧间相关性的，那就是说，如果丢失帧数据的话，会影响后面帧的解码。在上面的这个情况中mpeg4压缩编码是实时进行的，但是如果在窄带网络上传输的话，不可能能够将抓取到的每一帧都能发送到客户端。所以必然会造成数据的丢失，影响后端解码。这样的程序不具有通用性，在窄带网络上传输，马赛克会比较严重。
3。既然2的思路不行，那么怎么解决这个问题呢？我个人的想法是：
需要自己写个filter，实现如下的功能：在正常模式下，也就是没有申请网络传输的情况下，这个filter要实现dshow中Null Render Filter的功能,即不做任何事情，只是保证数据流的Render。在要进行网络传输时，该filter实现如下功能：mpeg4 编码、Grab Sample(编码后的）。那么这样可以根据网络情况，动态的改变传送的sample数据，做到每帧发送出去的Sample的编码是连续的。
4。在3中提到的方法，也有一定的局限性 :) ，对于新手而言，要实现上述的filter可能比较困难，还有一个较为妥当的方法是：在要进行网络传输的情况下，获取mpeg4编码前的数据，即未压缩的视频数据，（譬如说用dx自带的Sample Grabber就可以 ），然后自己用api函数实现数据编码（类似dx中mpeg4编码的功能）。
5。当然在3、4中如果需要在（服务器）本地纪录的话，就需要用2个mpeg4编码，一个负责纪录（连续的），另一个负责网络传输（不一定连续）。
2003-6-6 12:28:33gpgu 对内容进行了修改
本文获得 3枚
正在读取评价信息...主题 写给进行 “MPEG4视频流 网络传输” 编程的同仁们
gpgu
Creator 发表于 2003-6-6 11:00:37
--------------------------------------------------------------------------------
现在好像有不少的人正在编写 MPEG4 网络传输的程序，下面就这个谈谈我个人的看法：
1。在网上看了许多帖子，其中有几个共同点，那就是 客户端的PUSH SOURCE FILTER 是需要写的，这一点毋庸置疑，当然 PULL 的也可以用，但感觉好像没有PUSH的来的直观。另外，就我个人的观点，DX的PUSH 与 PULL 历程，PUSH历程远远要比PULL简单！push 例程在dx9.0 sdk中的..\DXSDK\Samples\C++\DirectShow\Filters\PushSource中的PushSourceBitmapSet。
2。在服务器端，有一点是值得注意的。有许多人提到自己的FILTER 流程如下：
采集卡-->...->MPEG4 压缩--->Grab Sample ,然后通过网络发送出去，这个想法很正常，但是在实际的情况中会行不通（除非网络带宽能够得到保证，不发生拥塞）。为什么呢？因为mpeg4压缩编码是具有帧间相关性的，那就是说，如果丢失帧数据的话，会影响后面帧的解码。在上面的这个情况中mpeg4压缩编码是实时进行的，但是如果在窄带网络上传输的话，不可能能够将抓取到的每一帧都能发送到客户端。所以必然会造成数据的丢失，影响后端解码。这样的程序不具有通用性，在窄带网络上传输，马赛克会比较严重。
3。既然2的思路不行，那么怎么解决这个问题呢？我个人的想法是：
需要自己写个filter，实现如下的功能：在正常模式下，也就是没有申请网络传输的情况下，这个filter要实现dshow中Null Render Filter的功能,即不做任何事情，只是保证数据流的Render。在要进行网络传输时，该filter实现如下功能：mpeg4 编码、Grab Sample(编码后的）。那么这样可以根据网络情况，动态的改变传送的sample数据，做到每帧发送出去的Sample的编码是连续的。
4。在3中提到的方法，也有一定的局限性 :) ，对于新手而言，要实现上述的filter可能比较困难，还有一个较为妥当的方法是：在要进行网络传输的情况下，获取mpeg4编码前的数据，即未压缩的视频数据，（譬如说用dx自带的Sample Grabber就可以 ），然后自己用api函数实现数据编码（类似dx中mpeg4编码的功能）。
5。当然在3、4中如果需要在（服务器）本地纪录的话，就需要用2个mpeg4编码，一个负责纪录（连续的），另一个负责网络传输（不一定连续）。
2003-6-6 12:28:33gpgu 对内容进行了修改
superdai 2004-12-22
- 打赏
- 举报
我也遇到过，没能解决，看过一个老外写的东西，好像还可以。不过好像要钱。
yichuan1982 2004-12-22
- 打赏
- 举报
有时候，我都真想直接去商场门口发传单，举牌子了
请一定帮忙，谢谢！
请看看：
http://community.csdn.net/Expert/topic/3663/3663763.xml?temp=.569195
请一定帮忙，谢谢！
请看看：
http://community.csdn.net/Expert/topic/3663/3663763.xml?temp=.569195
eego 2004-12-22
- 打赏
- 举报
看来是MPEG1容错性能不够好的问题了。我现在的只能定期重启一次播放过程。
eego 2004-12-21
- 打赏
- 举报
另外，我试了MPEG4图像，播放改用Push模式，同样模拟丢包，再停止丢包。结果图像是可以恢复流畅的。而且MPEG4图像在丢包时的表现还是很好的，即丢包时保持上一个画面，再收到数据马上处理。我采用丢包30%（每100个），图像效果看不出明显问题。
但在MPEG1图像，丢包时的表现非常差，一个画面一个画面的，相隔1-2秒。那个在处理MPEG1图像时有更好的方法？？？
---------
还有，qq，msn的图像都是MPEG4的，不是MPEG1图像，MPEG1图像高达1Mbps.
但在MPEG1图像，丢包时的表现非常差，一个画面一个画面的，相隔1-2秒。那个在处理MPEG1图像时有更好的方法？？？
---------
还有，qq，msn的图像都是MPEG4的，不是MPEG1图像，MPEG1图像高达1Mbps.
eego 2004-12-21
- 打赏
- 举报
to cryptonym(鹧鸪鸟) ：
其实是这样，可能没说清楚。
我觉得在图像丢包时，图像有影响没有关系，即一顿一顿的，但是，主要的问题在于图像恢复的问题。如后面网络正常了，不再丢包了（我自己测试的，先模拟丢包，在停止丢包），图像应该恢复流畅。
但实际上，图像仍然是一顿一顿的，比较慢，非得关闭播放过程再启动，就OK。
故，这里证明还是有可以改进的地方的，如何改进呢？我尝试修改Sample Time,但没有效果。
to nonocast(如果没有如果)：
你说的仅仅是访问数据的正确性，这点可以保证，我在每个包上封装了自己的标记数据，而且有包号，接收都是正确的。
其实是这样，可能没说清楚。
我觉得在图像丢包时，图像有影响没有关系，即一顿一顿的，但是，主要的问题在于图像恢复的问题。如后面网络正常了，不再丢包了（我自己测试的，先模拟丢包，在停止丢包），图像应该恢复流畅。
但实际上，图像仍然是一顿一顿的，比较慢，非得关闭播放过程再启动，就OK。
故，这里证明还是有可以改进的地方的，如何改进呢？我尝试修改Sample Time,但没有效果。
to nonocast(如果没有如果)：
你说的仅仅是访问数据的正确性，这点可以保证，我在每个包上封装了自己的标记数据，而且有包号，接收都是正确的。
cryptonym 2004-12-21
- 打赏
- 举报
哦，俺做的是mp4，只要I帧没被丢掉他就能重新同步过来。要是你丢了以后一直都同步不过来那程序是有问题了。
DarthVader 2004-12-21
- 打赏
- 举报
MPEG1容错性能不够好
nonocast 2004-12-20
- 打赏
- 举报
用UDP模拟TCP，会跳帧，但不会像你说的越来越慢
用2个缓冲队列
用2个缓冲队列
singlefox2050 2004-12-20
- 打赏
- 举报
建议使用RTP协议来实现该功能，因为RTP中支持流媒体数据用UDP传输，对你提到的包丢失包续混乱等情况有解决方法！
cryptonym 2004-12-20
- 打赏
- 举报
蹲是正常的，谁的不蹲啊，qq，msn都蹲。不蹲才不正常啊。
eego 2004-12-20
- 打赏
- 举报
用RTP协议就肯定可以？
我现在做了测试，如在接收过程中模拟丢包（每N个丢M个），图像也会变得很不流畅，一顿一顿的，故我觉得关键是如何调整播放过程，如memstream filter. 但还没有找到好的办法。
我现在做了测试，如在接收过程中模拟丢包（每N个丢M个），图像也会变得很不流畅，一顿一顿的，故我觉得关键是如何调整播放过程，如memstream filter. 但还没有找到好的办法。
listream1 2004-12-20
- 打赏
- 举报
用RTP协议
