G.729a compression problem in gcc compiler

umesh.gk

Member
Joined
Jul 14, 2008
Messages
11
Reaction score
0
Hello,

We had downloaded the open source code for G.729 from the link http://www.itu.int/rec/T-REC-G.729/e .

We are using g729AnnexA, upon compiling and installing the the coder in gcc compiler we obtained a binary file.

Later we passed a 16bit mono PCM data (16bit.raw) into the g729 coder

./coder 16bit.raw sample.raw

but on giving the above command, instead of we getting a compressed data of of sample.raw some more extra data got added to it!!!

the raw data size were 16bit.raw (60KB) and sample.raw (61KB).

We were not able to compress the data even on encoding it..., is there any changes we have to make in the open source code of g729a.

Regards,

umesh
 
Your program may have compiled correctly. The file sample.raw is an unpacked bitstream file as specified by the ITU standard. You may need to convert it to a compressed format such as RTP and then uncompress it again before decoding it if you want to reduce the file size.
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/5480986.aspx
http://www.dsprelated.com/groups/speechcoding/show/1112.php

If the program is working correctly then the command coder test.inp test1.bit should produce an exact copy (test1.bit) of the test.bit file that is included with the C source files. Similarly decoder test1.bit test1.syn should produce an exact copy (test1.syn) of the included file test.syn. If this is the case then everything is working correctly.

The bitstream format is described in the read.me file that comes included with the C source files of the ITU G.729 Annex A zip archive i.e 0x6b21 represents a Sync Word, 0x007f represents a zero bit in the bitstream while 0x0081 represents a one bit. Just use a hex editor to study the test.bit file carefully. Maybe you could use the VoiceAge encoder to compress the test.inp file and see if you can work out how to convert the test.bit file into the compressed format of the VoiceAge encoder.

Here is an example of some code to convert from RTP to bitsream format. You need to convert from bitstream to RTP. (I think that 0x71 should be a 0x7f near the end).
http://archives.devshed.com/forums/...real-rtpdump-and-voiceagedecoder-1911599.html
 
Last edited:
Hi Yotch,

in the link http://archives.devshed.com/forums/n...r-1911599.html , while converting from rtp to bitstream , should we have to wirte a code to remove the RTP headers or do we have to retain the RTP headers ?

in the code given ,

qbyte 1;
}
}
fwrite (out , 1 , lSize * 16, fileout);

what is the purpose of qbyte 1, is there anything missing in the code ??

after converting from rtp to bitstream do we have to insert the Sync word (0x6b21) ??

Regards,

Umesh G.K.
 
@umesh: You must just discard the Sync Word 0x6b21 and the Frame Size 0x0050 characters and only retain the binary digits. If you look at the test.bit file using a hex editor and you convert the first few strings into binary it should look like this: 0111 1000 0101 0010 etc. You then need to convert the binary byte by byte into ascii i.e.the ascii character corresponding to (0x78 (x) followed by 0x52 (R) ) etc.

Here is the test.bit file converted into RTP so that you can check your algorithm. You should be able to play it successfully using the Voice Age decoder as follows:
va_g729_decoder test.rtp test.raw
sox -w -s -r 8000 test.raw test.wav
http://www.yousendit.com/download/Q01IMWZEaytWRCt4dnc9PQ

I haven't tried that algorithm myself - I only included it to give you an idea about how to do the conversion process. You should also try to encode the test.inp file using the Voice Age encoder and then compare your RTP file with the VA one using a hex editor i.e. va_g729_encoder test.inp test1.rtp. You should find that the two files are quite different. It would appear that either the VA algorithm is rescaling the PCM file before encoding it or that the floating point version of the ITU code works a bit differently from the fixed point version. On playback though both files sound very similar. You could use a sound editor to compare them to see if there are any noticeable differences. The VA encoder might boost certain frequencies to improve the final sound quality.

Once you have working routines to convert back and forth between bitstream and RTP formats you can use this online Voip tool to convert your G.729 RTP files into uncompressed pcm16 to confirm that your software is working correctly. The wav file conversion does not appear to be functioning at the moment.
http://www.asteriskguru.com/tools/audio_conversion.php

