2008-07-23 16:33:27 g729 library questions
Doug Bailey (UNITED STATES)
Message: 59292
I have compiled the test programs for the g729 codec from libbfgdot and was a little confused about the output from the encoder and input into the decoder. This may be due to my lack of experience with this codec. However, The g729 document and Googling have not directed me to an answer that I can use so I am asking here.
As I understand it, the g729 encoder should take 80 16 bit PCM samples (one 10 mS audio segment) and provide me with 80 bits (10 bytes) of coefficients on the output. I would expect this to be a consistent transformation where every encode results in 10 bytes and the decode would result in 80 words.
When I run the test code I see the encoder outputting a header on the encoded stream. The header starts with the magic number 0x6b21 and then has a length count followed by data. Every time I run it, the length output is 160 bytes as opposed to 10 bytes. I noticed that the g729 test vectors also have the header on it and 160 byte payloads.
(See below )
Why would the decoder be outputting a header on the data packets and why are they so long? Also, where does the magic number 0x6b21 that identifies the frame come from?
Regards,
Doug Bailey
===========================================================
READING TEST VECTORS FROM g729ab_test.c:
int fread_a_frame(FILE * file, short *frame)
{
short read_short = 0;
short read_len = 0;
int ret = 0;
short *tmp = frame;
ret = fread(&read_short, 2, 1, file);
if (ret < 1)
return -1;
if (read_short == 0x6b21) {
*tmp++ = read_short;
ret = fread(&read_short, 2, 1, file);
if (ret < 1)
return -1;
/* Get length */
*tmp++ = read_short;
if (read_short == 0) {
return 0;
} else {
read_len = fread(tmp, 2, read_short, file);
if (read_len != read_short)
return -1;
else
return read_short;
}
} else {
fprintf(stderr, "wrong header: 0x%hx\n", read_short);
return -2;
}
return -1;
}
===========================================================================
SAMPLE OUTPUT FROM THE ENCODER (Data was previously all set to 0x5555):
21 6b 50 00 81 00 81 00 81 00 81 00 81 00 7f 00
7f 00 81 00 81 00 7f 00 81 00 81 00 81 00 81 00
81 00 81 00 81 00 7f 00 7f 00 7f 00 7f 00 7f 00
7f 00 7f 00 81 00 7f 00 81 00 7f 00 7f 00 7f 00
7f 00 7f 00 7f 00 7f 00 7f 00 7f 00 7f 00 7f 00
7f 00 7f 00 81 00 81 00 81 00 81 00 81 00 7f 00
81 00 7f 00 81 00 81 00 7f 00 7f 00 7f 00 7f 00
81 00 7f 00 7f 00 81 00 7f 00 81 00 7f 00 81 00
81 00 7f 00 7f 00 7f 00 81 00 7f 00 7f 00 81 00
81 00 7f 00 7f 00 81 00 81 00 7f 00 81 00 7f 00
7f 00 7f 00
QuoteReplyEditDelete
2008-07-23 21:43:49 Re: g729 library questions
Robin Getz (UNITED STATES)
Message: 59295
Doug:
G.729 encoder supports two output modes packed and unpacked. Please see the document I just checked into trunk (in the trunk/uClinux-dist/lib/libbfgdots/g729/doc directory)
To answer - why do we support this inefficient unpacked mode? Well the ITU test vectors use that format, and we like to test with the vectors unchanged after we obtain them from the ITU.
-Robin
QuoteReplyEditDelete
2008-08-04 12:42:07 Re: g729 library questions
Doug Bailey (UNITED STATES)
Message: 59888
Thanks for the information. I've got the library running albeit with some endian translations on the encoded end. (My g729 words had to be translated for incoming and outgoing g729 streams.)
My next question pertains to multithreaded operation. I noticed that the test application used one mutex (g729_mutex) to guard accesses into the g729 library. Is there any way to refine this (e.g. one mutex for encdoing and one for decoding) or is it that the code must be completely locked down when any of the library routines are being executed?
Thanks,
Doug
QuoteReplyEditDelete
2008-08-07 03:26:00 Re: g729 library questions
Yi Li (CHINA)
Message: 60069
The library was not designed with multi-thread in mind, and it uses globals without protection. So using lock is required.
But I am not sure "using one lock for decode and another lock for encode" would work, without looking into the code.