[MPlayer-dev-eng] rtmpe support

[Howard Chu]

Reimar Döffinger wrote:
> On Thu, Mar 11, 2010 at 11:27:57PM -0800, Howard Chu wrote:
>> I've written the attached module to let mplayer use rtmpdump's
>> librtmp. Unfortunately, I don't see how to pass in the necessary
>> options, mplayer.c always calls open_stream() with options==NULL, so
>> there doesn't seem to be any way to pass stream options in from the
>> command line. Note that just adding options to the main URL would be
>> extremely ugly, since RTMP URLs can be pretty long to begin with,
>> and typically 2-3 other very long URLs are also needed. E.g., to
>> play this movie from Youtube (actually crackle.com) we have to
>> supply these URLs:
>>    main: rtmpe://cdn-auth.akamai.crackle.com/ondemand/crackle/1/n/sk/6dpvb_306p.mp4
>>    swfUrl: http://crackle.com/flash/CracklePlayer.swf?id=2419511&site=219
>>    pageUrl: http://www.youtube.com/watch?v=yPeNnReBK0A&feature=spotlight
>>
>> Any suggestions?
>
> We already have rtmp support via libavformat, do we really need yet another implementation
> instead of improving what already exists and all other media players can profit from?

That's a fair question, and one that I considered for a long time, from many 
angles, before deciding to write this submission.

Given that the existing RTMP support didn't work at all for me, testing 
against an rtmplite server, it kinda tells me that the libavformat code leaves 
quite a lot of room for improvement. Whether that's a problem in the actual 
libavformat implementation, or in the mplayer interface, I wasn't sure at 
first, but after many hours of investigation it appears to be both.

Since the libavformat implementation is relatively incomplete and immature, it 
doesn't seem to be worth the time and effort to bring it up to par in terms of 
functionality or efficiency. It might still be worthwhile to write a 
libavformat wrapper for librtmp, but I figured there were too many moving 
parts clouding the picture. I decided to go straight into mplayer because then 
it would be easier to pinpoint any problems that arose. As it is, getting the 
first version of the code working took less time than it has taken me to 
compose this email. (Of course, getting Seeks working is still an open 
question but it sounds like uau has a fix for that now.)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/