Hi,
2016-05-06 2:19 GMT+02:00 Rostislav Pehlivanov :
> I plan to merge the fate tests as well tomorrow or on Saturday when I'll
> have time to quickly fix bugs which appear on platforms I haven't tested
> the encoder on. Hopefully none, but you never know.
Sure, makes sense.
In case you don't fi
On 5 May 2016 at 10:06, Christophe Gisquet
wrote:
> The slice prefix is 0 in the reference encoder and the decoder ignores it.
> Writing 0 there seems like the best temporary solution.
>
> The padding could have contained uninitialized data, but reference VC2
> encoders put 0xFF there, hence the
The slice prefix is 0 in the reference encoder and the decoder ignores it.
Writing 0 there seems like the best temporary solution.
The padding could have contained uninitialized data, but reference VC2
encoders put 0xFF there, hence the memset value.
Overall this allows producing bistreams with n
Hi,
2016-05-04 3:06 GMT+02:00 Rostislav Pehlivanov :
> vc2hqencode is not the reference encoder, vc2-reference is. It's even worse
> though.
Sorry, I thought authoritative could mean "from the authors", so I
didn't mean it as "the" reference/"the authority". Just a good
reference in case the spec
On 3 May 2016 at 18:25, Christophe Gisquet
wrote:
> 2016-05-03 19:06 GMT+02:00 Christophe Gisquet <
> christophe.gisq...@gmail.com>:
> > +memset(pb->buf_ptr, 0, pad_c);
>
> Commit squashing fail, attached patch should fix that. This
> unfortunately requires updating the fate tests as I ge
Le 3 mai 2016 22:15, "Rostislav Pehlivanov" a écrit :
>
> On 3 May 2016 at 19:16, Christophe Gisquet
> wrote:
> >
> >
> > Btw, afaik, the padding is 0xFF, so expecting 0 in the buffer there
> > can't do the job.
> >
> >
> I don't get it, you keep saying that the padding must be 0xff yet the
patch
On 3 May 2016 at 19:16, Christophe Gisquet
wrote:
>
>
> Btw, afaik, the padding is 0xFF, so expecting 0 in the buffer there
> can't do the job.
>
>
I don't get it, you keep saying that the padding must be 0xff yet the patch
you posted puts 0x00. Where did you even read that the padding must be
0xf
Hi,
2016-05-03 19:24 GMT+02:00 Hendrik Leppkes :
>> +// The reference decoder ignores it, and its typical length is 0
>> +memset(put_bits_ptr(pb), 0, s->prefix_bytes);
>> skip_put_bytes(pb, s->prefix_bytes);
>> +
>
> I don't suppose we have a function to just write zero bytes instead
On Tue, May 3, 2016 at 7:06 PM, Christophe Gisquet
wrote:
> The slice prefix is 0 in the reference encoder and the decoder ignores it.
> Writing 0 there seems like the best temporary solution.
>
> The padding could have contained uninitialized data, but its standardized
> value
> is 0xFF, hence t
The slice prefix is 0 in the reference encoder and the decoder ignores it.
Writing 0 there seems like the best temporary solution.
The padding could have contained uninitialized data, but its standardized value
is 0xFF, hence the memset value.
Overall this allows producing bistreams with no rando
2016-05-03 19:06 GMT+02:00 Christophe Gisquet :
> +memset(pb->buf_ptr, 0, pad_c);
Commit squashing fail, attached patch should fix that. This
unfortunately requires updating the fate tests as I generated them
from this squashing.
--
Christophe
From 3008fd916cca5b9ab22e96536e778d63ba25ed2
11 matches
Mail list logo
