[Red5] o.r.s.n.p.ProtocolException: Error during decoding

[Zayzon, Gergely]

Andy,

Thanks for the hints, but I'm not sure you found the cure, as checking 
diffs between the trunk and the version I have shows no significant 
difference in the affected methods.

org.red5.io.amf.Input.getString() (R3590) is just the same (only the 
buffer implementation seems to have been changed in the whole class, but 
that does not seem to be related at the first glance), and in 
org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decode() (R3625) I 
could not see anything dramatic either, except that they are full with 
the timestamp fixes (which looks impressive by the way). I must admit 
that the Red5 code is beyond my java knowledge (as a lot of other things 
unfortunately, I'm a newbie here), but I'll check out the trunk anyway, 
might spot something I haven't noticed yet.

Three questions I have (left);
1.) Why it is thought that there's a Flex message, is it normal to see 
that while I have only Flash? Can't be related to the problem?
2.) What if I remove the exceptions in org.red5.io.amf.Input.getString() 
and will return a null instead? Does that break something?
3.) Any chance someone can really investigate this, where it goes wrong 
(if I can somehow prove that trunk still have this problem)?

As a side note, it happened one hour ago once again, this time it come 
together with the heap filling effect.


Thanks,
Gergely Zayzon


Andy Shaules wrote:
> As I recall, that is patched and is a relativly small patch you can 
> apply to your version.
> 
> There is one method decode(RTMPProtocolDecoder.java:196) I believe shown 
> in the paste bin.
> 
> Actually 'decode packet' method is throwing an exception.
> 
> The error can be prevented by checking and handling  everything.
> 
> In the latest version I have, there is a lot of 'return null' which is 
> likely what you will want to do instead of having it throw the exception.
> 
> It looks like in here precisely
> at org.red5.io.amf.Input.readString(Input.java:233)
> 
> I think the trunk will double check the size of the buffer to prevent 
> that over-read Illegal argument exception.
> A few other error checking lines were added to deal with missing header 
> an such things.
> 
> 
> 
> 
> 
> 
> ----- Original Message ----- From: "Zayzon, Gergely" <gergoe at nexver.hu>
> To: <red5 at osflash.org>
> Sent: Saturday, November 14, 2009 10:54 AM
> Subject: Re: [Red5] o.r.s.n.p.ProtocolException: Error during decoding
> 
> 
>> Paul,
>>
>> The broadcaster is plain vanilla AS3 code, with one NetConnection and 
>> two NetStreams (one publisher and one subscriber of different 
>> streams). I can not tell you anything special about the application 
>> (as there's none), other than it only happens when publishing a stream 
>> for a long time without audio data and then enable the sending of it. 
>> This is simply done by calling NetStream.attachAudio(null) and 
>> NetStream.attachAudio(Microphone.getMicrophone()) respectively.
>>
>> I've never been able to reproduce it in the test environment, and I'm 
>> afraid to upgrade the production server to RC2 or trunk yet - hope you 
>> understand that.
>>
>> How could we/I found out the cause of the problem? Does the errors 
>> dumped to the error log not hold enough information? And how could 
>> this be related to excessive heap usage (this last one I can not 
>> understand at all, must be a small but nasty bug somewhere along the 
>> stack trace)?
>>
>> The problem is that I don't have the slightest knowledge of rtmp nor 
>> the sorenson codec, and actually my java knowledge is rather limited 
>> too, but I'm willing to follow any hints from the list.
>>
>> If that helps, i can add a logic to the application which starts to 
>> dump the received data on request (and it would be triggered by the 
>> broadcaster the moment it is about to send audio data). Only problem 
>> is that I have no idea how to dump the received data :-)
>>
>>
>> Thanks,
>> Gergely Zayzon
>>
>>
>> Mondain wrote:
>>> I would say that you should try the latest version available 0.9 RC2 or
>>> trunk, but it looks like something is wrong with your broadcaster. In 
>>> the
>>> log it would seem that your data cannot be decoded, I'm not sure 
>>> off-hand
>>> what would cause that.
>>>
>>> Paul
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Red5 mailing list
>>> Red5 at osflash.org
>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
> 
> 
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org