search for: oc_enc_frame_pack

Displaying 4 results from an estimated 4 matches for "oc_enc_frame_pack".

2015 Feb 03
2
Multithread support
Hi, I recently had to encode few hours of desktop stream with Theora and I noticed it used only one core for encoding. Was I missing something? I did not find any "thread" options. As I dig, I found there was a multithread patch back in 2007, and some ffmpeg2theora-multithread commits, but it looks like all this was dropped. Am I right? If the multithreading encoding was dropped out,
2015 Feb 04
0
Multithread support
...yone has been working on this for some years. There are two basic approaches. One is threading within a single frame, which does not require any API behavior changes. In theory you can scale to a fairly decent number of threads everywhere except the final conversion from tokens to VLC codes in oc_enc_frame_pack(). However, the units of work are sufficiently small and the task dependencies sufficiently involved that this needs some kind of lock-free work-stealing queues to have a hope of getting more benefit from the parallelism than you pay in synchronization overhead. I'd started designing one wi...
2011 Apr 07
1
binary stream after tokenizer and huffman
Which procedure/function or structure returns finally formed binary stream? I see lib/tokenize.c and lib/encode.c. But it is too hard to understand novice. Theora algorithm differ in coding with JPEG: http://www.pcs-ip.eu/index.php/main/edu/8 Which function/structure returns stream like this: 100000100011001101101101111101011111111010110011010
2015 Feb 04
3
Multithread support
...this for some years. There are > two basic approaches. > > One is threading within a single frame, which does not require any API > behavior changes. In theory you can scale to a fairly decent number of > threads everywhere except the final conversion from tokens to VLC codes in > oc_enc_frame_pack(). However, the units of work are sufficiently small and > the task dependencies sufficiently involved that this needs some kind of > lock-free work-stealing queues to have a hope of getting more benefit from > the parallelism than you pay in synchronization overhead. I'd started >...