[FFmpeg-devel] [PATCH] frame_thread_encoder: make task indexing deterministic.
Michael Niedermayer
michael at niedermayer.cc
Sun Apr 2 00:44:12 EEST 2017
On Sat, Apr 01, 2017 at 08:50:37AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Apr 1, 2017 at 6:15 AM, Michael Niedermayer <michael at niedermayer.cc>
> wrote:
> [.]
> >
> > about the patch itself, the changes done to indexing seem not to
> > change anything, it makes it possible for the variables to overflow
> > though.
> >
>
> That's intentional, they're both unsigned and the one is guaranteed to be
> larger than the other so the difference after subtract would still be
> guaranteed to be <= n_threads. So although the indices overflow, the
> subtraction will always be correct.
>
>
> > IIUC the only change your patch does is to remove the outdata check
> > from the quoted warning
> >
>
> Yes, because if you change the delay to be fixed (and equal to n_threads),
> you no longer need the check. If the difference between indices is smaller
> than n_threads, you don't return a packet. If it's equal, you do return a
> packet.
>
> its a while ago that i worked n this code but isnt this just "missing"
> > a finished_task_mutex lock over the access ?
>
>
> I don't know, it depends on what you're trying to accomplish. If you want a
> fixed-frame delay, you don't need the access and so no mutex is needed. I
> haven't thought much about what you need to get a variable-frame delay. To
> me, a fixed-frame delay for intra-only codecs (which is what this API
> currently accomplishes in practice) is exactly what you would expect,
> variable-frame delay implies you're not actually using all threads. But
> maybe I misunderstand.
Lower delay is better, so is using fewer threads if theres no need for
more
it means less delay for any form of real time commuication
less memory used, less L2 cache used and consequently better use of
the CPU.
If decoding with 1 thread is fast enough for the rate at which packets
become available using 12 threads will result in more cpu cycles per
frame, more memory used, more watts, a higher energy bill, ...
[...]
--
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: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170401/cbdae33e/attachment.sig>
More information about the ffmpeg-devel
mailing list