Summary:	ASTERISK-06535: I have added a time-compressed recording & catchup mode to app_meetme.c - should I submit it?
Reporter:	Andrew Pollack (andrewjaypollack)	Labels:
Date Opened:	2006-03-15 23:57:05.000-0600	Date Closed:	2011-06-07 14:03:25
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_meetme
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Now that I've gotten my managed code wrapper for the iaxclient library working, I'm taking the next steps. One of the things I've wanted to do for a while is record a conference is 'time compressed' mode -- meaning that any spaces where people are not speaking are left out.  This is useful for what I call "catch-up mode".  It has particular importance for me, but I wanted to ask if it has importance to anyone else. The way I've chosen to impliment it is as follows: 1.  An optional "R" flag  -- so far used in addition to the regular "r" flag but that seems redundant to me turns the basic mode on. When this is set, any time there is no user currently in the conference marked as "talking"  --  which means the user is making noise, and the user was marked when he entered the conference as someone who is being monitored for talking -- the stream of recording data is simply paused.  The stream simply does not get written to the file.  Everything else works as you would expect of the current MeetMe application. 2.  A further optional channel variable ${MEETME_LIVECATCHUPDIR} performs a new bit of magic, let me 'splain. Normally, it doesn't work out well if you try to play a file while it is being recorded in another thread.  I suppose you could do some kind of buffering but its an ugly hack at best.  I know, I've tried.  For catch up mode to work properly, you need to be able to play the audio that's transpired up to this point before putting the user in the conference. If set, this variable will mean that every time my additional code in app_meetme "pauses" for silence it quickly closes the current recording file and renames it to this directory with a numeric prefix indicating the counter of how many of these 'sub files' have been created.   It also resets the flags in the recording thread so that the very next thing that thread does is open a new file with the originally requested name as if it were just starting up from scratch.   When someone talks, the code jumps out of this "paused" mode and the streaming data is written to the new file just as if it had always been open. Now, when a user is on the way to the conference, I can use a quick AGI script (mine is a bash shell script) which reads the contents of that directory and queues up the list of files in order through the playback or background commands. Obviously you'd want some kind of scheduled job to clean up the directory -- concatonating the files older than whatever time you decided is no longer important and moving that archive off to somewhere else.   There are a thousand reasons to do this and as many ways to handle it. --------------------- Comments? ****** ADDITIONAL INFORMATION ****** The questions I expect: 1)  Why not concatonate the files right inside the thread, then you only need one additional file name? Because that would be potentially slow, as it moves lots of bytes.  Simply closing and renaming a file is a very minimal system impact AND HAPPENS WHEN THERE IS NOBODY TALKING.  The cleanup, if you need it, should be done at a time you specify and out of the thread loop of the meetme application -- which is already rushing to keep up with all it has to do. 2)  Won't looping through all those users for each frame to see who's talking slow down the recording thread? 99% of the time the same person is talking that was talking the last time.  For this reason, a pointer to the last user who was talking is kept locally.  Before looking to see who may be talking, the code checks the last user who was talking to see if they still are.  This then, is a single integer comparison.   If that person is not talking, then a loop through the users happens -- however even then we're talking about a single comparison of integer values for each user in the conference.  Even at a thousand users in conference, this would be an eye-blink on most machines, and again, should happen only when there is a pause in the talking.  It also takes no i/o operation. 3) How do you tell if a user is talking? I cheated -- I'm using the routines already in app_meetme.c which seem to call other places to figure it out.  I figure its best to use the standard way of doing this when at all possible.  It looks like the existing code takes into account a minimum silence duration and the other kinds of things which should be considered. 4)  Why didn't you just ______________________ ? Look, this is my first look at the code.  Today was the first day I actually starting reading the app_meetme.c file in any serious way.  In the past, I've looked at Asterisk source code maybe twice or three times without more than a few minutes.  To add to that, I haven't written anything in C++ since 1992 -- and I wasn't very good at it then.  If I've missed something in the code that already does this just fine, forgive me -- or better yet, point it out. 5)  Can you just svn me up a copy of the diff? Uh, maybe.  Remember that whole 1992 since I did this kind of work thing?  I've used svn and cvs to pull code, but that's about it.  My work is normally in other areas.  I'll read the FAQ on submitting code and diffs and things and see if I can't play the game correctly. -----------------------
Comments:	By: Andrew Pollack (andrewjaypollack) 2006-03-16 11:21:27.000-0600 A disclaimer has now been sent. By: Andrew Pollack (andrewjaypollack) 2006-03-16 12:42:02.000-0600 A few people have asked me "Why" I'd want to do this as it would tend to make the information hard to listen to. Please think for a moment of a conference call in a somewhat more asynchronous way.  A motion activated video camera recording system, for example, ads no value to feature length movies.  If you need to know who went through the door in the last 20 minutes however, looking at that output from that motion activated camera will save you the time form 20 minutes to about 20 seconds. By: Andrew Pollack (andrewjaypollack) 2006-03-17 16:14:15.000-0600 Ok, well.  I guess nobody wants this.  That's why I asked.  It will be useful to me regardless.  I'll just package the code up in such a way as to be an easy application to the existing trunk each time I upgrade. By: Olle Johansson (oej) 2006-03-17 16:23:30.000-0600 Just one day since you opened this and you already give up? Please mail the mailing list if you want to discuss this. The bug tracker is *not* a good discussion forum, so don't expect fast answers :-) Please have some patience :-) /Olle By: Andrew Pollack (andrewjaypollack) 2006-03-17 19:02:56.000-0600 Ok, will do.  I'm new to these tools.  Thanks. By: Jared Smith (jsmith) 2006-03-20 12:48:29.000-0600 Can you please provide a patch?  (If you're not sure how, let us know and we'll point you in the right direction.) Also, can you try to provide a patch against the development (TRUNK) version of Asterisk?  New features are only added to the development version, not to the release (1.2.x) versions of Asterisk. By: Serge Vecher (serge-v) 2006-05-03 13:34:02 is there a patch here? By: Serge Vecher (serge-v) 2006-05-17 10:30:13 AndrewJayPollack: I'm suspending this for now. Please reopen when you are ready with the patch. Thank you.