我用我自己的设备发送数据会报错 #5
Comments
|
哦哦,,终端发上来的数据有一个缓冲区，大小只有4096字节，而出现这个原因的情况一般是，解码后的消息包处理赶不上接收才会这样，你把PublisherManager类的那一大段注释解开，看看是不是ffmpeg出什么错了，看看是不是在持续的在转播视频流。。。。 |
|
你可以先简单的改大一点，在Jtt1078Decoder类的12行上，加一两个0试试看看。。。 |
|
还有你rtmp流媒体服务器配置正确吧？如果不正确的话，可能会出现推流推不动的可能，以至于消息包的处理赶不上接收。。。 |
|
我用你的测试tcpdump.bin的数据文件推流是正常的 |
|
在Jtt1078Decoder类的12行上加一个0后会报错 |
|
这是告诉你协议头有问题，你们这是自己设计开发的车载终端吗？ |
|
不是,但是我抓包下来的协议头是没有问题的,30316364开头的 |
|
这个问题我解决过，究其原因应该设备上传的数据存在粘包的情况，而楼主项目的Decoder部分没有做粘包处理，具体见Jtt1078MessageDecoder第26行，其中(int)Math.ceil(length / 512f)向上取整，对于半包的情况直接这半包就发出去了，后续剩余报文再上来就无法处理了，而楼主测试文件中的字节流比较规范，真实终端设备不会这样上传。 |
|
我的测试文件在读跟发的时候，也是按512字节进行发送的，接收的时候是按512为整块的写入到我的缓冲区里去了，最终在Jtt1078Decoder类里完成的粘包，这不是粘包的问题，可能是传输的数据包存在错误字段导致解包错位了。 另外，你还没有回答我，你这是自己在设计和开发符合1076标准的视频终端吗？ |
|
不是我们自己开发的,但是也是符合标准的 |
|
**有没有看过ffmpeg进程的输出？**这个很重要。。。 刚刚第二段报错其实有两个地方有问题.
|
|
我将PublisherManager里面的注释解开后多打印了这一段 |
|
从ffmpeg的输出上来看，ffmpeg还没有开始推流，目前阻塞在了fifo管道文件的读上了，也就是说PublisherManager一个消息包都还没有正确的得到的，还是消息包的接收上有问题，你仔细的跟踪一下车载终端发过来的数据，我项目里的tcpdump.bin就是通过netcat保存下来的车载终端发上来的数据，后面就可以用来反复的进行测试了，你多存一点儿，然后可以分析一下这个数据包。。。。 或者你把捕获的消息包文件也发我一份，我也给你瞅瞅。。。可以发我邮箱：wlhack@sina.com |
|
我发送了一个10m左右的消息包到您的邮箱里 |
|
好，我晚上看看 |
|
对，车牌号是皖的，因为是在运营的车，希望不要把视频数据泄露出去，谢谢 |
|
呃，我刚刚还传进来了呢，悲催，我删一下。。。不过这数据没什么关系吧。。。 |
|
给别人看到了认出来了会找我麻烦 |
|
客户都难缠 |
|
需要的话我可以录一段我们办公室的设备的视频发给你 |
|
不用了，我是刚好看到那个数据包里有一片我之前没碰到过的片断，所以觉得很有测试价值。。。 |
|
没事，有空录一段发发给你 |
|
我更新了之后用测试文件测试会报错 |
|
解决了,不好意思 |
|
给个原因啊 |
|
是因为我流媒体的地址写错了,我在同一个服务器下面地址要写127.0.0.1 |
|
我在路上跑 的车视频只能放5分钟左右就报上面的错了 |
|
呃，你上面两条回复我有点迷茫，现在是还有那个问题是吗？还是你仅仅只是在描述这个问题但是你已经解决掉了？ 出现那个问题的原因是因为服务器端5秒钟都没有收到终端发来的消息包，所以被定时器给关掉了，你可以看看日志里是不是有一行 |
|
还是那个问题，第一次我说解决了是我地址填错了，后来我试了一辆车每次只能看5分钟左右也会报那个错，我现在看不到日志因为我已经不在公司了，麻烦您了，我周一在仔细看看 |
|
[hentai] 2019-05-20 09:31:09,523 [WARN ] [video-server] - DefaultChannelPipeline - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. |
|
就是像这样的报错,我试了几次,每次播放5分钟左右就会出问题 |
|
你先把超时自动关闭的给屏蔽掉，再看看能坚持多久。。。。这个就是被我的定时器给关闭掉了，另外你也可以试试看用别的工具，比如我说的netcat看看一直接收又能收多久，反正它又不需要服务器端回复的。 另外，你也得做好断线重发实时音视频推流指令的工作。 |
|
对了，记得关闭掉超时自动关闭的功能后，记得同时使用tcpdump监听好网络的情况，看看五分钟后是不是还有数据交换。。。。 |
|
关闭超时自动关闭后用tcpdump监听,视频画面不动了之后就没有数据交互了,我在试试netcat能接收多长时间 |
|
我用netcat做了大概10分钟的测试,是能够一直接收的 |
|
你这10分钟的数据有保存吗？能否发我一份，我来测试一下项目。 |
|
没有,我等会保存一份给你 |
|
或者你看你就趁午休的时间，录个一小时的，画面什么的无所谓，静止的都OK。。。 |
|
ok |
|
刚刚瞄了一眼代码，发现之前的修改还有遗漏，我又重新提交了一下。 |
|
文件有260多M,太大邮件没法发送 |
|
那你更新一下项目代码，自己再试一试。 |
|
我发了一个带超大附件的邮件给你 |
|
我取消了超时处理，并且修正了一个起始位置读取错误的问题（已提交）后，目前已经坚持了18分钟了。应该是推流有时候赶不上接收的速度，导致通道堵塞，以至于5秒钟未能再往FIFO管道流里写数据，并触发了超时，并且被干掉了。 目前使用你的数据文件推流一直正常，如果你要能够稳定的长时间的运行，以及避免掉并发上所引发的问题，还有很多挑战，这是我实际项目应用里的一部分，其它还有很多糟心的事情要处理的呢。我看看今晚上能不能赶个文档再描述一下，关于集群布署和并发访问同一个视频通道上的问题。 |
|
// 定时清理超时的转发进程 |
|
这不能够啊，你刚刚发我的数据文件我都已经全部看完了都和谐得很，你那还是会报那个错吗？你注意一下日志输出，是不是还有那个 |
|
还是说，报了其它的错误？ |
|
注释了之后就没报错了,就是停在那了, |
|
也没有publisher-1 timeout and close automatically的字样 |
|
你用的是数据文件进行的测试吗？ |
|
对了，你应该把PublisherManager类的那一大堆注释解开，看看ffmpeg的输出，另外，就是视频不能播放的时候，你看看ffmpeg进程还在不在，以前通过jstack -l PID看看线程的情况。。。。 |
|
数据文件和实时数据都有 |
|
呃，揪心，我上面说的那个你试过了没有？有没有看到ffmpeg的输出？有没有看过jstack的输出？ |
|
我在看,很奇怪的事,我吧PublisherManager类的那一大堆注释解开后就可以播放很长时间了,我在多试几次 |
|
我去，还有这种事。。。。我觉得你不用在这个事情上花太长时间了，再稍稍试试就成了，我觉得更应该考虑的事情是断了重连的一套策略，而不是想去尽可能长的维持这个时间，因为实际行驶过程中，随时有断网的可能性。。。。 |
|
断了重连我的想法是netty有监控连接断开的类,检测到断开的时候判断一下人为还是被动的动作然后在重新发送指令 |
|
嗯，想办法做好重发指令的事情，再多试试看看，祝你好运了。。。 |
|
好的,谢谢,能加个微信什么的吗 |
|
加QQ吧，65827536 |
io.netty.handler.codec.DecoderException: java.lang.RuntimeException: exceed the max buffer size, max length: 4096, data length: 512
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:459)
at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:392)
at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:359)
at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:342)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1409)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:927)
at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:822)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: exceed the max buffer size, max length: 4096, data length: 512
at cn.org.hentai.jtt1078.util.ByteHolder.write(ByteHolder.java:32)
at cn.org.hentai.jtt1078.util.ByteHolder.write(ByteHolder.java:26)
at cn.org.hentai.jtt1078.server.Jtt1078Decoder.write(Jtt1078Decoder.java:16)
at cn.org.hentai.jtt1078.server.Jtt1078Decoder.write(Jtt1078Decoder.java:23)
at cn.org.hentai.jtt1078.server.Jtt1078MessageDecoder.decode(Jtt1078MessageDecoder.java:31)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:489)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:428)
... 17 more
The text was updated successfully, but these errors were encountered: