There are minimal changes to current code:
- Use h264 codec for output
- Specify number of threads for encoding to be same as system thread count
- Specify same nuber of threads for decoding. This may work only with some codecs(only h264 tested so far), but performance gain in encoding improves overall performance by big margin still. I have tested variety of codecs, and all were transcoded properly.
This is much simpler and straightforward patch than previous two, and this was in fact first thing I have tried to do in the beginning, but there was no improvement unless I have removed following lines:
rv->c->thread_count = BLI_system_thread_count(); rv->c->thread_type = FF_THREAD_SLICE;
I am not even sure how I found that these two lines were problematic.
Performance vs filesize comparison, source file was h264, 1920 x 1080, 2002 frames, 51M filesize
Old MJPEG implementation
| size | transcoding time | filesize |
| 25 | 13.7s | 44M |
| 50 | 17.2s | 116M |
| 75 | 20.1s | 197M |
| 100 | 21.4s | 297M |
Results for this patch
| size | transcoding time | filesize |
| 25 | 2.0s | 30M |
| 50 | 3.7s | 74M |
| 75 | 6.2s | 127M |
| 100 | 8.0s | 192M |
Transcoding VP9 coded resulted in performance and filesize.
Quality vs filesize for same source file:
| quality | filesize |
| 1 | 57M |
| 10 | 63M |
| 20 | 78M |
| 30 | 86M |
| 40 | 106M |
| 50 | 117M |
| 60 | 143M |
| 70 | 158M |
| 80 | 192M |
| 90 | 211M |
| 100 | 253M |
These tests were done on 16 core machine