[sip-comm-dev] Video call freeze/acceleration


#1

Hi folks,

I walk throught JMF and SC to find why sometime in a video call, video slow down or freeze and accelerate a lot some seconds after.

I found something interresting in src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java :

        // if the timestamp changes we are starting receiving a new frame
        if(!(currentStamp == lastTimestamp))
        {
            reset();
        }

(currentStamp is get by inputBuffer.getTimestamp())

But we never reach this condition, because currentStamp and lastTimestamp are always equal to -1. So H264Parser considers that the frame is never finished. It causes the encodedFrame to fill and fill up... and sometime reach maximum size and throws the exception "Cannot parse incoming null" in H264Parser::pushRTPInput. The timestamp are set to -1 in a JMF's internal class (other parameter such as flags or sequence number are correct).

So to solve this, I propose to use the marker flag (Buffer.FLAG_RTP_MARKER) to see if current frame is finished. In H264Parser, we remember if the last packet processed has the marker and if yes, we reset it and start processing packet for a new frame. Patch is attached, the result is that video has no more freeze/acceleration and "noise".

If nobody is against, I will commit it.

Regards,

sc-h264-marker.patch (1.14 KB)

···

--
Sebastien


#2

Hi,

it sounds reasonable. As making the packetizer and depacketizer I
remember that those are the two conditions for transmitting one frame.
The frame packets are with equal timestamps and the last frame ends
with rtp marker. There is one situation where this approach doesn't
work, if we are looking at the marker ant that packet is lost we are
in situation of merging two frames. But your approach is the only and
best resolution of the current problem. So you can go now and commit
it. That is my opinion.

Cheers
damencho

···

On Wed, Jan 6, 2010 at 2:28 PM, Sebastien Vincent <seb@sip-communicator.org> wrote:

Hi folks,

I walk throught JMF and SC to find why sometime in a video call, video slow
down or freeze and accelerate a lot some seconds after.

I found something interresting in
src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
:

  // if the timestamp changes we are starting receiving a new frame
  if\(\!\(currentStamp == lastTimestamp\)\)
  \{
      reset\(\);
  \}

(currentStamp is get by inputBuffer.getTimestamp())

But we never reach this condition, because currentStamp and lastTimestamp
are always equal to -1. So H264Parser considers that the frame is never
finished. It causes the encodedFrame to fill and fill up... and sometime
reach maximum size and throws the exception "Cannot parse incoming null" in
H264Parser::pushRTPInput. The timestamp are set to -1 in a JMF's internal
class (other parameter such as flags or sequence number are correct).

So to solve this, I propose to use the marker flag (Buffer.FLAG_RTP_MARKER)
to see if current frame is finished. In H264Parser, we remember if the last
packet processed has the marker and if yes, we reset it and start processing
packet for a new frame. Patch is attached, the result is that video has no
more freeze/acceleration and "noise".

If nobody is against, I will commit it.

Regards,
--
Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Still video slow down or freeze and accelerate a lot some seconds. After I
have added this patch .

···

On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent <seb@sip-communicator.org>wrote:

Hi folks,

I walk throught JMF and SC to find why sometime in a video call, video slow
down or freeze and accelerate a lot some seconds after.

I found something interresting in
src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
:

      // if the timestamp changes we are starting receiving a new frame
      if(!(currentStamp == lastTimestamp))
      {
          reset();
      }

(currentStamp is get by inputBuffer.getTimestamp())

But we never reach this condition, because currentStamp and lastTimestamp
are always equal to -1. So H264Parser considers that the frame is never
finished. It causes the encodedFrame to fill and fill up... and sometime
reach maximum size and throws the exception "Cannot parse incoming null" in
H264Parser::pushRTPInput. The timestamp are set to -1 in a JMF's internal
class (other parameter such as flags or sequence number are correct).

So to solve this, I propose to use the marker flag (Buffer.FLAG_RTP_MARKER)
to see if current frame is finished. In H264Parser, we remember if the last
packet processed has the marker and if yes, we reset it and start processing
packet for a new frame. Patch is attached, the result is that video has no
more freeze/acceleration and "noise".

If nobody is against, I will commit it.

Regards,
--
Sebastien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Romal,

Can you tell me the OSes of the two peers and have you tested over a LAN or over the internet ?

Regards,

···

--
Seb

romal patel a �crit :

Still video slow down or freeze and accelerate a lot some seconds. After I have added this patch .

