lookahead threading

Issue #17 resolved
Steve Borho created an issue

The lookahead is currently threaded such that it uses the worker thread pool to perform the lowres cost estimates, but slicetypeDecide() (called from addPicture()) is still being run in the API thread context (from x265_encoder_encode()) and when b-adapt 2 is in use this can bottleneck the encoder.

Because the lookahead can use the worker pool, and because rate-control can also ask for cost estimates, it complicates moving the lookahead into its own thread. The first step must be to move key fields of struct Lookahead into a per-cost-estimate class that derives from WaveFront. Certainly the bDoSearch, curb, etc fields would go into this structure. Also the weighted buffers and frames array.

Then estimateFrameCost() will need to allocate one of these structs, fill in the appropriate data, start it up and then block until it is complete. When done, the struct should go onto a free list for re-use.

Comments (2)

  1. Steve Borho reporter

    slicetype: use a worker thread for slicetypeDecide when it may help (closes #17)

    If slicetype/scenecut analysis is enabled and the user has a thread pool of at least 4 threads, use a worker thread to run slicetypeDecide.

    Improves performance in presets that were bottlenecked by b-adapt 2 style lookahead complexity.

    → <<cset c7f3b7487f60>>

  2. Log in to comment