Sat 26 Sep 2009 09:53:14 PM UTC, original submission:
Hi, I've found a live stream which is causing a crash in libRTMP and since I can't figure out how to file a bug for that, I figured here's just as good...
So here's the stream:
rtmp://peakbroadcasting.streamguys.org/live/kcix
It appears from my own debugging and verbose output of flvstreamer that it correlates with a "metadata" event/message. Usually packets directly following them start to have a type of 0x0, but not without a few packets that are read and whose size is interpreted to be something very large. This causes allocation of HUGE amounts of memory to read the packet body which causes a crash (on the iPhone) and on my mac a massive memory use (and possibly leak? though I'm not sure if it's leaking or just being allocated and deallocated).
I'm currently overwhelmed with other work so haven't been able to do too much to packet sniff, etc. to see exactly what's going on, but I can offer the commandline and the stream and what I've tried and someone else might test to see if they can reproduce it and might be better at debugging it than I am.
However, I do have one request, if at all possible and that's that any change be allowed to be under LGPL (since it's in the libRTMP code) and I've ported that to the iPhone. ) I guess if we can figure out what's wrong it might just be a couple lines of code to skip corrupt packets (though I think it's caused by bad parsing somehow).
Anyway, here's the command:
./flvstreamer -x -z -v -r "rtmp://peakbroadcasting.streamguys.org/live/kcix" -o out.flv
And here's an example of the problem: from the output (what to look for).
DEBUG: type: 08, size: 177, TS: 110852 ms, abs TS: 0
DEBUG: type: 08, size: 202, TS: 110898 ms, abs TS: 0
DEBUG: GetNextMediaPacket, received: notify 502 bytes
DEBUG: Property: <Name: no-name., STRING: onMetaData>
DEBUG: Property: <Name: no-name., OBJECT>
DEBUG: Property: <Name: audiodatarate, NUMBER: 32.00>
DEBUG: Property: <Name: audiosamplerate, NUMBER: 44100.00>
DEBUG: Property: <Name: audiocodecid, NUMBER: 10.00>
DEBUG: Property: <Name: canSeekToEnd, BOOLEAN: FALSE>
DEBUG: Property: <Name: audiodevice, STRING: Orban Optimod 1100 (212509059)>
DEBUG: Property: <Name: metadatacreator, STRING: Orban Opticodec-PC 3.0 (os=Windows NT 5.1 Service Pack 3)>
DEBUG: Property: <Name: description, STRING: Hi-Fi Internet Audio Stream>
DEBUG: Property: <Name: name, STRING: KISS 103.3 Boise's #1 Hit Music Station>
DEBUG: Property: <Name: createdby, STRING: Peak Broadcasting LLC>
DEBUG: Property: <Name: website, STRING: http://www.kiss1033.com>
DEBUG: Property: <Name: creationdate, STRING: Tuesday, September 22, 2009 05:16:10 UTC>
DEBUG: Property: <Name: artist, STRING: BREAK>
DEBUG: Property: <Name: title, STRING: 9/26/2009 3:47:53 PM>
DEBUG: Property: <Name: url, STRING: >
Metadata:
audiodatarate 32
audiosamplerate 44100
audiocodecid 10
canSeekToEnd FALSE
audiodevice Orban Optimod 1100 (212509059)
metadatacreator Orban Opticodec-PC 3.0 (os=Windows NT 5.1 Service Pack 3)
description Hi-Fi Internet Audio Stream
name KISS 103.3 Boise's #1 Hit Music Station
createdby Peak Broadcasting LLC
website http://www.kiss1033.com
creationdate Tuesday, September 22, 2009 05:16:10 UTC
artist BREAK
title 9/26/2009 3:47:53 PM
url
DEBUG: type: 12, size: 502, TS: 110898 ms, abs TS: 0
DEBUG: type: 08, size: 170, TS: 16888113 ms, abs TS: 0
DEBUG: GetNextMediaPacket, unknown packet type received: 0x00
DEBUG: GetNextMediaPacket, unknown packet type received: 0x00
DEBUG: GetNextMediaPacket, unknown packet type received: 0x00
....
And the problem is that this line: (from rtmp.cpp )
if (packet.m_nBodySize > 0 && packet.m_body == NULL && !packet.AllocPacket(packet.m_nBodySize))
calls AllocPacket with a HUGE body size, which allocates a giant buffer.
So, while I can think of workaround to prevent the crash (by saying anything over body size X just skips without allocation) the problem is there's an underlying error that's causing this, so that's much better to figure out and fix...
Let me know if you need any more info (and yes, using my slightly modified version of libRTMP from trunk in XBMC has the same issue so it's not something specific to my port or flvstreamer's modifications.
Hope someone can help.
|