Last header null not new, headerSize: 3, channelId 24

[Juan Diego]

Hi I am running red5 over wildfly 9 and it seems to work right, but I am having a problem with oflaDemo, movies last from 60 to 90 seconds and then it crashes and i loose connection via rtmp and I get this error.  I tried the same movies on the same machine with a red5 server and they work fine.  I am probably no loading something on one of the xml files.

18:34:15,769 ERROR [org.red5.server.net.rtmp.codec.RTMPProtocolDecoder] (NioProcessor-2) Last header null not new, headerSize: 3, channelId 24
18:34:15,770 WARN  [org.red5.server.net.rtmp.codec.RTMPProtocolDecoder] (NioProcessor-2) Closing connection because decoding failed: RTMPMinaConnection from 127.0.0.1 (in: 4167 out: 14011564) session: S8BRPXKETWFRP state: connected: org.red5.server.net.protocol.ProtocolException: Header is null, check for error
    at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodePacket(RTMPProtocolDecoder.java:291)
    at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decode(RTMPProtocolDecoder.java:182)
    at org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeBuffer(RTMPProtocolDecoder.java:122)
    at org.red5.server.net.rtmp.codec.RTMPMinaProtocolDecoder.decode(RTMPMinaProtocolDecoder.java:85)
    at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:230)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943)
    at org.red5.server.net.rtmpe.RTMPEIoFilter.messageReceived(RTMPEIoFilter.java:179)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943)
    at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
    at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:535)
    at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:697)
    at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:651)
    at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:640)
    at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
    at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1097)
    at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

[Chris Allen]

Hi Juan,

Which version of Red5 are you running? 

-Chris

--

---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to red5interest...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Juan Diego]

I compiled it from github it is red5-1.0.7 snapshot

[Andy Shaules]

We have a fix in the pipeline I believe.

[Chris Allen]

Yup, Andy beat me to it. I know he’s working on that very class (RTMPProtocolDecoder) right now. It just needs Paul’s review before it’s committed. 

[Jon Webb]

I'm still seeing this error with Flash Player when I try to connect an audio source using NellyMoser 22K (not with lower bitrate NellyMoser -- it happens when the client first starts to send audio). The decoder encounters a protocol error, connection is closed, and the client has to reconnect. This can repeat. Below is a partial log. I'm running the released Red5 1.0.7.

2016-07-08 10:20:36,354 [NioProcessor-8] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Chunk too small, buffering (139,883)

2016-07-08 10:20:36,354 [NioProcessor-8] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Chunk too small, buffering (419,883)

2016-07-08 10:20:36,354 [NioProcessor-8] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Chunk too small, buffering (95,883)

2016-07-08 10:20:36,855 [NioProcessor-21] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Decoded chunk size: 257

2016-07-08 10:20:36,855 [NioProcessor-57] INFO  o.r.c.n.rtmp.BaseRTMPClientHandler - ChunkSize is not fully implemented: ChunkSize: 257

2016-07-08 10:20:36,886 [NioProcessor-8] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Chunk too small, buffering (878,1024)

2016-07-08 10:20:36,906 [NioProcessor-8] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Last header null: HEADER_SAME_SOURCE, channelId 21

Any ideas?

-- Jon Webb

[Mondain]

On the surface it looks like chunking isn't working correctly with Red5-Client, or is this a mixed log section? In general, codecs and their settings should not matter at-all to the server itself, since it doesn't decode the audio or video content.

Paul

--

[Jon Webb]

If there's anything I can do to make this go away, or get more info, please let me know. 

The switch to NellyMoser 22K is definitely causing this problem, and was causing it in previous releases. Perhaps Flash Player is screwing up the protocol--maybe there's a problem that only appears at the higher bitrate. But I wonder if there's a way to get the server to handle the problem more gracefully, and not close the connection. From the code it appears that I can turn closeOnHeaderError off but I can't quite see how to do that. I put

    <bean id="rtmpProtocolDecoder" class="org.red5.server.net.rtmp.codec.RTMPProtocolDecoder">

        <property name="closeOnHeaderError" value="false" />

    </bean>

in red5-core.xml but that doesn't seem to have any effect.

-- Jon

You received this message because you are subscribed to a topic in the Google Groups "red5" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/red5interest/57Ou37LfMjs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to red5interest...@googlegroups.com.

[Rajdeep Rath]

Hi there , just catching up in this. So how can I reproduce this.  Can you point out the steps for me ?

Regards
Rajdeep Rath

[Jon Webb]

I don't think it would be easy to do. My client is part of a larger audioconferencing system and switches to the NellyMoser 22K codec under certain conditions. That's when the problem occurs. Perhaps I can get you some logs, or somehow get you access to my server -- please let me know. -- Jon 

