linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re : [Linphone-developers] grandstream gxv3000


From: Kelvin Chua
Subject: Re: Re : [Linphone-developers] grandstream gxv3000
Date: Thu, 4 Feb 2010 16:22:19 +0800

i still have not checked with git if these changes are in as i am using 1.3.0
but you need to add the following params in msx264.c

        params.analyse.b_transform_8x8 = 0;
        params.i_cqm_preset = X264_CQM_FLAT; 
        params.i_level_idc = 12;
        params.i_keyint_min = 10; 
        params.i_keyint_max = 60;
        params.analyse.i_weighted_pred = X264_WEIGHTP_NONE;

can you check if these params would give you a nice video?
i'm having some problems with mine, my proc usage would jack up to around 90%
while x264 is doing its thing, lower part of the video is kinda crap but ok.
i was kinda speculating that my laptop is not powerful enough for this, x264
is being inefficient or i need to tweak something in the params. i'm still
experimenting here on my side.

Kelvin Chua


On Wed, Feb 3, 2010 at 6:38 PM, Simon Morlat <address@hidden> wrote:
Le mercredi 03 février 2010 à 10:18 +0800, Kelvin Chua a écrit :
> i finally fixed it.
> msx264 parameters for x264 is not correct. gxv only accept baseline
> profile. and profile level 1.2
Great. Can you please send a patch ?


> i also noticed that linphone is not sending sprop, packetization and
> sprop details with SDP.
All those parameters are optional in RFC3984.
http://www.rfc-editor.org/rfc/rfc3984.txt

Thank you,

Simon

>
>
> happily doing h.264 with gxv ^_^
>
>
> Kelvin Chua
>
>
> On Tue, Feb 2, 2010 at 10:58 PM, Kelvin Chua <address@hidden> wrote:
>         i have written an application where i used sip to stream h264
>         320x240 videos to grandstreams one-way, it's a VOD-type
>         application. and it works. so i don't think it has something
>         to do with
>         the video size. i think the problem is more of the x264
>         encoding side. i wonder if there is a
>         way for linphone to show me the NAL headers, that way i can
>         check whether the NAL types
>         are within the 1-23 range and the F-bit 0. i have seen some
>         instances where x264 could chew
>         up NAL units with the F bit always set to 1 and i suspect gxv
>         does not like this.
>
>         Kelvin Chua
>
>
>
>
>         On Tue, Feb 2, 2010 at 10:48 PM, Aurelien Bouin
>         <address@hidden> wrote:
>                 Hello,
>                 I have been testing with a GXV3140 Grandstream and I
>                 figured out that the grandstream encoding format was
>                 320x240 which could be the problem, I am not sure but
>                 I feel like linphone cannot handle it ... ???But if
>                 not we should try to find a solution...
>                 Sincerely,
>
>                 Aurelien BOUIN
>
>                 --- En date de : Mar 2.2.10, Kelvin Chua
>                 <address@hidden> a écrit :
>
>                         De: Kelvin Chua <address@hidden>
>                         Objet: [Linphone-developers] grandstream
>                         gxv3000
>                         À: address@hidden
>                         Date: Mardi 2 Février 2010, 15h23
>
>
>
>                         been trying to do some interop with
>                         grandstream gxv3000.
>                         i know for a fact that the h263 stack of
>                         grandstream is very poor. so i am using h.264
>                         for my tests.
>                         compiled everything from source, ffmpeg, x264,
>                         linphone. msx264 plugin already shows up in
>                         linphone, both for packetization=1
>                         and another one with blank parameters which i
>                         assume to be packetization=0.
>
>
>                         source code versions are as follows:
>                         linphone-3.2.1
>                         msx264-1.3.0
>                         x264 core:83 r1400 20fa784
>                         ffmpeg r21566
>                         libswscale r29972
>
>
>                         don't know if it matters, my OS is karmic
>                         koala
>
>
>                         so anyway, i was looking at the code and
>                         trying to figure out, why linphone shows the
>                         h.264 video streaming from gxv but gxv
>                         does not show the video from linphone. i was
>                         speculating that the x264 plugin is not
>                         working in single NALU mode as defined in the
>                         RFC or packetization=0.
>                         i then stumbled into the parameter in msx264.c
>                         which
>                         sets  params.i_slice_max_size=ms_get_payload_max_size()-100;
>                         so that means, a slice is being fitted into
>                         100 less than the MTU which is correct for
>                         single NALU mode. i then fired up wireshark
>                         and was surprised to see no video packets
>                         coming from linphone to gxv :( only the 2-way
>                         g.711 and the h.264 stream from gxv.
>
>
>                         i think this all boils down to x264. i wonder
>                         what x264 revision you guys are using in your
>                         tests?
>
>
>                         Kelvin Chua
>
>
>                         -----La pièce jointe associée suit-----
>
>                         _______________________________________________
>                         Linphone-developers mailing list
>                         address@hidden
>                         http://lists.nongnu.org/mailman/listinfo/linphone-developers
>
>
>
>
>
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers




reply via email to

[Prev in Thread] Current Thread [Next in Thread]