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

[Eric Burger <[e-mail]>]

I think this means we agree: since the Media Server already knows the structure of the container format and codec, and the Media Server knows what the very semantics of "append" means for the container and codec, that we should leave it up to the Media Server to decide. So long as on the other side it is just stock, RFC 2616 HTTP, I think we should be fine.

On Oct 12, 2010, at 4:08 PM, Steve Liao wrote:

> On the contrary, I believe we can run into media file viability problems if we mandate mapping append=true to HTTP POST.  As Stephane and Lorenzo stated, adding to a media file oftentimes requires detailed knowledge of the media format and oftentimes cannot be accomplished by simply adding bytes to the end of an existing file.
> 
> While it's quite conceivable for a Media Server to perform the container format conversions and/or transcodings as necessary to append media, this capability is not necessarily available on an HTTP server.
> 
> Therefore, how the Media Server provides append=true should be left up to implementation, so long as it satisfies the requirement of append=true resulting in a media file that properly incorporates the new media.
> 
> Regards,
> Steve
> 
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Eric Burger [[e-mail]]
> Sent: Tuesday, October 12, 2010 5:39 AM
> To: [e-mail]
> Subject: Re: [MEDIACTRL] ISSUE 4 - IVR Package - <record> append
> 
> 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.)
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl