What would be the latency of the streaming raw video?

Discussion in 'PC Industry' started by Flux, Apr 4, 2013.

  1. Flux

    Regular

    Joined:
    Nov 10, 2006
    Messages:
    313
    Likes Received:
    2
    What would be the latency of streaming uncompressed video from a virtual machine on a server to a desktop PC?

    The server has several powerful GPUs(x4)on the same mainboard.

    The server is located in the same city and there are no hops between the server and the client. (think of VERY far range ethernet LAN)

    Example:GPU/VRAM-->CPU/RAM--->FiOS modem/network--->client desktop

    What would be the latency? 1ms? sub-1ms? Above 17ms?

    Is a video stream that is 20Mbytes/sec too wide for a FiOS connection?

    Thank you for replying.
     
  2. Thorburn

    Regular

    Joined:
    Oct 8, 2006
    Messages:
    323
    Likes Received:
    19
    Location:
    UK
    Uncompressed video is far higher than 20MB/sec. Specced up our video capture system for games 5 years ago and worked out we needed something like 400MB/sec for 1920x1200 @ 60Hz.
     
  3. Malo

    Malo Yak Mechanicum
    Legend Veteran Subscriber

    Joined:
    Feb 9, 2002
    Messages:
    6,894
    Likes Received:
    2,957
    Location:
    Pennsylvania
    Well Bluray spec is 40Mbps and that is for compressed h264 video. As Thorburn noted, 1080p uncompressed video would be massive, even at 24Hz.
     
  4. Albuquerque

    Albuquerque Red-headed step child
    Veteran

    Joined:
    Jun 17, 2004
    Messages:
    3,845
    Likes Received:
    329
    Location:
    35.1415,-90.056
    If it's truly uncompressed video, and you're not trying to do any sort of on-the-fly conversion, then the GPU and CPU prowess of the server or desktop typically will not be a determining factor. You need a disk subsystem that can keep up and a network connection to match it.

    Latency is likely not the worst of your concern; bandwidth will be the major limitation. Thorburn is correct; raw, uncompressed video streams are enormous. A single, dedicated OC12 (approximately 1Gbps optical carrier WAN link) would be insufficient to carry that sort of data for 1080p streams.

    Most FIOS links are rated around 100Mbps; that's approximately 12MBytes per second with a bit of room left over. That would be enough for several simultaneous high quality H.264 streams at 1080p, but would only be able to carry a raw, uncompressed 1080p video stream at just shy of two frames per second.
     
  5. itsmydamnation

    Veteran Regular

    Joined:
    Apr 29, 2007
    Messages:
    1,286
    Likes Received:
    385
    Location:
    Australia
    Taking 1080i DVB-T which is in Mpeg 2 and transcoding that to a 1080p H264 stream takes around 8,000-10,000 mhz of "piledirve" mhz(as reported via vsphere client). resulting steam size is around 2mbit.
     
  6. Alexko

    Veteran Subscriber

    Joined:
    Aug 31, 2009
    Messages:
    4,485
    Likes Received:
    897
    Sounds about right.

    32 bits per pixel × 1920 × 1080* pixels × 60 Hz = 3,981,312,000 b/s = 497,664,000 B/s = 486,000 kB/s = 474.61 MB/s.

    *We're talking about video, so probably 1080p.
     
  7. Thorburn

    Regular

    Joined:
    Oct 8, 2006
    Messages:
    323
    Likes Received:
    19
    Location:
    UK
    That was it. Was a complete pain in the arse building a RAID array that could sustain that with mechanical drives!
     
  8. Flux

    Regular

    Joined:
    Nov 10, 2006
    Messages:
    313
    Likes Received:
    2
    1080x1960 @ 24fps(24bbp) interlaced(720px980) is 74MBps.

    http://web.forret.com/tools/video_f...t=1920&fps=24&interlace=on&space=raw&depth=24

    if you compress 74MBps(loss less compression 1:3.5) its 21MBps

    What about DCT(1:6) compression?

    Will that decrease the latency?

    Whatever 20MBps+ is too high.
     
    #8 Flux, Apr 8, 2013
    Last edited by a moderator: Apr 8, 2013
  9. Albuquerque

    Albuquerque Red-headed step child
    Veteran

    Joined:
    Jun 17, 2004
    Messages:
    3,845
    Likes Received:
    329
    Location:
    35.1415,-90.056
    The resolution is actually 1920x1080; the math comes out to 23.73 megabytes per second. Using a guaranteed 3.5:1 compression, that takes it down to ~6.8 megabytes per second (around 54.25 megabit),
    If your machine can use that compression algorithm "in real time"; the latency will be a combination of bandwidth delay product, the time needed for your server to compress those frames, and the time needed for your workstation to decompress them.

    This will be "less latency" than trying to cram 470 megabytes of data into a pipe that can only hold 12.5 megabytes, but there will still be delay.
     
  10. Thorburn

    Regular

    Joined:
    Oct 8, 2006
    Messages:
    323
    Likes Received:
    19
    Location:
    UK
    If you have hardware h264 encoding on the server and decoding on the client then I'd wager that would have lower processing latency (and lower bit-rate) than trying to do some other compression on the CPU.
     
  11. Flux

    Regular

    Joined:
    Nov 10, 2006
    Messages:
    313
    Likes Received:
    2

    AMD FirePro has on hardware h.246 encoding.

    What would be the latency of a 1280x720p @ 24fps h.246 stream with no bframes and no latency setting on.
     
  12. Albuquerque

    Albuquerque Red-headed step child
    Veteran

    Joined:
    Jun 17, 2004
    Messages:
    3,845
    Likes Received:
    329
    Location:
    35.1415,-90.056
    There's no specific way to answer that. Latency would be a function of:
    • The video content you're compressing
    • Which h264 compressor you're using
    • Which h264 compression settings / features / flags you've set
    • Which model of FirePro will be doing the work
    • The capability of the rest of the system to feed 1080P raw data stream into that card for processing (disk bottlenecks, controller bottlenecks, PCI-E bus contention, CPU utilization)
    • The "base latency" of your FIOS connection
    There are other factors; this is only an example list.
     
  13. Simon F

    Simon F Tea maker
    Moderator Veteran

    Joined:
    Feb 8, 2002
    Messages:
    4,560
    Likes Received:
    157
    Location:
    In the Island of Sodor, where the steam trains lie
    To get high compression rates with h.264, the P or B frames might be referencing "future" frames so low latency and high compression may be mutually exclusive.
     
  14. Simon F

    Simon F Tea maker
    Moderator Veteran

    Joined:
    Feb 8, 2002
    Messages:
    4,560
    Likes Received:
    157
    Location:
    In the Island of Sodor, where the steam trains lie
    Many (most?) handheld devices have their own, multi-standard, video encoding hardware.
     
  15. Blazkowicz

    Legend Veteran

    Joined:
    Dec 24, 2004
    Messages:
    5,607
    Likes Received:
    256
    Yes, you have to turn to the h264 mode that is essentially similar to MJPEG.
     
  16. mczak

    Veteran

    Joined:
    Oct 24, 2002
    Messages:
    3,011
    Likes Received:
    110
    I don't see why you'd need to compress the frames individually. Referencing previous frames should in theory not introduce additional latency. Not referencing future frames certainly will reduce compression ratio (at the same quality) but just referencing previous frames should still offer far higher compression ratio at the same quality than compressing all frames individually.
     
  17. Blazkowicz

    Legend Veteran

    Joined:
    Dec 24, 2004
    Messages:
    5,607
    Likes Received:
    256
    I think it's good enough with the very high bandwith/bitrate we can afford here.
     
  18. Flux

    Regular

    Joined:
    Nov 10, 2006
    Messages:
    313
    Likes Received:
    2

    What is the compression ratio of Mjpeg2k?
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...