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

[Justin Ruggles]

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.

-Justin