Re: [media-types] Media type review requested for draft-ietf-avtcore-rtp-vvc-16

["Martin J. Dürst" <[e-mail]>]

Hello Stephan, others,

Just a few minor comments below.

On 2022-06-16 09:43, Stephan Wenger wrote:
> Hi Martin,
> thanks for your advice (very far down in this email) that suggested to include the template in this email.  Template below.  It's looooong.
> The link I posted earlier was no good.  Here's one that works. https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/16/
> Stephan
> 
> 
>     Type name:            video
> 
>     Subtype name:         H266
> 
>     Required parameters:  N/A

What about "Required parameters:  none"? N/A feels more like "don't 
really know what I'm supposed to write here", where as "none" gives a 
definite answer.


>     Optional parameters:
> 
>        profile-id, tier-flag, sub-profile-id, interop-constraints, level-
>        id, sprop-sublayer-id, sprop-ols-id, recv-sublayer-id, recv-ols-
>        id, max-recv-level-id, sprop-dci, sprop-vps, sprop-sps, sprop-pps,
>        sprop-sei, max-lsr, max-fps, sprop-max-don-diff, sprop-depack-buf-
>        bytes, depack-buf-cap (Refer to Section 7.2 for definitions).
> 
>     Encoding considerations:
> 
>        This type is only defined for transfer via RTP (RFC 3550).

As far as I remember, "Encoding considerations" are more about whether 
this is a binary encoding,... My guess is that the above line probably 
should go under "Interoperability considerations", or alternatively 
"Restrictions on usage"


>     Security considerations:
> 
>        See Section 9 of RFC XXXX.
> 
>     Interoperability considerations: N/A
> 
>     Published specification:
> 
>        Please refer to RFC XXXX and its Section 13.

Why not simply "Section 13 of RFC　XXXX"?

>     Applications that use this media type:
> 
>        Any application that relies on VVC-based video services over RTP
> 
>     Fragment identifier considerations: N/A
> 
>     Additional information: N/A
> 
>     Person & email address to contact for further information:
> 
>        Stephan Wenger ([e-mail])
> 
>     Intended usage: COMMON
> 
>     Restrictions on usage: N/A
> 
>     Author: See Authors' Addresses section of RFC XXXX.
> 
>     Change controller:
> 
>        IETF Audio/Video Transport Core Maintenance Working Group
>        delegated from the IESG.

Two points here: 1)  What happens when the Core Maintenance Working 
Group gets closed, and 2) it's usually the IETF, not the IESG that is 
mentioned as change controller. If we also want to mention the IESG, a 
very precise wording might be:

IETF, initially delegated by the IESG to the Audio/Video Transport Core 
Maintenance Working Group.

Not sure that level of precision is necessary, though.


> 7.2.  Optional Parameters Definition

Did this get appended just for reference? I hope it's not part of the 
template, that would be way too long.

Regards,    Martin.


