[FFmpeg-devel] [PATCH] RTMP client support for lavf

[compn]

On Wed, 29 Jul 2009 18:53:59 +0300, Kostya wrote:
>On Wed, Jul 29, 2009 at 10:39:21AM +0200, Michael Niedermayer wrote:
>> On Wed, Jul 29, 2009 at 09:26:05AM +0300, Kostya wrote:
>> > On Tue, Jul 28, 2009 at 03:33:36PM +0200, Michael Niedermayer wrote:
>> > > On Tue, Jul 28, 2009 at 09:27:11AM +0300, Kostya wrote:
>> > > > On Fri, Jul 24, 2009 at 03:08:32AM +0200, Michael Niedermayer wrote:
>> > > > > On Thu, Jul 23, 2009 at 06:34:13AM +0300, Kostya wrote:
>> > > > > > On Wed, Jul 22, 2009 at 12:01:46PM +0200, Michael Niedermayer wrote:
>> > > > > > > On Wed, Jul 22, 2009 at 07:58:05AM +0300, Kostya wrote:
>> > > > > > > > On Tue, Jul 21, 2009 at 11:30:26PM +0200, Michael Niedermayer wrote:
>> > > > > > > > > On Tue, Jul 21, 2009 at 11:04:09AM +0300, Kostya wrote:
>> > > > > > > > > > On Mon, Jul 20, 2009 at 05:05:41PM +0200, Michael Niedermayer wrote:
>> > > > > > > > > > > On Sat, Jul 18, 2009 at 08:01:17PM +0300, Kostya wrote:
>> > > > > > > > > > > > On Sat, Jul 18, 2009 at 11:29:34AM +0200, Michael Niedermayer wrote:
>> > > > > > > > > > > > > On Fri, Jul 17, 2009 at 06:38:46PM +0300, Kostya wrote:
>> > [...]
>> > > > > also shouldnt there be checks against receiving the wrong thing in the wrong
>> > > > > state?
>> > > > 
>> > > > well, because I can't be sure about what is wrong and I'm as willing to
>> > > > read Adobe spec as you're willing sign some agreement (for the same
>> > > > reason too).
>> > > 
>> > > so you think it might be ok for the playing state to return to prior
>> > > not yet initialized states?
>> >  
>> > Yes, I'm pretty sure of that - especially when server streams the same
>> > data on connect.
>> >  
>> > > [...]
>> > > > +
>> > > > +#define PLAYER_KEY_OPEN_PART_LEN 30   ///< length of partial key used for first client digest signing
>> > > > +/** Client key used for digest signing */
>> > > > +static const uint8_t rtmp_player_key[] = {
>> > > > +    'G', 'e', 'n', 'u', 'i', 'n', 'e', ' ', 'A', 'd', 'o', 'b', 'e', ' ',
>> > > > +    'F', 'l', 'a', 's', 'h', ' ', 'P', 'l', 'a', 'y', 'e', 'r', ' ', '0', '0', '1',
>> > > > +
>> > > > +    0xF0, 0xEE, 0xC2, 0x4A, 0x80, 0x68, 0xBE, 0xE8, 0x2E, 0x00, 0xD0, 0xD1, 0x02,
>> > > > +    0x9E, 0x7E, 0x57, 0x6E, 0xEC, 0x5D, 0x2D, 0x29, 0x80, 0x6F, 0xAB, 0x93, 0xB8,
>> > > > +    0xE6, 0x36, 0xCF, 0xEB, 0x31, 0xAE
>> > > > +};
>> > > > +
>> > > > +#define SERVER_KEY_OPEN_PART_LEN 36   ///< length of partial key used for first server digest signing
>> > > > +/** Key used for RTMP server digest signing */
>> > > > +static const uint8_t rtmp_server_key[] = {
>> > > > +    'G', 'e', 'n', 'u', 'i', 'n', 'e', ' ', 'A', 'd', 'o', 'b', 'e', ' ',
>> > > > +    'F', 'l', 'a', 's', 'h', ' ', 'M', 'e', 'd', 'i', 'a', ' ',
>> > > > +    'S', 'e', 'r', 'v', 'e', 'r', ' ', '0', '0', '1',
>> > > 
>> > > Is it needed to lie here ? or does it also work with correct info?
>> > 
>> > Huh? That's the key used by server to sign handshake data. 
>> 
>> i meant the player key
> 
>same for player
> 
>> >If server
>> > uses different key then we can't deal with it. 
>> 
>> thats sad too, I mean for a FOSS player ...
> 
>Wanna write your own RTMP protocol with blackjack and hookers? ;)
>Since this thing was obviously written for Adobe Flash player + Adobe
>RTMP Server deadlock, we can do nothing else but pretend, otherwise it
>won't work (reminds me about first modems - AT&T was forbidding to
>connect anything but their phones to phone sockets, so modems used phone
>speaker+microphone to transmit and receive data).

maybe michael wants to be able to change the key without
recompiling. e.g. some company creates/copies an rtmp
server+client to use a different key. e.g. "XYZ Website only 001".

i thought i heard talk of "Genuine Adobe Flash Player 003" but google
says no.

-compn