[Rajdeep Rath]

Could I perhaps reproduce it if I get a flash encoder to publish audio stream with 22 or 44 setting to red5 ?

[Jon Webb]

I can also get Wireshark logs if that would help. - Jon 

[Rajdeep Rath]

A switch would normally not cause any issues unless there was something different with the audio settings.

So is you issue with publishing stream or subscribing ?

[Jon Webb]

Publishing, definitely. Flash Player is capturing audio using NellyMoser 22K. The problem occurs when the first audio is sent.

I suppose the same thing might happen with Flash Encoder @ 22K.

-- Jon 

[Rajdeep Rath]

Nope i could not reproduce that issue using 1.0.7 and NellyMoser 22. Here is the encoder i tried, you can try yourself.
http://wmle.flashvisions.com/

[Jon Webb]

Well, as I said, it happens with Flash Player. Using another encoder isn't an option for me. -- Jon 

[Rajdeep Rath]

That is a flash player encoder with a built in flash player viewer. As you can see there are no issues using that with red5. So the issue must be elsewhere.

I also tried adobe flash media live encoder with nellymoser 22 and 44. There were no issues. Stream was smooth.

[Jon Webb]

I assure you that the problem I'm seeing does happen with Flash Player. I'm not even sure how it would be possible for me to capture audio using Flash Player and have the problem with RTMPProtocolDecoder create an issue "elsewhere." The problem is with Red5 1.0.7 and FlashPlayer, connecting over RTMP.

Did you test repeatedly? This is an intermittent problem; sometimes my client connects OK, sometimes it does not. It always works with NellyMoser 11K. And once the stream is established, at any bitrate, everything is OK.

-- Jon

[Jon Webb]

A bit more on this. I think I managed to get closeOnHeaderError turned off. Now I'm getting an error in BaseRTMPHandler:

2016-07-08 12:08:04,124 [NioProcessor-2] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Chunk too small, buffering (255,883)

2016-07-08 12:08:04,133 [NioProcessor-2] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Chunk too small, buffering (895,1024)

2016-07-08 12:08:04,133 [NioProcessor-2] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Last header null: HEADER_CONTINUE, channelId 63

2016-07-08 12:08:04,283 [NioProcessor-77] WARN  o.r.c.net.rtmp.RTMPMinaIoHandler - Exception caught null

2016-07-08 12:08:04,284 [NioProcessor-2] WARN  o.r.s.n.r.codec.RTMPProtocolDecoder - Unknown object type: -1

2016-07-08 12:08:04,288 [Thread-58] WARN  o.r.c.n.rtmp.BaseRTMPClientHandler - Stream data not found for stream id: 1.0

2016-07-08 12:08:04,290 [NioProcessor-2] DEBUG o.r.s.n.r.codec.RTMPProtocolDecoder - Last header null: HEADER_CONTINUE, channelId 63

2016-07-08 12:08:04,292 [RTMPConnectionExecutor-4] INFO  o.r.server.net.rtmp.BaseRTMPHandler - Message type unknown: Size: 256 Data:

00 00 00 00 01 00 02 00 01 00 01 00 00 00 00 00 FF FF FF FF 

FE FF FF FF FF FF 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 

01 00 01 00 00 00 00 00 00 00 00 00 01 00 02 00 00 00 00 00 

00 00 FF FF 00 00 00 00 01 00 01 00 00 00 00 00 00 00 00 00 

01 00 02 00 00 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 C6 

00 FF FF 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 

00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 00 02 00 01 

00 00 00 00 00 01 00 02 00 01 00 01 00 00 00 00 00 FF FF FF 

FF FE FF FF FF FF FF 00 00 00 00 01 00 01 00 02 00 01 00 00 

00 00 00 00 00 00 00 00 00 01 00 02 00 01 00 01 00 01 00 01 

00 00 00 00 00 00 00 FF FF FF FF 00 00 01 00 01 00 01 00 00 

00 FE FF FE FF FF FF 00 00 00 00 00 00 00 00 00

On Tuesday, March 22, 2016 at 7:37:51 PM UTC-4, Juan Diego wrote:

[Jon Webb]

I'm thinking this problem may be related to capturing from a live microphone. I'm guessing that your test setup is streaming from recorded content.

If I create a client that demonstrates the problem with a live microphone, will you take a look at the problem?

I would really like some help here.

-- Jon Webb

[Rajdeep Rath]

Hi

I did test with live microphone. Yes if you give me exact steps that can reproduce the issue I will be able to check it out for you.

Regards
Rajdeep Rath

--

[Jon Webb]

Well, while I'm working on a minimal app, since you can use an app with a live microphone, perhaps you could try something like:

