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 entire 4th and 5th quant tables are assumed to be entirely
zero.
This does not match the FFV1 spec, which has no such restriction, and after
some discussion, it was decided to fix FFmpeg to abide by the spec, rather
than change the spec.
Thanks for having taken care of this issue.
[...]
@@ -735,6 +737,7 @@ static int read_header(FFV1Context *f)
f->chroma_h_shift, f->chroma_v_shift, f->avctx->pix_fmt);
if (f->version < 2) {
context_count = read_quant_tables(c, f->quant_table);
+ f->three_quant_table = is_three_quant_tables(f->quant_table);
if (context_count < 0) {
av_log(f->avctx, AV_LOG_ERROR, "read_quant_table error\n");
return AVERROR_INVALIDDATA;
@@ -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));
+ p->three_quant_tables = f->three_quant_tables[idx];
context_count = f->context_count[idx];
} else {
memcpy(p->quant_table, f->quant_table,
sizeof(p->quant_table));
+ p->three_quant_tables = f->three_quant_table;
}
Couldn't three_quant_table be a local value instead of being stored in
the context?
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
I may have missed something, but I don't get what the additional code in
the encoding part does, value seems not used.
And I am reluctant to change anything in the encoder in this patch as we
consider that the issue is "only" a too aggressive optimization in the
decoder.
Jérôme
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