On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent > <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

    Hi folks,

    I walk throught JMF and SC to find why sometime in a video call,
    video slow down or freeze and accelerate a lot some seconds after.

    I found something interresting in
    src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
    :

          // if the timestamp changes we are starting receiving a new
    frame
          if(!(currentStamp == lastTimestamp))
          {
              reset();
          }

    (currentStamp is get by inputBuffer.getTimestamp())

    But we never reach this condition, because currentStamp and
    lastTimestamp are always equal to -1. So H264Parser considers that
    the frame is never finished. It causes the encodedFrame to fill
    and fill up... and sometime reach maximum size and throws the
    exception "Cannot parse incoming null" in
    H264Parser::pushRTPInput. The timestamp are set to -1 in a JMF's
    internal class (other parameter such as flags or sequence number
    are correct).

    So to solve this, I propose to use the marker flag
    (Buffer.FLAG_RTP_MARKER) to see if current frame is finished. In
    H264Parser, we remember if the last packet processed has the
    marker and if yes, we reset it and start processing packet for a
    new frame. Patch is attached, the result is that video has no more
    freeze/acceleration and "noise".

    If nobody is against, I will commit it.

    Regards,
    --
    Sebastien

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

I'm testing sip communicator to sip communicator on windows XP with this
patch.

Getting following error:

