Skip to main content
A
Anonymous
January 15, 2009
Answered

Spurious characters in FMS responses?

  • January 15, 2009
  • 2 replies
  • 649 views
We have some existing C++ code which communicates with Red5 and Wowza, but fails with FMS 3.0 and 3.5. Strangely enough, the responses from FMS contain spurious 0xC3 bytes.For instance, when we make a connect() request, the _result response from FMS should contain two objects, one with fmsVer and capabilities, the other with level and code. The response starts off well, but the value FMS sends us for the code attribute is "NetConnection.ConÃnect.Succes", with an extra 0xC3 byte inserted (the trailing 's' of "Success" is still there, which throws off all subsequent parsing).

I'm guessing that these have to do with chunking of RTMP. Is this behaviour documented somewhere? And how best to cope with these extra bytes? I looked at the pyamf code, and couldn't find anything relating to chunking.

Thanks.
    This topic has been closed for replies.
    Correct answer
    Nope, my guess was correct. The extra 0xC3 byte turns out to be a header-byte for the next chunk. Most clients only deal with the data after the chunks have been reassembled, which is why they never see these bytes. But since we're writing our own client, we have to do the reassembly ourselves.

    2 replies

    A
    Anonymous
    January 20, 2009
    I guess it may not be legally permitted with FMS. This is what FMS 3.0/3.5 license say :

    2.8.6. Streaming Restriction. Licensee may only use the Software to stream to or from Adobe’s proprietary or licensed (a) software such as the Adobe Flash Player, Adobe Integrated Runtime (AIR), Adobe Media Player, Flash Lite Player or Interactive Servers (and successor products); or (b) software protocols licensed to Licensee that Adobe licenses to Licensee under a separate written agreement solely for use with the Software.
    A
    Anonymous
    January 20, 2009
    quote:
    Originally posted by: fmslove
    I guess it may not be legally permitted with FMS.


    Ouch. That's good to know. I'll pass that on to management.

    Thanks.

    T
    techeye
    Participating Frequently
    January 16, 2009
    Nope, your guess is wrong. If it was the case the the "extra 0xC3" byte was inserted in the connect msg, it would break everyones code; not just yours.
    A
    Anonymous
    Correct answer
    January 19, 2009
    Nope, my guess was correct. The extra 0xC3 byte turns out to be a header-byte for the next chunk. Most clients only deal with the data after the chunks have been reassembled, which is why they never see these bytes. But since we're writing our own client, we have to do the reassembly ourselves.
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices