[rtmpdump] rtmpsuck Segmentation Fault

[Howard Chu]

Francisco Legaspi wrote:
>> From: Howard Chu
>> Perfect. This crashed is now fixed in svn -r253.
>>
>> Still don't know what to tell you about the other problems.
>
> Cool. There's no more segfault now. Thanks.
>
> About the other problems... I got the video to playback fully when using
> rtmpsuck -z by dumping stderr out to a file. The text from stderr ended up
> creating a nearly 250MB text file, so it seems to be at least seeing much
> more than 128KB worth of video data. I don't know if it can help, but I
> compressed and uploaded text from stderr here:
> http://www.mediafire.com/?yrzuxew24yy
>
> For this particular site, it seems like it first does some kind of connection
> test, which eventually times out. Then, it connects to the server again to play
> the video. I believe the connection for the video starts at line 232 in the
> text file.

OK. The client is doing something weird; it sends a Play command immediately 
followed by an UnPause command (even though nothing was paused yet). The 
effect is that the server starts playing the media twice.

In rtmpsuck, whenever it sees a Play.Start status, it tries to advance to the 
next output file (assuming a multi-file playlist is in effect). In this case, 
since there's only one active file, it advances to nothing. (Closes the 
current file, and then has no active output file.)

svn r254 fixes this latter problem, but the UnPause will still cause trouble - 
the output file will probably be broken. Since it writes the first 128KB of 
data, and then the server starts over again from the beginning, the file will 
have the beginning in it twice, and most players will choke if they see data 
starting over again from zero in an existing stream.

I'd really rather not have to keep track of Pause/Seek offsets in this code. 
Perhaps I could have rtmpsuck drop the UnPause command if there is not a Pause 
currently in effect. Will have to think about it...