Re: mng_display_gotime() and large files

> The MNG format don't have restriction on the file size, is it?

Nope.
 
> >> Whether  there  is  a  way  to  limit  a memory allocation, but to
> >> use mng_display_gotime()?
> 
> > This is just not possible currently.
> 
> In future this may be?

Not likely. Unless it becomes extremely important to a large group of people.
 
> > (may not even need SAVE, if you keep track of IHDR's).
> > Then wheneveer the user wants to jump to a specific time, just reset
> > your input-stream to the right IHDR, and start feeding libmng from
> > that point, making sure the last chunk read before doing this is
> > always the IEND.
> 
> Yes, I tried this method earlier (before i wrote first message).
> But i have error "incorrect chunk". Probably it is my mistake.
> 
> This is correct sequence? :
> 
> 1.  Play.
> 
>     mng_readdisplay();
>     while (mymng->delay)
>     {
>         ...
>         mng_read_resume(mng);
>     }
> 
> 2.  Rewind request.
> 
>     mng_display_reset();
>     seek(required_IHDR_chunk_pos_in_file);
> 
> 3.  Play again.
> 
>     mng_readdisplay();
>     while (mymng->delay)
>     {
>         ...
>         mng_read_resume(mng);
>     }

Don't call mng_display_reset() on the rewind request. Just keep going until an 
IEND has been given to libmng, then do the seek, and continue to call 
mng_read_resume() (eg. don't do the mng_readdisplay() on resuming play).

That way you keep the order of the chunks correct. libmng will can expect an 
IHDR after the previous IEND. Doesn't matter to libmng if it's coming from a 
previous part of the input-stream.

The easiest way would be to use the pushchunk mechanism, rather than 
using the normal read callbacks. It means your app will have to do some of 
the decoding (eg. splitting the stream into chunks), but this way you have total 
control and will know where the IHDR's are in the stream.

Gerard


--
Send the message body "help" to [email protected]