[rtmpdump] Bug that creates malformed FLV files for live streams and a suggested fix

[Kirill K]

 Hey all,

I have encountered problem of downloading several live video streams with latest version (any version starting 2.3 and up to latest version in trunk) - the recorded files were no playable. My investigation showed that the problem mostly appeared in live video streams that were broadcasted with Flash 11 client in h264 codec. Debug session (on windows machine :-() showed that the problem happens when many first chunks has 0 time stamps so there's a trigger for realloc just before buffer overflow. The reallocation doesn't consider the first 13 bytes of the header that exists in the buffer and that's how 13 bytes get vaporized. It forces next chunk to start in incorrect offset and the stream becomes unplayable.

Suggested fix: in file rtmp.c add on line 5001:
cnt = sizeof(flvHeader);

In the end it'll look like this:
     char *mybuf = malloc(HEADERBUF), *end = mybuf + HEADERBUF;
      int cnt = 0;
      r->m_read.buf = mybuf;
      r->m_read.buflen = HEADERBUF;

      memcpy(mybuf, flvHeader, sizeof(flvHeader));
      r->m_read.buf += sizeof(flvHeader);
      r->m_read.buflen -= sizeof(flvHeader);
      cnt = sizeof(flvHeader);

      while (r->m_read.timestamp == 0)

It solved the issue for me.

I don't know why there're so many chunks with timestamp 0. Sometimes it takes 300KB for first non-zero timestamp. Maybe it's an issue with flash built-in encoder or FMS (4.5) - has anyone encountered similar behavior?

Last note is that in my case rtmpdump/librtmp doesn't start to output the data until the limit of 128kb reached. So it adds latency to live manipulation on this stream. And none of the input argument has changed this behavior for me (I mean -b 0).

Best Regards,
Kirill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20130115/25bf7d37/attachment.html>