[asterisk-bugs] [Asterisk 0015484]: [branch] RTMP support in Asterisk

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15484 
====================================================================== 
Reported By:                phsultan
Assigned To:                phsultan
====================================================================== 
Project:                    Asterisk
Issue ID:                   15484
Category:                   Channels/NewFeature
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     ready for testing
Target Version:             1.8
Asterisk Version:           SVN 
JIRA:                       SWP-1477 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-07-10 07:30 CDT
Last Modified:              2010-07-23 13:26 CDT
====================================================================== 
Summary:                    [branch] RTMP support in Asterisk
Description: 
I created a new branch that implements Adobe's RTMP (Real Time Media
Protocol).

It allows Asterisk to connect as a client to an RTMP media server like
Red5 or FMS (Flash Media Server), and then publish or receive media streams
from such server. I only tested the connection with Red5.

To install the branch, you'll need several libavcodec, included in FFMPEG
version 0.6. Be careful to configure FFMPEG's sources with the
--enable-shared option activated in the configure script.

Prior to install Asterisk, you need to have librtmp on your system.
librtmp is part of the rtmpdump program : http://rtmpdump.mplayerhq.hu/

To install it :
# wget http://rtmpdump.mplayerhq.hu/download/rtmpdump-2.2e.tar.gz [^]
# tar zxvf rtmpdump-2.2e.tar.gz
# cd rtmpdump-2.2e/
# make
# make install

To install Asterisk :
# svn co http://svn.digium.com/svn/asterisk/team/phsultan/rtmp-support
asterisk-rtmp
# cd asterisk-rtmp
# ./configure
# make menuselect
[check here that chan_rtmp is eligible for installation]
# make
# make install
====================================================================== 

---------------------------------------------------------------------- 
 (0124923) jtodd (administrator) - 2010-07-23 13:26
 https://issues.asterisk.org/view.php?id=15484#c124923 
---------------------------------------------------------------------- 
OK!  When I remove all codecs from Eyebeam except for H.263-1998, it works.
 I get video and audio!  But then eyebeam crashes.  :-)  But that's not
your problem.   It needs to have the video window open at the start of the
call, or it will not start video after the audio track has started. 
Putting a video call on hold stops the audio and video, but only re-starts
audio after un-holding (which I assume is related to the prior sentence.) 

 The audio frequently becomes un-synchronized with the video, and I know
that's going to be a big problem... or is it?  Is there any way to use RTCP
to know when video and audio streams are out of sync?  Could it be possible
to artificially pause audio frames for a certain period of time until the
video catches up?  Honestly, I don't know what RTCP feeds back in enough
detail to say if this is possible.  I'd say not to worry about that right
now, right?  :-)

Video quality is terrible. ;-)


I get these messages consistently on the file-based version, at the same
spot (about 20? seconds in):
[h263 @ 0xd459ee0]encoded frame too large

...and sporadically on the stream-based versions.  On the file-based
version, eyebeam crashes, every time, right after that error message
appears on the Asterisk console.  On the stream-based versions, eyebeam
only sporadically crashes after that message appears.  I have only
experimented about 5 times, so this is not 100% certain.


 Audio is a bit "clicky" and has a vibrating sound going through it.  This
is quite distracting.  I've tried different codecs on eyebeam (G.711 A,
G.711 U, and GSM) and it's the same result, and consistently in the same
places in the soundtrack, which makes me think this is a systemic problem. 
I am running both the Linux/Asterisk instance (VMWare) and Eyebeam on the
same dual-core machine, so maybe that's the problem. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-23 13:26 jtodd          Note Added: 0124923                          
======================================================================