[h323plus] H.261 and G.722
jan at willamowius.de
Mon Jan 10 16:47:39 EST 2011
Simon took out the whole call to PreIncEncodeSetup() and not just the
zeroing of sbit_. I have restored that and added the initialization of
sbit_ in the H261Encode c'tor. Unfortuantely it doesn't help - if sbit_
isn't reset to 0, the plugin crashes in InEncodeAndGetPacket(), so I
just commented the suggested removal for now.
Alessandro, could you please provide a "diff -u" of your code against
the latest CVS ?
Alessandro Angeli wrote:
> From: "Jan Willamowius" <jan at willamowius.de>
> Date: Monday 10 January 2011 04:30
> > after your change to the H.261 plugin, it stopped working for me: With
> > the new plugin, I only receive a black video stream with Spranto and
> > Polycom PVX.
> > I had tested the old plugin with Polycom PVX, Polycom HDX 9004,
> > Tandberg T3 and the Mirial Softphone and all worked.
> > Alessandro, which Polycom device causes you trouble ? Is the new
> > plugin working any better there ?
> So far only the Polycom VSX 5000: it was the first one I tried and it
> did not work, so I found a fix for it but have not tested it with other
> devices yet.
> In any case the fix makes sense: resetting the sbit to 0 produces a
> packet stream that is RFC2032-compliant but the resulting bitstream is
> not H.261-compliant, that is it is decodable only by an RFC-aware
> However H261Encoder::sbit_ seems to never be initialized to a know
> value, so it is possible that (depending on machine, build type and
> alignment of the Moon in Pisces) the initial value falls outside the
> 0..7 range and nothing will work.
> Can you try to add
> , sbit_(0)
> (including the leading comma) to the list of initializers of
> H261Encoder::H261Encoder() (the very first function defined in
Jan Willamowius, jan at willamowius.de, http://www.gnugk.org/
More information about the h323plus