This link mentions the floating point G.729 routines and PCM scaling.
http://www.dsprelated.com/groups/speechcoding/show/247.php
Here are some ideas about using inlining to improve the performace of the ITU routines.
http://www.dsprelated.com/groups/speechcoding/show/488.php
 
Last edited:
bit stream to rtp conversion

Hello Yotch,

Sorry for the delay,

I have written a program to convert bit stream file to rtp file,

#include<stdio.h>
#include <sys/time.h>
#include <netinet/in.h>
#include "rtp.h"
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <errno.h>

#define EIGHTY_WORDS 160 /* 80 words of data */
#define PAYLOAD_SIZE 155 /**Assuming the payload size to be 155 bits**/

#define tv2dbl(tv) ((tv).tv_sec + (tv).tv_usec / 1000000.0)
#define dbl2prnt(x) ((int)((long)(x))) ((int)(((int)(1000000.0*((double)(x))))%((int)1000000)))


int main(int argc,char **argv){
FILE *binary_fp;
FILE *obinary_fp;
FILE *rtp_fp;

if(argc!=4){
printf("./bit_rtp <file1.bit> <file2.bit> <file3.rtp>");
exit(0);
}

binary_fp=fopen(argv[1],"rb");
if(binary_fp==NULL){
printf("The file could not opened");
exit(0);
}

obinary_fp=fopen(argv[2],"wb");
if(obinary_fp==NULL){
printf("Target file cold not be opened");
exit(0);
}

/**Creating a file which does not have the Sync and the Frame size**/

int i;
char ch;

printf("\n Entering into the mode to remove Frame size and SYNC word \n");

while(1){
fseek(binary_fp,4,SEEK_CUR); //skipping the frame and sync words
if((ch=fgetc(binary_fp))==EOF)
break;
fseek(binary_fp,-1,SEEK_CUR);

for(i=0;i<EIGHTY_WORDS;i++){
ch=fgetc(binary_fp);
fputc(ch,obinary_fp);
}//End of buffering

}//End of while

printf("\n A file has been created with no frame size and SYNC word \n");

fclose(binary_fp);
// fseek(obinary_fp,0L,SEEK_SET);
// rewind(obinary_fp);
fclose(obinary_fp);

/**RTP header format**/
rtp_hdr_t pkt;
pkt.v=2;
pkt.p=0;
pkt.x=0;
pkt.cc=4;
pkt.m=1;
pkt.pt=7;
pkt.seq=1;

struct timeval tv;
struct timezone tzp;
gettimeofday(&tv, &tzp);
pkt.ts=tv2dbl(tv);
pkt.ssrc=0;
pkt.csrc=0;
pkt.xtnhdrp=0;


rtp_fp=fopen(argv[3],"w");
if(rtp_fp==NULL){
printf("The file2 could not be opened");
exit(0);
}

obinary_fp=fopen(argv[2],"rb");

printf("\n Entering into the mode of constructing packet size rtp data \n");

int j=0;

while(1){
ch=fgetc(obinary_fp);
if(ch==EOF)
break;
fseek(obinary_fp,-1,SEEK_CUR);

/**Constructing an rtp packet of payload 155 bits**/

fprintf(rtp_fp,"%u %u %u %u %u %u %u %u %u %u%u",pkt.v,pkt.p,pkt.x,pkt.cc,pkt.m,pkt.pt,pkt.seq,pkt.ts,pkt.ssrc,pkt.csrc,pkt.xtnhdrp);

/**Constructing payload of 155 bits**/

for(i=0;i<PAYLOAD_SIZE;i++){

ch=fgetc(obinary_fp);
if(ch==EOF){
for(j=i;j<PAYLOAD_SIZE;j++)
fputc(0,rtp_fp);
break;

}
else
fputc(ch,rtp_fp);

}//End of constructing the 155 bits data

}//End of while

printf("\nThe file conversion to rtp is completed \n");

fclose(obinary_fp);
fclose(rtp_fp);

}//End of main();

/******************************************************************************************/

and the rtp header file is,

#ifndef _RTP_H_
#define _RTP_H_

#include <sys/socket.h>
#include <sys/types.h>

