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
>...