Picture freezes (slideshow-like), in file downloaded from wowza-based streamingserver

[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...p4&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!GsUe9g...2t0rTQkv 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!N96RuBB93GAf2NpcQXqg73wdCCtLHevVOlTBUXh7yAU

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/cus...le-t16103.html )
I have tried

make

and

make SHARED=

(as suggested in http://list-archives.org/2012/12/12/...t/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?