Reducing Mpeg4 end-to-end latency/delay?

[BlackBox]

Hello group,

This is my first post, but i have been a member for a while now. I have been using Mpeg 1/2 Vbricks for a number of years, and have recently invested in a Dual Channel Mpeg4 encoder....

I am looking for suggestions to minimize the observed latency when streaming live from the Mpeg4 brick, out to a reflector, then on to the internet for the public to access. I know most of the latency comes from the CDN portion, but is there anything that can de done on the encoder side? I dont imagine that there is much i can do; but for my case, every extra milisecond counts.

Also, I have noticed that the "delay" dosnt stay consistent. The live stream seems to get progressively more "behind" as time goes on. Can this be addressed by changing the frame/bit rates (CFR-VBR, VFR-CBR, etc)? Or is this something i need to address with my CDN's buffers, etc?

Would there be any benifit (less delay) for my reflector to log into the brick and "pull" the stream, versus "pumping" the stream out to the reflector? I assume that it wouldnt make that much of a difference, given that the same process would need to take place either way. Am I missing something?

thanks in advance,
  Justin

5 6200 mpeg2 bricks
1 4300 mpeg4 brick
1 VB-400 mpeg1 Brick
1 V-4000 STB (pace)

[rmavro]

Hello group,

This is my first post, but i have been a member for a while now. I have been using Mpeg 1/2 Vbricks for a number of years, and have recently invested in a Dual Channel Mpeg4 encoder....

I am looking for suggestions to minimize the observed latency when streaming live from the Mpeg4 brick, out to a reflector, then on to the internet for the public to access. I know most of the latency comes from the CDN portion, but is there anything that can de done on the encoder side? I dont imagine that there is much i can do; but for my case, every extra milisecond counts.

Also, I have noticed that the "delay" dosnt stay consistent. The live stream seems to get progressively more "behind" as time goes on. Can this be addressed by changing the frame/bit rates (CFR-VBR, VFR-CBR, etc)? Or is this something i need to address with my CDN's buffers, etc?

Would there be any benifit (less delay) for my reflector to log into the brick and "pull" the stream, versus "pumping" the stream out to the reflector? I assume that it wouldnt make that much of a difference, given that the same process would need to take place either way. Am I missing something?

thanks in advance,
  Justin

5 6200 mpeg2 bricks
1 4300 mpeg4 brick
1 VB-400 mpeg1 Brick
1 V-4000 STB (pace)

Justin,

The first step is to configure the source VBrick MPEG-4 for "Low Delay" -- this is a setup option that ensure you don't have B-Frames.  The end-to-end delay VBrick-to-VBrick is about 180 ms in this case.  If you are trying to view the video on a desktop, then the only way to get low delay is to use the VBrick player...QuickTime Player is high delay.

Not sure exactly what you mean by reflector in case of MPEG-4; I guess you mean a Darwin server where you have placed your SDP?  If it is your own Darwin, I believe you can tweek the buffer to minimize delay here too.  The rest is propagation delay.

[BlackBox]

Rich,

The "reflector" i am referring to is actually my CDN, Powerstream. My SDP files are hosted on their servers. Paul had mentioned that there wasn't much he could do on his end, but i cant help but think there is at least some trimming of buffers possible - I would trade "Instant On" buffering for overall less latency if it were possible. I would rather see it take longer for a users buffer to initially fill up, if it meant their experience was as close to "realtime" as possible.

Maybe i need to be on a dedicated server at their end? Is there any logic in putting another Mpeg4 Brick at their location? How does the brick-to-brick latency compare to brick-to-VBStreamPlayer latency?

You know my goals, and how every bit of latency can negatively affect my situation.

thanks again,
  Justin

[rmavro]

Rich,

The "reflector" i am referring to is actually my CDN, Powerstream. My SDP files are hosted on their servers. Paul had mentioned that there wasn't much he could do on his end, but i cant help but think there is at least some trimming of buffers possible - I would trade "Instant On" buffering for overall less latency if it were possible. I would rather see it take longer for a users buffer to initially fill up, if it meant their experience was as close to "realtime" as possible.

Maybe i need to be on a dedicated server at their end? Is there any logic in putting another Mpeg4 Brick at their location? How does the brick-to-brick latency compare to brick-to-VBStreamPlayer latency?

You know my goals, and how every bit of latency can negatively affect my situation.

thanks again,
  Justin

Justin,

PowerStream, or any commercial service provider, has to host multiple accounts on each server.  The server buffer settings tend to be global.  They typically have to be set to deal with input packet jitter, etc.  So, if you want really low delay via a reflector, you'll need to host your own.  But if you do this, then you might as well use the VBrick's own RTSP streaming server and you will get the lowest possible delay.  Just NAT or otherwise expose your VBrick to your intended audience.  I know...you likely do not have the bandwidth to support the desired audience size.

[BlackBox]

Rich,

I have talked with my CDN, and they are willing and excited to do some R&D with me. We are going to test some results on using a dedicated server for my content. This will allow me to have settings that only affect my content streams. Hopefully, tweaking the dedicated Darwin Server Buffer will help reduce the latency a bit. I will follow up on this next week after we have had a chance to do some trial and error R&D.

thanks for a great forum,
  Justin