Timestamp issue with certain EAAC+ clips.

Email lists > Helix DNA datatypes discussion

Thread: Timestamp issue with certain EAAC+ clips.

Search this list only Search all lists
Timestamp issue with certain EAAC+ clips.
	2007-08-22 16:23:18

Hi, <<File5.mp4>> Attached clip is an EAAC Plus clip with implicit SBR and explicit non backward compatible parametric stereo. It has play duration of 15.7 seconds and sampling frequency of 22050 Hz read from the file. Helix file source object generates a timestamp sequence after reading the above specified information from the file as given below. Timestamp = 0 Timestamp = 93 Timestamp = 186 Timestamp = 279 Timestamp = 372 Timestamp = 464 Timestamp = 557 Timestamp = 650 Timestamp = 743 Timestamp = 836 Timestamp = 929 Timestamp = 1022 Timestamp = 1115 Timestamp = 1207 Timestamp = 1300 But actually the clip has play duration of 7.8 seconds and sampling frequency of 44100 Hz (Implicit SBR with PS component). This wrong timestamp causes the helix to play the clip with a silence in between two decoded audio data packets. As we get the actual sampling frequency of the clip only after starting the decoding in this case there has to be a correction to the timestamp with actual parameters at a later stage to fix this issue. The timestamp has to be as given below. Timestamp = 0 Timestamp = 46 Timestamp = 92 Timestamp = 138 Timestamp = 184 Timestamp = 230 Timestamp = 276 Timestamp = 322 Timestamp = 368 Timestamp = 414 Timestamp = 460 Timestamp = 506 Timestamp = 552 Timestamp = 598 Timestamp = 644 I am able to play the attached clip without any failure using couple of other players (Nokia music player and MediaCoder). I would like to know your comment on this issue. I noticed the specified error on both mobile device helix player and desktop helix player. Thanks & regards Saleem

Re: Timestamp issue with certain EAAC+ clips.
United States	2007-08-22 19:46:23

The file you attached has incorrect systems information. The time-stamps for packets is formed incorrectly (or sampling rate is provided incorrectly) which is the reason for mp4 file-format generating the time-stamps as you provide them below. Helix is broad media framework with its plugins running in server as well as client thus requiring systems information to be used for it was designed for. Other, simple players, may choose to ignore aspects of system information and simply feed data to the decoders in queue based fashion. In this case, such strategy pays off but is not a proper general solution and does not change the fact that this particular file is malformed. Helix does contain code to deal with malformed files and in this case its heuristic for detecting the malformed file has missed this case by a hair.  The fact that audio frames in actuality are entire frame length apart is too far for Helix mp4 audio renderer to treat them as contiguous. Any less, Helix audio renderer would force the decoder output into a contiguous sequence.  The dilemma the mp4 audio renderer needs to overcome is weather to trust the systems information or simply assume all audio is always contiguous. We do pay attention to systems information since that is what it was designed for. While one could extend the heuristic to say 1.5 frame length and thus include this file into right side of the heuristic. Local playback would work. Hinting or attempting to stream this file would fail on the server as data would not be paced properly. Milko At 02:23 PM 8/22/2007, ext-saleem.adookkattilnokia.com wrote: Hi, <<File5.mp4>> Attached clip is an EAAC Plus clip with implicit SBR and explicit non backward compatible parametric stereo. It has play duration of 15.7 seconds and sampling frequency of 22050 Hz read from the file. Helix file source object generates a timestamp sequence after reading the above specified information from the file as given below. Timestamp = 0 Timestamp = 93 Timestamp = 186 Timestamp = 279 Timestamp = 372 Timestamp = 464 Timestamp = 557 Timestamp = 650 Timestamp = 743 Timestamp = 836 Timestamp = 929 Timestamp = 1022 Timestamp = 1115 Timestamp = 1207 Timestamp = 1300 But actually the clip has play duration of 7.8 seconds and sampling frequency of 44100 Hz (Implicit SBR with PS component). This wrong timestamp causes the helix to play the clip with a silence in between two decoded audio data packets. As we get the actual sampling frequency of the clip only after starting the decoding in this case there has to be a correction to the timestamp with actual parameters at a later stage to fix this issue. The timestamp has to be as given below. Timestamp = 0 Timestamp = 46 Timestamp = 92 Timestamp = 138 Timestamp = 184 Timestamp = 230 Timestamp = 276 Timestamp = 322 Timestamp = 368 Timestamp = 414 Timestamp = 460 Timestamp = 506 Timestamp = 552 Timestamp = 598 Timestamp = 644 I am able to play the attached clip without any failure using couple of other players (Nokia music player and MediaCoder). I would like to know your comment on this issue. I noticed the specified error on both mobile device helix player and desktop helix player. Thanks & regards Saleem _______________________________________________ Datatype-dev mailing list Datatype-devhelixcommunity.org http://lists.helixcommunity.org/mailman/listinfo/datatype-dev

[1-2]

about | contact Other archives ( Real Estate discussion Medical topics )

Mailing lists

ARCHIVES