On 6/8/2020 7:54 AM, Anton Khirnov wrote: > Quoting Hendrik Leppkes (2020-06-08 12:42:08) >> On Mon, Jun 8, 2020 at 12:22 PM Anton Khirnov <an...@khirnov.net> wrote: >>> >>> This stops update_thread_context() from being called with frame >>> threading, which causes races. >>> --- >>> libavcodec/codec_desc.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c >>> index 9f8847544f..5117984c75 100644 >>> --- a/libavcodec/codec_desc.c >>> +++ b/libavcodec/codec_desc.c >>> @@ -1520,7 +1520,7 @@ static const AVCodecDescriptor codec_descriptors[] = { >>> .type = AVMEDIA_TYPE_VIDEO, >>> .name = "cfhd", >>> .long_name = NULL_IF_CONFIG_SMALL("Cineform HD"), >>> - .props = AV_CODEC_PROP_LOSSY, >>> + .props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_INTRA_ONLY, >>> }, >>> { >>> .id = AV_CODEC_ID_TRUEMOTION2RT, >>> -- >>> 2.26.2 >>> >> >> A codec property influencing a decoder implementation behavior seems >> iffy at best, doesn't it? >> What if I make an intra-only implementation for a codec that >> theoretically supports more? The information no longer matches. >> >> Flags changing behavior of an implementation should really be on AVCodec. > > I generally agree, but that condition is already there and changing it > to be more robust is not entirely trivial. I am planning to get to that > as a part of some other threading work, but I did not want it to delay > my other set which is blocked by this.
Maybe we could partially revert 13b1bbff0b (the intra only part) and re-purpose the flag to also apply to decoders? Or only decoders, whatever is best. We still can seeing 4.3 wasn't tagged. _______________________________________________ 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".