[FFmpeg-devel] [PATCH] Common ACELP code & G.729 [4/7] - G.729 core

Michael Niedermayer michaelni
Sat Oct 18 01:19:15 CEST 2008


On Sat, Oct 18, 2008 at 01:55:24AM +0700, Vladimir Voroshilov wrote:
> 2008/10/17 Michael Niedermayer <michaelni at gmx.at>:
> > On Fri, Oct 17, 2008 at 03:14:27PM +0700, Vladimir Voroshilov wrote:
> >> 2008/10/17 Michael Niedermayer <michaelni at gmx.at>:
[...]
> >> According to above the best way will be just dropping it completely
> >> (but i whould prefer keeping format structure as is, because it will
> >> be necessary when G.729 will be added).
> >>
> >
> >> I am also not against dropping BFI code, since i feel myself having
> >> poor knowledge to compare it with other frame erasure algorithms.
> >> (But with BFI speech is understandable with 50% of input packets loss,
> >> afair. I can made this simple test again, if you wish).
> >
> > and is it better or worse than repeating the previous packet?
> 
> I've made dumb test: each second frame was assumed "bad".
> 
> Original sound (all samples are raw 8kHz, 1 channel audio):
> http://doors.univer.omsk.su/~voroshil/downloads/SPEECH.BIT.ffmpeg.sw
> 
> Repeating previous "good" frame:
> http://doors.univer.omsk.su/~voroshil/downloads/SPEECH.BIT.ffmpeg.sw.fc
> 
> Frame erasure flag for "bad" frame:
> http://doors.univer.omsk.su/~voroshil/downloads/SPEECH.BIT.ffmpeg.sw.fe
> 
> The latter sounds a bit better for me even if it
> quieter (since algorithm reduces signal power on broken frame).

well, if it sounds better then lets keep it for now


> 
> >> >
> >> > [...]
> >> >> @@ -138,6 +531,108 @@ static inline int g729_get_parity(uint8_t value)
> >> >>                  14,
> >> >>                  ctx->subframe_size);
> >> >>
> >> >> +        memcpy(synth, ctx->syn_filter_data, 10 * sizeof(int16_t));
> >> >
> >> > there are 2 memcpies copying this around, i dont see why it would need 2.
> >>
> >> I'll try to describe this as much as i understand it.
> >>
> >> Well... Synthesis filter can be written as
> >> in[i]=sum{a[k]*out[i-k]},k=0..filter_order, i=0..subframe_size-1
> >> where a[k] - filter coefficients, a[0] == 1, in[i] - input, out[i] -
> >> output signal data
> >>
> >> Due to optimization, a[0] is eliminated and filter (in code) is implemented as:
> >> buf[i]=buf[i] - sum{a[k]*buf[i-1-k]}, k=0..filter_order-1
> >>
> >> Thus, i need a buffer of length subframe_size+(filter_order-1).
> >> But... the top of this buffer must contains k-1 samples from the end
> >> of previous filter run result.
> >> Brrr. I mean:
> >> buffer after Nth call:
> >> (0),..,(k-1),(k),..,[(subframe_size-k),..,(subframe_size-1)]
> >>
> >> buffer before (N+1)th  call:
> >> [(0),..,(k-1)], (the rest is garbage yet)
> >>
> >> data in brackets must be the same.
> >
> > fine, so much i knew alraedy, that makes it one memcpy from the end to the
> > start, not 2
> 
> This is true only when one filter is used (see below).
> 
> >> When synthesis filter is single filter working with this buffer, there
> >> is enough one memmove.
> >> Unfortunately there are also high-pass filter and postfilter, which
> >> also changes buffer.
> >> So, i have to save synthesis filter output data before passing them
> >> to below filters and restore saved
> >> data back before next call to synthesis filter.
> >
> > IIRC (ive not rechecked the code)
> > there is data for 2 subframes
> > [0..k] frame0 frame1
> > by the time frame1 is done the memcpy would move the data from frame1
> > over frame0, i thought this would not affect subsequent steps run over
> > frame1?
> 
> Let's assume this order (subframe1 and subframe2 are processed by two
> iterations of "for" loop inside one decoder call):
> frame0_subframe1,frame0_subframe2,frame1_subframe1,frame1_subframe2
> 
> Assume also that we are just finished synthesis filtering of
> frame1_subfram2 and want to save data.
> 
> If you put memmove before high-pass filter  you'll pass wrong input to
> it (you'll pass just memmove'd end of the frame1_subframe2 instead of
> expected end of frame0_subframe2).
> If you put memmove after high-pass filter, synthesis filter will
> receive (in next iteration) the end of frame1_subframe2 (as it
> expects) but data will be already modified by high-pass filter.
> 
> In any case you'll broke either synthesis or high-pass filter.

IIRC I have explained how precissely a generic feedback free chain of filters
can be implemented with a arbitrary small number of memcpies.
Iam not at all interrested in arguments based on the broken buffer design of
your current implementation.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081018/9886c607/attachment.pgp>



More information about the ffmpeg-devel mailing list