[Mp4-tech] MPEG 4 Video Buffer problem

[Dave Singer]

At 9:32 PM +0530 11/5/04, Shailesh Sakri wrote:
>Hi,
>      How do we manage the less handler condition while decoding  mp4 file.
>      a) Say I have mp4 file in a 3gpp format. For first frame I get 3gpp
>header in which i come to know the mp4 compressed frame length. Then the
>actual mp4 (first frame->header+data)follows in bitstream. Now I have mp4
>frame length of xbytes for a particular frame. I have a decoder internal
>buffer of 'Y' bytes. How do i decide the max size of this internal buffer
>such that Y>=x bytes always. I am defining internal buffer size Ybytes only
>once in the Appopen. And all rest frames it is constant once defined for a
>particular stream. Do i skip those frame where the frame size is more than
>my internal buffer or keep a auxillary buffer where i copy remaining data
>and then decode considering i have certain memory constrain. Is there any
>max encoded data frame size for simple profile in mpeg4 codec?

if you are reading an MP4/3GP file, you could (a) look at the buffer 
size limits for the declared level or (b) scan the sample size table 
at open, and find the largest frame in it.  It's compact.
>
>And
>     b)Say at a particular point of time I know from 3gpp header that current
>frame size is x bytes. but only y bytes of data is available at that point
>of time where y <x. How do i handle this less handler situation. do I copy
>available data into internal buffer and wait for remaining data or start
>decoding and exit with error condition as i  will not have entire encoded
>stream to decode. This will adversely have effect on tht entire GOP of
>frames and only synchup at next 'I' frame.

I don't understand how you can be short of data reading from a file. 
If this is a network, how you handle error resilience to late or lost 
data is very much part of your own system design.
>
>Rgds,
>Shailesh
>
>
>
>                            SASKEN BUSINESS DISCLAIMER
>This message may contain confidential, proprietary or legally 
>Privileged information. In case you are not the original intended 
>Recipient of the message, you must not, directly or indirectly, use, 
>Disclose, distribute, print, or copy any part of this message and 
>you are requested to delete it and inform the sender. Any views 
>expressed in this message are those of the individual sender unless 
>otherwise stated. Nothing contained in this message shall be 
>construed as an offer or acceptance of any offer by Sasken 
>Communication Technologies Limited ("Sasken") unless sent with that 
>express intent and with due authority of Sasken. Sasken has taken 
>enough precautions to prevent the spread of viruses. However the 
>company accepts no liability for any damage caused by any virus 
>transmitted by this email
>_______________________________________________
>NOTE: Please use clear subject lines for your posts. Include [audio, 
>[video], [systems], [general] or another apppropriate identifier to 
>indicate the type of question you have.
>
>Note: Conduct on the mailing list is subject to the Antitrust 
>guidelines found at 
>http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php

-- 
David Singer
Apple Computer/QuickTime