>     profile-id, tier-flag, sub-profile-id, interop-constraints, and
>     level-id:
> 
>        These parameters indicate the profile, tier, default level, sub-
>        profile, and some constraints of the bitstream carried by the RTP
>        stream, or a specific set of the profile, tier, default level,
>        sub-profile and some constraints the receiver supports.
> 
>        The subset of coding tools that may have been used to generate the
>        bitstream or that the receiver supports, as well as some
>        additional constraints are indicated collectively by profile-id,
>        sub-profile-id, and interop-constraints.
> 
>        Informative note: There are 128 values of profile-id.  The
>           subset of coding tools identified by the profile-id can be
>           further constrained with up to 255 instances of sub-profile-id.
>           In addition, 68 bits included in interop-constraints, which can
>           be extended up to 324 bits provide means to further restrict
>           tools from existing profiles.  To be able to support this fine-
>           granular signaling of coding tool subsets with profile-id, sub-
>           profile-id and interop-constraints, it would be safe to require
>           symmetric use of these parameters in SDP offer/answer unless
>           recv-ols-id is included in the SDP answer for choosing one of
>           the layers offered.
> 
>        The tier is indicated by tier-flag.  The default level is
>        indicated by level-id.  The tier and the default level specify the
>        limits on values of syntax elements or arithmetic combinations of
>        values of syntax elements that are followed when generating the
>        bitstream or that the receiver supports.
> 
>        In SDP offer/answer, when the SDP answer does not include the
>        recv-ols-id parameter that is less than the sprop-ols-id parameter
>        in the SDP offer, the following applies:
> 
>        -  The tier-flag, profile-id, sub-profile-id, and interop-
>           constraints parameters MUST be used symmetrically, i.e., the
>           value of each of these parameters in the offer MUST be the same
>           as that in the answer, either explicitly signaled or implicitly
>           inferred.
> 
>        -  The level-id parameter is changeable as long as the highest
>           level indicated by the answer is either equal to or lower than
>           that in the offer.  Note that a highest level higher than
>           level-id in the offer for receiving can be included as max-
>           recv-level-id.
> 
>        In SDP offer/answer, when the SDP answer does include the recv-
>           ols-id parameter that is less than the sprop-ols-id parameter
>           in the SDP offer, the set of tier-flag, profile-id, sub-
>           profile-id, interop-constraints, and level-id parameters
>           included in the answer MUST be consistent with that for the
>           chosen output layer set as indicated in the SDP offer, with the
>           exception that the level-id parameter in the SDP answer is
>           changeable as long as the highest level indicated by the answer
>           is either lower than or equal to that in the offer.
> 
>        More specifications of these parameters, including how they relate
>        to syntax elements specified in [VVC] are provided below.
> 
>     profile-id:
> 
>        When profile-id is not present, a value of 1 (i.e., the Main 10
>        profile) MUST be inferred.
> 
>        When used to indicate properties of a bitstream, profile-id is
>        derived from the general_profile_idc syntax element that applies
>        to the bitstream in an instance of the profile_tier_level( )
>        syntax structure.
> 
>        VVC bitstreams transported over RTP using the technologies of this
>        memo SHOULD contain only a single profile_tier_level( ) structure
>        in the DCI, unless the sender can assure that a receiver can
>        correctly decode the VVC bitstream regardless of which
>        profile_tier_level( ) structure contained in the DCI was used for
>        deriving profile-id and other parameters for the SDP O/A exchange.
> 
>        As specified in [VVC], a profile_tier_level( ) syntax structure
>        may be contained in an SPS NAL unit, and one or more
>        profile_tier_level( ) syntax structures may be contained in a VPS
>        NAL unit and in a DCI NAL unit.  One of the following three cases
>        applies to the container NAL unit of the profile_tier_level( )
>        syntax structure containing syntax elements used to derive the
>        values of profile-id, tier-flag, level-id, sub-profile-id, or
>        interop-constraints: 1) The container NAL unit is an SPS, the
>        bitstream is a single-layer bitstream, and the profile_tier_level(
>        ) syntax structures in all SPSs referenced by the CVSs in the
>        bitstream has the same values respectively for those
>        profile_tier_level( ) syntax elements; 2) The container NAL unit
>        is a VPS, the profile_tier_level( ) syntax structure is the one in
>        the VPS that applies to the OLS corresponding to the bitstream,
>        and the profile_tier_level( ) syntax structures applicable to the
>        OLS corresponding to the bitstream in all VPSs referenced by the
>        CVSs in the bitstream have the same values respectively for those
>        profile_tier_level( ) syntax elements; 3) The container NAL unit
>        is a DCI NAL unit and the profile_tier_level( ) syntax structures
>        in all DCI NAL units in the bitstream has the same values
>        respectively for those profile_tier_level( ) syntax elements.
> 
>        [VVC] allows for multiple profile_tier_level( ) structures in a
>        DCI NAL unit, which may contain different values for the syntax
>        elements used to derive the values of profile-id, tier-flag,
>        level-id, sub-profile-id, or interop-constraints in the different
>        entries.  However, herein defined is only a single profile-id,
>        tier-flag, level-id, sub-profile-id, or interop-constraints.  When
>        signaling these parameters and a DCI NAL unit is present with
>        multiple profile_tier_level( ) structures, these values SHOULD be
>        the same as the first profile_tier_level structure in the DCI,
>        unless the sender has ensured that the receiver can decode the
>        bitstream when a different value is chosen.
> 
>     tier-flag, level-id:
> 
>        The value of tier-flag MUST be in the range of 0 to 1, inclusive.
>        The value of level-id MUST be in the range of 0 to 255, inclusive.
> 
>        If the tier-flag and level-id parameters are used to indicate
>        properties of a bitstream, they indicate the tier and the highest
>        level the bitstream complies with.
> 
>        If the tier-flag and level-id parameters are used for capability
>        exchange, the following applies.  If max-recv-level-id is not
>        present, the default level defined by level-id indicates the
>        highest level the codec wishes to support.  Otherwise, max-recv-
>        level-id indicates the highest level the codec supports for
>        receiving.  For either receiving or sending, all levels that are
>        lower than the highest level supported MUST also be supported.
> 
>        If no tier-flag is present, a value of 0 MUST be inferred; if no
>        level-id is present, a value of 51 (i.e., level 3.1) MUST be
>        inferred.
> 
>        Informative note: The level values currently defined in the VVC
>           specification are in the form of "majorNum.minorNum", and the
>           value of the level-id for each of the levels is equal to
>           majorNum * 16 + minorNum * 3.  It is expected that if any
>           levels are defined in the future, the same convention will be
>           used, but this cannot be guaranteed.
> 
>        When used to indicate properties of a bitstream, the tier-flag and
>        level-id parameters are derived respectively from the syntax
>        element general_tier_flag, and the syntax element
>        general_level_idc or sub_layer_level_idc[j], that apply to the
>        bitstream, in an instance of the profile_tier_level( ) syntax
>        structure.
> 
>        If the tier-flag and level-id are derived from the
>        profile_tier_level( ) syntax structure in a DCI NAL unit, the
>        following applies:
> 
>        -  tier-flag = general_tier_flag
> 
>        -  level-id = general_level_idc
> 
>        Otherwise, if the tier-flag and level-id are derived from the
>        profile_tier_level( ) syntax structure in an SPS or VPS NAL unit,
>        and the bitstream contains the highest sublayer representation in
>        the OLS corresponding to the bitstream, the following applies:
> 
>        -  tier-flag = general_tier_flag
> 
>        -  level-id = general_level_idc
> 
>        Otherwise, if the tier-flag and level-id are derived from the
>           profile_tier_level( ) syntax structure in an SPS or VPS NAL
>           unit, and the bitstream does not contain the highest sublayer
>           representation in the OLS corresponding to the bitstream, the
>           following applies, with j being the value of the sprop-
>           sublayer-id parameter:
> 
>        -  tier-flag = general_tier_flag
> 
>        -  level-id = sub_layer_level_idc[j]
> 
>     sub-profile-id:
> 
>        The value of the parameter is a comma-separated (',') list of data
>        using base64 [RFC4648] representation.
> 
>        When used to indicate properties of a bitstream, sub-profile-id is
>        derived from each of the ptl_num_sub_profiles
>        general_sub_profile_idc[i] syntax elements that apply to the
>        bitstream in a profile_tier_level( ) syntax structure.
> 
>     interop-constraints:
> 
>        A base64 [RFC4648] representation of the data that includes the
>        syntax elements ptl_frame_only_constraint_flag and
>        ptl_multilayer_enabled_flag and the general_constraints_info( )
>        syntax structure that apply to the bitstream in an instance of the
>        profile_tier_level( ) syntax structure.
> 
>        If the interop-constraints parameter is not present, the following
>        MUST be inferred:
> 
>        -  ptl_frame_only_constraint_flag = 1
> 
>        -  ptl_multilayer_enabled_flag = 0
> 
>        -  gci_present_flag in the general_constraints_info( ) syntax
>           structure = 0
> 
>        Using interop-constraints for capability exchange results in a
>        requirement on any bitstream to be compliant with the interop-
>        constraints.
> 
>     sprop-sublayer-id:
> 
>        This parameter MAY be used to indicate the highest allowed value
>        of TID in the bitstream.  When not present, the value of sprop-
>        sublayer-id is inferred to be equal to 6.
> 
>        The value of sprop-sublayer-id MUST be in the range of 0 to 6,
>        inclusive.
> 
>     sprop-ols-id:
> 
>        This parameter MAY be used to indicate the OLS that the bitstream
>        applies to.  When not present, the value of sprop-ols-id is
>        inferred to be equal to TargetOlsIdx as specified in 8.1.1 in
>        [VVC].  If this optional parameter is present, sprop-vps MUST also
>        be present or its content MUST be known a priori at the receiver.
> 
>        The value of sprop-ols-id MUST be in the range of 0 to 256,
>        inclusive.
> 
>        Informative note: VVC allows having up to 257 output layer sets
>           indicated in the VPS as the number of output layer sets minus 2
>           is indicated with a field of 8 bits.
> 
>     recv-sublayer-id:
> 
>        This parameter MAY be used to signal a receiver's choice of the
>        offered or declared sublayer representations in the sprop-vps and
>        sprop-sps.  The value of recv-sublayer-id indicates the TID of the
>        highest sublayer that a receiver supports.  When not present, the
>        value of recv-sublayer-id is inferred to be equal to the value of
>        the sprop-sublayer-id parameter in the SDP offer.
> 
>        The value of recv-sublayer-id MUST be in the range of 0 to 6,
>        inclusive.
> 
>     recv-ols-id:
> 
>        This parameter MAY be used to signal a receiver's choice of the
>        offered or declared output layer sets in the sprop-vps.  The value
>        of recv-ols-id indicates the OLS index of the bitstream that a
>        receiver supports.  When not present, the value of recv-ols-id is
>        inferred to be equal to value of the sprop-ols-id parameter
>        inferred from or indicated in the SDP offer.  When present, the
>        value of recv-ols-id must be included only when sprop-ols-id was
>        received and must refer to an output layer set in the VPS that
>        includes no layers other than all or a subset of the layers of the
>        OLS referred to by sprop-ols-id.  If this optional parameter is
>        present, sprop-vps must have been received or its content must be
>        known a priori at the receiver.
> 
>        The value of recv-ols-id MUST be in the range of 0 to 256,
>        inclusive.
> 
>     max-recv-level-id:
> 
>        This parameter MAY be used to indicate the highest level a
>        receiver supports.
> 
>        The value of max-recv-level-id MUST be in the range of 0 to 255,
>        inclusive.
> 
>        When max-recv-level-id is not present, the value is inferred to be
>        equal to level-id.
> 
>        max-recv-level-id MUST NOT be present when the highest level the
>        receiver supports is not higher than the default level.
> 
>     sprop-dci:
> 
>        This parameter MAY be used to convey a decoding capability
>        information NAL unit of the bitstream for out-of-band
>        transmission.  The parameter MAY also be used for capability
>        exchange.  The value of the parameter a base64 [RFC4648]
>        representations of the decoding capability information NAL unit as
>        specified in Section 7.3.2.1 of [VVC].
> 
>     sprop-vps:
> 
>        This parameter MAY be used to convey any video parameter set NAL
>        unit of the bitstream for out-of-band transmission of video
>        parameter sets.  The parameter MAY also be used for capability
>        exchange and to indicate sub-stream characteristics (i.e.,
>        properties of output layer sets and sublayer representations as
>        defined in [VVC]).  The value of the parameter is a comma-
>        separated (',') list of base64 [RFC4648] representations of the
>        video parameter set NAL units as specified in Section 7.3.2.3 of
>        [VVC].
> 
>        The sprop-vps parameter MAY contain one or more than one video
>        parameter set NAL units.  However, all other video parameter sets
>        contained in the sprop-vps parameter MUST be consistent with the
>        first video parameter set in the sprop-vps parameter.  A video
>        parameter set vpsB is said to be consistent with another video
>        parameter set vpsA if the number of OLSs in vpsA and vpsB is the
>        same and any decoder that conforms to the profile, tier, level,
>        and constraints indicated by the data starting from the syntax
>        element general_profile_idc to the syntax structure
>        general_constraints_info(), inclusive, in the profile_tier_level()
>        syntax structure corresponding to any OLS with index olsIdx in
>        vpsA can decode any CVS(s) referencing vpsB when TargetOlsIdx is
>        equal to olsIdx that conforms to the profile, tier, level, and
>        constraints indicated by the data starting from the syntax element
>        general_profile_idc to the syntax structure
>        general_constraints_info(), inclusive, in the profile_tier_level(
>        ) syntax structure corresponding to the OLS with index
>        TargetOlsIdx in vpsB.
> 
>     sprop-sps:
> 
>        This parameter MAY be used to convey sequence parameter set NAL
>        units of the bitstream for out-of-band transmission of sequence
>        parameter sets.  The value of the parameter is a comma-separated
>        (',') list of base64 [RFC4648] representations of the sequence
>        parameter set NAL units as specified in Section 7.3.2.4 of [VVC].
> 
>        A sequence parameter set spsB is said to be consistent with
>        another sequence parameter set spsA if any decoder that conforms
>        to the profile, tier, level, and constraints indicated by the data
>        starting from the syntax element general_profile_idc to the syntax
>        structure general_constraints_info(), inclusive, in the
>        profile_tier_level( ) syntax structure in spsA can decode any
>        CLVS(s) referencing spsB that conforms to the profile, tier,
>        level, and constraints indicated by the data starting from the
>        syntax element general_profile_idc to the syntax structure
>        general_constraints_info(), inclusive, in the profile_tier_level(
>        ) syntax structure in spsB.
> 
>     sprop-pps:
> 
>        This parameter MAY be used to convey picture parameter set NAL
>        units of the bitstream for out-of-band transmission of picture
>        parameter sets.  The value of the parameter is a comma-separated
>        (',') list of base64 [RFC4648] representations of the picture
>        parameter set NAL units as specified in Section 7.3.2.5 of [VVC].
> 
>     sprop-sei:
> 
>        This parameter MAY be used to convey one or more SEI messages that
>        describe bitstream characteristics.  When present, a decoder can
>        rely on the bitstream characteristics that are described in the
>        SEI messages for the entire duration of the session, independently
>        from the persistence scopes of the SEI messages as specified in
>        [VSEI].
> 
>        The value of the parameter is a comma-separated (',') list of
>        base64 [RFC4648] representations of SEI NAL units as specified in
>        [VSEI].
> 
>        Informative note: Intentionally, no list of applicable or
>           inapplicable SEI messages is specified here.  Conveying certain
>           SEI messages in sprop-sei may be sensible in some application
>           scenarios and meaningless in others.  However, a few examples
>           are described below:
> 
>        1) In an environment where the bitstream was created from film-
>           based source material, and no splicing is going to occur during
>           the lifetime of the session, the film grain characteristics SEI
>           message is likely meaningful, and sending it in sprop-sei
>           rather than in the bitstream at each entry point may help with
>           saving bits and allows one to configure the renderer only once,
>           avoiding unwanted artifacts.
> 
>        2) Examples for SEI messages that would be meaningless to be
>           conveyed in sprop-sei include the decoded picture hash SEI
>           message (it is close to impossible that all decoded pictures
>           have the same hashtag) or the filler payload SEI message (as
>           there is no point in just having more bits in SDP).
> 
>     max-lsr:
> 
>        The max-lsr MAY be used to signal the capabilities of a receiver
>        implementation and MUST NOT be used for any other purpose.  The
>        value of max-lsr is an integer indicating the maximum processing
>        rate in units of luma samples per second.  The max-lsr parameter
>        signals that the receiver is capable of decoding video at a higher
>        rate than is required by the highest level.
> 
>        Informative note: When the OPTIONAL media type parameters are
>           used to signal the properties of a bitstream, and max-lsr is
>           not present, the values of tier-flag, profile-id, sub-profile-
>           id interop-constraints, and level-id must always be such that
>           the bitstream complies fully with the specified profile, tier,
>           and level.
> 
>        When max-lsr is signaled, the receiver MUST be able to decode
>        bitstreams that conform to the highest level, with the exception
>        that the MaxLumaSr value in Table 136 of [VVC] for the highest
>        level is replaced with the value of max-lsr.  Senders MAY use this
>        knowledge to send pictures of a given size at a higher picture
>        rate than is indicated in the highest level.
> 
>        When not present, the value of max-lsr is inferred to be equal to
>        the value of MaxLumaSr given in Table 136 of [VVC] for the highest
>        level.
> 
>        The value of max-lsr MUST be in the range of MaxLumaSr to 16 *
>        MaxLumaSr, inclusive, where MaxLumaSr is given in Table 136 of
>        [VVC] for the highest level.
> 
>     max-fps:
> 
>        The value of max-fps is an integer indicating the maximum picture
>        rate in units of pictures per 100 seconds that can be effectively
>        processed by the receiver.  The max-fps parameter MAY be used to
>        signal that the receiver has a constraint in that it is not
>        capable of processing video effectively at the full picture rate
>        that is implied by the highest level and, when present, max-lsr.
> 
>        The value of max-fps is not necessarily the picture rate at which
>        the maximum picture size can be sent, it constitutes a constraint
>        on maximum picture rate for all resolutions.
> 
>        Informative note: The max-fps parameter is semantically
>           different from max-lsr in that max-fps is used to signal a
>           constraint, lowering the maximum picture rate from what is
>           implied by other parameters.
> 
>        The encoder MUST use a picture rate equal to or less than this
>        value.  In cases where the max-fps parameter is absent, the
>        encoder is free to choose any picture rate according to the
>        highest level and any signaled optional parameters.
> 
>        The value of max-fps MUST be smaller than or equal to the full
>        picture rate that is implied by the highest level and, when
>        present, max-lsr.
> 
>     sprop-max-don-diff:
> 
>        If there is no NAL unit naluA that is followed in transmission
>        order by any NAL unit preceding naluA in decoding order (i.e., the
>        transmission order of the NAL units is the same as the decoding
>        order), the value of this parameter MUST be equal to 0.
> 
>        Otherwise, this parameter specifies the maximum absolute
>        difference between the decoding order number (i.e., AbsDon) values
>        of any two NAL units naluA and naluB, where naluA follows naluB in
>        decoding order and precedes naluB in transmission order.
> 
>        The value of sprop-max-don-diff MUST be an integer in the range of
>        0 to 32767, inclusive.
> 
>        When not present, the value of sprop-max-don-diff is inferred to
>        be equal to 0.
> 
>     sprop-depack-buf-bytes:
> 
>        This parameter signals the required size of the de-packetization
>        buffer in units of bytes.  The value of the parameter MUST be
>        greater than or equal to the maximum buffer occupancy (in units of
>        bytes) of the de-packetization buffer as specified in Section 6.
> 
>        The value of sprop-depack-buf-bytes MUST be an integer in the
>        range of 0 to 4294967295, inclusive.
> 
>        When sprop-max-don-diff is present and greater than 0, this
>        parameter MUST be present and the value MUST be greater than 0.
>        When not present, the value of sprop-depack-buf-bytes is inferred
>        to be equal to 0.
> 
>        Informative note: The value of sprop-depack-buf-bytes indicates
>           the required size of the de-packetization buffer only.  When
>           network jitter can occur, an appropriately sized jitter buffer
>           has to be available as well.
> 
>     depack-buf-cap:
> 
>        This parameter signals the capabilities of a receiver
>        implementation and indicates the amount of de-packetization buffer
>        space in units of bytes that the receiver has available for
>        reconstructing the NAL unit decoding order from NAL units carried
>        in the RTP stream.  A receiver is able to handle any RTP stream
>        for which the value of the sprop-depack-buf-bytes parameter is
>        smaller than or equal to this parameter.
> 
>        When not present, the value of depack-buf-cap is inferred to be
>        equal to 4294967295.  The value of depack-buf-cap MUST be an
>        integer in the range of 1 to 4294967295, inclusive.
> 
>        Informative note: depack-buf-cap indicates the maximum possible
>           size of the de-packetization buffer of the receiver only,
>           without allowing for network jitter.
> 
> 
> 
> 
> 
> On 6/15/22, 17:34, "Martin J. Dürst" <[e-mail]> wrote:
> 
>      Standard reminder for this list: Please put the template into the mail.
>      This increases the chance of getting comments.
> 
>      Regards,    Martin.
> 
>      On 2022-06-16 08:25, Stephan Wenger wrote:
>      > Folks,
>      >
>      > The involved people collectively forgot to ask for a media type review of the subject draft, located here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/16/  It took an AD DISCUSS to remind us __. The VVC payload is a straightforward RTP payload format for the H.266/VVC codec.
>      >
>      > The draft is past IETF LC and is on tomorrow's IESG telechat.  Obviously, I can only hope that one of the good folks here could run a review overnight... but hoping I do.  If that's not workable, please time things as you see fit.
>      >
>      > Thanks very much,
>      > Stephan
>      >
>      >
> 

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan