rtmpdump: update to 2.4

[dargo@…]

2.4 adds support for RTMPE type 9 handshakes. this is needed for sites like hulu.

[ryandesign (Ryan Carsten Schmidt)]

I don't see any 2.4 distfile in their ​download directory.

[larryv (Lawrence Velázquez)]

As far as I can tell, v2.4 is only available in the git repo.

[dargo@…]

there's now a 2.4 source available. from their mailing list: ​http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-October/001664.html

looks like a lot of sites are using the type 10 handshake now, so we'll want a rtmpdump 2.5 as soon as it's released :-)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #32805.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dargo@…:

there's now a 2.4 source available. from their mailing list: ​http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-October/001664.html

Bizarre. The distfile is there. But it doesn't show up in the listing of that directory.

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

Attached is a Portfile patch and updated patchfiles to update to 2.4. Please evaluate and indicate whether it can be committed, or attach alternate patches.

Upstream now defines the library version number as 0; in our old patchfile, since upstream had not defined a library version number, we had set it the same as the program version number. Since with this update the library version number will change from 2.3 down (!) to 0, all ports linking with librtmpdump will need their revisions increased to force a rebuild.

Upstream changes in 2.4 include support for building OS X dylibs, and building the shared library by default (in addition to the static one) so some parts of the patchfiles were no longer necessary. Upstream neglected to use the -install_name argument when creating the dylib so I retained that from the old patch. I did not retain the -current_version and -compatibility_version arguments we were using in our old patch, because 0 is the default anyway, and I recall badness on Tiger when these arguments are set to zero. Upstream would be wise to select a library version number greater than zero.

Other dylib creation arguments in our old patchfile I did not retain are -Wl,-undefined, -Wl,dynamic_lookup, and -Wl,-single_module, because I do not know their purpose. Meanwhile, dylib creation arguments upstream is using that we were not using are -flat_namespace, -undefined suppress and -fno-common; I do not know their purpose either.

I retained the part of our patchfiles that changed the VERSION variable from e.g. "v2.4" to just "2.4". I do not know why we are doing this. I imagine it was at least partly to ease computation of the library version number; since we no longer compute the library version number, perhaps we can stop munging the VERSION.

Since this version's distfile does not show up in the directory listing, the livecheck still thinks 2.3 is the latest version. Upstream would be wise to fix their directory listing.

[falkoni@…]

Somebody please work on this, since yle-dl requires rtmpdump ≥ 2.4 to work.

Update: Ok. I went and applied the patch, installed rtmpdump 2.4 and it seems to work, at least with yle-dl. Tried this with Snow Leopard (10.6.8).

[sami.laine@…]

I agree with previous commentor. The portfile produced from diff in this ticket + additional two patch files produce a working binary. These files should be pushed to the repository in order to replace completely outdated 2.3 version (yle-dl is but one of the many scripts which require newer version).

Waiting for upstream to fix issues presented above is as smart as waiting for moon to turn into gold and drop into your pocket: as we all know, mplayer folks are notorious about how they handle things.

[larryv (Lawrence Velázquez)]

Oops.

[larryv (Lawrence Velázquez)]

Replying to ryandesign@…:

Upstream now defines the library version number as 0; in our old patchfile, since upstream had not defined a library version number, we had set it the same as the program version number. Since with this update the library version number will change from 2.3 down (!) to 0, all ports linking with librtmpdump will need their revisions increased to force a rebuild.

Which ports would require a revbump? port echo depends:rtmpdump doesn’t turn up anything for me.

[ryandesign (Ryan Carsten Schmidt)]

port echo depends:rtmpdump will only find ports that depend on rtmpdump in their default variants. To find ports that that might depend on it in a non-default variant, you can use port file all | sort -u | xargs grep :rtmpdump but that doesn't turn up any either. I guess we can update the port without needing to change any other ports.

[larryv (Lawrence Velázquez)]

Updated in r104380.