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

[Kostya]

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).
 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB