January 2013 - rtmpdump - lists.mplayerhq.hu

rtmpdump-2.4.tgz
by Samuli Kaipiainen 05 Feb '13

05 Feb '13

Hi, is it possible to add a tar.gz package for 2.4 into http://rtmpdump.mplayerhq.hu/download/? Re: https://github.com/mxcl/homebrew/pull/17303 Helsinki ski greetings, Sampumon

4 4

RTMPGW and FFMPEG
by Dan Turner 02 Feb '13

02 Feb '13

Hi All, I am trying to use RTMPGW for a project and have a question regarding connection. When I connect to RTMPGW with an HTTP GET request using VLC or MPlayer like so: mplayer "http://localhost:8902/?r=rtmp://live.dtv.cubecdn.net:80/kdmobil/KanalD1&W=h…" ...with RTMPGW set as so: rtmpgw --sport 8902 ...it works a treat, and RTMPGW's terminal output is: Streaming on http://0.0.0.0:8902 Connecting ... port: 80, app: kdmobil/KanalD1 388.507 KB / 48853.38 sec Lovely! However, when I try to do the same thing with ffmpeg/ffplay like this: ffplay -i "http://localhost:8902/?r=rtmp://live.dtv.cubecdn.net:80/kdmobil/KanalD1&W=h…" I just get "HTTP error 416 Requested Range Not Satisfiable" from ffplay and "processTCPrequest, Range request not supported" from RTMPGW. Do you have any idea why ffmpeg won't connect, but VLC and mplayer will? Thanks for any help Dan

1 1

Streaming from rtvslo.si with rtmpdump results in malformed files
by bartmon 17 Jan '13

17 Jan '13

Hello! First of all I would like to thank all contributors to this project as it has on many an occasion saved me from the hell of using Adobes's Flash client. I'm experiencing issues dumping streams from rtvslo.si. Judging from verbose output [1] I believe there are constant buffer underruns, some messages between server and client about pausing and then resumption of streaming. It, however, does not continue from where the underrun happened, but resumes from a percentage that is a bit lower. Due to constant errors some streams never dump completely and those that do are full of errors because all received data, even restreamed is dumped to file. This way files are full of missing keyframes and repeated fragments. Here's the command I used for a file that completes (about 300MB): rtmpdump -V -r "rtmp://stream.rtvslo.si/simplevideostreaming" -a "simplevideostreaming" -f "LNX 11,2,202,261" -W " http://tvslo.si/media_jwplayer_5.7.swf" -p "http://tvslo.si" -y "mp4:17/20/Infodromx201301071737x700000x351x413x.mp4" -o Infodrom_20130107.flv [1] Output is way too long to post here (0.5MB) or pastebins. Please download a compressed version from https://dl.dropbox.com/u/1277626/rtmpdump2.4-issue_rtvslo.si.log.zip or http://takra.tk/files/rtmpdump2.4-issue_rtvslo.si.log.zip A longer stream I tried to dump was constantly retrying at 89% and the file grew to several GB before i terminated the process. I'm reporting this issue here so that someone with more knowledge of RTMP and rtmpdump's source can try and fix this. Please also feel free to nudge me in the appropriate direction and I'll try to analyse the issue when time permits.

3 3

Bug that creates malformed FLV files for live streams and a suggested fix
by Kirill K 16 Jan '13

16 Jan '13

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

2 2

[PATCH 1/2] Correct the length of base64 digests
by Martin Storsjo 02 Jan '13

02 Jan '13

From: Björn Axelsson <bjorn.axelsson(a)intinor.se> This was broken in e42b5d09. This makes adobe auth against akamai servers work again. --- librtmp/rtmp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/librtmp/rtmp.c b/librtmp/rtmp.c index b966710..d64a0bb 100644 --- a/librtmp/rtmp.c +++ b/librtmp/rtmp.c @@ -2514,8 +2514,8 @@ PublisherAuth(RTMP *r, AVal *description) #define RESPONSE_LEN 32 #define CHALLENGE2_LEN 16 #define SALTED2_LEN (32+8+8+8) -#define B64DIGEST_LEN 22 /* 16 byte digest => 22 b64 chars */ -#define B64INT_LEN 6 /* 4 byte int => 6 b64 chars */ +#define B64DIGEST_LEN 24 /* 16 byte digest => 22 b64 chars + 2 chars padding */ +#define B64INT_LEN 8 /* 4 byte int => 6 b64 chars + 2 chars padding */ #define HEXHASH_LEN (2*MD5_DIGEST_LENGTH) char response[RESPONSE_LEN]; char challenge2[CHALLENGE2_LEN]; -- 1.7.9.4

2 2