On 06/ 9/13 10:00 AM, Julien Cristau wrote:
The padding is *before* the rate field, so the rate is placed on a 32bit
boundary. This change adds explicit padding between height and rate,
and removes extraneous padding after the rate field, which the server
never sent and xlib never read.
This ch
On 10 June 2013 11:55, Julien Cristau wrote:
> On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote:
>
>> On 9 June 2013 19:00, Julien Cristau wrote:
>> > The padding is *before* the rate field, so the rate is placed on a 32bit
>> > boundary. This change adds explicit padding between heig
Julien Cristau writes:
>
> Both it and libXv use sz_xvEncodingInfo, which is ok.
Am I right code is always supposed to use the "sz_" constants, not
sizeof? Not that that would be an excuse to break anything.
If in doubt I suppose could put the intended pad before, but leave the
pad at the end a
On Mon, Jun 10, 2013 at 11:41:00 +0200, Daniel Martin wrote:
> On 9 June 2013 19:00, Julien Cristau wrote:
> > The padding is *before* the rate field, so the rate is placed on a 32bit
> > boundary. This change adds explicit padding between height and rate,
> > and removes extraneous padding afte
On 9 June 2013 19:00, Julien Cristau wrote:
> The padding is *before* the rate field, so the rate is placed on a 32bit
> boundary. This change adds explicit padding between height and rate,
> and removes extraneous padding after the rate field, which the server
> never sent and xlib never read.
>
The padding is *before* the rate field, so the rate is placed on a 32bit
boundary. This change adds explicit padding between height and rate,
and removes extraneous padding after the rate field, which the server
never sent and xlib never read.
This changes sizeof(xvEncodingInfo). Hopefully that'
