[FFmpeg-devel] [PATCH] WAV file length (writing to stdout)

[Axel Holzinger]

Justin Ruggles writes:
> Axel Holzinger wrote:
> > Rich Felker writes:
> >> On Tue, Oct 16, 2007 at 05:02:39PM +0200, Cyril B. wrote:
> >>> Hi,
> >>>
> >>> As reported recently on this mailing list [1], ffmpeg sets 
> >> 0 as file length
> >>> in the WAV header if output is streamed (for instance, when 
> >> outputting to
> >>> stdout). Nero AAC encoder does not accept such streams 
> >> ('could not parse
> >>> WAV file' error).
> >>>
> >>> The WAV file specs [2] say the file length (ChunkSize) must 
> >> be 36 + data
> >>> length. The included patch writes 36 instead of 0, which 
> >> satisfies Nero
> >>> encoder.
> >> IMO both are wrong. The most compatible way to make a wav 
> header for
> >> unknown length is to put 0xffffffff in the header.
> > 
> > 0 as the RIFF length and 0 as the data chunk length is a 
> common agreement in serious recording applications while 
> still recording the file. So a playback application can 
> determine that the given file is still being recorded. As 
> soon as the recording application finishes the ongoing 
> recording, it writes the correct values for RIFF lenth and 
> data chunk length to the file.
> > 
> > I think Nero AAC encoder is an application that is not 
> considering that a given file might still be recorded at the 
> moment it is passed to Nero AAC encoder.
> > 
> > Setting theboth length to 0xffffffff (-1) makes the file 
> invalid as 0xffffffff (-1) is an invalid value for the lenth 
> fields. So I consider this to not be a good way.
> 
> The length is treated as unsigned, so 4294967295 is a valid 
> length.  But 
> there are many programs which use this convention because it has the 
> effect of saying "keep reading data until the end-of-file".  
> There are 
> only a couple downsides.  One is that a program may report 
> the playing 
> time as something like 6 hours instead of the actual playing time. 
> Another is that no other chunks can follow the DATA chunk.

0xFFFFFFFF being invalif as a RIFF length has nothing to do
with signed/unsigend (clearly it is unsigned), but with the
fact that The RIFF length is a even number by the spec.

Also the length of the data chunk is even (that's what the RIFF/WAVE
spec defines). If you have 8 bit mono you have to add a padding byte.

Axel