On 07/17/2012 08:26 PM, Jordi Ortiz wrote:
>> +
>
>>> + // Send Window Acknowledgement Size (wireshark)
>>
>> wireshark?
>>
> Both wireshark and the specification document I used as reference call this
> Send Widndow Acknowledgement Size instead of Set Client BW which is what I
> would expect if I look at the code while watching wireshark. May be the
> comment wasn't very appropriated =p
use "in the specification" not (wireshark)
>
>
>>> + if ((ret = ff_rtmp_packet_create(&pkt, RTMP_NETWORK_CHANNEL,
>>> + RTMP_PT_CLIENT_BW, 0, 4096)) < 0)
>>> + return ret;
>>
>> 4096 looks like a magic number, #define it somewhere
>>
> It is the allocated data which is freed few lines later. I will reduce the
> size for those cases in which it is easy to calculate but others like the
> result_ to the connect command are quite difficult to calculate.
call it RTMP_${something} but not leave it unnamed.
>>
>>> + p = pkt.data;
>>> + bytestream_put_be32(&p, 268435455);
>>
>> same
>>
> In this case I just set the value I saw in crtmpd server capture. I'll
> change it to rt->server_bw if you agree.
Ok
>>
>>> + // Send result_
>>> + if ((ret = ff_rtmp_packet_create(&pkt, RTMP_SYSTEM_CHANNEL,
>>> + RTMP_PT_INVOKE, 0, 8192)) < 0)
>>> + return ret;
>>
>> Yet another magic number
>>
>>> + p = pkt.data;
>>> + ff_amf_write_string(&p, "_result");
>>> + ff_amf_write_number(&p, 1);
>>> +
>>> + ff_amf_write_object_start(&p);
>>> + ff_amf_write_field_name(&p, "fmsVer");
>>> + ff_amf_write_string(&p, "FMS/3,0,1,123");
>>> + ff_amf_write_field_name(&p, "capabilities");
>>> + ff_amf_write_number(&p, 31);
>>> + ff_amf_write_object_end(&p);
>>> +
>>> + ff_amf_write_object_start(&p);
>>> + ff_amf_write_field_name(&p, "level");
>>> + ff_amf_write_string(&p, "status");
>>> + ff_amf_write_field_name(&p, "code");
>>> + ff_amf_write_string(&p, "NetConnection.Connect.Success");
>>> + ff_amf_write_field_name(&p, "description");
>>> + ff_amf_write_string(&p, "Connection succeeded.");
>>> + ff_amf_write_field_name(&p, "objectEncoding");
>>> + ff_amf_write_number(&p, 0);
>>> + ff_amf_write_object_end(&p);
>>> +
>>
> This one is the one difficult to calculate
>
>>> + pkt.data_size = p - pkt.data;
>>> + ret = ff_rtmp_packet_write(rt->stream, &pkt,
>> rt->chunk_size,
>>> + rt->prev_pkt[1]);
>>> + ff_rtmp_packet_destroy(&pkt);
>>
> anyway here it is freed.
>
>> +static int rtmp_listen_handshake(URLContext *s, RTMPContext *rt)
>>> +{
>>> + uint8_t buffer[RTMP_HANDSHAKE_PACKET_SIZE];
>>> + uint32_t epoch; // to context?
>>> + uint32_t my_epoch; // to context?
>>> + uint32_t temp;
>>> + uint8_t peer_random[RTMP_HANDSHAKE_PACKET_SIZE - 8]; // to context?
>>> + uint8_t my_random[RTMP_HANDSHAKE_PACKET_SIZE - 8]; // to context?
>>> + int randomidx = 0;
>>> + ssize_t inoutsize = 0;
>>> +
>>> + inoutsize = ffurl_read(rt->stream, buffer, 1); // Receive C0
>>> + if (inoutsize == 0) return AVERROR(EIO);
>>> + if (buffer[0] == 3) /* Check Version */
>>> + if (!ffurl_write(rt->stream, buffer, 1)) { // Send S0
>>> + av_log(NULL, AV_LOG_ERROR,
>>> + "Unable to write answer - RTMP S0\n");
>>> + return AVERROR_PROTOCOL_NOT_FOUND;
>>> + }
>>> + /* Receive C1 */
>>> + inoutsize = ffurl_read(rt->stream, buffer, 4096);
>>> + if (inoutsize == 0)
>>> + return AVERROR(EIO);
>>> + if (inoutsize != RTMP_HANDSHAKE_PACKET_SIZE) {
>>> + av_log(NULL, AV_LOG_ERROR, "Erroneous C1 Message size %d"
>>> + " not following standard\n", (int)inoutsize);
>>> + return AVERROR_INVALIDDATA;
>>> + }
>>
>> Do we have something along the other EXPLODE flags?
>
> What do you mean?
git grep for that word, we have a setting to be strict on errors ad
otherwise we'd be lenient.
> Yes, I have seen that there are a lot of magic numbers to act as certain
> clients and so... is that what you speak about?
any constant that isn't explained is "magic".
> maybe a parse_rtmp_hs_packet(uint32_t *first_int , uint32_t *second_int,
> char *arraydata, int size) would be a good idea... what do you think? I'll
> remove a lot of memcpy, ntohl, the -8, ...
You could coordinate with Samuel on that part. =)
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
