Patch for rtmpdump/librtmp

On the assumption that lightning doesn't strike twice in the same spot, reposting this thread that was lost last time 'round... (from google cache)

highlandsun 2010-03-10 22:05 Wrote:I've posted a patch to adapt DVDInputStreamRTMP to use rtmpdump's librtmp instead of the current libRTMP.

http://trac.xbmc.org/ticket/8971

This adds support for SWF Verification, encrypted streams, etc. etc...

exobuzz 2010-03-10 23:37 Wrote:Nice work.

I was looking at this last night - you saved me some work . Now we just need to either associate a url of a player with a listitem from python or add a new python function to get the hash and then associate that with each item.

Or you have other ideas ?

highlandsun 2010-03-11 01:07 Wrote:librtmp will compute the hash automatically. You just have to tell it to do so by setting the SWFVerify boolean property in your stream item. Search for "SWFVerify" in the patch, you'll see it. (The player URL is already being provided in another item property, that's always been in there.)

exobuzz 2010-03-11 01:29 Wrote:aha i see. Thanks.

highlandsun 2010-03-11 02:00 Wrote:If you haven't already, you should grab the current code in rtmpdump svn HEAD. Read the rtmpdump(1) manpage, that will give you a better idea of what's going on. I've also posted a copy of the manpage here

http://rtmpdump.mplayerhq.hu/rtmpdump.1.html

I'm having the same issue exobuzz identified in Trac.

I have the following setup...

rtmpdump/trunk : rev 396
xbmc/trunk : rev 28256

Applied your patch and tested as follows...

1) tried IPlayer stream, with no modification to SWFVerification property - rtmpdump reports SWFVerification will not be used. Stream plays for around 1 minute then terminates as expected (although a crash due to 'double free' occurs.
2) Modified patch to ignore SWFVerification property (still using SWFPlayer : http://www.bbc.co.uk/emp/9player.swf?rev...0344_10753) - I get the RTMP_ReadPacket, failed to read RTMP packet header error.

Any thoughts on this?

As I noted in the trac item, you need xbmc revision 28276, not 28256.

What do you mean by "modified patch to ignore swfverification property" ?

If you want this to work with iPlayer you have to set the SWFVerify property to "true".

Would this patch make the justin.tv plugin viable again?

Dunno anything about justin.tv or its plugin. Why did it stop working?

Possibly it will help; I revived the Hulu plugin (but that needed a lot of scraping/parsing fixes in addition to this patch).

highlandsun Wrote:Dunno anything about justin.tv or its plugin. Why did it stop working?

Possibly it will help; I revived the Hulu plugin (but that needed a lot of scraping/parsing fixes in addition to this patch).

Some sort of DRM on the SWF now for justin.tv

highlandsun Wrote:As I noted in the trac item, you need xbmc revision 28276, not 28256.

What do you mean by "modified patch to ignore swfverification property" ?

If you want this to work with iPlayer you have to set the SWFVerify property to "true".

I suspect what Jackanddougal means is that a switchable SWFVerify property is largely redundant since it could be assumed to be always necessary...

If you assume swf verification is always a possibility in any stream, then if you receive a request for verification for the stream, you send the response, if you don't, you don't.

WRT the revisions, I don't see anything between those two revision numbers which would make any difference to this.

spicemuseum Wrote:I suspect what Jackanddougal means is that a switchable SWFVerify property is largely redundant since it could be assumed to be always necessary...

If you assume swf verification is always a possibility in any stream, then if you receive a request for verification for the stream, you send the response, if you don't, you don't.

WRT the revisions, I don't see anything between those two revision numbers which would make any difference to this.

Certainly; even if you turn on the swfverify option, it will only be used upon request from the server. But the reason not to always generate the hash information by default is that sometimes this has a significant cost in execution time. I.e., you have to fetch the SWF using http, decompress it, and then calculate the hash. It's better not to go through all of that hassle if you know the server won't request it. (Even though all of this hassle is hidden inside librtmp, so it's no big deal to activate it, it still can mean a noticeable delay before a stream can actually be opened and processed.)

Patch updated. Option handling is now delegated completely to librtmp, since we add new options frequently. Also, the ffmpeg team has now merged support for librtmp, and is using the new option mechanism as well. This approach will allow RTMP URLs and options to be specified uniformly across ffmpeg, mplayer, XBMC, and any other apps that use librtmp.

The old XBMC RTMP options are still supported, but new options can only be specified using the new mechanism. See the trac item for an example.

Just to re-cap - this is what I do to build XBMC with this patch...

1. start with XBMC svn r28276
2. apply the patches from http://trac.xbmc.org/ticket/8971
3. move the old xbmc/xbmc/libRTMP out of the way
4. put rtmpdump librtmp into xbmc/xbmc/libRTMP
5. configure and make as usual
   

You'll also need to apply this patch to ffmpeg to get RTMP seek working:
https://lists.mplayerhq.hu/pipermail/ffm...28885.html

If you're building on Debian or Ubuntu, you should probably build librtmp first, with "make CRYPTO=GNUTLS", that will keep the process size smaller. (Since a lot of their system libraries are already built with GnuTLS, it's a waste of space to build librtmp using OpenSSL.)

Last I checked, the patches also work with current XBMC SVN trunk, but I'm not using that since I don't know how the new plugin/addon system is supposed to work yet...