<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for your response.<br>
<br>
I made some testing with "live" streaming.<br>
<br>
I used this very basic command line:<br>
<br>
ffmpeg2theora /dev/video0 -f video4linux2 --inputfps 12 -x 352 -y 288
-A 32 -V 500 -K 2 -d 1 -o - | oggfwd localhost 8000 hackme /teste.ogv<br>
<br>
Warning: could not set desired buffer delay of 1, using 12 instead.<br>
<br>
This message is generated by :<br>
<pre> if(info.passno!=1 && this->buf_delay >= 0){
int arg = this->buf_delay;
ret = th_encode_ctl(info.td, TH_ENCCTL_SET_RATE_BUFFER,
&this->buf_delay, sizeof(this->buf_delay));
if (this->buf_delay != arg)
fprintf(stderr, "Warning: could not set desired buffer delay of %d, using %d instead.\n",
arg, this->buf_delay);
if(ret < 0){
fprintf(stderr, "Warning: could not set desired buffer delay.\n");
}
}
</pre>
It seems that buf_delay is set by th_encode_ctl...<br>
<br>
The lower "latency" i got was 12seconds... Am i missing something?<br>
<br>
Other thing that i've noticed is that for static images (i.e) a static
bitmap on every frame (with these options), the bitrate does not have "d<br>
ffmpeg2theora /dev/video0 -f video4linux2 --inputfps 12 -x 352 -y 288
-A 32 -V 500 -K 2 -d 1 -o - | oggfwd localhost 8000 hackme /teste.ogv<br>
<br>
Gregory Maxwell wrote:
<blockquote
cite="mid:e692861c1001050437p6f248cc8i40484212146820b0@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Jan 4, 2010 at 11:49 PM, iMDT - Tiago Jacobs <a class="moz-txt-link-rfc2396E" href="mailto:tiago@imdt.com.br"><tiago@imdt.com.br></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
The algorithmic delay is one frame. Never greater because the format
does not use forward references.
</pre>
<blockquote type="cite">
<pre wrap=""> -> Is the format tolerant to lost frames?
</pre>
</blockquote>
<pre wrap=""><!---->
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 <a class="moz-txt-link-rfc2396E" href="mailto:mgliga@integrasoft.ro"><mgliga@integrasoft.ro></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
<a class="moz-txt-link-freetext" href="http://media.xiph.org/video/derf/y4m/soccer_4cif.y4m">http://media.xiph.org/video/derf/y4m/soccer_4cif.y4m</a> (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.
</pre>
</blockquote>
</body>
</html>