Re: Review requested: audio/atrac3 media type registration
Hi, On 2/27/08, actech <actech@jp.sony.com> wrote:
Hi Mark,
We think it is very useful that the all of decoding parameters are available before decoding, without any parsing of payload data. For example, if the receiver has only 48000Hz D/A clock, the receiver can activate sampling rate converter before 44100Hz decoding, or send back decoder capability(refusal of 44100Hz streaming) to sender side in SDP offer-answer exchange.
In addition, we made a discuss with AVT chair that also ATRAC3 media type registration should have a bit-rate parameter even if it can be only 44100, considering the consistency that ATRAC-X and ATRAC Advanced Lossless media type have bit-rate parameter.
Ok, so there seems to be some kind of generic processing model here. Can you describe how that works? I ask because I'm trying to figure out a) how a recipient should interpret the content when either a required parameter is missing or ATRAC3 content is transferred with an ATRAC media type, and b) if the generic processing model is of a variety that might benefit from a "+atrac" extension on media type names similar to "+xml" for XML content. Keep in mind I know nothing about audio formats. Thanks. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Hi Mark, We think that the proper streaming of ATRAC will be realized by using SDP assuming that: - Initializing audio decoder instance by "Media Type name : audio" - If the "Media Subtype name" is one of the {atrac3, atrac-x, atrac-advanced-lossless}, activating corresponding decoder. Otherwise, the session will be closed. - If the Parameter "rate" is not identical to D/A clock in the system, and if the sampling rate converter instance is available with the conversion ratio calculated by [D/A clock/rate parameter], it will be activated and start conversion task between decoder output and D/A converter input. In case of missing of required parameter, or ATRAC media type, ATRAC streaming session can not be started. The situation is exceptional, and it is out of scope in our ATRAC payload format document. As you say, the above processing may also be realized by +atrac extension for particuler purpose, but our scope is more generic, and described for lower level negotiation at the beginning of the normal ATRAC streaming. Best Regards,
Hi,
On 2/27/08, actech <actech@jp.sony.com> wrote:
Hi Mark,
We think it is very useful that the all of decoding parameters are available before decoding, without any parsing of payload data. For example, if the receiver has only 48000Hz D/A clock, the receiver can activate sampling rate converter before 44100Hz decoding, or send back decoder capability(refusal of 44100Hz streaming) to sender side in SDP offer-answer exchange.
In addition, we made a discuss with AVT chair that also ATRAC3 media type registration should have a bit-rate parameter even if it can be only 44100, considering the consistency that ATRAC-X and ATRAC Advanced Lossless media type have bit-rate parameter.
Ok, so there seems to be some kind of generic processing model here. Can you describe how that works? I ask because I'm trying to figure out a) how a recipient should interpret the content when either a required parameter is missing or ATRAC3 content is transferred with an ATRAC media type, and b) if the generic processing model is of a variety that might benefit from a "+atrac" extension on media type names similar to "+xml" for XML content.
Keep in mind I know nothing about audio formats.
Thanks.
Mark.
Hi, On 2/29/08, actech <actech@jp.sony.com> wrote:
In case of missing of required parameter, or ATRAC media type, ATRAC streaming session can not be started. The situation is exceptional, and it is out of scope in our ATRAC payload format document.
But if the media type was atrac3, then it could be started because rate=44100 could be assumed, no? Or is the generic processing model independent of the media type? I guess a spec would be required for me to check that 8-)
As you say, the above processing may also be realized by +atrac extension for particuler purpose, but our scope is more generic, and described for lower level negotiation at the beginning of the normal ATRAC streaming.
Ok. Plus the other legacy media types obviously can't be retrofitted with +atrac. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
One thing I should point out is what RFC 4855 says about the rate parameter: <quote> 2. Procedure For Registering Media Types for RTP Payload Types ... Required parameters: If the payload format does not have a fixed RTP timestamp clock rate, then a "rate" parameter is required to specify the RTP timestamp clock rate. ... </quote> So the "rate" parameter is not essential in this particular case. I would qualify this by saying that I should review correspondence Colin had with the authors to see if it covered this. Mark Baker wrote:
Hi,
On 2/29/08, actech <actech@jp.sony.com> wrote:
In case of missing of required parameter, or ATRAC media type, ATRAC streaming session can not be started. The situation is exceptional, and it is out of scope in our ATRAC payload format document.
But if the media type was atrac3, then it could be started because rate=44100 could be assumed, no? Or is the generic processing model independent of the media type? I guess a spec would be required for me to check that 8-)
As you say, the above processing may also be realized by +atrac extension for particuler purpose, but our scope is more generic, and described for lower level negotiation at the beginning of the normal ATRAC streaming.
Ok. Plus the other legacy media types obviously can't be retrofitted with +atrac.
Mark.
Tom, Mark, The rate parameter is clearly redundant for this media type, since the ATRAC3 codec only supports one rate. If having a required parameter with only one legal value is a problem -- which it hasn't been for some other formats -- then it can be removed. The reason I suggested it be included, however, is that this media type will frequently be used with SDP signalling. SDP requires that the rate parameter be present. Rather than special-case the SDP processing code to generate the rate parameter based on knowledge of the media type, it seemed simpler to provide the parameter, even when its value is fixed for this code. Colin On 7 Mar 2008, at 03:53, Tom Taylor wrote:
One thing I should point out is what RFC 4855 says about the rate parameter:
<quote>
2. Procedure For Registering Media Types for RTP Payload Types ... Required parameters: If the payload format does not have a fixed RTP timestamp clock rate, then a "rate" parameter is required to specify the RTP timestamp clock rate. ...
</quote>
So the "rate" parameter is not essential in this particular case.
I would qualify this by saying that I should review correspondence Colin had with the authors to see if it covered this.
Mark Baker wrote:
Hi, On 2/29/08, actech <actech@jp.sony.com> wrote:
In case of missing of required parameter, or ATRAC media type, ATRAC streaming session can not be started. The situation is exceptional, and it is out of scope in our ATRAC payload format document. But if the media type was atrac3, then it could be started because rate=44100 could be assumed, no? Or is the generic processing model independent of the media type? I guess a spec would be required for me to check that 8-) As you say, the above processing may also be realized by +atrac extension for particuler purpose, but our scope is more generic, and described for lower level negotiation at the beginning of the normal ATRAC streaming. Ok. Plus the other legacy media types obviously can't be retrofitted with +atrac. Mark.
-- Colin Perkins http://csperkins.org/
Hi, Colin, We completely agree with your point that the SDP processing code based on knowledge of the media type is not efficient. It increase the complexity, and interrupt quick response in result, we think. So we keep as it is, regarding on the description of "rate" parameter of ATRAC3 in our draft. Best Regards,
Tom, Mark,
The rate parameter is clearly redundant for this media type, since the ATRAC3 codec only supports one rate. If having a required parameter with only one legal value is a problem -- which it hasn't been for some other formats -- then it can be removed.
The reason I suggested it be included, however, is that this media type will frequently be used with SDP signalling. SDP requires that the rate parameter be present. Rather than special-case the SDP processing code to generate the rate parameter based on knowledge of the media type, it seemed simpler to provide the parameter, even when its value is fixed for this code.
Colin
On 7 Mar 2008, at 03:53, Tom Taylor wrote:
One thing I should point out is what RFC 4855 says about the rate parameter:
<quote>
2. Procedure For Registering Media Types for RTP Payload Types ... Required parameters: If the payload format does not have a fixed RTP timestamp clock rate, then a "rate" parameter is required to specify the RTP timestamp clock rate. ...
</quote>
So the "rate" parameter is not essential in this particular case.
I would qualify this by saying that I should review correspondence Colin had with the authors to see if it covered this.
Mark Baker wrote:
Hi, On 2/29/08, actech <actech@jp.sony.com> wrote:
In case of missing of required parameter, or ATRAC media type, ATRAC streaming session can not be started. The situation is exceptional, and it is out of scope in our ATRAC payload format document. But if the media type was atrac3, then it could be started because rate=44100 could be assumed, no? Or is the generic processing model independent of the media type? I guess a spec would be required for me to check that 8-) As you say, the above processing may also be realized by +atrac extension for particuler purpose, but our scope is more generic, and described for lower level negotiation at the beginning of the normal ATRAC streaming. Ok. Plus the other legacy media types obviously can't be retrofitted with +atrac. Mark.
participants (4)
-
actech -
Colin Perkins -
Mark Baker -
Tom Taylor