H263 JMF

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-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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.co
m/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 <emchoemcho.com>
Fecha: Sábado, Junio 23, 2007 11:10 pm
Asunto: Re: [sip-comm-dev] H263 JMF
Para: devsip-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-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-
> communicator.dev.java.net
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net