/*
* RTP payload types
*/
typedef enum {
RTP_PCMU = 0,
RTP_GSM = 3,
RTP_G723 = 4,
RTP_PCMA = 8,
RTP_CN = 13,
RTP_G729 = 18,
RTP_TSE = 100,
RTP_TSE_CISCO = 101
} rtp_type_t;

#define RTP_NSAMPLES_UNKNOWN (-1)

/*
* RTP data header
*/
typedef struct {
//#if BYTE_ORDER == BIG_ENDIAN
unsigned int v:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
//#else
// unsigned int cc:4; /* CSRC count */
// unsigned int x:1; /* header extension flag */
// unsigned int p:1; /* padding flag */
// unsigned int version:2; /* protocol version */
// unsigned int pt:7; /* payload type */
// unsigned int m:1; /* marker bit */
//#endif
unsigned int seq:16; /* sequence number */
uint32_t ts; /* timestamp */
uint32_t ssrc; /* synchronization source */
uint32_t csrc; /* optional CSRC list */
uint32_t xtnhdrp; /* extension header*/
} rtp_hdr_t;

struct rtp_packet {
size_t size;

struct sockaddr_storage raddr;
socklen_t rlen;
size_t data_size;
int data_offset;
int nsamples;
uint32_t ts;
uint16_t seq;
int resizeable;
double rtime;

struct rtp_packet *next;
struct rtp_packet *prev;

/*
* The packet, keep it the last member so that we can use
* memcpy() only on portion that it's actually being
* utilized.
*/
union {
rtp_hdr_t header;
unsigned char buf[8192];
};
};

#define RTP_HDR_LEN(rhp) (sizeof(*(rhp)) + ((rhp)->cc * sizeof((rhp)->csrc[0])))

void rtp_packet_parse(struct rtp_packet *);
struct rtp_packet *rtp_recv(int);

struct rtp_packet *rtp_packet_alloc();
void rtp_packet_free(struct rtp_packet *);
void rtp_packet_set_seq(struct rtp_packet *, uint16_t seq);
void rtp_packet_set_ts(struct rtp_packet *, uint32_t ts);

size_t rtp_samples2bytes(int codec_id, int nsamples);

#define ts_less(ts1, ts2) (((ts1) - (ts2)) > (uint32_t) (1 << 31))

#endif


is this what you had asked me to do ??

Yotch, I had one doubt, how does one achieve a compressed file on converting a bit stream file to rtp file ??? Please help!!!
 
Last edited:
@umesh: I'm not sure whether or not I am answering your question.

The unpacked bitstream file that the ITU routines produce consists of a combination of just four strings - a Sync Word (0x6b21), a Frame Size (0x0050), a Zero Bit (0x007f) and a One Bit (0x0081). This file can be packed into a compressed RTP type format in order to achieve maximum compression. Most of the G.729 routines such as the VoiceAge routines store the compressed sound files as an RTP payload without any header information. I was trying to explain how to do this.

Here is the hexadecimal representation of the first few lines of ascii characters of the test.bit file that comes included with the ITU routines. I am using the hexadecimal representation as it is very unlikely that this forum will be able to display the corresponding ascii characters correctly.

21 6B 50 00 7F 00 81 00 81 00 81 00 81 00 7F 00 7F 00 7F 00 7F 00 81 00 7F 00 81 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 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 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 21 6B 50 00 7F 00 81 00 7F 00 81 00 7F 00 81 00 81 00 81 00 7F 00 7F 00 81 00 81 00 81 00 7F 00 7F 00 81 00 81 00 7F 00 7F 00 7F 00 7F 00 81 00 7F 00 7F 00 7F 00 81 00 7F 00 81 00 81 00 81 00 81 00 81 00 81 00 81 00 81 00 7F 00 81 00 81 00 81 00 81 00 81 00 81 00 81 00 81 00 81 00 7F 00 81 00 7F 00 81 00 81 00 7F 00 81 00 81 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 7F 00 7F 00 7F 00 81 00 81 00 81 00 81 00 81 00 81 00 7F 00 7F 00 etc.

If you ignore all the Sync Word (21 6B) and Frame Size characters (50 00), this data stream can be compressed down to the following 20 byte hexadecimal representation of the corresponding 20 character ascii string.
78 52 80 A0 00 FA C2 00 07 D6 57 39 84 5F EF FA DD 00 00 FC etc.

