[FFmpeg-devel] [RFC] [PATCH] huffyuvenc, multithread and context=1

Christophe Gisquet christophe.gisquet at gmail.com
Fri Jun 13 11:01:44 CEST 2014


2014-06-13 4:07 GMT+02:00 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Jun 13, 2014 at 12:56:30AM +0200, Christophe Gisquet wrote:
> and check for it after the avcodec_open2() call in ff_frame_thread_encoder_init()
> and then fall back to like the warning case thats above

avcodec_open2 is a public API, right? So that would need an API bump anyway.
Another point, would that be an error code? The issue I see with this
is that currently, instead of failing, ff_frame_thread_encoder_init
changes the thread count.

But returning an error implies a failure. For external users of
avcodec_open2 that don't know better, there's no graceful way to
handle it. ff_frame_thread_encoder_init can be made to completely
revert the threading, probably, but that's kind of messy.

> i suspect that will be more lines of code but could avoid all the
> codec specific checks in frame_thread_encoder

The most glaring issues with it are:
- Getting the option value ignores the codec's default
- It is completely dependent on knowing the codec option, without
having the codec tell us about it

> another option would be a new callback in AVCodec

Yeah, I get that this whole thing seems like over-engineered.

> either way the patch isnt that bad, i can apply it if you want?

I feel like people will come to any of us in the future and complain
about this hack. But if they don't step up soon, maybe that's the less
bothersome way.


More information about the ffmpeg-devel mailing list