[sip-comm-dev] H263 JMF


#1

Hi!

I'm working with other SIP clients: xLite, Radvision, . and I'm having the
same problem, the H263 decoder doesn't work very good. It decode some blocks
badly. I explain the situation:

- SIP-Communicator to SIP-Communicator: it works very well.

- The problem appears in CIF and QCIF.

- At least, Radvision uses B mode frames, to send video.

- If I don't move, the image quality is restored slowly.

- If I reduce the bit rate the effect is reduced ---> It's like the
decoder had a lot of work to do and It was overflowed,

What's your opinion?

Thanks.

Regards, Pablo.


#2

Hi Pablo,

I really don't know what the problem might be, because I've never been looking inside the JMF codec code. Still I find it hard to believe that it would be a performance issue. I am more inclined to think that this would be an implementation bug.

Chris is currently investigating whether we could replace JMF with FMJ and he'll be working on filling in the blanks ( the RTP stack is the first thing he's going tackle I think ). Maybe, if he has time be fore his GSoC project has ended, he could try and look for alternative codec implementations, but even if he doesn't get to this himself, we'd still be looking into other solutions since JMF is probably the weakest link in the current version of SIP Communicator.

Cheers
Emil

Pablo wrote:

···

Hi!

I�m working with other SIP clients: xLite, Radvision, � and I�m having the same problem, the H263 decoder doesn�t work very good. It decode some blocks badly. I explain the situation:

- SIP-Communicator to SIP-Communicator: it works very well.

- The problem appears in CIF and QCIF.

- At least, Radvision uses B mode frames, to send video.

- If I don�t move, the image quality is restored slowly.

- If I reduce the bit rate the effect is reduced ---> It�s like the decoder had a lot of work to do and It was overflowed,

What�s your opinion?

Thanks.

Regards, Pablo.

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


#3

Thanks Emil for your anwser.

I've recently tested the codec again. I use my own RTPConnector (based
in the SUN example http://java.sun.com/products/java-
media/jmf/2.1.1/solutions/RTPConnector.html) with the RTPManager, and
I've seen that if I change the getMinimumTransferSize value in the
read socket the noise changes, so I think that it could be related
with a sockets, buffers or packets issue, but I don't know about these
topics so much.

Other thing I'm seeing is that the noise appears always in the same
place. For exaple, the upper area of the frame never has noise and a
few lines appears in the left side of the frame.

I've changed the codec using FOBS (the codecs is called only H263,
without RTP, but it seems to decode the packets correctly though the
log indicates some decodings errors (bad header, ...) and a similar
problem (noise) appears.

Could you find out something from this diagnostic?

Thanks again.

Regards, Pablo.

···

----- Mensaje original -----
De: Emil Ivov <emcho@emcho.com>
Fecha: Sábado, Junio 23, 2007 11:10 pm
Asunto: Re: [sip-comm-dev] H263 JMF
Para: dev@sip-communicator.dev.java.net

Hi Pablo,

I really don't know what the problem might be, because I've never
been
looking inside the JMF codec code. Still I find it hard to believe
that
it would be a performance issue. I am more inclined to think that
this
would be an implementation bug.

Chris is currently investigating whether we could replace JMF with
FMJ
and he'll be working on filling in the blanks ( the RTP stack is
the
first thing he's going tackle I think ). Maybe, if he has time be
fore
his GSoC project has ended, he could try and look for alternative
codec
implementations, but even if he doesn't get to this himself, we'd
still
be looking into other solutions since JMF is probably the weakest
link
in the current version of SIP Communicator.

Cheers
Emil

Pablo wrote:
> Hi!
>
>
>
> I’m working with other SIP clients: xLite, Radvision, … and I’m
having
> the same problem, the H263 decoder doesn’t work very good. It
decode
> some blocks badly. I explain the situation:
>
> - SIP-Communicator to SIP-Communicator: it works very

well.

>
> - The problem appears in CIF and QCIF.
>
> - At least, Radvision uses B mode frames, to send video.
>
> - If I don’t move, the image quality is restored slowly.
>
> - If I reduce the bit rate the effect is reduced --->
It’s like
> the decoder had a lot of work to do and It was overflowed,
>
>
>
> What’s your opinion?
>
>
>
> Thanks.
>
>
>
> Regards, Pablo.
>
>
>
>
>
>
>
>
>

-------------------------------------------------------------------
--
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