Subject: Re: Re: Re: Re: [AVT] RTP timestamp calculation for MPEG1 Video and AudioESsothat itworks with RTSP client like RealOne/QuickTime

From: "Neo Anderson" <[email-masked]>
Date: Sat, 30 Aug 2003 12:57:03 +0530

Comments inline:
>1. I am encapsulating the audio frames based on Audio Frame Sync 
>code.
>   I determine the end of the frame if I get a next frame sync code.
>   So, one RTP packet consists of one frame.
>   Is this correct ?
In cases when there is no intermediate data between the mpeg frames, 
this is correct. (For most practical cases this should hold good).
Else, the size of the frame has to be calculated using the same 
formula as in (2).

(If you are doing live encoding, are you not able to get the frame 
length from the encoder itself?)

>2.  About the formula
>> Sampling Rate = Fs Hz
>> Calculated Samples per frame = x
>> Timestamp in 90kHz units = ((x/Fs) * 90000)
>How do I calculate samples per frame, Could you please stick the 
>extract
>over here. I tried the http://www.wotsit.org/search.asp?
>page=5&s=music

There are some more files. Kindly have a look into them too. (Search 
for mp3 in wotsit)

>but it says .
>If I check mpeghdr.htm file,
>It says
>******
>How to calculate frame size
>
>Read the BitRate, SampleRate and Padding (as value of one or zero) 
of the
>frame header and use the formula:

>FrameSize = 144 * BitRate/ SampleRate + Padding

>Example: BitRate = 128000, SampleRate=441000, Padding=0  ==>  
>FrameSize=417
>bytes
******
>But, I am not sure from where 144 has come from. And where does the 
>padding
>bit come from.

Note 1: SampleRate=441000 should be 44100.

All the bits come from the MPEG frame header which resides after the 
sync. You will have to parse the related info from the frame.

Another good reading of mpeghdr.htm should solve your problem of 
parsing the frame header. 

144 comes like this:
There are 1152 "RAW" samples per frame in layer II & III.
After compression, frame length is calculated in slots.
One slot is 1 byte long for layer II and layer III.
Consider Fs = 44100 and BR=128000

Duration of audio in a frame = 1152/44100 (seconds)

Since we get 128000 bits in a second:
Number of bits in this duration = ((1152/44100) * 128000) * (1), 
where 1 is the number of slots
or 
(((1152/44100)*128000)/8) * (1) BYTES, where 1 is the number of slots.

The variables here are Fs and BR. The constant field is (1152/8) = 
144.

Extract from the same url above:
"Padding is used to fit the bit rates exactly. For an example: 128k 
44.1kHz layer II uses a lot of 418 bytes and some of 417 bytes long 
frames to get the exact 128k bitrate. For Layer I slot is 32 bits 
long, for Layer II and Layer III slot is 8 bits long. "

Suggests you will have a few frames which are padded and a few which 
do not, in order to maintain proper bitrate because we end up in a 
fraction with "0.95" slots left over per frame (0.4 bits i.e. we may 
insert one padded frame for every 19 frames, say and frame length 
will be 418)!

Try other sampling frequencies and you will not end up with a 
fractional value.
44100 and 22050 is maintained for some historical reason to do with 
cd's and tv's...

--Neo
Get your own Free E-mail at Witch Wisdom http://www.witchwisdom.com
__________________
http://www.zzn.com

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Sat, 30 Aug 2003 20:11:26 -0500 (GMT)

Thanks very much for a excellent response.
This is good information.

Also observed :
We just tried sending the PTS from MPEG1 header as it is in
the RTP timestamp field for each MPEG1 packet for audio and it 
also worked fine and smooth on RealOne.

Thanks and Regards
Deepak

Thanks and Regards
Deepak
[email-masked] wrote

of the

******

144 comes like this:

--Neo