patch for video display on chan_oss.c

A student of mine, Sergio Fadda (in Cc), came up with a
preliminary patch to
receive video on chan_oss (in fact the original code was
developed
on chan_alsa so it should be relatively straightforward to
port to it),
so i am attaching it in case people are interested to give
it a try.

At the moment it only works with h263plus video (e.g. one
of
the formats supported by linphone, and possibly ekiga as
well).

In addition to chan_oss, you need to:

+ have SDL and ffmpeg installed (no autoconf support yet);
+ have a recent trunk (77023) or at least update main/rtp.c
as in

	http://svn.digium.com/view/asterisk?view=rev&
revision=77023

+ manually patch the top level Makefile as descrived in
chan_oss.c
  to add these lines near the main 'all:' target:

	# GCC configuration flags for SDL library
	ASTCFLAGS+=`sdl-config --cflags`
	# Add library for ffmpeg and SDL lib.
	SOLINK+=-lavcodec -lz -lm -g `sdl-config --libs`

+ add the following to your sip.conf

        [general](+) 
                allow=h263p


+ apply this patch to main/rtp.c (there are probably ways
to
  achieve the same through the config files but i have no
idea how):

 -1509,5
+1511,6 
        [31] = {1, AST_FORMAT_H261},
        [34] = {1, AST_FORMAT_H263},
        [97] = {1, AST_FORMAT_ILBC},
+       [98] = {1, AST_FORMAT_H263_PLUS},
        [99] = {1, AST_FORMAT_H264},
        [101] = {0, AST_RTP_DTMF},
        [102] = {1, AST_FORMAT_T140},   /* Real time text
chat */
        [103] = {1, AST_FORMAT_H263_PLUS},

+ have an entry in your dialplan that ponts to your console
e.g.

	exten => 999,1,Dial(Console/dsp)


Once done this, answering an incoming call should create a
window to
display the incoming video. Or you can call a video-enabled
phone
and receive the video stream.
There are known issues e.g. if you do a 'console hangup'
while the
video is displayed, it won't close well and probably crash
asterisk.
You better close the call on the remote end.

We are working on webcam support to actually produce a video
stream.

	cheers
	luigi

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Luigi Rizzo wrote:
> + have SDL and ffmpeg installed (no autoconf support
yet);

Just in case anyone else was curious about the licensing of
these libraries, 
I'll include it here since I just looked it up.

libsdl: LGPL

ffmpeg: mostly LGPL, but contains some GPL components
(libpostproc and 
libswscale).  If they get used, then the GPL applies to all
of ffmpeg.

So, assuming that this can be done without requiring the GPL
components of 
ffmpeg, this is something that we could eventually include
in the main Asterisk 
distribution, which is pretty awesome.  

-- 
Russell Bryant
Software Engineer
Digium, Inc.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Wed, Jul 25, 2007 at 05:03:30PM -0400, Russell Bryant
wrote:
> Luigi Rizzo wrote:
> > + have SDL and ffmpeg installed (no autoconf
support yet);
> 
> Just in case anyone else was curious about the
licensing of these libraries, 
> I'll include it here since I just looked it up.
> 
> libsdl: LGPL
> 
> ffmpeg: mostly LGPL, but contains some GPL components
(libpostproc and 
> libswscale).  If they get used, then the GPL applies to
all of ffmpeg.

i don't think we use any of these parts (we really use the
basic codec stuff).

> So, assuming that this can be done without requiring
the GPL components of 
> ffmpeg, this is something that we could eventually
include in the main Asterisk 
> distribution, which is pretty awesome.  

even more awesome is the fact that if you don't have X,
ffmpeg will try
to use aalib to render the output... which at videoconf
resolutions
is not _that_ unreasonable...

BTW what's the status of your effort on chan_console so
we can possibly avoid duplicating the functionality in
alsa/oss ?

cheers
luigi

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Russell Bryant wrote:
> So, assuming that this can be done without requiring
the GPL components of 
> ffmpeg, this is something that we could eventually
include in the main Asterisk 
> distribution, which is pretty awesome.  

Also, let me explicitly state that this opinion is not
officially endorsed by 
Digium, Inc.    There are
also patent issues involved with various video 
codecs, so I am in no position to make an official decision
on this matter.

-- 
Russell Bryant
Software Engineer
Digium, Inc.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Luigi Rizzo wrote:
> even more awesome is the fact that if you don't have X,
ffmpeg will try
> to use aalib to render the output... which at videoconf
resolutions
> is not _that_ unreasonable...

That is actually pretty hilarious.  

> BTW what's the status of your effort on chan_console
so
> we can possibly avoid duplicating the functionality in
alsa/oss ?

The only functionality that chan_console has that chan_alsa
or chan_oss do not 
have is the ability to support the Mac sound system (core
audio), and a number 
of others which aren't as applicable to Asterisk.  (It uses
libportaudio).  I 
copied a lot of code from chan_oss, so the code is pretty
similar to that.

It works well enough for my personal use, but it could
eventually become the 
single console channel driver with some more effort.

Here is a list of what features alsa/oss have that
chan_console does not:

* Multiple device support
* Setting auto-answer from the dialplan
* Some CLI commands: flash, transfer, autoanswer, boost,
active

In addition to matching all of the existing functionality,
here are some more 
things that I wanted to do before I considered it
trunk-worthy:

* Remove the uses of busy.h, ringtone.h, etc.  Asterisk has
an API for 
generating these tones on a channel, and it seems to make
more sense to use that 
instead of doing it manually.  The API is in indications.h. 
Another benefit of 
using this API is that it can use localized tones instead of
the ones hard coded 
into the header file.

* There is some special handling for the write_buf to ensure
that packets of 
audio are written to the audio device in 160 sample chunks. 
There is an API for 
this, as well.  It is the ast_smoother API defined in
frame.h.  Unfortunately, 
the API is almost completely undocumented.  However, it
should help simplify the 
code a bit.

* I need to go back and better document some deadlock
avoidance code I added to 
the console_hangup() function, because it isn't obvious to
me why it was needed, 
and it has been long enough to where I have forgotten.

-- 
Russell Bryant
Software Engineer
Digium, Inc.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

The asterisk-video mailing list is a good list to discuss
video- 
related development.

/O

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev