FreeCalypso > hg > gsm-codec-lib

comparison doc/AMR-EFR-philosophy @ 457:9bcf65088006

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/AMR-EFR-philosophy: document implemented solution
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 10 May 2024 18:20:06 +0000
parents 83408f67a96c
children ad032051166a
comparison
equal deleted inserted replaced
456:4c458145e793 457:9bcf65088006
46 ========================================================= 46 =========================================================
47 47
48 I (Mother Mychaela) previously entertained the idea of creating a unified codec 48 I (Mother Mychaela) previously entertained the idea of creating a unified codec
49 library that supports both AMR and EFR with common code, producing a published- 49 library that supports both AMR and EFR with common code, producing a published-
50 source, FOSS-culture equivalent of what most proprietary vendors have done. 50 source, FOSS-culture equivalent of what most proprietary vendors have done.
51 However, on further reflection, that idea has been rejected. The current vision 51 However, on further reflection, that idea has been rejected. The current
52 (as of 2024-04) is that libgsmefr (stable since early 2023) and libtwamr 52 situation as of 2024-05 is as follows:
53 (currently a work in progress) shall remain separate and independent libraries,
54 the former implementing GSM-EFR (the original bit-exact definition) and the
55 latter implementing AMR. My reasons for this decision are:
56 53
57 * Libgsmefr already exists, and it is already a bit of a jewel compared to the 54 * Libgsmefr is our production-oriented implementation of GSM-EFR codec. It
58 sorry state of true GSM codec support in the world of FOSS outside Themyscira. 55 implements the original bit-exact definition of EFR, not the AMR-EFR hybrid
59 Giving up on this library and moving to some nebulous new one does not sound 56 version, and it includes full support for DTX encoding and SID decoding with
60 appealing. 57 comfort noise generation per GSM 06.62.
61 58
62 * There does not exist any formal, bit-exact definition for what we informally 59 * Libtwamr is our librification of 3GPP AMR reference code. The library is
63 call "EFR version 2": the realization of EFR as implemented by post-AMR-era 60 structured in such a way that libtwamr stateful encoder and decoder functions
64 proprietary vendors, some sort of AMR-EFR hybrid. As I see it, it is not my 61 can be combined with stateless EFR frame packing and unpacking functions from
65 place to try to innovate in speech codec design, instead it is my job to 62 libgsmefr, allowing AMR-EFR hybrid encoders and decoders to be built. The
66 provide 100% correct, bit-exact implementations of existing solid standards - 63 decoder homing function in libtwamr can be told to trigger on EFR DHF instead
67 and there is no bit-exact standard to follow for "EFR version 2". 64 of MR122 version, and for the encoder direction there is a simple utility
65 function that artificially transforms MR122 DHF into EFR DHF post-encoder.
66 However, there is no support for AMR-EFR hybrid encoding with DTX enabled,
67 and the low-effort version of AMR-EFR hybrid decoder constructed in this
68 manner cannot grok EFR SID frames or generate CN per GSM 06.62.
68 69
69 * Libtwamr project: the task of turning the original AMR code from 3GPP into a 70 Production implementations of GSM network elements that need to perform EFR
70 proper library, style-consistent with Themyscira libgsmfr2 and libgsmefr, 71 speech transcoding should use libgsmefr, not libtwamr. The limited support
71 without the ugliness of opencore-amr, is already a lot of work as it is. 72 that is provided for AMR-EFR hybrid encoding and decoding with the combination
72 There is no need to make it harder by adding the task of supporting AMR-based 73 of libtwamr and libgsmefr is intended for experimentation and reverse
73 EFR, especially when the latter lacks formal definition. 74 engineering of other people's implementations, for times when it becomes
75 necessary to model, simulate or replicate bit-exact operation of someone else's
76 network element.
74 77
75 Performance issues 78 Command line utilities for AMR-EFR hybrid
76 ================== 79 =========================================
77 80
78 Right now the only significant downside of libgsmefr compared to 81 The present package includes a small set of command line utilities that work
79 libopencore-amrnb is that our library is significantly slower: almost 7 times 82 with the AMR-EFR hybrid described above:
80 slower on non-DTX encode and a little over 3 times slower on SID-free decode. 83
81 However, this performance problem will need to be solved by profiling the code 84 amrefr-encode-r
82 to find the slowest spots, comparing the code of individual blocks between ours 85 amrefr-decode-r
83 and theirs, and porting over whatever performance-optimizing strategies were 86
84 implemented in OpenCORE code base. The latter code base is a derivative work 87 These two utilities function just like gsmefr-encode-r and
85 based on 3GPP AMR source, hence the guts of the codec are largely the same 88 gsmefr-decode-r described in Codec-utils article, but implement the
86 between 3GPP AMR and libopencore-amrnb; the latter has been significantly 89 AMR-EFR hybrid version of the codec instead of original EFR. The
87 performance-optimized, but also heavily uglified. But there is no reason why 90 no-DTX limitation applies: amrefr-encode-r lacks -d option, and the
88 the same performance fixes can't be applied to EFR code base - it will simply 91 input to amrefr-decode-r must not contain any SID frames.
89 take work. This work is currently part of our future roadmap. 92
93 amrefr-tseq-enc
94 amrefr-tseq-dec
95
96 These two utilities are AMR-EFR counterparts to gsmefr-etsi-enc and
97 gsmefr-etsi-dec test programs described in EFR-testing article. They
98 pass all tests on the non-DTX t??_efr.* sequences in ETSI's
99 amr122_efr.zip, but not on any of the DTX sequences included in the
100 same ZIP. Just like amrefr-encode-r, amrefr-tseq-enc lacks -d option,
101 and amrefr-tseq-dec rejects input containing SID frames.