On Fri, 2 Dec 2011, Martin Storsjö wrote:
On Thu, 1 Dec 2011, Justin Ruggles wrote:
On 12/01/2011 06:24 PM, Martin Storsjö wrote:
Earlier, bits per sample was defined as 8, which wasn't chosen
with any thought, only chosen since it didn't seem to change
anything compared to not defining it at all.
g722 encodes 2 samples into one byte codeword, therefore the
bits per sample is 4. By changing this, the generated timestamps
for streams encoded with g722 become correct.
While technically true, this causes problems with WAV. In WAV files, the
bits-per-sample field in the header is supposed to be 8 (or 7 or 6) not
4. So we need an override for g722 in the WAV header writing function in
lavf to write the correct value.
Yeah, I came to think of this detail right after posting the patch - I guess
I chose 8 since it was the default for the "number of bits per
codeword/sample pair", which the decoder uses - my patch also makes the raw
g722 decoder set bits_per_coded_sample to 4, which gives warnings in the
decoder, which I realized after posting it.
FWIW, changing it to 4 makes the raw g722 demuxer generate proper
timestamps for input data, too. But I'm not sure any such data really
exists in the wild other than for testing the codec, so it's not an
important usecase. The raw g722 demuxer's requirement of a non-zero
bits_per_coded_sample was what triggered the addition of the definition in
the first place (in 029f966c3aa73531a90cb14ca95057f2fb3f0a26).
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