[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one
[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one
[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one
[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one
[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one
[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one
[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one
[h264 @ 0x6ea14e0]number of reference frames exceeds max (probably corrupt
input), discarding one

when video slow down or freeze and accelerate a lot some seconds.

···

On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent <seb@sip-communicator.org>wrote:

Hi Romal,

Can you tell me the OSes of the two peers and have you tested over a LAN or
over the internet ?

Regards,
--
Seb

romal patel a écrit :

Still video slow down or freeze and accelerate a lot some seconds. After I
have added this patch .

On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent < >> seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

   Hi folks,

   I walk throught JMF and SC to find why sometime in a video call,
   video slow down or freeze and accelerate a lot some seconds after.

   I found something interresting in

src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
   :

         // if the timestamp changes we are starting receiving a new
   frame
         if(!(currentStamp == lastTimestamp))
         {
             reset();
         }

   (currentStamp is get by inputBuffer.getTimestamp())

   But we never reach this condition, because currentStamp and
   lastTimestamp are always equal to -1. So H264Parser considers that
   the frame is never finished. It causes the encodedFrame to fill
   and fill up... and sometime reach maximum size and throws the
   exception "Cannot parse incoming null" in
   H264Parser::pushRTPInput. The timestamp are set to -1 in a JMF's
   internal class (other parameter such as flags or sequence number
   are correct).

   So to solve this, I propose to use the marker flag
   (Buffer.FLAG_RTP_MARKER) to see if current frame is finished. In
   H264Parser, we remember if the last packet processed has the
   marker and if yes, we reset it and start processing packet for a
   new frame. Patch is attached, the result is that video has no more
   freeze/acceleration and "noise".

   If nobody is against, I will commit it.

   Regards,
   --
   Sebastien

   ---------------------------------------------------------------------
   To unsubscribe, e-mail:
   dev-unsubscribe@sip-communicator.dev.java.net
   <mailto:dev-unsubscribe@sip-communicator.dev.java.net>

   For additional commands, e-mail:
   dev-help@sip-communicator.dev.java.net
   <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Is there any other condition need to be add in h264parser.java file. Let me
know

I already added following statement

        if(!(currentStamp == lastTimestamp) || lastHasMarker)
        {
             reset();
        }

···

On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent < > seb@sip-communicator.org> wrote:

Hi Romal,

Can you tell me the OSes of the two peers and have you tested over a LAN
or over the internet ?

Regards,
--
Seb

romal patel a écrit :

Still video slow down or freeze and accelerate a lot some seconds. After
I have added this patch .

On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent < >>> seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

   Hi folks,

   I walk throught JMF and SC to find why sometime in a video call,
   video slow down or freeze and accelerate a lot some seconds after.

   I found something interresting in

src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
   :

         // if the timestamp changes we are starting receiving a new
   frame
         if(!(currentStamp == lastTimestamp))
         {
             reset();
         }

   (currentStamp is get by inputBuffer.getTimestamp())

   But we never reach this condition, because currentStamp and
   lastTimestamp are always equal to -1. So H264Parser considers that
   the frame is never finished. It causes the encodedFrame to fill
   and fill up... and sometime reach maximum size and throws the
   exception "Cannot parse incoming null" in
   H264Parser::pushRTPInput. The timestamp are set to -1 in a JMF's
   internal class (other parameter such as flags or sequence number
   are correct).

   So to solve this, I propose to use the marker flag
   (Buffer.FLAG_RTP_MARKER) to see if current frame is finished. In
   H264Parser, we remember if the last packet processed has the
   marker and if yes, we reset it and start processing packet for a
   new frame. Patch is attached, the result is that video has no more
   freeze/acceleration and "noise".

   If nobody is against, I will commit it.

   Regards,
   --
   Sebastien

   ---------------------------------------------------------------------
   To unsubscribe, e-mail:
   dev-unsubscribe@sip-communicator.dev.java.net
   <mailto:dev-unsubscribe@sip-communicator.dev.java.net>

   For additional commands, e-mail:
   dev-help@sip-communicator.dev.java.net
   <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi,

Have you compile and run SIP Communicator from the latest trunk version (revision 6582 now) ? Because we have updated libffmpeg/x264 recently.

Regards,

···

--
Seb

romal patel a �crit :

Is there any other condition need to be add in h264parser.java file. Let me know

I already added following statement

        if(!(currentStamp == lastTimestamp) || lastHasMarker)
        {
             reset();
        }

    On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent > <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

        Hi Romal,

        Can you tell me the OSes of the two peers and have you tested
        over a LAN or over the internet ?

        Regards,
        --
        Seb

        romal patel a �crit :

            Still video slow down or freeze and accelerate a lot some
            seconds. After I have added this patch .

            On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent > <seb@sip-communicator.org > <mailto:seb@sip-communicator.org> > <mailto:seb@sip-communicator.org > <mailto:seb@sip-communicator.org>>> wrote:

               Hi folks,

               I walk throught JMF and SC to find why sometime in a
            video call,
               video slow down or freeze and accelerate a lot some
            seconds after.

               I found something interresting in
                          src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
               :

                     // if the timestamp changes we are starting
            receiving a new
               frame
                     if(!(currentStamp == lastTimestamp))
                     {
                         reset();
                     }

               (currentStamp is get by inputBuffer.getTimestamp())

               But we never reach this condition, because currentStamp and
               lastTimestamp are always equal to -1. So H264Parser
            considers that
               the frame is never finished. It causes the encodedFrame
            to fill
               and fill up... and sometime reach maximum size and
            throws the
               exception "Cannot parse incoming null" in
               H264Parser::pushRTPInput. The timestamp are set to -1
            in a JMF's
               internal class (other parameter such as flags or
            sequence number
               are correct).

               So to solve this, I propose to use the marker flag
               (Buffer.FLAG_RTP_MARKER) to see if current frame is
            finished. In
               H264Parser, we remember if the last packet processed
            has the
               marker and if yes, we reset it and start processing
            packet for a
               new frame. Patch is attached, the result is that video
            has no more
               freeze/acceleration and "noise".

               If nobody is against, I will commit it.

               Regards,
               --
               Sebastien

                          ---------------------------------------------------------------------
               To unsubscribe, e-mail:
               dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
               <mailto:dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>

               For additional commands, e-mail:
               dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>
               <mailto:dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>>

        ---------------------------------------------------------------------
        To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
        For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

I downloaded 2322 source code and I used lib from this source. Where I get
revision 6582 source please send me download link.

sip-communicator-src-1.0-alpha3-nightly.build.2322.zip <http://sip-communicator.org/download/nightly-builds/src/sip-communicator-src-1.0-alpha3-nightly.build.2322.zip>

Hi,

Have you compile and run SIP Communicator from the latest trunk version
(revision 6582 now) ? Because we have updated libffmpeg/x264 recently.

Regards,
--
Seb

romal patel a écrit :

Is there any other condition need to be add in h264parser.java file. Let
me know

I already added following statement

       if(!(currentStamp == lastTimestamp) || lastHasMarker)
       {
            reset();
       }

       Hi Romal,

       Can you tell me the OSes of the two peers and have you tested
       over a LAN or over the internet ?

       Regards,
       --
       Seb

       romal patel a écrit :

           Still video slow down or freeze and accelerate a lot some
           seconds. After I have added this patch .

              Hi folks,

              I walk throught JMF and SC to find why sometime in a
           video call,
              video slow down or freeze and accelerate a lot some
           seconds after.

              I found something interresting in

src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
              :

                    // if the timestamp changes we are starting
           receiving a new
              frame
                    if(!(currentStamp == lastTimestamp))
                    {
                        reset();
                    }

              (currentStamp is get by inputBuffer.getTimestamp())

              But we never reach this condition, because currentStamp and
              lastTimestamp are always equal to -1. So H264Parser
           considers that
              the frame is never finished. It causes the encodedFrame
           to fill
              and fill up... and sometime reach maximum size and
           throws the
              exception "Cannot parse incoming null" in
              H264Parser::pushRTPInput. The timestamp are set to -1
           in a JMF's
              internal class (other parameter such as flags or
           sequence number
              are correct).

              So to solve this, I propose to use the marker flag
              (Buffer.FLAG_RTP_MARKER) to see if current frame is
           finished. In
              H264Parser, we remember if the last packet processed
           has the
              marker and if yes, we reset it and start processing
           packet for a
              new frame. Patch is attached, the result is that video
           has no more
              freeze/acceleration and "noise".

              If nobody is against, I will commit it.

              Regards,
              --
              Sebastien

---------------------------------------------------------------------
              To unsubscribe, e-mail:
              dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
              <mailto:dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>

              For additional commands, e-mail:
              dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>
              <mailto:dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>>

---------------------------------------------------------------------
       To unsubscribe, e-mail:
       dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
       For additional commands, e-mail:
       dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

···

On Fri, Jan 8, 2010 at 3:10 PM, romal patel <patel.romal@gmail.com> wrote:

On Fri, Jan 8, 2010 at 3:04 PM, Sebastien Vincent < > seb@sip-communicator.org> wrote:

   On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent >>> <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:
           On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent >>> <seb@sip-communicator.org >>> <mailto:seb@sip-communicator.org> >>> <mailto:seb@sip-communicator.org >>> <mailto:seb@sip-communicator.org>>> wrote:


#9

Hum, the 2322 source package contains already the patch. Do you have compiled 2322 sources or do you use another modified version of SIP Communicator (and replace native libs by 2322 ones) ?

Regards,

···

--
Sebastien

romal patel a �crit :

On Fri, Jan 8, 2010 at 3:10 PM, romal patel <patel.romal@gmail.com > <mailto:patel.romal@gmail.com>> wrote:

    I downloaded 2322 source code and I used lib from this source.
    Where I get revision 6582 source please send me download link.

    sip-communicator-src-1.0-alpha3-nightly.build.2322.zip <http://sip-communicator.org/download/nightly-builds/src/sip-communicator-src-1.0-alpha3-nightly.build.2322.zip>

    On Fri, Jan 8, 2010 at 3:04 PM, Sebastien Vincent > <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

        Hi,

        Have you compile and run SIP Communicator from the latest
        trunk version (revision 6582 now) ? Because we have updated
        libffmpeg/x264 recently.

        Regards,
        --
        Seb

        romal patel a �crit :

            Is there any other condition need to be add in
            h264parser.java file. Let me know

            I already added following statement

                   if(!(currentStamp == lastTimestamp) || lastHasMarker)
                   {
                        reset();
                   }

               On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent > <seb@sip-communicator.org > <mailto:seb@sip-communicator.org> > <mailto:seb@sip-communicator.org > <mailto:seb@sip-communicator.org>>> wrote:

                   Hi Romal,

                   Can you tell me the OSes of the two peers and have
            you tested
                   over a LAN or over the internet ?

                   Regards,
                   --
                   Seb

                   romal patel a �crit :

                       Still video slow down or freeze and accelerate
            a lot some
                       seconds. After I have added this patch .

                       On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent
                       <seb@sip-communicator.org
            <mailto:seb@sip-communicator.org>
                       <mailto:seb@sip-communicator.org
            <mailto:seb@sip-communicator.org>>
                       <mailto:seb@sip-communicator.org
            <mailto:seb@sip-communicator.org>
                       <mailto:seb@sip-communicator.org
            <mailto:seb@sip-communicator.org>>>> wrote:

                          Hi folks,

                          I walk throught JMF and SC to find why
            sometime in a
                       video call,
                          video slow down or freeze and accelerate a
            lot some
                       seconds after.

                          I found something interresting in
                                               src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
                          :

                                // if the timestamp changes we are
            starting
                       receiving a new
                          frame
                                if(!(currentStamp == lastTimestamp))
                                {
                                    reset();
                                }

                          (currentStamp is get by
            inputBuffer.getTimestamp())

                          But we never reach this condition, because
            currentStamp and
                          lastTimestamp are always equal to -1. So
            H264Parser
                       considers that
                          the frame is never finished. It causes the
            encodedFrame
                       to fill
                          and fill up... and sometime reach maximum
            size and
                       throws the
                          exception "Cannot parse incoming null" in
                          H264Parser::pushRTPInput. The timestamp are
            set to -1
                       in a JMF's
                          internal class (other parameter such as flags or
                       sequence number
                          are correct).

                          So to solve this, I propose to use the
            marker flag
                          (Buffer.FLAG_RTP_MARKER) to see if current
            frame is
                       finished. In
                          H264Parser, we remember if the last packet
            processed
                       has the
                          marker and if yes, we reset it and start
            processing
                       packet for a
                          new frame. Patch is attached, the result is
            that video
                       has no more
                          freeze/acceleration and "noise".

                          If nobody is against, I will commit it.

                          Regards,
                          --
                          Sebastien

                                               ---------------------------------------------------------------------
                          To unsubscribe, e-mail:
                                     dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                                  <mailto:dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                     <mailto:dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                                  <mailto:dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>

                          For additional commands, e-mail:
                          dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>
                       <mailto:dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>>
                                     <mailto:dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>
                       <mailto:dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>>>

                              ---------------------------------------------------------------------
                   To unsubscribe, e-mail:
                   dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                              <mailto:dev-unsubscribe@sip-communicator.dev.java.net
            <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                   For additional commands, e-mail:
                   dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>
                   <mailto:dev-help@sip-communicator.dev.java.net
            <mailto:dev-help@sip-communicator.dev.java.net>>

        ---------------------------------------------------------------------
        To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
        For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

in 2322 version Video not sending at both side.

I'm using 2169 version with new changes in h264parser.java file.

···

On Fri, Jan 8, 2010 at 3:23 PM, Sebastien Vincent <seb@sip-communicator.org>wrote:

Hum, the 2322 source package contains already the patch. Do you have
compiled 2322 sources or do you use another modified version of SIP
Communicator (and replace native libs by 2322 ones) ?

Regards,
--
Sebastien

romal patel a écrit :

On Fri, Jan 8, 2010 at 3:10 PM, romal patel <patel.romal@gmail.com<mailto: >> patel.romal@gmail.com>> wrote:

   I downloaded 2322 source code and I used lib from this source.
   Where I get revision 6582 source please send me download link.

   sip-communicator-src-1.0-alpha3-nightly.build.2322.zip <
http://sip-communicator.org/download/nightly-builds/src/sip-communicator-src-1.0-alpha3-nightly.build.2322.zip>

   On Fri, Jan 8, 2010 at 3:04 PM, Sebastien Vincent >> <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

       Hi,

       Have you compile and run SIP Communicator from the latest
       trunk version (revision 6582 now) ? Because we have updated
       libffmpeg/x264 recently.

       Regards,
       --
       Seb

       romal patel a écrit :

           Is there any other condition need to be add in
           h264parser.java file. Let me know

           I already added following statement

                  if(!(currentStamp == lastTimestamp) || lastHasMarker)
                  {
                       reset();
                  }

              On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent >> <seb@sip-communicator.org >> <mailto:seb@sip-communicator.org> >> <mailto:seb@sip-communicator.org >> <mailto:seb@sip-communicator.org>>> wrote:

                  Hi Romal,

                  Can you tell me the OSes of the two peers and have
           you tested
                  over a LAN or over the internet ?

                  Regards,
                  --
                  Seb

                  romal patel a écrit :

                      Still video slow down or freeze and accelerate
           a lot some
                      seconds. After I have added this patch .

                      On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent
                      <seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>
                      <mailto:seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>>
                      <mailto:seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>
                      <mailto:seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>>>> wrote:

                         Hi folks,

                         I walk throught JMF and SC to find why
           sometime in a
                      video call,
                         video slow down or freeze and accelerate a
           lot some
                      seconds after.

                         I found something interresting in

src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
                         :

                               // if the timestamp changes we are
           starting
                      receiving a new
                         frame
                               if(!(currentStamp == lastTimestamp))
                               {
                                   reset();
                               }

                         (currentStamp is get by
           inputBuffer.getTimestamp())

                         But we never reach this condition, because
           currentStamp and
                         lastTimestamp are always equal to -1. So
           H264Parser
                      considers that
                         the frame is never finished. It causes the
           encodedFrame
                      to fill
                         and fill up... and sometime reach maximum
           size and
                      throws the
                         exception "Cannot parse incoming null" in
                         H264Parser::pushRTPInput. The timestamp are
           set to -1
                      in a JMF's
                         internal class (other parameter such as flags or
                      sequence number
                         are correct).

                         So to solve this, I propose to use the
           marker flag
                         (Buffer.FLAG_RTP_MARKER) to see if current
           frame is
                      finished. In
                         H264Parser, we remember if the last packet
           processed
                      has the
                         marker and if yes, we reset it and start
           processing
                      packet for a
                         new frame. Patch is attached, the result is
           that video
                      has no more
                         freeze/acceleration and "noise".

                         If nobody is against, I will commit it.

                         Regards,
                         --
                         Sebastien

---------------------------------------------------------------------
                         To unsubscribe, e-mail:

dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                                <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                   <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                                <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>

                         For additional commands, e-mail:
                         dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>
                      <mailto:dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>>
                                   <mailto:
dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>
                      <mailto:dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>>>

---------------------------------------------------------------------
                  To unsubscribe, e-mail:
                  dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                            <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                  For additional commands, e-mail:
                  dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>>

---------------------------------------------------------------------
       To unsubscribe, e-mail:
       dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
       For additional commands, e-mail:
       dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hi,

Strange. Do you have any message in the call panel or in log file that could help us to find why video is not sent and received by all peers ?

I have tested _over_LAN_ with Linux to Linux/Mac OS X/Windows Vista but not Windows to Windows. I will give it a try after.

Regards,

···

--
Seb

romal patel a �crit :

in 2322 version Video not sending at both side.

I'm using 2169 version with new changes in h264parser.java file.

On Fri, Jan 8, 2010 at 3:23 PM, Sebastien Vincent > <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

    Hum, the 2322 source package contains already the patch. Do you
    have compiled 2322 sources or do you use another modified version
    of SIP Communicator (and replace native libs by 2322 ones) ?

    Regards,
    --
    Sebastien

    romal patel a �crit :

        On Fri, Jan 8, 2010 at 3:10 PM, romal patel > <patel.romal@gmail.com <mailto:patel.romal@gmail.com> > <mailto:patel.romal@gmail.com <mailto:patel.romal@gmail.com>>> > wrote:

           I downloaded 2322 source code and I used lib from this source.
           Where I get revision 6582 source please send me download link.

           sip-communicator-src-1.0-alpha3-nightly.build.2322.zip
        <http://sip-communicator.org/download/nightly-builds/src/sip-communicator-src-1.0-alpha3-nightly.build.2322.zip>

           On Fri, Jan 8, 2010 at 3:04 PM, Sebastien Vincent > <seb@sip-communicator.org <mailto:seb@sip-communicator.org> > <mailto:seb@sip-communicator.org > <mailto:seb@sip-communicator.org>>> wrote:

               Hi,

               Have you compile and run SIP Communicator from the latest
               trunk version (revision 6582 now) ? Because we have updated
               libffmpeg/x264 recently.

               Regards,
               --
               Seb

               romal patel a �crit :

                   Is there any other condition need to be add in
                   h264parser.java file. Let me know

                   I already added following statement

                          if(!(currentStamp == lastTimestamp) ||
        lastHasMarker)
                          {
                               reset();
                          }

                      On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent
                      <seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>
                   <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>>
                   <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>
                   <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>>>> wrote:

                          Hi Romal,

                          Can you tell me the OSes of the two peers
        and have
                   you tested
                          over a LAN or over the internet ?

                          Regards,
                          --
                          Seb

                          romal patel a �crit :

                              Still video slow down or freeze and
        accelerate
                   a lot some
                              seconds. After I have added this patch .

                              On Wed, Jan 6, 2010 at 5:58 PM,
        Sebastien Vincent
                              <seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>
                   <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>>
                              <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>
                   <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>>>
                              <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>
                   <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>>
                              <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>
                   <mailto:seb@sip-communicator.org
        <mailto:seb@sip-communicator.org>>>>> wrote:

                                 Hi folks,

                                 I walk throught JMF and SC to find why
                   sometime in a
                              video call,
                                 video slow down or freeze and
        accelerate a
                   lot some
                              seconds after.

                                 I found something interresting in
                                                            src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
                                 :

                                       // if the timestamp changes we are
                   starting
                              receiving a new
                                 frame
                                       if(!(currentStamp ==
        lastTimestamp))
                                       {
                                           reset();
                                       }

                                 (currentStamp is get by
                   inputBuffer.getTimestamp())

                                 But we never reach this condition,
        because
                   currentStamp and
                                 lastTimestamp are always equal to -1. So
                   H264Parser
                              considers that
                                 the frame is never finished. It
        causes the
                   encodedFrame
                              to fill
                                 and fill up... and sometime reach maximum
                   size and
                              throws the
                                 exception "Cannot parse incoming
         null" in
                                 H264Parser::pushRTPInput. The
        timestamp are
                   set to -1
                              in a JMF's
                                 internal class (other parameter such
        as flags or
                              sequence number
                                 are correct).

                                 So to solve this, I propose to use the
                   marker flag
                                 (Buffer.FLAG_RTP_MARKER) to see if
        current
                   frame is
                              finished. In
                                 H264Parser, we remember if the last
        packet
                   processed
                              has the
                                 marker and if yes, we reset it and start
                   processing
                              packet for a
                                 new frame. Patch is attached, the
        result is
                   that video
                              has no more
                                 freeze/acceleration and "noise".

                                 If nobody is against, I will commit it.

                                 Regards,
                                 --
                                 Sebastien

                                                            ---------------------------------------------------------------------
                                 To unsubscribe, e-mail:
                                                  dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                          <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                               <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                          <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
                                                  <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                          <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                               <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                          <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>

                                 For additional commands, e-mail:
                                        dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>
                   <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>>
                                     <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>
                   <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>>>
                                                  <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>
                   <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>>
                                     <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>
                   <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>>>>

                                           ---------------------------------------------------------------------
                          To unsubscribe, e-mail:
                                 dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                          <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                           <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                          <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
                          For additional commands, e-mail:
                          dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>
                   <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>>
                                 <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>
                   <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>>>

                      ---------------------------------------------------------------------
               To unsubscribe, e-mail:
               dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
               <mailto:dev-unsubscribe@sip-communicator.dev.java.net
        <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
               For additional commands, e-mail:
               dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>
               <mailto:dev-help@sip-communicator.dev.java.net
        <mailto:dev-help@sip-communicator.dev.java.net>>

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

I am trying to improve video quality from last 6 months please help me to
sort out this video slow down or freeze and accelerate
           a lot some problem.

···

On Fri, Jan 8, 2010 at 3:28 PM, romal patel <patel.romal@gmail.com> wrote:

in 2322 version Video not sending at both side.

I'm using 2169 version with new changes in h264parser.java file.

On Fri, Jan 8, 2010 at 3:23 PM, Sebastien Vincent < > seb@sip-communicator.org> wrote:

Hum, the 2322 source package contains already the patch. Do you have
compiled 2322 sources or do you use another modified version of SIP
Communicator (and replace native libs by 2322 ones) ?

Regards,
--
Sebastien

romal patel a écrit :

On Fri, Jan 8, 2010 at 3:10 PM, romal patel <patel.romal@gmail.com<mailto: >>> patel.romal@gmail.com>> wrote:

   I downloaded 2322 source code and I used lib from this source.
   Where I get revision 6582 source please send me download link.

   sip-communicator-src-1.0-alpha3-nightly.build.2322.zip <
http://sip-communicator.org/download/nightly-builds/src/sip-communicator-src-1.0-alpha3-nightly.build.2322.zip>

   On Fri, Jan 8, 2010 at 3:04 PM, Sebastien Vincent >>> <seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

       Hi,

       Have you compile and run SIP Communicator from the latest
       trunk version (revision 6582 now) ? Because we have updated
       libffmpeg/x264 recently.

       Regards,
       --
       Seb

       romal patel a écrit :

           Is there any other condition need to be add in
           h264parser.java file. Let me know

           I already added following statement

                  if(!(currentStamp == lastTimestamp) || lastHasMarker)
                  {
                       reset();
                  }

              On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent >>> <seb@sip-communicator.org >>> <mailto:seb@sip-communicator.org> >>> <mailto:seb@sip-communicator.org >>> <mailto:seb@sip-communicator.org>>> wrote:

                  Hi Romal,

                  Can you tell me the OSes of the two peers and have
           you tested
                  over a LAN or over the internet ?

                  Regards,
                  --
                  Seb

                  romal patel a écrit :

                      Still video slow down or freeze and accelerate
           a lot some
                      seconds. After I have added this patch .

                      On Wed, Jan 6, 2010 at 5:58 PM, Sebastien Vincent
                      <seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>
                      <mailto:seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>>
                      <mailto:seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>
                      <mailto:seb@sip-communicator.org
           <mailto:seb@sip-communicator.org>>>> wrote:

                         Hi folks,

                         I walk throught JMF and SC to find why
           sometime in a
                      video call,
                         video slow down or freeze and accelerate a
           lot some
                      seconds after.

                         I found something interresting in

src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
                         :

                               // if the timestamp changes we are
           starting
                      receiving a new
                         frame
                               if(!(currentStamp == lastTimestamp))
                               {
                                   reset();
                               }

                         (currentStamp is get by
           inputBuffer.getTimestamp())

                         But we never reach this condition, because
           currentStamp and
                         lastTimestamp are always equal to -1. So
           H264Parser
                      considers that
                         the frame is never finished. It causes the
           encodedFrame
                      to fill
                         and fill up... and sometime reach maximum
           size and
                      throws the
                         exception "Cannot parse incoming null" in
                         H264Parser::pushRTPInput. The timestamp are
           set to -1
                      in a JMF's
                         internal class (other parameter such as flags or
                      sequence number
                         are correct).

                         So to solve this, I propose to use the
           marker flag
                         (Buffer.FLAG_RTP_MARKER) to see if current
           frame is
                      finished. In
                         H264Parser, we remember if the last packet
           processed
                      has the
                         marker and if yes, we reset it and start
           processing
                      packet for a
                         new frame. Patch is attached, the result is
           that video
                      has no more
                         freeze/acceleration and "noise".

                         If nobody is against, I will commit it.

                         Regards,
                         --
                         Sebastien

---------------------------------------------------------------------
                         To unsubscribe, e-mail:

dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                                <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                   <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                                <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>

                         For additional commands, e-mail:
                         dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>
                      <mailto:dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>>
                                   <mailto:
dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>
                      <mailto:dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>>>

---------------------------------------------------------------------
                  To unsubscribe, e-mail:
                  dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                            <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
           <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                  For additional commands, e-mail:
                  dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
           <mailto:dev-help@sip-communicator.dev.java.net>>

---------------------------------------------------------------------
       To unsubscribe, e-mail:
       dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
       For additional commands, e-mail:
       dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Ok I'll send u log file but in 2169 i added patch in h264parser.java but
same problem occurred (video slow down or freeze and
accelerate). i 'm trying last 6 month to sort out this problem please help
me.

···

On Fri, Jan 8, 2010 at 3:38 PM, Sebastien Vincent <seb@sip-communicator.org>wrote:

Hi,

Strange. Do you have any message in the call panel or in log file that
could help us to find why video is not sent and received by all peers ?

I have tested _over_LAN_ with Linux to Linux/Mac OS X/Windows Vista but not
Windows to Windows. I will give it a try after.

Regards,
--
Seb

romal patel a écrit :

in 2322 version Video not sending at both side.

I'm using 2169 version with new changes in h264parser.java file.

On Fri, Jan 8, 2010 at 3:23 PM, Sebastien Vincent < >> seb@sip-communicator.org <mailto:seb@sip-communicator.org>> wrote:

   Hum, the 2322 source package contains already the patch. Do you
   have compiled 2322 sources or do you use another modified version
   of SIP Communicator (and replace native libs by 2322 ones) ?

   Regards,
   --
   Sebastien

   romal patel a écrit :

       On Fri, Jan 8, 2010 at 3:10 PM, romal patel >> <patel.romal@gmail.com <mailto:patel.romal@gmail.com> >> <mailto:patel.romal@gmail.com <mailto:patel.romal@gmail.com>>> >> >> wrote:

          I downloaded 2322 source code and I used lib from this source.
          Where I get revision 6582 source please send me download link.

          sip-communicator-src-1.0-alpha3-nightly.build.2322.zip
       <
http://sip-communicator.org/download/nightly-builds/src/sip-communicator-src-1.0-alpha3-nightly.build.2322.zip
>

          On Fri, Jan 8, 2010 at 3:04 PM, Sebastien Vincent >> <seb@sip-communicator.org <mailto:seb@sip-communicator.org> >> <mailto:seb@sip-communicator.org >> <mailto:seb@sip-communicator.org>>> wrote:

              Hi,

              Have you compile and run SIP Communicator from the latest
              trunk version (revision 6582 now) ? Because we have updated
              libffmpeg/x264 recently.

              Regards,
              --
              Seb

              romal patel a écrit :

                  Is there any other condition need to be add in
                  h264parser.java file. Let me know

                  I already added following statement

                         if(!(currentStamp == lastTimestamp) ||
       lastHasMarker)
                         {
                              reset();
                         }

                     On Fri, Jan 8, 2010 at 2:42 PM, Sebastien Vincent
                     <seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>
                  <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>>
                  <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>
                  <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>>>> wrote:

                         Hi Romal,

                         Can you tell me the OSes of the two peers
       and have
                  you tested
                         over a LAN or over the internet ?

                         Regards,
                         --
                         Seb

                         romal patel a écrit :

                             Still video slow down or freeze and
       accelerate
                  a lot some
                             seconds. After I have added this patch .

                             On Wed, Jan 6, 2010 at 5:58 PM,
       Sebastien Vincent
                             <seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>
                  <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>>
                             <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>
                  <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>>>
                             <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>
                  <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>>
                             <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>
                  <mailto:seb@sip-communicator.org
       <mailto:seb@sip-communicator.org>>>>> wrote:

                                Hi folks,

                                I walk throught JMF and SC to find why
                  sometime in a
                             video call,
                                video slow down or freeze and
       accelerate a
                  lot some
                             seconds after.

                                I found something interresting in

src/net/java/sip/communicator/impl/neomedia/codec/video/h264/H264Parser.java
                                :

                                      // if the timestamp changes we are
                  starting
                             receiving a new
                                frame
                                      if(!(currentStamp ==
       lastTimestamp))
                                      {
                                          reset();
                                      }

                                (currentStamp is get by
                  inputBuffer.getTimestamp())

                                But we never reach this condition,
       because
                  currentStamp and
                                lastTimestamp are always equal to -1. So
                  H264Parser
                             considers that
                                the frame is never finished. It
       causes the
                  encodedFrame
                             to fill
                                and fill up... and sometime reach maximum
                  size and
                             throws the
                                exception "Cannot parse incoming
        null" in
                                H264Parser::pushRTPInput. The
       timestamp are
                  set to -1
                             in a JMF's
                                internal class (other parameter such
       as flags or
                             sequence number
                                are correct).

                                So to solve this, I propose to use the
                  marker flag
                                (Buffer.FLAG_RTP_MARKER) to see if
       current
                  frame is
                             finished. In
                                H264Parser, we remember if the last
       packet
                  processed
                             has the
                                marker and if yes, we reset it and start
                  processing
                             packet for a
                                new frame. Patch is attached, the
       result is
                  that video
                             has no more
                                freeze/acceleration and "noise".

                                If nobody is against, I will commit it.

                                Regards,
                                --
                                Sebastien

---------------------------------------------------------------------
                                To unsubscribe, e-mail:

dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                        <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                             <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                        <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
                                                <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                        <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                             <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                        <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>>

                                For additional commands, e-mail:

dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>>
                                   <mailto:
dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>>>
                                                <mailto:
dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>>
                                   <mailto:
dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>>>>

---------------------------------------------------------------------
                         To unsubscribe, e-mail:

dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                        <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
                                         <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
                        <mailto:
dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>>
                         For additional commands, e-mail:
                         dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>>
                               <mailto:
dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>
                  <mailto:dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>>>

---------------------------------------------------------------------
              To unsubscribe, e-mail:
              dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
              <mailto:dev-unsubscribe@sip-communicator.dev.java.net
       <mailto:dev-unsubscribe@sip-communicator.dev.java.net>>
              For additional commands, e-mail:
              dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>
              <mailto:dev-help@sip-communicator.dev.java.net
       <mailto:dev-help@sip-communicator.dev.java.net>>

   ---------------------------------------------------------------------
   To unsubscribe, e-mail:
   dev-unsubscribe@sip-communicator.dev.java.net
   <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
   For additional commands, e-mail:
   dev-help@sip-communicator.dev.java.net
   <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net