[1/2] rtmp: Handle FLV packets written in more than one write call

Message ID 1316524182-8328-1-git-send-email-martin@martin.st
State Committed
Commit a14c784210198fe830391a59897d4dc62f13ab84
Headers show

Commit Message

Martin Storsjö Sept. 20, 2011, 1:09 p.m.
From: Chiranjeevi Melam <cmelam@rgbnetworks.com>

If the FLV packet is larger than the AVIO buffer, a partial
FLV packet will be flushed to the RTMP protocol.

This commit handles the most common cases of FLV packets
being written in more than one call.
---

Compared to other versions of the same patch, this one
adjusts size_temp based on flv_size - flv_off, before
recalculating flv_off. Other versions do that after updating
flv_off, making size_temp end up with completely bogus values.

 libavformat/rtmpproto.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

Comments

Kostya Shishkov Sept. 20, 2011, 1:17 p.m. | #1
On Tue, Sep 20, 2011 at 04:09:41PM +0300, Martin Storsjö wrote:
> From: Chiranjeevi Melam <cmelam@rgbnetworks.com>
> 
> If the FLV packet is larger than the AVIO buffer, a partial
> FLV packet will be flushed to the RTMP protocol.
> 
> This commit handles the most common cases of FLV packets
> being written in more than one call.
> ---
> 
> Compared to other versions of the same patch, this one
> adjusts size_temp based on flv_size - flv_off, before
> recalculating flv_off. Other versions do that after updating
> flv_off, making size_temp end up with completely bogus values.
> 
>  libavformat/rtmpproto.c |    8 +++++---
>  1 files changed, 5 insertions(+), 3 deletions(-)

Maybe OK (if you also trust this patch).
Martin Storsjö Sept. 20, 2011, 1:22 p.m. | #2
On Tue, 20 Sep 2011, Kostya Shishkov wrote:

> On Tue, Sep 20, 2011 at 04:09:41PM +0300, Martin Storsjö wrote:
>> From: Chiranjeevi Melam <cmelam@rgbnetworks.com>
>>
>> If the FLV packet is larger than the AVIO buffer, a partial
>> FLV packet will be flushed to the RTMP protocol.
>>
>> This commit handles the most common cases of FLV packets
>> being written in more than one call.
>> ---
>>
>> Compared to other versions of the same patch, this one
>> adjusts size_temp based on flv_size - flv_off, before
>> recalculating flv_off. Other versions do that after updating
>> flv_off, making size_temp end up with completely bogus values.
>>
>>  libavformat/rtmpproto.c |    8 +++++---
>>  1 files changed, 5 insertions(+), 3 deletions(-)
>
> Maybe OK (if you also trust this patch).

Yes, I tested it myself by setting the AVIO buffer size to different 
sizes, to test the different cases.

// Martin

Patch

diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index de4eb0f..66265f2 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -925,7 +925,7 @@  static int rtmp_write(URLContext *s, const uint8_t *buf, int size)
     uint32_t ts;
     const uint8_t *buf_temp = buf;
 
-    if (size < 11) {
+    if (!rt->flv_off && size < 11) {
         av_log(s, AV_LOG_DEBUG, "FLV packet too small %d\n", size);
         return 0;
     }
@@ -966,20 +966,22 @@  static int rtmp_write(URLContext *s, const uint8_t *buf, int size)
         if (rt->flv_size - rt->flv_off > size_temp) {
             bytestream_get_buffer(&buf_temp, rt->flv_data + rt->flv_off, size_temp);
             rt->flv_off += size_temp;
+            size_temp = 0;
         } else {
             bytestream_get_buffer(&buf_temp, rt->flv_data + rt->flv_off, rt->flv_size - rt->flv_off);
+            size_temp   -= rt->flv_size - rt->flv_off;
             rt->flv_off += rt->flv_size - rt->flv_off;
         }
 
         if (rt->flv_off == rt->flv_size) {
             bytestream_get_be32(&buf_temp);
-
+            size_temp -= 4;
             ff_rtmp_packet_write(rt->stream, &rt->out_pkt, rt->chunk_size, rt->prev_pkt[1]);
             ff_rtmp_packet_destroy(&rt->out_pkt);
             rt->flv_size = 0;
             rt->flv_off = 0;
         }
-    } while (buf_temp - buf < size_temp);
+    } while (buf_temp - buf < size);
     return size;
 }