[etiam]

Hi,

I've been trying to download some nice video lectures, but this mihght just prove to be the most difficult case I have ever come across.
Here's an example:
https://www.ipam.ucla.edu/wowzavideo.aspx?vfn=10660.mp4&vfd=gss2012

rtmpsrv sniffs it out all right, but it was necessary to add --realtime (or possibly --live) to prevent the download from just repeating the first few minutes without end. With that addition the stream downloads, but the resulting file only has smooth visual performance for approximately the first minute. Then it starts showing a new frame only about once per second.

Here's a short video sample (the problem starts around 1:10):
https://mega.co.nz/#!FJli3TbJ!GsUe9gPYrSawNWC7SsiGT3b8TGM5XPW2t0rTQkv 9q7s

At the time I was using the git repository version from 10 April 2013 (compiled statically) on Linux Mint 13.
Terminal I/O from the first 60 seconds of a run would look something like this:
~/rtmpdump $ ./rtmpdump -e --realtime -l 0 -r "rtmp://128.97.46.13:1935/gss2012/" -a "gss2012/" -f "LNX 11,0,1,152" -W "https://www.ipam.ucla.edu/videoplayer/jwplayer.flash.swf" -p "https://www.ipam.ucla.edu/wowzavideo.aspx?vfn=10660.mp4&vfd=gss2012" -y "mp4:10660.mp4" -o mp4_10660.flv
RTMPDump v2.4
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
Connecting ...
INFO: Connected...
Starting download at: 0.000 kB
in approximately realtime (disabled BUFX speedup hack)
INFO: Metadata:
INFO: trackinfo:
INFO: timescale 30000.00
INFO: length 98732634.00
INFO: language eng
INFO: sampledescription:
INFO: sampletype avc1
INFO: timescale 48000.00
INFO: length 157974528.00
INFO: language eng
INFO: sampledescription:
INFO: sampletype mp4a
INFO: audiochannels 2.00
INFO: audiosamplerate 48000.00
INFO: videoframerate 29.97
INFO: aacaot 2.00
INFO: avclevel 40.00
INFO: avcprofile 100.00
INFO: audiocodecid mp4a
INFO: videocodecid avc1
INFO: width 1920.00
INFO: height 1080.00
INFO: frameWidth 1920.00
INFO: frameHeight 1080.00
INFO: displayWidth 1920.00
INFO: displayHeight 1080.00
INFO: framerate 29.97
INFO: moovposition 32.00
INFO: duration 3291.14
1649.603 kB / 10.81 sec (0.3%)


Is there something I can do to fix this problem?
Am I doing something wrong in my usage? And if not, where would be a good place to direct a bug report?

[KSV]

have you tried it with my patches? i was able to download it without any problem after adding the -R switch and video around 70 seconds plays just fine.

http://stream-recorder.com/forum/customized-rtmpdump-binaries-patch-file-t16103.html

[etiam]

Thanks for the tip KSV, I had missed your patches so far and I'm sure they will come in handy.
However, even with the patched version of rtmpdump I still don't get a proper download of these videos . For instance, see the following result from the Jason Weston video I linked.

https://mega.co.nz/#!FJ0BAJDQ!N96RuBB93GAf2NpcQXqg73wdCCtLHevVOlTBUXh 7yAU

The issue starts at 1:18 in this case. It's only easy to spot for a few seconds since it doesn't show clearly with static picture like the presentation slides, but it is visible again from 2:24.

[KSV]

i am using the following command line and downloaded file works as expected without any glitches.

rtmpdump -r "rtmp://128.97.46.13/gss2012/" -a "gss2012/" -f "WIN 11,6,602,180" -W "https://www.ipam.ucla.edu/videoplayer/jwplayer.flash.swf" -p "https://www.ipam.ucla.edu/wowzavideo.aspx?vfn=10660.mp4&vfd=gss2012" -y "mp4:10660.mp4" -o "2013-05-03_10-41-38_mp4_10660.flv" -R

