RTMPProtocolEncoder always write AMF0 for SharedObjects

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Create a RTMPClient and connect it to Server.

   Map<String, Object> defParams = rtmpClient.makeDefaultConnectionParams(_host, _port, _application);

   defParams.put("objectEncoding", Integer.valueOf(3));

   rtmpClient.connect(_host, _port, defParams, this, null);

2. Obtain a ClientSharedObject using the RTMPClient connection.

   IClientSharedObject myClientSho = rtmpClient.getSharedObject("TestSho", true);

  myClientSho.addSharedObjectListener(new ShoListener(this));

  myClientSho.connect(_appConn);

3. Write ByteArray to the ClientSharedObject.

   We get the below exception message on Console:

   "ByteArray objects not supported with AMF0"     

What is the expected output? What do you see instead?

The ByteArray written to ClientSharedObject should reach to Server without 
throwing any exception.

What version of the product are you using? On what operating system?

Please provide any additional information below.

RTMPProtocolEncoder and decoder takes the instance of Output which was hard 
coded to use AMF0 Output in place of AMF3 Output instance.

Below is the method from RTMPProtocolEncoder:

public void doEncodeSharedObject(ISharedObjectMessage so, RTMP rtmp, IoBuffer 
out) 
{
    final Output output = new org.red5.io.amf.Output(out);

The output instance was hard coded to use org.red5.io.amf.Output in place of 
condtional Output instance which can use either org.red5.io.amf.Output or 
org.red5.io.amf3.Output based on the encoding type used by the RTMPClient.

Similary the Red5 server fails to decode the AMF3 message.

Original issue reported on code.google.com by bhagwat....@gmail.com on 4 Oct 2011 at 10:48

[GoogleCodeExporter]

Original comment by mondain on 15 Nov 2011 at 3:33

• Changed state: Accepted

[GoogleCodeExporter]

After making the local fix to use AMF0/ AMF3 based on the encoding set by 
client, the Shared Object always write AMF0 header even if flash client uses 
AMF3. Since Red5 writes AMF0, the flash client simply reject the attribute 
changes made by Red5.

The main aim of raising this defect is to fix the ByteArray send/receive by 
both RTMPClient and Flash Client.

Original comment by bhagwat....@gmail.com on 16 Nov 2011 at 2:06

[GoogleCodeExporter]

I'm seeing the same error on Red5 1.0 and Windows 2008 Server.

Original comment by Ste...@Velocedge.com on 16 Nov 2011 at 6:20

[GoogleCodeExporter]

I've made a few changes to how this is handled across the board so please 
retest with at least revision 4300 and let me know how it goes.

Original comment by mondain on 1 Dec 2011 at 9:39

[GoogleCodeExporter]

Hi,

I will do the re-test over this weekend and also make the sample Project in 
Red5, Flash and Java to do the re-test if required in future.

Original comment by bhagwat....@gmail.com on 9 Dec 2011 at 3:54

[GoogleCodeExporter]

Shared object issues appear to be resolved starting with revision 4304.

Original comment by mondain on 9 Dec 2011 at 10:31

• Changed state: Fixed
• Added labels: Component-SharedObjects