[FFmpeg-devel] [PATCH] Frame erasure case of pitch delay decoding

[Vladimir Voroshilov]

2009/6/27 Michael Niedermayer <michaelni at gmx.at>:
> On Sat, Jun 27, 2009 at 01:49:49AM +0700, Vladimir Voroshilov wrote:
>> Updated patch.
>>
>>
>> --
>> Regards,
>> Vladimir Voroshilov ? ? mailto:voroshil at gmail.com
>> JID: voroshil at gmail.com, voroshil at jabber.ru
>> ICQ: 95587719
>
>> ?g729dec.c | ? ?7 ++++++-
>> ?1 file changed, 6 insertions(+), 1 deletion(-)
>> c66e04bc9abc50854d2bd35ac5299ae0e4b28637 ?0005-Frame-erasure-support-for-pitch-delay-decoding.176.patch
>> From aa4b23873bc3c5e103a5756ade017558bda12961 Mon Sep 17 00:00:00 2001
>> From: Vladimir Voroshilov <voroshil at gmail.com>
>> Date: Thu, 11 Jun 2009 13:51:28 +0700
>> Subject: [PATCH 05/25] Frame erasure support for pitch delay decoding
>>
>>
>> diff --git ffmpeg-r19281/libavcodec/g729dec.c ffmpeg-r19281_v176/libavcodec/g729dec.c
>> index b937235..f193123 100644
>> --- ffmpeg-r19281/libavcodec/g729dec.c
>> +++ ffmpeg-r19281_v176/libavcodec/g729dec.c
>> @@ -306,7 +306,9 @@ static int decode_frame(AVCodecContext *avctx, void *data, int *data_size,
>> ? ? ? ? ?gc_1st_index ?= get_bits(&gb, format.gc_1st_index_bits);
>> ? ? ? ? ?gc_2nd_index ?= get_bits(&gb, format.gc_2nd_index_bits);
>>
>> - ? ? ? ?if(!i) {
>> + ? ? ? ?if (frame_erasure)
>> + ? ? ? ? ? ?pitch_delay_3x ? = 3 * ctx->pitch_delay_int_prev;
>> + ? ? ? ?else if(!i) {
>> ? ? ? ? ? ? ?if (bad_pitch)
>> ? ? ? ? ? ? ? ? ?pitch_delay_3x ? = 3 * ctx->pitch_delay_int_prev;
>
> if(!i || frame_erasure)
>
> also, i think bad_pitch and frame_erasure are redundant that is the same
> either your frame is damaged or not
> If you disagree, id like to hear which real life system uses g729 and
> can suffer from single bit errors not passing through a FEC code
> (that stuff might exist but my gut feeling says it does not, so unless
> ?you have an example i prefer the simpler code)

Afaik, bad_pitch is rsult of checking most significant part of input
parameters: vector of quantizer
along with switched MA predictor. Getting garbage here will cause
large quality degradaion.
On the other side remaining parts will bring far less noise.
I can guess that having something data in frame (even with bad vector
of quantizer) from the standpoint of G.279 authors is still better
than entire frame erasure.

If you can see in case of frame erasure pitch delay is computed
differently for both subframes, while bad_pitch
keeps computing of pitch_delay for second subframe the same.

And here we again comes to the question about bitexactness.
If it is possible i prefer creating decoder which passes all ITU
tests, and ONLY after that
break it (decoder) by introducing desired optimizations.

>
> [...]
> --
> Michael ? ? GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
>> ... defining _GNU_SOURCE...
> For the love of all that is holy, and some that is not, don't do that.
> -- Luca & Mans
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFKRVevYR7HhwQLD6sRAgGDAJ0WLw8HcwzXoo4clePuZkfelekEeQCeMUcl
> AQUgNRaokZUQVf03YdKWyeQ=
> =uVoS
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



-- 
Regards,
Vladimir Voroshilov     mailto:voroshil at gmail.com
JID: voroshil at gmail.com, voroshil at jabber.ru
ICQ: 95587719