The header is always written by the main thread, so it is
not surprising that header_bits can be moved to MPVMainEncContext
as well.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avpriv_slicethread_free() is one of our functions that takes
a pointer to a pointer and resets the pointer when done.
It is legal for such functions to be passed a pointer to a NULL
pointer, yet passing a NULL pointer would be insane and should
not be tolerated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is no longer necessary given that the MPEG-1 encoder
now adapts the size of the last slice to ensure that
no slice header has an invalid slice_start_code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The valid values for slice_start_code are 0x1..0xAF, which implies
that one can't start a slice with row nb > 174 (zero-based).
This problem can be encountered with files of sufficient height
(more than 2800 pixels) either by using the slice option or by
imposing an RTP payload limit.
Fix this by making the last slice start on the maximum allowed
slice row if necessary and divide the first 174 rows to the remaining
slices. This will impede parallelism both in the decoder and encoder,
but that is unavoidable.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Everything except setting the dc_scale_tables can be done
before calling ff_mpv_encode_init(); setting the dc_scale_tables
unfortunately still has to be performed via a (now inlined)
callback performed by ff_mpv_encode_init() as it relies
on intra_dc_precision having been sanitized.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for merging ff_mpeg1_encode_init()
into the MPEG-1/2 encoder's init function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reuse the already computed value of macroblocks; use an array
instead of a switch, evaluate 64 * sizeof(MJpegHuffmanCode)
at compile-time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, ff_mpv_encode_init() is set as FFCodec.init and
calls ff_speedhq_encode_init(). The opposite is more natural,
avoids a non-static function and allows to reuse e.g.
slice_context_count instead of duplicating the logic from
ff_mpv_common_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely use avctx directly instead of s->avctx. While just at it,
also move the switch to the other checks involving avctx.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, ff_mpv_encode_init() is set as FFCodec.init and
calls ff_speedhq_encode_init(). The opposite is more natural
and avoids a non-static function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the H.263-based decoders as well as the encoders need it;
so move it to ff_h263_decode_init() as well as ff_mpv_encode_init().
Also for the latter make it only set these tables if none are
already set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Right now, ff_mpv_encode_init() is set as FFCodec.init and
calls ff_h261_encode_init(). The opposite is more natural
and avoids a non-static function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move b_frame_strategy and b_sensitivity and brd_scale;
they are all only used by an encoder's main thread when
b_frame_strategy == 2.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for moving all the elements from
MpegEncContext that are only used by the main encoder thread
to MPVMainEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Core framework and AV1 only for now.
This will be useful in an upcoming commit, where CBS will be utilized by
a module outside libavcodec.
Signed-off-by: James Almer <jamrial@gmail.com>
This will be useful a following commit, where the offset of the Tile Group
inside a Frame OBU needs to be known.
Signed-off-by: James Almer <jamrial@gmail.com>
This reduces stack space requirements my 1.5 mb and should fix fate
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
not a bugfix as this path was only used for float16 but it makes sense
to allow using this for integers too
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes failures in some systems since 171060d5dc.
This can be further improved by only allocating the arrays when needed.
Signed-off-by: James Almer <jamrial@gmail.com>
ATM this performs as well or better as any other algorithm tried.
Its simple for the decoder.
On the encoder side complexity depends on how parameters are
chosen. But with a fixed mul_count of 1 and basic heuristic
it performs as well as any more complex choice i tried so far.
The encoder code here is flexible and allows mul_count > 1
and also can easily be used to exactly test various parameters.
With mul_count=512 we can gain another 6% in remap table size
for fixed point in float data. (this is not implemented in this
patch though)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
