Hi,
That is a little disappointing to hear. We are currently
encoding live rv10 at 50kbps in cbr with 15fps and packet
protection on. But the wireless connection via cdma from
encoder to server varies a lot from 20-60kbps. So the end
effect is there are frequent packets losses that causes the
playback very blocky, tearing, frozen, or sometimes big
messy for many seconds.
Since codec doesn't have the scaling back capability, what
could you suggest to set the encoding options or special
kind of tricks to encode like lowering the framerate to
handle the big variability of wireless connection for
cleaner and stable broadcasting and playing back experience?
thanks very much for your help and time,
Frank
Karl Lillevold <karll real.com> wrote: I am
afraid you may have misunderstood a little. I was trying to
say
such a feature could be developed inside the codec, but
there are no
resources available to do so now. Also, if such work were
done, some
kind of registry alternative would have to be thought of for
Linux.
Karl.
on focus wrote:
> Karl,
>
> that is very good news since the change of bitrate on
the fly is
> definitely a key feature for our application on the
wireless network.
> Because we are using helix encoder and codec (on the
Linux platform)
> directly, could you please advise me how we could call
related
> interface of codec/encoder sdk directly to achieve the
same effect via
> registry you described in your email? thanks very much
for your help.
>
> alan
>
>
> */Karl Lillevold /* wrote:
>
> I am not sure Steve's suggestion would work too
well. The codec will
> strive to produce the number of bits it initially
was asked to produce.
> The ability to change bitrate on the fly could be
added to the codec
> itself without any producer interfaces, via a
registry entry that could
> be read for every frame, but I am afraid there are
no resources
> available to do so at the moment.
>
>
> Karl.
>
>
> Steve McMillen wrote:
> > I'm not the right expert but maybe you could
just stop sending some of
> > the frames to the encoder. The codec may work
against you a bit when
> > doing this by increasing the quality of the
frames it does encode but
> > you should be able to make moderate changes in
output bit rate by
> > lowering input frame rate.
> >
> > Other than that, I'm not aware of ways to
dyamically adjust the
> bit rate
> > the codec is targeting.
> >
> > Steve
> >
> > on 1/12/08 8:13 PM on focus said the
following:
> >> Hi, Karl and helix producer experts,
> >>
> >> Is there anyway for the encoding bitrate
in the Helix encoder to be
> >> modified on the fly? The sureStream
technology (imho, it is from
> >> server to player) doesn't really apply to
our situation because our
> >> application is for the encoding box to use
wireless connection to
> >> broadcast to server. But the wireless
connection varies a lot and it
> >> is very beneficial for our encoding box to
adjust the bitrate to
> adapt
> >> to the wireless connection. Any
suggestions will be appreciated.
> >> Frank,
> >>
> >> Karl Lillevold wrote: Yes, it is highly
optimized for
> >> MMX and SSE2. Without it, it would be 4x
> >> slower.
> >>
> >> Karl.
> >>
> >>
> >> on focus wrote:
> >>
> >>> Karl,
> >>>
> >>> I just thought of one question (or
idea). Does the encoder codec
> RV9/10
> >>> compiled for X86 architecture have the
MMX/SSE/SSE2 instruction
> >>> optimization? Since my Pentinum M CPU
has all the mmx/sse/sse2
> >>> optimization flags on, I am just
wondering if the codec libs we
> got has
> >>> those optimization on, which could
make huge difference if not.
> thanks,
> >>>
> >>> Frank,
> >>>
> >>> */Karl Lillevold /* wrote:
> >>>
> >>> Frank,
> >>>
> >>> I am pretty sure what happens when you
run multiple encoding
> >>> processes
> >>> in parallel, is contention over CPU
resources, in particular cache
> >>> memory. So I am not too surprised to
see your numbers. I do not have
> >>> any good suggestions for speeding it
up further than using low
> >>> complexity.
> >>>
> >>> RV10 Low complexity is in fact
the same as RV9, algorithmically.
> >>>
> >>> Karl.
> >>>
> >>>
> >>>
> >>> on focus wrote:
> >>> > Karl,
> >>> >
> >>> > thanks very much for the response
and result to share. I did
> >>> some test
> >>> > based on Steve's suggestion and
come up with quite similar
> >>> result to
> >>> > yours, which we are glad that is
something at least we can have
> >>> some
> >>> > common base, i.e. for talking
head sequence like CIF Aikyo,
> >>> RV10 with
> >>> > complexity low setting and
keyframe setting at 15 can do 520+
> >>> frames per
> >>> > second to encode bitstream of
225kbps 25fps (audience setting is
> >>> 256K)
> >>> > on a P4 Dual core 3.0GHz machine.
But I have some troubles to
> >>> understand
> >>> > why the above result doesn't
scale up:
> >>> >
> >>> > We use the same machine with the
above hw configuration to
> >>> encode 8
> >>> > channels of the same clip with
same setting (by launching 8
> >>> different
> >>> > encoder processes), the CPU is
very much saturated and the encoded
> >>> clips
> >>> > have some frame loss (can only
encode around 23fps).
> >>> Intuitively, 8
> >>> > channels = 8 * 25fps = 200fps
which is only half of 500fps the
> >>> machine
> >>> > can achieve. Where is the CPU
spin on?
> >>> >
> >>> > If what Karl's mentioning of file
reading overhead really
> >>> matters, our
> >>> > test seems not echoing that
statement because we tried to read all
> >>> > YUV420 data into memory and keep
using it for every channel, it
> >>> doesn't
> >>> > seem to matter that much (there
are slight improvement) to cover
> >>> the 50%
> >>> > difference we observed.
> >>> >
> >>> > we seems to run out of idea how
to make sense of this problem and
> >>> would
> >>> > like to get some expert
suggestion from you or anyone in the Helix
> >>> > producer community who has some
experience on this issue. thanks,
> >>> >
> >>> > Frank,
> >>> >
> >>> > P.S., How can we configure the
Helix producer to use RV9 instead
> >>> of RV10
> >>> > to see if there is any
difference?
> >>> >
> >>> > */Karl Lillevold /* wrote:
> >>> >
> >>> > The encoder also has several
complexity levels that can vary the
> >>> > encoding speed up to 3-5X for
real time adaptation on slower
> >>> systems.
> >>> >
> >>> > For the system mentioned, the
file reading overhead is going to be
> >>> large
> >>> > part of the time it takes to
encode an uncompressed test sequence.
> >>> >
> >>> > On my dual core 2 at 2.4 GHz, I
get from 5 to 19 ms per frame for
> >>> > Foreman CIF, depending on chosen
complexity, and from 2.5 to 14
> >>> ms per
> >>> > frame for Akiyo, not counting
file reading overhead.
> >>> >
> >>> > Karl.
> >>> >
> >>> >
> >>> > Steve McMillen wrote:
> >>> > > I recommend you do a file to
file encode of an input clip of
> >>> a fixed
> >>> > > duration and your resulting
duration will tell you how many
> >>> fps were
> >>> > > processed. I fully expect
the result to be < actual clip
> >>> duration.
> >>> > > That is, given that frame
size and bit rate, encoding should
> >>> easily be
> >>> > > faster than realtime on the
box you specified.
> >>> > >
> >>> > > On 8/5/2007 6:56 PM, on
focus wrote:
> >>> > >> Hi, Steve,
> >>> > >>
> >>> > >> We have come to a point
that we need to know more exactly what
> >>> is the
> >>> > >> encoding performance of
RV10. We checked the only available
> >>> Rv10
> >>> > codec
> >>> > >> review .pdf file from
Helix community/Real website, there is a
> >>> brief
> >>> > >> mentioning of its speed,
but not quite exact (there is
> >>> actually a
> >>> > >> conflicting and
confusing info there with footnote) to let us
> >>> decide
> >>> > >> what machine we can
properly choose for our encoding task.
> >>> Basically,
> >>> > >> are there any more
thorough or exact doc that can be shared in
> >>> Helix
> >>> > >> community that gives:
> >>> > >>
> >>> > >> What is the encoding
speed or performance for encoding a target
> >>> > of CIF
> >>> > >> 352x288 25fps
256kbps on a P4 Dual 3.0GHz machine or whatever
> >>> > >> physical machine it
could be targeted for a standard test
> >>> sequence,
> >>> > >> like, Aikyo, or Foreman?
The encoding speed can be measured
> >>> by how
> >>> > >> many actual frames RV10
can encode per second? or How many
> >>> mips it
> >>> > >> takes for encoding a
frame averagely?
> >>> > >>
> >>> > >> Many thanks,
> >>> > >>
> >>> > >> Frank,
> >>> > >>
> >>> > >>
> >>> >
> >>>
> >>>
>
------------------------------------------------------------
------------
> >>> > >> Ready for the edge of
your seat? Check out tonight's top picks
> >>> > >> on Yahoo! TV.
> >>> > >
> >>> > >
_______________________________________________
> >>> > > Helix-producer-dev mailing
list
> >>> > > Helix-producer-devhelixcommunity.org
> >>> > >
> >>> http://lists.helixcommunity.org/mailman/listi
nfo/helix-producer-dev
> >>> >
> >>> >
_______________________________________________
> >>> > Helix-producer-dev mailing list
> >>> > Helix-producer-devhelixcommunity.org
> >>> >
> >>> http://lists.helixcommunity.org/mailman/listi
nfo/helix-producer-dev
> >>> >
> >>> >
> >>> >
> >>>
> >>>
>
------------------------------------------------------------
------------
> >>> > Building a website is a piece of
cake.
> >>> > Yahoo! Small Business gives you
all the tools to get online.
> >>> >
> >>> >
> >>>
> >>>
> >>>
>
------------------------------------------------------------
------------
> >>> Yahoo! oneSearch: Finally, mobile
search that gives answers
> >>> ,
> >>> not web links.
> >>>
> >>
> >>
> >> ---------------------------------
> >> Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.
> >> Try it now.
> >>
_______________________________________________
> >> Helix-producer-dev mailing list
> >> Helix-producer-devhelixcommunity.org
> >> http://lists.helixcommunity.org/mailman/listi
nfo/helix-producer-dev
> >>
> >>
>
>
>
------------------------------------------------------------
------------
> Be a better friend, newshound, and know-it-all with
Yahoo! Mobile. Try
> it now.
> >>
---------------------------------
Never miss a thing. Make Yahoo your homepage.
_______________________________________________
Helix-producer-dev mailing list
Helix-producer-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listi
nfo/helix-producer-dev
|
Hi, Helix codecers:
I have a codec related question of how to control the
variability of output bitrate stream that I definitely need
your expertise because no matter how much I read the Helix
producer's doc and api, I couldn't figure out a way to solve
it.
Box setting: Helix DNA producer SDK V11 release on Linux
with kernel 2.6.18 on Petinum 4 2.0G and 1G RAM machine
Encoding setting: 50kbps, CIF, and 15fps
kPropEncodingType, kValueEncodingTypeCBR
ulMaxTimeBetweenKeyframes = 10
kPropEncodingComplexity =
kValueEncodingComplexityMedium
Encoding with live TV through capture card as input source
seems fine if you view the encoded .rm file later or watch
the live encoding when the encoder is connected to server
with broadband connection
But the output packet stream from encoder has such a big
variability that it causes the problem of packet dropping
for narrowband connection between encoder and server. here
is the typical capture of 20 seconds encoder's packet (UDP)
data output speed train (PER SECOND)
Time(s) Pkts Bytes
1 14 4041
2 12 3521
3 25 8293
4 37 12167
5 8 3153
6 17 7258
7 21 9053
8 26 11415
9 30 12882
10 4 632
11 17 5325
12 17 3284
13 26 8337
14 33 7247
15 13 2799
16 68 30535
17 16 5682
18 19 6236
19 33 11895
20 4 724
You can see that encoder's output datastream has variability
(second to second) from 200kbps to 6kbps, which is a huge
swing and causes big trouble of packet drops when the
encoder is connected to server through narrowband with
60kbps bandwidth such as cdma type of wireless connection.
This kind of output pattern looks more like variable bitrate
encoding than constant bitrate encoding setting.
So my question is: does our observation make any sense at
all from codec point of view? if it does NOT, did I make
some mistakes somewhere in encoder setting or could you
recommend something to try because I am running out ideas
now? thanks for your help very much,
Frank,
p.s., I know the capturing routine works because when I
switch to a different data stream feeder with known average
and variance bitstream to it, the captured data matches the
bitstream quite closely.
---------------------------------
Looking for last minute shopping deals? Find them fast with
Yahoo! Search.
_______________________________________________
Helix-producer-dev mailing list
Helix-producer-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listi
nfo/helix-producer-dev
|
