> + > > + // 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