[FFmpeg-devel] A question about flushing the Vorbis decoder.

Dale Curtis dalecurtis at chromium.org
Thu Jun 12 21:03:36 CEST 2014


On Fri, Jun 6, 2014 at 5:19 PM, Michael Niedermayer <michaelni at gmx.at>
wrote:

> On Wed, Jun 04, 2014 at 05:59:45PM -0700, Dale Curtis wrote:
> >
> > No idea, hence my question :) I will say that not setting that means
> > clients which call flush prior to a seek(0) get a buffer that's not there
> > on the first decoding pass. That said, all future buffers are correctly
> > bit-exact. It's just the extra buffer that I'm curious about.
>
> i guess its better to discard the initial not correct data, so
> suggested change made
>
>
Thanks. I did some further analysis with an ogg file* and this is at least
consistent with what the libvorbis decoder is doing. At least in terms of
the number of decoder frames:

$ ffmpeg -ss 0.1 -i sfx.ogg -f framemd5 - 2>&1 | grep -e ^0, | tee /dev/tty
| wc -l
0,          0,          0,      390,      780,
f5116cf5e0e8c748192c3dfac6991775
0,        390,        390,     1024,     2048,
8afb797452aa59e2facb56cd597b6c4f
0,       1414,       1414,     1024,     2048,
5725e18fb43746ebfb505a3d90d971d0
0,       2438,       2438,     1024,     2048,
f781b97bdedd88c81a8666f4d49cc45d
0,       3462,       3462,     1024,     2048,
e77dd1490708858ae662f8ac7b212090
0,       4486,       4486,     1024,     2048,
57e13053bc3ff3bd810b0a7f9a16212f
0,       5510,       5510,     1024,     2048,
197d5062f5fa7a3d309f0a28798e6ab1
0,       6534,       6534,     1024,     2048,
5a4dce821c10b8975f966c33219b00ff
0,       7558,       7558,     1024,     2048,
4b741d602f61ad75dd131d22f48ebd57
0,       8582,       8582,     1024,     2048,
c99a74c555371a433d121f551d6c6398
0,       9606,       9606,     1024,     2048,
c99a74c555371a433d121f551d6c6398
0,      10630,      10630,     1024,     2048,
c99a74c555371a433d121f551d6c6398
12

$ ffmpeg -acodec libvorbis -ss 0.1 -i sfx.ogg -f framemd5 - 2>&1 | grep -e
^0, | tee /dev/tty | wc -l
0,          0,          0,      390,      780,
9848c71eb7042844d4ff6be07a1cab1b
0,        390,        390,     1024,     2048,
584bf6491134b71af270066dd79b12d2
0,       1414,       1414,     1024,     2048,
37d3e33174a1160997e1d0aa2890e59b
0,       2438,       2438,     1024,     2048,
d840884160d8ab58dd8e2ff3c269c014
0,       3462,       3462,     1024,     2048,
9edcf65f6ba4a12f46c2e0e6f2688c62
0,       4486,       4486,     1024,     2048,
bc23c102400469e7c5933cb5e37d40fd
0,       5510,       5510,     1024,     2048,
0035f8652410fee4562d95eed0d54fef
0,       6534,       6534,     1024,     2048,
76b0b39afdc4e6ab478cd7a236f15c06
0,       7558,       7558,     1024,     2048,
40ddeb9555919182feab822f514fd5a0
0,       8582,       8582,     1024,     2048,
c99a74c555371a433d121f551d6c6398
0,       9606,       9606,     1024,     2048,
c99a74c555371a433d121f551d6c6398
0,      10630,      10630,     1024,     2048,
c99a74c555371a433d121f551d6c6398
12

I couldn't find any documentation/history* on why the first frame is
discarded, but it seems to be correct.

[0]: http://commondatastorage.googleapis.com/dalecurtis-shared/sfx.ogg
[1]:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=0bde73d907dbe684e01bafc979bf4a04ddeace1d
[1.1]: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2005-May/003383.html

- dale


More information about the ffmpeg-devel mailing list