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

[Justin Ruggles]

Axel Holzinger wrote:
> 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.

I'm sorry.  I was not aware of the fact that RIFF chunks are 
16-bit-aligned.  I was essentially reacting to 0xFFFFFFFF being treated 
as -1, which it is not in this case.

-Justin