| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This avoids confusing situations where we call stop(), then try
to restart the finder (unsuccessfully, because once it's stop()ped
it will stay around, never to be restarted).
|
|
It should be allowed to not have any grok stuff in the config file,
and we should generally call it grok rather than GPU in case
other non-grok GPU stuff arrives in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I think this makes sense, and also allows us to forward-declare the
contexts in a forthcoming commit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Soon we'll add a new encoder type, and the existing structure was
already creaking a bit at the seams while handling local and remote
encodes. Here we split out an encoder thread and introduce the concept
of a "sync" thread (which blocks while the encoding is happening).
Later we'll have another type which submits the encode request to a
GPU and receives the reply back later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
via his tool "grok".
|
