Daniel Stenberg wrote:
> On Thu, 6 May 2010, Howard Chu wrote:
>
>> librtmp doesn't like non-blocking sockets; we normally just use a receive
>> timeout. So that's what I've done here; it would be rather painful to change
>> this behavior...
>
> The downside may not be that obvious or big, but it may hamper how good RTMP
> works together with other protocols when the multi interface is used. But I'm
> totally willing to go with whatever works now as it can always be improved in
> the future.

Sounds good. I'll think about how to make that work in librtmp down the road.

Some other obviously missing features from this patch
  - I haven't given any thought to how to integrate with the proxy support.
librtmp itself already supports socks4, but we should use the proxy settings
from the curl data if it's set. Also, rtmpt[e|s] variants that are tunneled in
HTTP ought to respect HTTP_PROXY settings and currently don't.
  - There's no resume support. The rtmpdump app has this feature, but it's not
present in the library. It would require some duplication of code to bring
that in here; we have to read backward from the tail of the file looking for
FLV packet headers to find the last keyframe in the file. For video streams
RTMP can only seek to keyframes. For audio-only streams I think we can seek to
any audio packet, but we still need to find the start of a packet. RTMP seeks
are based on packet timestamps, not byte offsets, so we can't just use the
offsets that libcurl provides.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html