On 21/09/13 20:50, Josh Allmann wrote:
> On 21 September 2013 02:11, Luca Barbato <[email protected]> wrote:
>> ---
>>  libavformat/rtmpproto.c | 69 
>> +++++++++++++++++++++++++++++--------------------
>>  1 file changed, 41 insertions(+), 28 deletions(-)
>>
>> diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
>> index 2b2baa3..da84254 100644
>> --- a/libavformat/rtmpproto.c
>> +++ b/libavformat/rtmpproto.c
>> @@ -2187,6 +2187,46 @@ static int rtmp_parse_result(URLContext *s, 
>> RTMPContext *rt, RTMPPacket *pkt)
>>      return 0;
>>  }
>>
>> +static int handle_metadata(RTMPContext *rt, RTMPPacket *pkt)
>> +{
>> +    int ret, old_flv_size;
>> +    const uint8_t *next;
>> +    uint8_t *p;
>> +    uint32_t size;
>> +    uint32_t ts, cts, pts = 0;
>> +
>> +    old_flv_size = update_offset(rt, pkt->size);
>> +
>> +    if ((ret = av_reallocp(&rt->flv_data, rt->flv_size)) < 0)
>> +        return ret;
>> +
>> +    next = pkt->data;
>> +    p    = rt->flv_data + old_flv_size;
>> +
>> +    /* rewrite timestamps */
> 
> /* copy data while rewriting timestamps */
> might be more accurate
> 
>> +    ts = pkt->timestamp;
>> +    while (next - pkt->data < pkt->size - 11) {
> 
> The number 11 here is magic, maybe a comment explaining this is
> supposed to be the length of a header?
> 
>> +        *p++ = *next++;
>> +        size = bytestream_get_be24(&next);
>> +        bytestream_put_be24(&p, size);
> 
> Group this with bytestream_put_be24(&p, ts), just for consistency?

Either you read and write each field (as I do now) or you
try to read all the bits and then write.

Not sure which is more consistent.

> Please elaborate on these changes in the commit message also
> (since this seems like a bit more than a refactor to shuffle code around)
> 
> Maybe something like this:
> 
> rtmp: Handle metadata outside get_packet
> 
> Use update_offset(), and also copy the data while rewriting
> timestamps, rather than overwriting the old timestamps then copying.

I'll be more verbose indeed =)

lu

_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to