1. Run the app in Google Chrome.

2. Connect to server and share the microphone, which should be receiving sound, using codec NellyMoser 22K. Chrome will ask your permission to share the microphone.

3. Give permission.

It's at this point that the app fails. I suspect something in Flash Player is not handling the protocol correctly, or something in Red5 is not interpreting it properly.

Also, it would be a lot easier for me to provide Wireshark logs with my existing app, which I'm trying to pare down so I can share. You would be able to see the RTMP messages that cause the problem. Would that help?

-- Jon

[Rajdeep Rath]

Ok I will test it later but the primary thing is you shouldn't be initializing a mic before it is acquired. You should initialize it with audio broadcast parameters only after you have successfully acquired it . After the permission stage.

[Jon Webb]

Thanks, that's very useful. - Jon 

You received this message because you are subscribed to a topic in the Google Groups "red5" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/red5interest/57Ou37LfMjs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to red5interest...@googlegroups.com.

[Jon Webb]

I've been unable to create a small app that you could use to see the issue. The problem is that my app is part of a SIP system for conferencing, and there is simply too much going on on the server and with other devices to extract the portion that shows the failure.

However, I'm convinced that the problem is occurring in the Flash portion of the code, not the server. I used the debugger on the server common library and was able to see the bad packets arriving. Not only is there a bad header, but the bad packets persist. Even if I ignore the first one, the problem does not go away. It looks like the Flash client is sending null data.

I'm at a loss to find what I'm dong wrong on the Flash client, though. The code I have works at the lower bit rate, and as far as I can find from the online tutorials I'm doing things correctly. 

Your comment on not initializing the microphone before it's acquired intrigues me, though. I didn't find anything to that effect online. (I did change my code to wait until the permission is granted, but the effect is the same -- as soon as I change the codec, the stream is damaged.) 

Are there any online tutorials or code examples that might help me understand what I'm doing wrong? I'm receiving and sending audio data on the same NetConnection -- could that be part of the problem? Can you give me any other guidance?

-- Jon

On Monday, July 11, 2016 at 12:49:42 PM UTC-4, Jon Webb wrote:

Thanks, that's very useful. - Jon 

On Mon, Jul 11, 2016 at 12:31 PM Rajdeep Rath wrote:

Ok I will test it later but the primary thing is you shouldn't be initializing a mic before it is acquired. You should initialize it with audio broadcast parameters only after you have successfully acquired it . After the permission stage.

To unsubscribe from this group and stop receiving emails from it, send an email to red5interest+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "red5" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/red5interest/57Ou37LfMjs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to red5interest+unsubscribe@googlegroups.com.

[Jon Webb]

(To be clear, I'm using the same NetConnection for sending & receiving data -- not the same NetStream. I create two different NetStreams on the NetConnection. - J 

[Mondain]

I dont know if this will fix it, but could you try using separate NetConnections? I have seen issues and posts about problems arising from sharing a NetConnection; while it should work, it doesn't always.

You received this message because you are subscribed to a topic in the Google Groups "red5" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/red5interest/57Ou37LfMjs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to red5interest...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jon Webb]

I finally tracked the problem down to an issue on the server (not the client). My servlet makes an internal RTMP connection to another servlet to control the phone call. The code uses a subclass of BaseRTMPClientHandler to communicate with the other servlet. For some reason that I don't quite understand, the code (which overrides onCommand) apparently creates a race condition, probably in BaseRTMPClientHandler. This results in a corrupted RTMP stream between the two servlets, which leads to the entire subsystem, including the RTMP connection to the client, being shut down.

I don't think this is necessarily a bug in Red5 -- my servlet code subclassing BaseRTMPClientHandler seems fishy. But in any case the problem is pretty easy for me to work around.

Thanks for the help. While the idea of separating the two NetStreams into different NetConnections didn't solve the problem in itself, it did lead me to the solution, since I could see more clearly what was going on with the connections. And I really appreciate your (you and especially Rajdeep) taking time to look at this. It encouraged me to spend more time figuring out exactly what was going on as I was led to believe the problem was in my code, not Red5.

-- Jon Webb

To unsubscribe from this group and stop receiving emails from it, send an email to red5interest+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "red5" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/red5interest/57Ou37LfMjs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to red5interest...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rajdeep Rath]

You are most welcome Jon. Very nice to hear you caught your fish ☺. Thank you for your patience and explaining your issues with clarity. It helps everyone, including us.. now and those of who will come looking for answers tomorrow.

Good luck with your project !! 👍

You received this message because you are subscribed to a topic in the Google Groups "red5" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/red5interest/57Ou37LfMjs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to red5interest...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to red5interest...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--