On Mon, Jan 4, 2010 at 11:49 PM, iMDT - Tiago Jacobs <tiago at
imdt.com.br> wrote:> Hello, i am member of red5 project. I am studying ways to integrate your
> codec into red5 and in a near future inside Flash Player.
>
> I want to figure some things about Theora codec.
>
> ? ?-> Is theora proper for live streams (i.e live transcondig webcam)?
> What is latency for encoding process?
The algorithmic delay is one frame. Never greater because the format
does not use forward references.
> ? ?-> Is the format tolerant to lost frames?
Not especially, unless you make every frame a key frame at a great
loss of compression efficiency. If you lose a frame you will
experience considerable corruption until the next keyframe. If your
client can communicate back to the to encoder that you've lost a frame
you should be able to force a keyframe, thus recovering.
The *format* could do better. Rather than only using whole-frame
keyframes an encoder could produce "rolling keyframes" where a part of
the frame is refreshed without reference to prior frames on each
frame. This would speed up recovery from a loss somewhat without the
cost of making more complete frames a keyframe, but it would require a
fair amount of infrastructure work in the encoder.
On Tue, Jan 5, 2010 at 2:06 AM, Mircea Gliga <mgliga at integrasoft.ro>
wrote:> Hello,
> I also was studying Theora a month ago. I wanted to integrate Theora in
> a online conference system. I encoded
> the video from a webcam using Theora and Xvid. Then I made a comparison
> between Theora and Xvid performaces.
> I measured how long does it take for Theora to encode an 640x480 image from
> the webcam (th_encode_ycbcr_in and th_encode_packetout
> API calls). I was doing this while shaking the camera, generating a lot of
> keyframes. On average: *80 ms*.
> Using XVID I've obtained between *20-25 ms* for an image.
That's 60ms
> longer using Theora.
> Also, the CPU load was higher in case of Theora.
We were never able to figure out why Theora was slow for you. There
may be some flaw with the windows project files and assembly support.
If you have an opportunity can you time a quality 25 (quality 4 in
applications with a range of 10) keyframe interval 64 encode of
http://media.xiph.org/video/derf/y4m/soccer_4cif.y4m (704x576x60fps
with high motion)
For me, on 2.8ghz core2 (X3360, so 6MB cache) that file averages
36.7ms/frame for the entire encode process, including reading the
frames. 30.6ms/frame with a lower bitrate (2mbit/sec) output.
20ms/frame with keyint=1 (the high bitrate of the keyframes is offset
by never having to do any of the differential stuff, as well has
having fewer modes to consider; of course the bitrate is stupid, but
this might matter for applications where the bitrate isn't important)
Switching to speed level 2 (which might be acceptable for a low motion
talking head clip, its not for this kind of footage) the speed
increases to 16.9ms/frame.
On a 1.6ghz core2 (L7500; 4mb cache) I'm timing an average of
66.9ms/frame (31.2ms/frame with speedlevel 2)
In all my cases I'm building with GCC 4.4.2 on Fedora, so its a fairly
different environment. Still, If there is something wrong with the
windows project files for encoding assembly support I would be
interested in finding that out.