search for: pabis

...cept #1 you described, CUDA and OpenCL have efficient mechanisms to deal with synchronization, memory sharing etc. This approach probably would benefit with higher resolutions. CUDA and/or OpenCL could be also performing concept #2, with the same limitations unfortunately. -- Best regards Mateusz Pabis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/theora-dev/attachments/20150204/9d6a0bb9/attachment.htm

...it looks like all this was dropped. Am I right? If the multithreading encoding was dropped out, may I ask why? I think I could dedicate some of my free time to bring multithreading to the Theora encoder but I would like to ensure not to be redundant ;-) -- Thanks in advance for answers. Mateusz Pabis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/theora-dev/attachments/20150204/2a6e39aa/attachment.htm

Am 04.02.2015 um 12:31 schrieb Timothy B. Terriberry: > M. Pabis wrote: >> 1. Each thread deals with frames from intra frame up to next intra frame >> - 1; > > This works if you know where the intra frames are. Could this information be gathered by having one thread encode a downsampled version of the input video sequence, or would this be a...

M. Pabis wrote: > If the multithreading encoding was dropped out, may I ask why? IIRC, the commits from 2007 only threaded the motion search, and gave gains of only 10 to 20%. However, as part of the work to improve the Theora encoder quality for the HTML5 video tag, the way this search was done was...

M. Pabis wrote: > 1. Each thread deals with frames from intra frame up to next intra frame > - 1; This works if you know where the intra frames are. Currently the frame type decision is made by trying to encode as an inter frame, and keeping statistics on expect rate and distortion from using all i...