Post by eHhlb2 » Wed, 14 Jun 2006 12:24:01

A problem we have been seeing with WM9 (ASF) encoder start/stop reliability.

Our scenario involves multiple encoders - running around 50-70% sustained

We run the encoders in an A/B mode, switching between them every (default)
30 mins to create chunked recordings, with an overlap of ~5 secs at the
transition point. This to provides manageable file sizes, and distributes
risk in the event of other component failure.

These systems run 24 x7 x365 - and seem to work quite well - except for....

(we originally used WME components - but have since moved to our own graphs
& filters in an attempt to eliminate the symptom I describe below.)

Continuous Audio and Video sources - into standard WM codecs (usually WM9
video and audio)

A script stream is injected to the multiplex every 200ms - containing HTML
tags that carry our 'metadata' and closed caption strings.

With this scenario, we have successful operation - except that
'occasionally' (perhaps between one and five times a day), an encoder will
not stop, or will not complete the start-up cycle - possibly due to an
earlier failed 'stop' cycle??. These conditions are not faulted in NET -
hence we can't trap them as exceptions - they occur deep in the encoder

The only way we can detect one of these failed encoders is to look at the
output archive file size, and respond when it doesn't grow as expected !
Fortunately, our A/B model supports this, and the outgoing encoder remains in
operation until the new incoming encoder is confirmed as operating properly.

In the event that we do indeed detect a 'dead encoder', the background task
destroys that process, and a new encoder is launched in its place - ready for
a new attempt at file changeover

HOWEVER... If we disable the script channel, we do not seem to have this

It's not enough to slow down or stop the script data injection; we must
disable the script channel in the encoding graph - to see the problem
disappear reliably.

With our attempts at fault isolation - the questionable component comes down
to ASF_WRITER, as this is the only common element between our original
efforts using WM components, and our home-grown discrete DX9 / WMF SDK
encoder graphs that we are now using. Unfortunately we can't easily rewrite
/ replace ASF_WRITER, as it is not in the public domain... so over to your
guys !

I suspect that the problem is somewhere between high-speed script (~200mS),
and continuous script injection... perhaps a buffer is not reinitialized
properly when stopped / restarting, or some other minor oversight like that.

I hope you can share this with some development / test gurus that can help
or discuss the issue. We are keen to remain with WM - as it gives us good
reach to the corporate desktops that use our client applications.



Post by ampfaW5fYX » Thu, 15 Jun 2006 00:11:02

've had what might be a similar problem with an encoding application I wrote
- see my post here for details:

In this app I am trying to capture closed captions also. I never considered
eliminating the closed caption stream for testing - I'm in production now
don't currently have a good dev environment to test removing the script
stream, but I should have one in the next week or two and will test that and
update this post.

"xxeon" wrote:



Post by eHhlb2 » Thu, 22 Jun 2006 02:53:01

J - thanks
It will be intersting to see if you hit the same issues.
I look forward to your results on testing... !
Maybe we can get more feeddback from 'you know who' with two sites and the
same problems... !


"jj_in_atlanta" wrote: