[Mp4-tech] Re: LATM

[Ralph Sperschneider]

Dear Philipp,
MPEG meanwhile addressed this issue. Assuming you being an MPEG member, please
check out what we drafted in N7022. Note that this is still in a proposal stage.
Best regards,
Ralph
Philipp Kraetzer wrote:
> Ralph, thanks for your answers.
>  
> The case that muxConfigPresent=0 is maybe not that rare when the 
> StreamMuxConfig() is defined out-of-band using e.g. SDP. In this case, 
> the optional SDP parameter 'cpresent' corresponds to muxConfigPresent 
> and might be set to 0. I do not completely understand why the standard 
> does not allow a flexible number of AAC frames for each AudioMuxElement 
> without changing the StreamMuxConfig().
>  
> In the case that muxConfigPresent=1 I appreciate your proposal for a 
> corrigendum in case the nobody else has another solution. A byte-aligned 
> insertion of the "raw" AAC data into the LATM layer would simplify the 
> implementation, and would allow hinting AAC tracks in MP4/3GPP files to 
> create RFC3016 compliant streams.
>  
> I found further discussion on this topic in an older IMTC document 
> (October 23, 2002, "IMTC,Packet-Switched Streaming, Activity Group, 
> Implementation Guide") which might be of interest
> "
> 
> 
>     /2.3// MPEG4-Audio-AAC-LATM/SDP: is streamMuxConfig allowed inband ?/
> 
> * *
> 
>  
> 
> According to RFC3016 for audio streamMuxConfig  can be sent inband RTP 
> or outband in the SDP description. The advantage of outband transmission 
> is having a secure transmission of the parameters and bit shifting of 
> audio data can be avoided (streamMuxConfig  is not byte aligned in 
> inband mode). The advantage of inband transmission is the possibility to 
> change parameters of streamMuxConfig  during transmission.
> 
>  
> 
> SA4 approved the following solution due to following CRs (
> 
> Tdoc S4-020349, Tdoc S4-020348):
> 
>  
> 
> ”Configuration information is mandated to be sent in the SDP (which is 
> transported over TCP and thus safely delivered to the terminal) for 
> MPEG4 audio and MPEG4 video.”
> 
> "
> and
> "
> 
> 
>     /2.11 MPEG4-Audio-AAC-LC/RFC3016 : “last audioMuxElement containing
>     fewer packets than signalled allowed ?”/
> 
> *(new)*
> 
>  
> 
> when streaming AAC under the ‘cpresent=0’ restriction, you cannot 
> reconfigure the number of frames per audioMuxElement during streaming.  
> This may present a problem at the end of the stream, since the final 
> audioMuxElement (completed in the last RTP packet) might need to contain 
> fewer AAC frames than originally configured at start of streaming.  The 
> issue would ask for some clarification on how to handle this.
> 
>  
> 
> Suggestion for a solution :
> 
> Send a request to IETF and/or MPEG-4 Audio for a solution.
> 
>  
> 
> *On discussion*
> 
> "
>  
> Any further hints or suggestions are very welcome.
>  
> Thanks,
> Philipp
> 
> -----Ursprüngliche Nachricht-----
> Von: Ralph Sperschneider [mailto:ralph.sperschneider iis.fraunhofer.de]
> Gesendet: Freitag, 26. November 2004 11:27
> An: Philipp Kraetzer
> Cc: mp4-tech lists.mpegif.org; 'mpam uow.edu.au'
> Betreff: Re: LATM
> 
> Philipp Kraetzer wrote:
> 
>>I correct my posting from yesterday - sorry for confusion:
>>
>>I have two issues with LATM as defined in 14496-3 Amd. 1 (MPEG-4 Audio).
>>
>>1) A LATM packet always contains n AAC frames where n is equal to the
>>numSubFrames field in the StreamMuxConfig. If MuxConfigPresent is set
>>to 0 the configuration cannot change during transmission and all LATM
>>packets must contain the same number of AAC frames. How can I transport
>>a stream containing m AAC frames where m is no multiple of
>>numSubFrames? Do I have to do some padding in the last LATM packet?
>> 
>>
> If you really use a configuration with muxConfigPresent=0, then your 
> assumption is correct. This would however only make sence in a closed 
> system, where all the parameters usually specified in the
> StreamMuxConfig() are pre-defined.
> All the sync-streams specified by MPEG pre-configure muxConfigPresent=1.
> 
>>2) If MuxConfigPresent is 1 the LATM packet may start with the
>>StreamMuxConfig which does not seem to be octet-aligned. Does this mean
>>that I have to shift all of the following bytes of the AAC frames 
> repectively?
>> 
>>
> This is tru just in the case you need those bytes in a byte-aligned 
> fashion. Even without the StreamMuxConfig() you would have to deal with 
> the useSameStreamMux flag.
> 
>>Even worse, I want to create a MP4 file with a hint track for a
>>standard AAC
>>(non-LATM) track. The hint track shall create a LATM stream for RFC3016
>>compliant streaming. The hint track syntax allows the insertion of data
>>from the sample descriptor but only an integer number of bytes. I
>>cannot see how to create a valid LATM packet (AudioMuxElement) from the
>>descriptor data (the StreamMuxConfig) and the ES data if the
>>StreamMuxConfig is not octet-aligned.
>> 
>>
> Well, I don't see a simple solution for that kind of problem. Does 
> anyone else do? In case this is urgently needed one could consider to 
> correct this by means of a corrigendum for audioMuxVersion=1, which is 
> not yet used up to my knowledge. The syntax could then look like:
> 
>     if (muxConfigPresent) {      
>         useSameStreamMux;
>         if (!useSameStreamMux)      
>             StreamMuxConfig();      
>         if ( audioMuxVersion = 1 )
>             ByteAlign();
>     }      
> 
> Any suggestion is welcome.
> 
> Ralph
> 

-- 
Dipl.-Ing. Ralph Sperschneider  | Phone: +49 9131 776 344
Fraunhofer IIS                  | Fax:   +49 9131 776 67 344
Am Wolfsmantel 33               | mailto:ralph.sperschneider iis.fraunhofer.de
D 91058 Erlangen                | http://www.iis.fraunhofer.de/amm/