rohc team mailing list archive

[Manuel Iglesias <Manuel.Iglesias@xxxxxxxxxxxx>]

Hi Didier,

The patch works like a charm! :)

Thank you so much,

One thing I was working to crosscompile rohc on my devel PC, I actually could compile the c code without problem, then install library on embedded host, that is working and tested. The problem I have was during the python compile, I could not build the python code on my devel, I was trying to actually build and install using some directive but the build didn't go thru, I end up copying the build dir to embedded host to build python.

Here is the problem I got

usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires'
  warnings.warn(msg)
running build
running build_py
copying rohc.py -> build/lib.linux-x86_64-2.7
running build_ext
building '_rohc' extension
swigging rohc.i to rohc_wrap.c
swig -python -I../../src/common -I../../src/comp -I../../src/decomp -o rohc_wrap.c rohc.i
arm-linux-gnueabihf-gcc -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I../../src/common -I../../src/comp -I../../src/decomp -I/usr/include/python2.7 -c rohc_wrap.c -o build/temp.linux-x86_64-2.7/rohc_wrap.o
In file included from rohc_wrap.c:3051:0:
rohc_helpers.h: In function ‘rohc_comp_rtp_cb’:
rohc_helpers.h:116:3: warning: implicit declaration of function ‘ntohs’ [-Wimplicit-function-declaration]
   if(ntohs(udp_dport) == default_rtp_ports[i])
   ^
rohc_wrap.c: In function ‘_wrap_new_rohc_buf’:
rohc_wrap.c:4011:8: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
   arg1 = PyBytes_AsString(obj0);
        ^
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/rohc_wrap.o -L../../src/.libs -lrohc -o build/lib.linux-x86_64-2.7/_rohc.so

I was using arm-linux-gnueabihf-gcc compiler, which seems to be correctly invoked at first but then it calls the host gcc compiler and since my libraries were compile before with the arm compiler, then it fails.

Not sure if you have done something similar or have any suggestion. Maybe something you have figure out that need to be done that I can contribute, just let me know.

Appreciated!

Best,


Manuel Iglesias

________________________________________
From: Rohc [rohc-bounces+manuel.iglesias=plcpower.com@xxxxxxxxxxxxxxxxxxx] on behalf of Didier Barvaux [didier@xxxxxxxxxxx]
Sent: Saturday, May 21, 2016 2:24 PM
To: ROHC Library
Subject: Re: [Rohc] RTP compare port python binding

Hi Manuel,


> I appreciate your past answer, I haven't tested the patch since I
> remove temporarily the check in rohc_comp.c, specifically I did on
> line 2225
>
> check_profile = true;
>
> commenting the previous assignment, then recompiled rohc.

OK, that works too ;-)

When you got some time, please test if the changes I made work for you.


> I have an issue I would like your comments, my program start one
> compressor and one decompressor instance, the same program runs on
> another host, compressor on one program send to decompressor on the
> other host and vice versa, when I tested with RTP audio in one way at
> a given time it works perfectly, but when I tested with rtp packets
> feeding the compresors on both programs at the same time, the
> decompressor of the starter RTP flow (the one that receives RTP
> packets last but send first) just fails to decompress the first
> packet and of course further packets. Not sure if it might be
> something I am missing or something on the python binding since a
> couple of times during my tests when I change rohc library it didn't
> fail.

According to the logs, the ROHC decompressor fails to decompress the
received packets because they are not IR packets. Indeed, at the
beginning of a new network stream, the compressor shall only send IR
packets.

So, either there is some packet loss between the compressor and the
decompressor, either the decompressor doesn't recognize the IR packets
that the compressor sent.

The 2nd option could be caused by ROHC configuration. Do the compressors
and decompressors share the same configuration (small/large CID,
MAX_CID, WLSB width...) ? If configurations do match, please check your
network for packet loss.

Tell me what you find.

Regards,
Didier