(The first 8 words (ignoring the Sync and Frame characters) of the top string 7F 00 81 00 81 00 81 00 represent 0111 in binary or 7 in hex, the second 8 words 81 00 7F 00 7F 00 7F 00 represent 1000 in binary or 8 in hex, the third 8 words 7F 00 81 00 7F 00 81 00 represent 0101 in binary or 5 in hex, the fourth 8 words 7F 00 7F 00 81 00 7F 00 represent 0010 in binary or 2 in hex etc.) 78 in hex can then be represented by the ascii character 'x' while 52 can be represented by 'R' etc. and hence the lengthy string above can be compressed down to an equivalent 20 character ascii string. You need to write a few lines of code to automate this conversion procedure in order to pack the bitstream files into this format if you want to achieve maximum compression. You presumably also need to write a routine to convert the packed bitstream file back into the original uncompressed form so that you can use the ITU decoder to play back compressed G.729 voice files. In this case you need to insert the Sync Words and Frame Length characters in the appropriate positions in the file and to convert the ascii characters back into Zero Bit and One Bit characters.

In the code that you provided above it appears that you are attempting to add RTP headers to the bitstream. I'm not exactly sure of your application but the addition of RTP headers will of course increase the file size. In Voip applications the addition of headers increases the bandwidth demands substantially. If you can explain exactly what type of bitstream you are trying to produce with some sample files I might be able to help further. It might be easier if you have a sample bitstream that you can analyse with a hex editor.

There is a commercial version of the fixed point ITU G.729A routines which you can download from here (just cancel the Chinese download) - http://www.imtelephone.com/EasyG729A.html. These routines should produce bit for bit identical results (often referred to as 'bit exact') to those from the ITU routines that you are working on in the packed format described above. You could try to compare the output from these routines to confirm that your routines are functioning correctly using the following command - test_encode test.inp test.rtp. The file test.rtp will consist of the packed bitstream that you are trying to construct from the ITU routines and should be identical to the one that I constructed in the yousendit link above. Post again if you are still having problems.
 
Last edited:
achieved the compression strength.

Hi yotch,

I followed the steps which you had asked me to do, I achieved the good compression strength. Later I decompressed the file and played it in my headphones and it played.

following is the steps followed ,
a.converted a wave file to raw, used g.729A coder to convert the file into bit file.
1.remove_frame_sync.c (is to remove the the frame and sync word from the file)
2.compress.c(is to compress the file)
3.decompress.c(is to decompress the file)
4.insert_frame_sync.c(is to insert the frame and the sync word into the file).
b.used the g.729A decoder to convert the bit file to raw, and later converted the raw file to wave file to play it in my headphone.

now I am trying to convert the compressed the file to rtp and bind to udp and send it to the voip phone to play it, will this file play in the phone ???
 
Last edited:
@umesh: I have never tried to send an RTP stream directly to a softphone myself but you might be able to use rtptools from this link to do this. Let us know if you have any luck.
http://www.cs.columbia.edu/irt/software/rtptools/

I would then try to construct a file (sample.txt) looking something like this (one packet per line).

1.050000 RTP len=22 v=2 p=0 x=0 cc=0 m=0 pt=18 seq=54554 ts=3988999648 ssrc=0x59c72 data=785280a000fac20007d6
1.060000 RTP len=22 v=2 p=0 x=0 cc=0 m=0 pt=18 seq=54555 ts=3988999728 ssrc=0x59c72 data=5739845feffadd0000fc
1.070000 RTP len=22 v=2 p=0 x=0 cc=0 m=0 pt=18 seq=54556 ts=3988999808 ssrc=0x59c72 data=e0640b9dc6e35d8c0a56
1.080000 RTP len=22 v=2 p=0 x=0 cc=0 m=0 pt=18 seq=54557 ts=3988999888 ssrc=0x59c72 data=b4a1ae751bc3d987fbc0
1.090000 RTP len=22 v=2 p=0 x=0 cc=0 m=0 pt=18 seq=54558 ts=3988999968 ssrc=0x59c72 data=f00291bd35c8a7baa6c3
1.100000 etc.
1.110000 etc.

