接收udp数据问题,急!!!

l87480405 2011-08-16 09:42:10
用vlc发送ts媒体流到一个组播地址,然后在组播上收取这些媒体流,存为本地文件,用的是udp传输,为什么收到的文件总是比原来的文件小几百K,视频时间也少一两秒,已经把socket缓存设置的很大了,丢包问题不是很严重了,感觉是有一部分数据在什么地方未读到或读到未写入,求高人指点。
...全文
225 19 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
19 条回复
切换为时间正序
请发表友善的回复…
发表回复
l87480405 2011-08-16
  • 打赏
  • 举报
回复
[Quote=引用 16 楼 ganjianh8 的回复:]

建议用bcompare看一下接收到的文件与发送文件的比较,看缺失的地方在那里
[/Quote]
通过对比发现是文件最后少了一点点,不知道这最后的一点是没收到还是没写入,我是这么收和写的:

while(1)
{
rev=recvfrom(sck1, rBuf, sizeof(rBuf), 0,(struct sockaddr *)&local, &len);
if(rev>0)
{
//接收媒体流写入文件
fwrite(rBuf,rev,1,fw);
}
else
{
printf("%d",GetLastError());
}
}

ganjianh8 2011-08-16
  • 打赏
  • 举报
回复
建议用bcompare看一下接收到的文件与发送文件的比较,看缺失的地方在那里
luciferisnotsatan 2011-08-16
  • 打赏
  • 举报
回复
char字符串里,'\0'即0x0的含义是结束符,代表字符串结束了。strlen(str代表string)这类是处理字符串的函数。

rBuf[2048];
rev=recvfrom(sck1, rBuf, sizeof(rBuf), 0,(struct sockaddr *)&local, &len);
rBuf没有初始化,里面不知道放了些什么。用strlen,遇到0x0才结束。所以每次的值可能不同。
l87480405 2011-08-16
  • 打赏
  • 举报
回复
原文件162 MB (170,012,912 字节),传完收到161 MB (169,272,992 字节)(+ - 200K),传输端是用vlc发的组播,我这边自己收取流的,应该没问题,好像是剩一点在哪儿没收到或没写入
l87480405 2011-08-16
  • 打赏
  • 举报
回复
那二进制的流存在char型数组里是什么结构的啊
luciferisnotsatan 2011-08-16
  • 打赏
  • 举报
回复
你总得文件多大?传输每次都少差不多大小?确定传输端没问题,没少传?
luciferisnotsatan 2011-08-16
  • 打赏
  • 举报
回复
strlen内部做如下的操作。
size_t strlen(const char* p)
{
size_t n = 0;
while(0 != *p++)
n++;
return n;
}
l87480405 2011-08-16
  • 打赏
  • 举报
回复
[Quote=引用 9 楼 luciferisnotsatan 的回复:]

strlen是count到字符串结束符'\0'退出。媒体流用的应该是2进制的吧,别用strlen这种处理字符串的函数来做。
你开始写的没问题,用sizeof,或者直接写上2048
[/Quote]

用的是二进制,但为什么strlen(rBuf)有时候是1有时候不是呢???,而且把fwrite的第三个参数设置为strlen(rBuf)文件的播放也是流畅的,只是还是少个一两秒,文件大小会比原来大一点
luciferisnotsatan 2011-08-16
  • 打赏
  • 举报
回复
strlen是count到字符串结束符'\0'退出。媒体流用的应该是2进制的吧,别用strlen这种处理字符串的函数来做。
你开始写的没问题,用sizeof,或者直接写上2048
AnYidan 2011-08-16
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 babilife 的回复:]
UDP本来就不是可靠传输吧,丢包是比较常见的事情
[/Quote]
++
l87480405 2011-08-16
  • 打赏
  • 举报
回复
阿偶,顶一下,沉底了……
l87480405 2011-08-16
  • 打赏
  • 举报
回复
收到的总数据应该是rev * count,但就是不知道strlen(rBuf)不为1时,后面的rev还是不是和前面的rev一样,感觉应该是比前面的rev小了,所以才会把count直接设为1收到数据变小,设为strlen(rBuf)又会变大,对这个rBuf结构到底是什么样的很疑惑……
l87480405 2011-08-16
  • 打赏
  • 举报
回复
tcp不能组播,重传机制也实现不了,因为发送端不是我控制的,我写文件是用的fwrite(rBuf,rev,1,fw);其中char rBuf[2048];
rev=recvfrom(sck1, rBuf, sizeof(rBuf), 0,(struct sockaddr *)&local, &len);
FILE *fw;
现在感觉问题是出在fwrite的第三个参数count上,因为看了看strlen(rBuf)的值,大多时候是1,有事会是4啊5啊之类的,但把count换成strlen (rBuf)收到的文件又会比原文件大,不知何解。
羽飞 2011-08-16
  • 打赏
  • 举报
回复
自己保证传输完全,对包编一下号,自己重组
liangyonglou 2011-08-16
  • 打赏
  • 举报
回复
UDP是不安全的,用TCP试试吧!
luciferisnotsatan 2011-08-16
  • 打赏
  • 举报
回复
忽略,或改用tcp,或自己写个验证重传机制
至善者善之敌 2011-08-16
  • 打赏
  • 举报
回复
UDP本来就不是可靠传输吧,丢包是比较常见的事情
w346581442 2011-08-16
  • 打赏
  • 举报
回复
UDP和TCP的功能有重叠的地方,但又各有所长
l87480405 2011-08-16
  • 打赏
  • 举报
回复
又没人来了……

70,020

社区成员

发帖
与我相关
我的任务
社区描述
C语言相关问题讨论
社区管理员
  • C语言
  • 花神庙码农
  • 架构师李肯
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