unusual streaming (RTMPT, port:80) www.tvs.pl

[any ANONYMOUS forum user]

running now 2 Blader testdrives with "live video" checked.
testrun1: "*.mp4", 170 MB (178.714.780 Bytes), crc32:364B9E1B (MediaInfo says "Flash Video", so we need to rename to *.flv!).
testrun2: "*.mp4", 170 MB (178.714.780 Bytes), crc32:364B9E1B



this perfect result (compare with rtmpdump results) should not surprise. afaik, Blader's download engine is rtmpdump.exe. So in a way, blader is a GUI for rtmpdump!

(.......)

So how do i know that i need to use "Live" switch (in rtmpdump, in RMC4, in Blader)? the video isnt live! it is a static MP4 file on the Polish server

[chap]

any ANONYMOUS forum user

it is a static MP4 file on the Polish server

Yes, but the fact remains.

[placebo]

Verdict:
Apparently the RTMPT stream is still a challenge to many software coders (Replay Media Catcher 4, HiDownload, NetTransport, GetFLV, Jaksta, ..). Only RTMPDUMP produced 100% perfect results (see above), and also Blader which uses rtmpdump as download engine. Here is the ranking (as of early May, 2011) with big thanks to chap, KSV (for the updated rtmpdump.exe's) and nullacht (who was right from the very beginning!):

shared 1st prize: rtmpdump. file size is reproducibly 170MB, and video can be played back smoothly (with no audible defects in VLC media player). The FLV itself is perfect as is, and certainly does not need any fixing.
shared 1st prize: Blader. downloads reproducibly the same file as RTMPDUMP. just rename from *.MP4 to *.FLV!
2nd prize: Replay Media Catcher 4 (or Jaksta). file size is reproducibly 170MB, downloaded *.FLV-file requires heavy fixing ("Fix duration" + "Fix Time"), and even after that the FLV is not perfect (e.g. wrong duration, wrong file size&crc32)! after all the video can be played back smoothly (with minimal audible defects in VLC media player), so why complain?
3rd prize: HiDownload. 2 test drives, 2 wrong file sizes (350-370MB). video plays smoothly in all players. no sign of videographic or audible corruption.
pending: GetFLV. (GFLV Team promised to include RTMPT support in some future versions/updates of their product. fingers crossed!)

IMPORTANT TO NOTE:
the raw media data (*.aac, *.264) contained in the *.FLV-files downloaded by RMC4 vs. Blader vs. rtmpdump vs. Jaksta are 100% identically the same (crc32 codes). You can verify this fact by extracting the raw data with FLVExtract. Knowing the "videoframerate" to be "15" (How do we know? ), you can then use Yamb to combine the audio and video raw data to package them in a perfect MP4-file ("to remux"). Keeping/saving MP4-files (instead of FLV-files) is always the preferred or recommended procedure anyway.

[placebo]

Originally Posted by placebo

pending: GetFLV. (GFLV Team promised to include RTMPT support in some future versions/updates of their product. fingers crossed!)

Originally Posted by getflv

Update of GetFLV v9.0.2.5 (2011.6.28)

1.Added RTMPT stream capture. GetFLV can download some rtmpt video sites now.

URL downloaded by GFLV:
rtmp://streaming.tvs.pl:80/vod

, ,

testrun1: 170 MB (179.052.491 Bytes), crc32:217B00F4
testrun2: 170 MB (178.714.800 Bytes), crc32:5761D947

*.264 extracted from FLV:
145 MB (153.048.174 Bytes), crc32:3E8817DC
145 MB (152.758.084 Bytes), crc32:51E6B270

Perfect playback, no stuttering, no artefacts. Reproducible download results. Perfect, congrats getflv!!

Note: since the FLV plays perfectly (incl. display of total time length, and seeking), the file doesnt need to be "fixed". perfectionists still would want to fix it since the total time length is NOT displayed by MediaInfo (see right screenshot). People who dont own MediaInfo would not know whether rtmpdump/CooJah + Blader produced the better download result or GFLV. therefore, in the ranking, GFLV shares the 1st prize with rtmpdump/blader. I'm serious

Here is some interesting info from the developer of Replay Media Catcher 4:

I have had a look into this further. It is not our handling of RTMPT that is the issue but of how we treat timestamps for MP4 streams that is the issue.

When adobe first started to support MP4 files, there was issues with the timestamps that were sent. For more info see http://www.kaourantin.net/2007/08/wh...on-web_20.html

My code contains a hack to work around this when an MP4 RTMP stream is detected, so that the file would play back correctly. When this hack is disabled this RTMPT download plays back correctly. Other sites though such as MetOpera that also stream RTMP MP4 playback fine whether this hack is in use or not. Im not sure why that is the case except that MetOpera is a much higher bitrate and perhaps therefore it is not noticable.

rtmpdump does not contain the hack as it arrived on the scene well after Adobe supported MP4 streams correctly.

Do you know any other RTMP/RTMPT MP4 streams to test against?
RMC (Jaksta) prints out in the progress logs when it is an MP4 stream.