Re: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append

[Eric Burger <[e-mail]>]

Will we run into interoperability problems if this is implementation-dependent? My guess is if it is up to the media server, the media server already knows the current file format and codec, so should also be able to know if it can just add bytes to the end of the current file or if it has to suck down the whole thing, repackage, and send it back.

On Oct 9, 2010, at 7:58 AM, Stéphane Bastien wrote:

> Hi,
> 
> Just appending data to the end of media files work for some audio file formats, but fails for common file formats such as MOV, 3GP, and MP4. (Even appending audio to a WAV file fails unless you modify the WAV header - which means that the HTTP server handling the POST must know how to do this.) And as Lorenzo mentions in another e-mail, how can the HTTP POST deal with issues such as the first part of a recording is in one codec, while the remainder of the recording is using some other codec. This is just one more failure mode when using plain HTTP POST for appending.
> 
> I strongly recommend that we leave the appending mechanism as an implementation-specific issue in the spec.
> 
> Stéphane
> 
> Le 2010-10-08 à 20:09, Victor Paulsamy a écrit :
> 
>> 2010/10/8 Lorenzo Miniero <[e-mail]>
>> I agree with Stephane, appending to a media file is not like appending
>> text and so a "brutal" POST might result in a corrupted file.
>> 
>>  
>> Are you anticipating corruption or have you encountered it?
>> 
>> In my testing, during the last 8-months or so, append works like a charm -- even under load; I'm yet to run into recorded media corruption. We download files only for playback. Recorded media are transferred to remote (HTTP or NFS) storage, in chunks of about 40-ms audio, without storing it onboard (append is heavily used.)