[FFmpeg-devel] [PATCH] WMA Lossless: reset channel residues between subframes
qbast at go2.pl
Sat Apr 14 20:38:58 CEST 2012
W dniu 2012-04-14 19:29, Mashiat Sarker Shakkhar pisze:
> On 4/14/2012 8:25 PM, Jakub Stachowski wrote:
>> By the way: does anybody know if WMA stream contains exact number of
>> samples? I tried to fix decoder cutting off last packet from decoded
>> data (due not not handling 'flush'), but now have opposite problem -
>> last frame is always full length (2048 samples) padded with zeros and I
>> found no good way of determining how many samples are valid.
> Supposedly there is a way, although I don't know if it works that way in
> practice. Let me know if the following method works for you:
> Every WMAL frame has a fixed number of samples - samples_per_frame in
> our decoder. Now after you have finished decoding the very last frame,
> you may have additional rounding-off samples. In theory, the get_bits1()
> at line 1056 will return 1 in such cases. Then you will know how many
> samples to prune from the end of the last frame. (So the last frame size
> will be samples_per_frame - skip in this case.)
> I'd be glad if you could try it and reply with result.
For first test I used WMA file from bug #1055:
Decoded with dBpoweramp or Microsoft's wmal2pcm.exe I got 1410612 samples.
Decoded with ffmpeg (without taking skip value): 1413120
During decoding last frame, get_bits1() returned 460 samples to skip.
Difference is 2048+460 samples, so it should skip one full frame (I
wonder which one) and 460 from last one?
Next test: hand-crafted file with 15000 samples. All of them zeros apart
from last 14 bytes, then encoded with MS Expression Encoder
wmal2pcm.exe decoded it perfectly
ffmpeg after taking skip value into account also created file with right
length, however all samples were 0 (last 14 non-zero bytes got destroyed).
So it is step in right direction, but not completely correct yet.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel