Hi , For the final question I mean that; Since increasing "lsb_width " results less decompress ratio, we want to adjust "lsb_width " dynamically according to network quality conditions. For examle initially I use "lsb_width " = 256 and if network quality become better I will set it to 16 while related compressor is in progress. For the "lsb shift ", I think with new version " reorder_ratio " parameter will satisfy us, because for example ratio 1/2 will generate always the half of "lsb_width ", so there will be no need to change " lsb shift ", changing "lsb_width " will change "lsb shift " automatically.
Best Regards... 2018-02-19 16:27 GMT+03:00 mehmet sulak <mehmet.su...@gmail.com>: > Hi, > > Is it possible to make "ROHC_WLSB_WIDTH_MAX 256U" in the next release so > that a wide range of width values can be used in > rohc_comp_set_wlsb_window_width() method? > > Is it possible to make "rohc_lsb_shift_t" values parametric in next > release ? I mean to make lsb shift values parametric so that users can set > any shift value from a related parameter? > > Final one is; is it possible to change lsb_width and shift values > dynamically while related compressor/decompressors are in progress? > > Best Regards... > > > 2018-02-12 14:39 GMT+03:00 mehmet sulak <mehmet.su...@gmail.com>: > >> Hi , >> >> Thank you for your response, >> >> Here are my changes; >> >> in file interval.h >> //#define ROHC_WLSB_WIDTH_MAX to 64U (comment out) >> #define ROHC_WLSB_WIDTH_MAX 256U (new definition) >> >> also added new enum value at "rohc_lsb_shift_t" >> >> ROHC_LSB_SHIFT_UDP_SN = 128 >> >> to be used in UDP traffic. >> >> also in files c_udp.c and d_udp.c >> >> instead of using "ROHC_LSB_SHIFT_SN" which is -1 >> >> I used newly defined "ROHC_LSB_SHIFT_UDP_SN" value >> >> >> For the trade-off between compression efficiency and robustness I >> observed that for configurations >> >> higher then lsb_w = 32 and p=16 makes UDP/IP header to 7 bytes. So I >> choose the lsb_w=256 and p = 128 for greatest coverage. >> >> Best Regards... >> >> >> 2018-02-08 17:17 GMT+03:00 Didier Barvaux <did...@barvaux.org>: >> >>> Hello, >>> >>> Sorry for not answering sooner. I could have saved you some time about >>> the WLSB width :-/ >>> >>> First of all, your changes seem correct. Please send me a patch, I'll >>> check if I can integrate your changes in the next release. >>> >>> The increased size is indeed a consequence. You ask the library to be >>> more robust, so it sends more information to achieve that goal. >>> >>> You have to choose a trade-off between a/ compression efficiency and b/ >>> robustness. Did you try to set smaller value for the WLSB width? Maybe >>> 128 provides enough robustness? Maybe 192? >>> >>> Regards, >>> Didier >>> >>> >>> On Tue, 6 Feb 2018 17:31:18 +0300, >>> mehmet sulak <mehmet.su...@gmail.com> wrote: >>> >>> > After some trials I saw that; >>> > >>> > rohc_comp_set_wlsb_window_width() method is working correctly, the >>> > second parameter is just width of LSB window however I toughed that >>> > it was the number of bits that are for LSB width. >>> > >>> > I set it as 256 to handle large number of problematic cases(by setting >>> > ROHC_WLSB_WIDTH_MAX to 256U). Also I set ROHC_LSB_SHIFT_SN as 128 to >>> > handle delayed packets. >>> > (I defined new enumeration field whose value is 128 by updating >>> > interval.h and setting new value in c_udp.c and d_udp.c files) >>> > >>> > The results are seems to perfect. Rohc decomress errors are seems to >>> > minimized to very small values which stems from loss of initial >>> > context packages. >>> > >>> > The drawback is that 28 byte UDP headers were compressed to 4 bytes >>> > previously but with the solution that I tried they are now compressed >>> > to 7 bytes. >>> > >>> > Is this normal behavior? >>> > >>> > Best Regards.. >>> > >>> > >>> > >>> > 2018-01-30 17:26 GMT+03:00 mehmet sulak <mehmet.su...@gmail.com>: >>> > >>> > > Thanks for your detailed response first; >>> > > >>> > > First I tried method rohc_comp_set_wlsb_window_width(comp,8) by >>> > > giving 8bits window width but I still observe the following in the >>> > > log files; >>> > > >>> > > rohc_decomp_rfc3095.c:1463 parse_uo0() 4 SN bits = 0xe >>> > > >>> > > So I think it still uses 4 bit window length? If yes did I do >>> > > something wrong? >>> > > >>> > > Secondly I think for UDP packets ROHC_LSB_SHIFT_SN(-1) is used for >>> > > compressor and decompressor which makes parsing delayed packets >>> > > impossible. >>> > > >>> > > So I need to use something half of (2 ^ lsb_width) instead of -1 by >>> > > adding a new enumeration value. >>> > > >>> > > Do have any idea about this parameter? >>> > > >>> > > Best Regards.. >>> > > >>> > > 2018-01-29 22:11 GMT+03:00 Didier Barvaux <did...@barvaux.org>: >>> > > >>> > >> Hello, >>> > >> >>> > >> > I am using Rohc comressor/decomressor pair on a lossy >>> > >> > media(sometimes at receiver side some packets are lost) and the >>> > >> > orderings of the UDP packets are not guaranteed.(packets are >>> > >> > not coming in right order all the time). >>> > >> > >>> > >> > I am using Unidirectional mode and observe some decomression >>> > >> > failures about CRC check, malformed packets... >>> > >> > >>> > >> > Any recommendation to overcome these issues? >>> > >> >>> > >> The ROHC protocol provides several ways to handle packet loss or >>> > >> reordering: >>> > >> >>> > >> a/ Increasing the width of the window used by the W-LSB algorithm >>> > >> improves the robustness of the ROHC protocol by sending more >>> > >> bits for changing fields. Given a W-LSB width <wlsb_width>, up to >>> > >> (<wlsb_width> - 1) packets may be lost without causing >>> > >> additional loss. >>> > >> The default width is set to 4 by the ROHC library ; please use >>> > >> the rohc_comp_set_wlsb_window_width() function to change the >>> > >> value ; see [1] for more details. >>> > >> >>> > >> b/ Increasing the number of transmissions N required for a changing >>> > >> static fields or a changing pattern for a dynamic field ensures >>> > >> that the loss of N-1 packets during such a change will cause no >>> > >> additional loss. >>> > >> The default number of transmissions is set to 3 by the ROHC >>> > >> library ; there is no API to change the value at that time, but >>> > >> you may change the value of the constant MAX_IR_COUNT in the >>> > >> source file src/comp/rohc_comp_internals.h and re-build/re-install >>> > >> the library. >>> > >> >>> > >> c/ Same as b/ but for lists of extensions headers (such as IPv6 >>> > >> extension headers, GRE, AH...). Use the function >>> > >> rohc_comp_set_list_trans_nr() to change the value ; the default >>> > >> value is set to 5 ; see [2] for more details. >>> > >> >>> > >> d/ You may enable packet/context repair upon CRC failures, so that >>> > >> the decompressor tries to fix the context or packet if it detects a >>> > >> decompression problem (due to packet loss/reordering for >>> > >> example). The feature is disabled by default. Enable it with the >>> > >> function rohc_decomp_set_features() and the feature >>> > >> ROHC_DECOMP_FEATURE_CRC_REPAIR ; see [3] for more details. >>> > >> >>> > >> Configuring options a-c is easier if you know the largest number of >>> > >> consecutive losses that you may expect and/or you want to be >>> > >> protected against. >>> > >> >>> > >> Let me know if my explanations are clear enough or if you need more >>> > >> details. And, of course, let me know if one of the options solves >>> > >> your problem. >>> > >> >>> > >> Regards, >>> > >> Didier >>> > >> >>> > >> >>> > >> [1] documentation of rohc_comp_set_wlsb_window_width(): >>> > >> https://rohc-lib.org/support/documentation/API/rohc-doc-2.1. >>> > >> 0/group__rohc__comp.html#ga2b68070dddbc038cd55490952a7b3fa4 >>> > >> >>> > >> [2] documentation of rohc_comp_set_list_trans_nr(): >>> > >> https://rohc-lib.org/support/documentation/API/rohc-doc-2.1. >>> > >> 0/group__rohc__comp.html#ga32608bc06e1b0d1656e463eeb1ccbd7f >>> > >> >>> > >> [3] documentation of rohc_decomp_set_features(): >>> > >> https://rohc-lib.org/support/documentation/API/rohc-doc-2.1. >>> > >> 0/group__rohc__decomp.html#ga2298148ca8dc277a1c1905f550f21f7b >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> Mailing list: https://launchpad.net/~rohc >>> > >> Post to : rohc@lists.launchpad.net >>> > >> Unsubscribe : https://launchpad.net/~rohc >>> > >> More help : https://help.launchpad.net/ListHelp >>> > >> >>> > > >>> > > >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~rohc >>> Post to : rohc@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~rohc >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~rohc Post to : rohc@lists.launchpad.net Unsubscribe : https://launchpad.net/~rohc More help : https://help.launchpad.net/ListHelp