> +
> > + // 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
> > + 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.
>
> > + 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.
>
> > + // 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?
> rtmp probably could
> enjoy its usage a LOT. There are a number of non-standard situations.
>
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?
>
> > + memcpy(&temp, buffer, 4);
> > + epoch = ntohl(temp);
> > + my_epoch = epoch;
> > + memcpy(&temp, buffer + 4, 4);
> > + temp = ntohl(temp);
> > + if (temp != 0) {
> > + av_log(NULL, AV_LOG_WARNING,
> > + "Erroneous C1 Message zero != 0 -> %d\n", temp);
> > + }
> > + memcpy(peer_random, buffer + 8,
> > + RTMP_HANDSHAKE_PACKET_SIZE - 8);
> > + /* Send S1 */
> > + /* By now same epoch will be send */
>
> sent
>
=s
>
> > + for (randomidx = 0;
> > + randomidx < (RTMP_HANDSHAKE_PACKET_SIZE - 8);
> > + randomidx += 4) {
> > + temp = av_get_random_seed();
> > + memcpy(my_random + randomidx, &temp, 4);
> > + }
> > + memcpy(buffer + 8, my_random, RTMP_HANDSHAKE_PACKET_SIZE - 8);
>
> RTMP_HANDSHAKE_PACKET_SIZE - 8 is used a lot, maybe a macro would be good.
>
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, ...
>
> > + inoutsize = ffurl_write(rt->stream, buffer,
> > + RTMP_HANDSHAKE_PACKET_SIZE);
> > + av_log(s, AV_LOG_ERROR, "Unexpected rtmp packet type\n");
> > + return AVERROR_INVALIDDATA;
> > + break;
> > + }
> > + ff_rtmp_packet_destroy(&rpkt);
> > + }
> > + return 0;
> > +}
>
>
> Might be nice having this function split in smaller ones.
>
ok
>
> > +
>
> > + rt->flv_off = 0;
> > + memcpy(rt->flv_data, "FLV\1\5\0\0\0\011\0\0\0\0",
> rt->flv_size);
>
> Make that string a macro if it is used more than in those two places.
>
nenjordi@ACERASPIRE:~/DEV/libav-rtmp$ grep -rn "FLV\\\1" libavformat/*
libavformat/rtmpproto.c:1658: memcpy(rt->flv_data,
"FLV\1\5\0\0\0\011\0\0\0\0", rt->flv_size);
libavformat/rtmpproto.c:1682: memcpy(rt->flv_data,
"FLV\1\5\0\0\0\011\0\0\0\0", rt->flv_size);
XD
>
> > + } else {
> > + rt->flv_size = 0;
> > + rt->flv_data = NULL;
> > + rt->flv_off = 0;
> > + rt->skip_bytes = 13;
> > + }
>
> Almost there =)
>
thanks for your time
> 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
>
--
Jordi Ortiz
mailto: nenjo...@gmail.com
http://www.jordiortiz.es
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
