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

Michael Niedermayer michaelni
Wed Jul 29 10:39:21 CEST 2009


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


>If server
> uses different key then we can't deal with it. 

thats sad too, I mean for a FOSS player ...


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090729/c5b3cf79/attachment.pgp>



More information about the ffmpeg-devel mailing list