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/cus...le-t16103.html )
I have tried
and
(as suggested in
http://list-archives.org/2012/12/12/...t/f/1826750246)
I also tried
Code:
make XLDFLAGS="-s -static"
, but that fails to compile with the following:
Code:
$ 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?