Steve,
We tried rolling the output using both Rollup by Time (2-10
minutes of each rollup) and by Size (1 to 10 MBytes of each
rollup) based on your suggestion in the email. It basically
works, but we found two problems:
1. Each rollup's time is almost always bigger than the
pre-set rollup time, therefore, the sum of all rollups is
bigger than the supposed total encoded duration without
rollup. The more roll-ups, the longer the summed total will
be.
2. Between the transition or cut off of two neighbor
roll-ups, there is audio cut-off before the end of first
rollup, and then there is video pause in the next rollup.
The transitional a/v messed-up could be just 3 seconds, or
it could be as long as 10 seconds.
If we don't do any rollup, the encoding is perfectly fine
with A/V well synched. So we figure it could either be our
problem of how to apply the roll up (based on the mannual,
it is quite straightforward), or the rollup internal
implementation of Helix producer does have this bad side
effect. Your insight will be very much appreciated.
Frank,
Steve McMillen <stevemc real.com> wrote:
There is an option to roll the output by time or size; you
will not loose frames but there are some issues with pasting
the results in RM Editor due to key frame alignment between
the audio and video streams. You can combine these using
SMIL effectively. Here is what is in the release notes:
If you need to combine Audio/Video rolled files (files
created as a result of the file rolling functionality of the
RealProducer) use SMIL as shown above. Combining rolled
files in RMEditor may result in an error, or cause the audio
to loose sync with the video.
The example SMIL is in the release notes.
Steve
On 7/19/2007 8:22 PM, on focus wrote: Hi, Steve, thanks for
your detail response. I like to follow up with the archive
without gap issue. Basically, I think what we need is to
continue encoding without missing any real even (for
security reason), but at the same time, the encoder will
archive what has been lively encoded into a file
periodically, say, every 10 minutes. The problem is once you
issue command to encoder engine to archive, the whole chain
just stops for 1 or 2 seconds, which is not acceptable. So
here are the questions:
1. Are there any upper and lower bound for the time to
restart Helix encoder? 0.5 second, 1 second, or 2 second?
2. If there is upper bound, then we can work around the
issue by continuing capturing the data and buf them up for
say 2 seconds while we stop Helix encoding and restart
encoding to archive what has been encoded. Once encoder
restarted, it continue grab the data from the buffer to
encode.
thanks,
Frank,
Steve McMillen <stevemcreal.com> wrote:
Please see inline.
On 7/5/2007 7:13 PM, on focus wrote:
> Hi, Steve and other Helix folks,
>
> several questions to ask about using Helix producer
for live encoding,
>
> 1. Our application requires to archive the Helix
producer encoded rm
> per hour, but we also want to continue encoding
without gap in
> encoding. So is there any way to instruct Helix
producer to archive
> what is encoding into a file while start a new
encoding file without
> any gap in encoding?
There is no support in the application or SDK today for
pause. I think
a customization to the input plug-in would suffice but
someone more
technical would have to comment how to go about doing this.
As I
understand it, pausing the input would cause all downstream
elements to
just wait for more frames and thus work just fine. Because
of the way
that AV sycnh is done (as explained below in #2) there is
no need to
feed AV samples in real time.
>
> 2. For audio/video sync while encoding, the sample
codes from helix
> producer shows no particularly synchronization of
timestamp for
> audio and video data. Shall I use audio time to stamp
video or vice
> verse or shall I use wall-clock (GetTimeOfDay like
call) to stamp both
> audio and video timestamp?
Using the std capture plug-in, timestamps are determined
from audio
samples. Producer determines time via the audio sample
knowing the
sample rate. Within the RM file, the same is true (though
the sample
rate may have been converted depending on the codec). I
don't think you
timestamp the video explicitly; its implicit in the audio
stream.
Maybe you are talking about writing an input plug-in and
how to provide
timestamps for that. That I'm not sure about.
>
> 3. For multiple channel live encoding (via multiple
instance of
> helixproduer or multiple job), if our encoding machine
is not powerful
> enough to do all live full framerate encoding (say
30fps), how to make
> sure all channel degrade in about the same degree,
say, to 20fps in
> average instead of some channels degraded to 15fps,
while other
> channels degraded to 25 fps?
The CPU Scalability code signals the input plug-in to drop
frames based
on a heuristic that combines various factors such as CPU
load and
encoding latency. Because frame dropping is done in the
input, it will
be the same for all outputs in a single multiple output
encode (i.e. a
job with 1 input and 1 or more outputs).
The frame rate is determined by what value the heuristic is
at. Only in
very severe cases do we even start to drop frames. Before
that we apply
scaling in the codec that affects video quality. If it goes
low enough,
the first level drops 1/2 frames, then 2/3, then 3/4 and so
on (always
drop evenly spaced frames to maintain smooth video)
Note: The codecs themselves also scale frame rate based on
bit
constraints. If the bit rate is too low for the frame
size/quality
requested, the codec will encode less frames per second.
There is nothing in the system today that allows the
determination of
what frame rate to apply across different encoding
instances. It is
possible it could be made to work this way by modifying the
source.
You'd probably need to modify the code that manages the cpu
scalability
and get it to listen to some sort of outside control.
Note: Make sure all codecs in a given encode are set to the
same frame
rate. Also, as noted, if you set the bit rate too low, some
codecs will
be unable to attain the requested frame rate and thus scale
back even if
there is plenty of CPU.
> thanks a lot
>
> Frank,
>
>
------------------------------------------------------------
------------
> Boardwalk for $500? In 2007? Ha!
> Play Monopoly Here and Now
>
> (it's updated for today's economy) at Yahoo! Games.
---------------------------------
Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge
to see what's on, when.
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life,
your story.
Play Sims Stories at Yahoo! Games.
_______________________________________________
Helix-producer-dev mailing list
Helix-producer-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listi
nfo/helix-producer-dev
|
