GitLab

Summary:
One can pass "threads" and "thread_type" to `decoder_option` of StreamReaader to change the multithreading configuration.

These affects the timing that decoder starts emitting the decoded frames. i.e. how many packets at minimum have to be processed before the first frame is decoded.

Overall, multithreading in decoder does not improve the performance.
(One possible reason is because the design of StreamReader, "decode few frames then fetch them", does not suited to saturate the decoder with incoming packets.)

num_threads=1 seems to exhibit overall good performance/resource balance.

![Decoding time over threading](https://user-images.githubusercontent.com/855818/210380632-1ab72608-76aa-4445-808a-50cef215dbac.png)
![Decoding time over threading (1)](https://user-images.githubusercontent.com/855818/210380639-ec5574b0-9087-4f22-84a4-a2c0ee632dd9.png)
(Tested on 320x240 25 FPPS, YUV420P videos generated with `ffmpeg -f lavfi -t "${duration}" -i testsrc -pix_fmt "yuv420p"`)

For this reason, we default to single thread execution in StreamReader.
closes https://github.com/pytorch/audio/issues/2855

Follow-up: Apply similar change to encoder option in StreamWriter.

Pull Request resolved: https://github.com/pytorch/audio/pull/2949

Reviewed By: carolineechen

Differential Revision: D42343951

Pulled By: mthrok

fbshipit-source-id: aea234717d37918f99fc24f575dbcfe7dcae1e80