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

Michael Niedermayer michaelni at gmx.at
Fri Jun 13 11:56:02 CEST 2014


On Fri, Jun 13, 2014 at 11:01:44AM +0200, Christophe Gisquet wrote:
> Hi,
> 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.

the idea was that the avcodec_open2 call from the user doesnt fail
just the one from the frame_thread_encoder, which comes first
and reverts the threading then the single thread init wont fail

but yes it certainly isnt the prettiest solution

> > 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.

ill wait a few days and if noone complains or has a better suggestion,
will apply it then

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140613/67b0cec7/attachment.asc>

More information about the ffmpeg-devel mailing list