On Wed, Jul 31, 2024 at 01:26:23PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-07-24 20:44:50)
> > On Tue, Jul 16, 2024 at 07:11:48PM +0200, Anton Khirnov wrote:
> > > Reorganize the code such that the frame threading code does not call the
> > > decoders directly, but instead calls back into the generic decoding
> > > code. This avoids duplicating the logic that wraps the decoder
> > > invocation and allows receive_frame()-based decoders to use frame
> > > threading.
> > > 
> > > Further work by Timo Rothenpieler <timo@rothenpieler.org>.
> > > ---
> > >  libavcodec/avcodec.c          |   9 +-
> > >  libavcodec/avcodec_internal.h |  25 +--
> > >  libavcodec/decode.c           |  40 +++--
> > >  libavcodec/internal.h         |   7 +
> > >  libavcodec/pthread_frame.c    | 278 +++++++++++++++++++++-------------
> > >  5 files changed, 235 insertions(+), 124 deletions(-)
> > 
> > this (frm your recive_frame branch) breaks:
> 
> Then I will need to reintroduce some form of patch 28 - ideally its
> second iteration split into 3 patches, as then the ownership semantics
> of slice_damaged is much simpler.

simple is good
race is bad

Some more advanced EC code would be cool, if such a path would stay possible
I mean something that could maybe do a 2nd pass and fill in damaged slices
using both past and future non-damaged slices
(i mean not just for ffv1 but all codecs)
so the codec itself would do simply EC itself not depending on much surrounding
state.
Bit it then could export side data about what areas are damaged and have something
in a 2nd pass go over these areas and fill them in with more advanaced stuff

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr