Re: Question about playback alacrity...

Neil Smith [MVP Digital Media] <neil@xxxxxxxxxx> loquated like no one had
ever loquated before with:

On Sat, 1 Jul 2006 00:49:18 -0400, "WTH" <spamsucks@xxxxxxxxx> wrote:


Neil Smith [MVP Digital Media] <neil@xxxxxxxxxx> loquated like no
one had ever loquated before with:

On Fri, 30 Jun 2006 12:45:39 -0400, "WTH" <wth@xxxxxxxxxx> wrote:

I am supplying video from a live video feed from my encoder
application to my WMP client which I've written to (temporarily)
use CAxWindow in order to host the WMP control.

Playback is great; however, I'm experiencing the standard long
period of delay while connecting. Now, I can set the buffering
time to 1 millisecond

The connection delay is usually cause by setup and teardown of the
Directshow filters needed for playback, assuming you otherwise have
no mismatch between the player download bitrate, and the clip
bitrate (else see buffering, below)

In my experience (using codecs on my own and a streaming system
using MPEG4 that I wrote) the largest delay comes from feeding
enough frames to the compressor to start sending a viable stream.
Direct Show filter creation in code I've written previously for
reading incoming data from a framegrabber driver (which proffered a
filter) was lightening fast. I'm just wondering,


Yes, but that's not the case for the player, is it

It isn't the case for the player, but I did not specify that I'm only
looking at the player. I'm look at all aspects of the system from source to
playback.

- WMP has to
examine the data, and try a range of filter graphs to setup the
correct playback for (choose random video codec here).

Why on earth would it do that? LOL. I would hazard that while the media
player may enumerate the filters and ask them for their capabilities, it
does not try to configure random video codecs to find an applicable graph.
That wouldn't make any sense since the player knows the stream information,
and codecs expose their capabilities just for this purpose.

Presumably your code *knew* what the video input type was (MPEG4) and
you implicitly built a graph passing parameters just to handle that
video type ?

Actually the header to each frame of MPEG video had information such as the
type of video, the dimensions, and feedback information. You can use JPEG,
MPEG2, and MPEG4 with my current system. So, my code simply enumerates the
registered codecs and takes the first one that has the caps for the
appropriate media type. Takes a few hundred milliseconds.

what is the fastest scenario to get lag-free live video. I'm not too
concerned about startup time, I'm concerned that the preview frame
window from my encoder application shows video that is 5 seconds
ahead of the video playing in my client video windows.


The windows media platform is not a real time solution (and is not
intended to be), there will be the elements of lag discussed in those
links to create an optimal, glitch free playback wherever possible.

Understood, and for its intended purpose I find it a marvelous and
INCREDIBLY easy to use platform; however, I can probably live with the
streaming delay (and maybe I can modify that with 'fast start' approaches),
but I've got to find a way to get the player to skip ahead to the very
latest video that has come in (sort of fast forward through the buffer...)
I'm going to look at writing my own player with a stream reader from the
(iirc) WMF SDK 9.5. Hopefully I'll be able to push the reader through any
buffered video after connection occurs.

You need to investigate a video conferencing platform (such as
livemeeting) if this is more important to you than playback quality.

If the above doesn't pan out, I'll look into things like that and NetMeeting
(which one is the latest? Or is one the precursor to the other?)

Video conferencing codecs are designed with lowest possible latency
but less EC because the codec has a shorter pipe so there's less
possiblilty to correct bad or missing frames - they're dropped instead

Yeah, I'm surprised this isn't bumped into the media services sdks and
player because it's trivial to do from a coding point of view. Microsoft is
probably stratifying its product niches and wants to keep them separate from
some reason.

The difficulty you *seem* to be having is actually Latency, not
Bandwidth related.

Again, that's not why I mentioned the bandwidth. A higher bandwidth
profile with the same video dimensions usually allows the compressor
to begin transmission sooner because it needs fewer frames to encode
to produce an accurate representation on the client.


OK that's a fair point I suppose, if the keyframe rate is high enough
*because* the initial profile settings for "high bandwidth" specify
that keyframe rate (if it's not I can't see how that would have more
than a marginal effect)

I know, I'm grasping at straws, but I've got to ;).

Thanks again for the info,

WTH:)


.

Relevant Pages

  • Re: play video/audio in C# application
    ... Real is a problem with most video players, as far as I know, as there ... the Real player, but I am not sure that it can be embedded in your app. ... you want to play. ... install codecs for video types over the user's preferences. ...
    (microsoft.public.dotnet.languages.csharp)
  • Having a problem when playing MPEG-based files
    ... When I attempt to play ... any MPEG-based video file, regardless of the playing software used, I ... stop the playback the current active player window will freeze. ... sound no video, stop playback, then Media Player Classic will lock up. ...
    (microsoft.public.windowsxp.basics)
  • Re: Playing video with IrfanView
    ... Use external player ... window (only accessible while a video file is open), ... Irfanview uses plugins to play videos. ... You MUST have current codecs to match what was recorded to play back the video. ...
    (rec.photo.digital)
  • Re: Sound choppy when playing DVD in Windows Media Centre PC
    ... Sound is choppy / video is fine. ... Plays fine in one player and not another? ... When you install a codec package, it makes these available to all players. ... When you install a player with codecs bundled in, they may or may not share ...
    (microsoft.public.windowsxp.accessibility)
  • Re: WMP10 Jerky playback and Audio falls behind
    ... MPEG codecs don't necessarily swap out ... Windows Media Development Team ... When I Play MPG video files they start up perfect but after about a minute ... InterVideo Codec results in perfect playback. ...
    (microsoft.public.windowsmedia.player)
Quantcast