On 03/01/2020 21:59, Derek Buitenhuis wrote:
> Is this guaranteed somehow? It isn't mentioned in the spec.
Looks like it's inherent to how it's stored.
I'll send a v2 with this.
Thanks,
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 03/01/2020 22:59, Derek Buitenhuis wrote:
On 02/01/2020 23:09, Michael Niedermayer wrote:
I think if entry 128 is 0 then the whole table must be 0.
If that is the case, checking the entry 128 of table 4 and 5 would be enough
and caching the entry comparission is maybe not needed.
Is this
On 02/01/2020 23:09, Michael Niedermayer wrote:
> I think if entry 128 is 0 then the whole table must be 0.
> If that is the case, checking the entry 128 of table 4 and 5 would be enough
> and caching the entry comparission is maybe not needed.
Is this guaranteed somehow? It isn't mentioned in
On Thu, Jan 02, 2020 at 03:22:25PM +, Derek Buitenhuis wrote:
> Currently, the decoder checks the 128th value of the 4th quant table during
> while deriving the context on each sample, in order to speed itself up. This
> is due to relying on the behavior of FFmpeg's FFV1 encoder, in which if
On 02/01/2020 16:17, Jerome Martinez wrote:
>> @@ -797,9 +800,11 @@ static int read_header(FFV1Context *f)
>> p->quant_table_index = idx;
>> memcpy(p->quant_table, f->quant_tables[idx],
>> sizeof(p->quant_table));
>> +
On 02/01/2020 16:22, Derek Buitenhuis wrote:
Currently, the decoder checks the 128th value of the 4th quant table during
while deriving the context on each sample, in order to speed itself up. This
is due to relying on the behavior of FFmpeg's FFV1 encoder, in which if that
value is zero, the
Currently, the decoder checks the 128th value of the 4th quant table during
while deriving the context on each sample, in order to speed itself up. This
is due to relying on the behavior of FFmpeg's FFV1 encoder, in which if that
value is zero, the entire 4th and 5th quant tables are assumed to be