Make sure that the times in the first column increase regularly by 10ms, the sequence numbers (seq) by 1 unit and the timestamps (ts) by 80 (i.e. 8000Hz * 10ms) for each packet. Then add the complete G.729 payload in hex in 10 byte pieces in sequence using lower case characters. The packet length (len) should comprise the 12 byte packet header together with the 10 byte G.729 frame. Take a look at this link for more details about the header parameters.
http://www.cs.columbia.edu/~hgs/rtp/faq.html#lite

Start up the softphone and then try to send the RTP packets to the softphone RTP port (5000) using the command
rtpsend -f sample.txt 192.168.1.103/5000 (use your own IP address and softphone RTP port).

If this doesn't work you can try to capture the RTP stream that is being sent by the rtpsend utility using this command
rtpdump -F dump -o sample.rtp 192.168.1.103/5000 (use your own IP address / RTP port).

You should also find a file called bark.rtp together with the RTP tools. You can convert it into a more readable form using the command rtpdump -F hex -f bark.rtp -o bark.txt
You can then study bark.txt carefully to understand the rtpsend format.

The softphone must of course support the G.729 codec. You could perhaps try Firefly together with the G729.dll from these links. You would then need to configure the softphone to use only G.729, set the RTP port to 5000 etc.
http://www.dslreports.com/forum/r20768334-General-MiniPax-softphone-free-and-g729
Two other free G.729 compatible softphones ...
http://www.bol2000.com/website_e/download.htm (SIPPhone 1.6)
http://www.vidosystem.com/sip_softphone.htm

Unfortunately QuickTime, JMF JMStudio, VLC etc. do not support the G.729 codec otherwise playback of the RTP stream would be very simple.
http://ethereal.archive.sunet.se/lists/ethereal-users/200401/msg00264.html
 
Last edited:
Hi yotch,

I used the rtp tool 1.18 , after compiling and installing the tool, I gave the command
rtpsend -f file.rtp 192.168.11.250/5000 (softphone IP address and softphone RTP port).

got an error:
line H>>u is invalid.

could you please help me out in solving this error!!!

and in the sample.txt constructed file, is the first column
1.050000 RTP len=22 v=2 p=0 x=0 cc=0 m=0 pt=18 seq=54554 ts=3988999648 ssrc=0x59c72 ...
1.060000
1.070000
1.080000
required in the file, because at the receiving end what purpose will the first column help us in... ???
 
@umesh: Are you transferring a text file with rtpsend or an RTP one? rtpsend requires a text file such as sample.txt while rtpplay expects an ascii RTP dump file. What kind of file is file.rtp in your post above?

Here are three files that you can use to test your rtpsend, rtpplay and rtpdump routines - sample.inp, sample.rtp and sample.hex. The file sample.inp is just a text file but the .txt extension gives problems with yousendit.
http://www.yousendit.com/download/bVlETkFpeFVIcWRjR0E9PQ
http://www.yousendit.com/download/bVlETkF2YWJKV00wTVE9PQ
http://www.yousendit.com/download/bVlETkF2YWIwZ2xFQlE9PQ
The file sample.rtp was captured from sample.inp using rtpdump as follows. rtpdump -F dump -o sample.rtp 192.168.1.103/5004 (use your own IP address / RTP port etc.)
rtpsend -f sample.inp 192.168.1.103/5004
Rtpdump must be running in the background before executing the rtpsend command - use Ctrl C to end the rtpdump session. The G.729 data comprises the packed ITU test.bit file.

I think that you do need to include the column of time values that you referred to above otherwise the rtpsend program may terminate with an error - the format appears to be very specific i.e. no extra space at the beginning of new lines or before and after =, no missing data, alignment problems etc.

You really need to get all three utilities working correctly. I'm not sure whether your error is being caused by a source problem or as a result of an incompatible text file format. Try to run rtpsend with the sample.inp file as this format is correct.

If you can't get rtpsend to work you can also use rtpplay. rtpplay requires a file in the rtpdump format i.e. sample.rtp. You need to enter the command -
rtpplay -f sample.rtp 192.168.1.103/5004 etc.