i have analyzed your uploaded file and it has only video keyframes saved at the problem point hence the slideshow effect. if you have also tried with latest git version + my patch file then only reason of corruption i can think of is some third party software messing up network traffic. pretty weird though.

your file:
http://pastebin.com/UQpU095B
My file:
http://pastebin.com/sHgLmrsi

[etiam]

Thank you for the analysis KSV!

Strange as it may seem, I get the problem under a lot of conditions.
To build, I cloned the git repository and applied the patch as per the instructions in "Customized rtmpdump binaries with patch file"
( http://stream-recorder.com/forum/customized-rtmpdump-binaries-patch-file-t16103.html )
I have tried make and make SHARED=(as suggested in http://list-archives.org/2012/12/12/rtmpdump-mplayerhq-hu/rtmpdump-segmentation-fault/f/1826750246)

I also tried make XLDFLAGS="-s -static", but that fails to compile with the following:
$ make XLDFLAGS="-s -static"
make[1]: Entering directory `/home/mirari/Desktop/rt2/rtmpdump/librtmp'
gcc -Wall -DRTMPDUMP_VERSION=\"v2.4\" -DUSE_OPENSSL -O2 -fPIC -c -o rtmp.o rtmp.c
rtmp.c: In function ‘RTMP_ReadPacket’:
rtmp.c:3954:7: warning: variable ‘didAlloc’ set but not used [-Wunused-but-set-variable]
gcc -Wall -DRTMPDUMP_VERSION=\"v2.4\" -DUSE_OPENSSL -O2 -fPIC -c -o log.o log.c
gcc -Wall -DRTMPDUMP_VERSION=\"v2.4\" -DUSE_OPENSSL -O2 -fPIC -c -o amf.o amf.c
gcc -Wall -DRTMPDUMP_VERSION=\"v2.4\" -DUSE_OPENSSL -O2 -fPIC -c -o hashswf.o hashswf.c
gcc -Wall -DRTMPDUMP_VERSION=\"v2.4\" -DUSE_OPENSSL -O2 -fPIC -c -o parseurl.o parseurl.c
ar rs librtmp.a rtmp.o log.o amf.o hashswf.o parseurl.o
ar: creating librtmp.a
gcc -shared -Wl,-soname,librtmp.so.0 -s -static -o librtmp.so.0 rtmp.o log.o amf.o hashswf.o parseurl.o -lssl -lcrypto -lz -lm
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.6/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [librtmp.so.0] Error 1
make[1]: Leaving directory `/home/mirari/Desktop/rt2/rtmpdump/librtmp'
make: *** [librtmp/librtmp.a] Error 2

In order to test if some third party software interferes with the network traffic, I made some space and installed Windows 7 in dual boot. I get similar results using the precompiled binaries from KSV:s archive on that system (except that there the image simply freezes on a frame in the ballpark of 70 seconds in and doesn't update at all). In the test on Windows 7 I simply reused the command from KSV:s post. On the Linux Mint 13 system I have tried my old command, the command from KSV:s post, and taking it from rtmpsrv again and adding -R.
It's probably not waterproof evidence, but at least it seems pretty unlikely that third party software on my own system is interfering both under the Linux system and the fresh Windows system.
I also tried on OpenSUSE in Virtualbox under the linux system, just to check if this could be an anomaly with Ubuntu-based distributions, but there the slideshow effect was present right from the start of the file.

I have pretty rudimentary skills with C and could well be making some mistake when compiling, but then again in this case there shouldn't be much to it but to run "make", right?
Would a poor transfer rate from the server explain this? I seem to be downloading in clearly less than real time (in spite of this being a 10Mbps connection, and UCLA probably have ample capacity at their end).

I'm really at a bit of a loss about how to continue here. Should I consider this a bug, and if so, who should be told, and what would they need to know?