On Wed, Oct 24, 2012 at 12:10 AM, Steven Penny <svnpenn@gmail.com> wrote:
On Tue, Oct 23, 2012 at 11:39 PM, NhJm wrote:
>> -               /* skip extension */
>> -               if (subExt && p == ext) {
>> -                       p += 4;
>> -                       pplen -= 4;
>> -                       continue;
>> -               }
>
> Please be careful not to break things.

If you are certain this is an error, please state as such. In the mean time I
will assume it is and check it.

rtmpdump's current behavior is to translate "blah.mp4?foo" into "mp4:blah?foo". By removing this piece of code, rtmpdump will instead generate "mp4:blah.mp4?foo"

> Anyways, the proper behavior is to actually *NOT* do any urldecoding. The
> %xx should be sent to the server as-is.

This has not been my experience. Admittedly I have only been testing with that
one server, but it is not accepting encoded characters. Notice carefully the
literal newlines in the first example.

The official Flash Player does not urldecode the path like rtmpdump is currently doing to part of the URL.

Using http://support.akamai.com/flash/ to test

rtmp://cp67126.edgefcs.net/on%64emand/mp4:mediapm/ovp/content/test/video/spacealone%68d_sounas_640_300.mp4
(random letters in the app and playpath have been urlencoded)

results in the characters being sent as-is: http://i.imgur.com/wBxp4.png

Also note that the weird stream you're testing will accept spaces in addition to line breaks, so this whole urlencoding issue is easy to avoid for that stream:

rtmpdump -r "rtmp://freeview.fms.visionip.tv/live/tvnetwork-hellenictv-sigma-hsslive-25f-4x3-SDh " --live
(In case the previous line gets broken up: there is a space between SDh and the quotation mark.)