You could also try to capture an RTP stream from a phone conversation using your softphone. You need to have rtpdump running in the background before initiating a call as above (rtpdump -F dump -o phone.rtp 192.168.1.103/5004). You can then compare the rtpdump file that is produced by the softphone with sample.rtp to see if you need to make any changes such as to the ssrc (0x059c72). You might need to change this before the softphone will replay your rtp stream as this number may be chosen randomly for each conversation. You would probably have to change the string during a phone conversation and then send the rtp stream to the softphone to achieve playback.

Here are the first 3 packets of sample.rtp in rtpplay dump format (shown in hex).
31 36 38 2E 31 2E 31 30 30 2F 33 36 31 31 35 0A 48 BD C0 32 00 09 00 B7 C0 A8 01 64 13 8D 89 33 (preamble)
00 1E 00 16 00 00 BC F4 80 12 01 F4 00 00 11 CC 00 05 9C 72 78 52 80 A0 00 FA C2 00 07 D6
00 1E 00 16 00 00 BD 55 80 12 01 F5 00 00 12 1C 00 05 9C 72 57 39 84 5F EF FA DD 00 00 FC
00 1E 00 16 00 00 BD DF 80 12 01 F6 00 00 12 6C 00 05 9C 72 E0 64 0B 9D C6 E3 5D 8C 0A 56

See here for more details about the RTP header format - http://www.geocities.com/intro_to_multimedia/RTP/header.html
The rtpplay dump format includes additional information such as the column of time values that you mentioned above. The format consists of a 32 byte preamble (ignore this) followed by a variable number of packets (hex values have been included for the first packet of sample.rtp for illustration purposes) -
2 byte size (00 1E=22+8 bytes), 2 byte len (00 16=12+10 bytes), 4 byte time (00 00 BC F4=48372ms), 1 byte (80 -> v=2 (2 bits), p=0 (1 bit) x=0 (1 bit), cc=0 (4 bits)), 1 byte (12 -> m=0 (1 bit), pt=18 (7 bits)), 2 byte ssn (01 F4=500), 4 byte ts (00 00 11 CC=4556), 4 byte ssrc (00 05 9C 72=0x059c72), 10 byte G.729 payload (78 52 80 A0 00 FA C2 00 07 D6) etc. The rtpplay dump format inserts an extra 8 bytes in front of the standard 22 byte RTP packet.

See the note above for bark.rtp for details on how to use rtpdump to translate the dump format into the hex rtpsend type format (sample.hex). The column of time values in sample.hex does not increase regularly by 10ms for each packet - I'm not sure why not but this shouldn't affect the RTP file as they aren't required as you mentioned above. I think rtpsend and rtpplay strip out this information before sending the RTP packets.
 
Last edited:
Hello Guys, seems like on the whole google only this thread got some info regarding g729 implementation. I did try to implement ITU g729 and seems like i passed all the test vectors. But when I try to test the third party generated g729 decoding from asteriskguru it produce me distorted sound like metalic scrambled. I am attaching my code which decompress th g729 first and then send that to decoder. the decompression coded is attached here. Any help will be appreciated.


void covertBit2Serial(Word16 *input, Word16 *output){
output[0]=SYNC_WORD;
output[1]=SIZE_WORD;
int outIndex =2;
int i,j;
Word16 Mask;
for (i=0;i<5;i++){
for(j=0;j<16;j++){
Mask = 0x0001 << (15-j);

printbits(Mask);
printbits(input);
if ((Mask | input) == input){
output[outIndex++] = BIT_1;
printf("in if\n");
//getchar();
}
else{
output[outIndex++] = BIT_0;
printf("in else\n");
}
}

}
}
 
@iajdani: You first need to uncompress the packed bitstream into the unpacked ITU format. These two files together with the description in post #6 above should illustrate the process. Post again if you are still unsure how to proceed. Your program must be able to convert test.rtp into test.bit.

test.rtp
http://www.youconvertit.com/Download/DownloadPreview.aspx?fg=D798f6598-6ba8-48a3-9896-bcb1c88bd20a
test.bit
http://www.youconvertit.com/Download/DownloadPreview.aspx?fg=D873169b3-2369-4b71-a2f4-e64f6d8210c3
 
Top
Sign up to the MyBroadband newsletter
X