[Ffmpeg-devel] Bug: wav decoder decodes garbage at end of file

[Michael Niedermayer]

Hi

On Mon, Jun 26, 2006 at 04:17:23PM +0200, Ulrich von Zadow wrote:
> Michael Niedermayer wrote:
> >>If I read the ffmpeg code correctly, the chunk size is actually read and 
> >>returned in find_tag (wav.c, 266ff) but then thrown away by 
> >>wav_read_header (wav.c, 331ff). This value should be used in 
> >>wav_read_packet to determine whether to set a logical eof state, I think.
> >>
> >>I made a short attempt at writing a patch, but ran into too many ffmpeg 
> >>design questions to get very far. For starters, where should the chunk 
> >>size be stored?
> >
> >something like WAVContext, though it seems our wav demuxer doesnt have one,
> >its private context size is 0, you will have to change that ...
> 
> Ok. Does this sound about right?
> 
> - Define a WAVContext struct in wav.c that contains a single member
>   wave_chunk_len.
> - Change wav_iformat so memory for the WAVContext is allocated.
> - In wav_read_header, set wave_chunk_len
> - In wav_read_packet, compare s->data_offset+wave_chunk_len to s->pb->pos to

wrong, url_ftell() is want you want


>   determine how many bytes are left to read. When none are left, set
>   s->eof_reached=1.

no, messing with eof_reached is unaceptable
also the correct behavior is to parse the chunks afterwards too, even if you
just skip over them, after all there could in principle be another WAVE chunk

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is