How do they design this live streaming architecture

Discussion in 'HTML & Website Design' started by ketting00, Oct 12, 2015.

  1. #1
    I have no idea how the system works and not sure is it the right place to ask, the section has the 'design' in it anyway, but I know how to make it happen and I'll need a clear direction before moving forwards, so that it's safe of rebuilding the whole thing again, which is not very wise if participation grows large.

    What I'm doing is like YouTube live streaming channels.

    Supposed I want to stream a security camera 24 hours a day seven days week and want everyone can view those data feed on a website like:

    www.mystreamsite.com/this_cam.php?id=xxx
    Code (markup):
    or embedded it to other sites, which point do they match the requesting audience with the streaming camera, at server or at the end user's device.

    If at the user's device, is JavaScript capable of sorting out very large amount of data that sent to the device(supposed there are 150 cameras running at the same time).

    Or did they do it at server and pushed data pipe to it a requesting URL.

    Which one is the most efficient way.

    Thanks in advance,

    PS, data may transfer via TCP, UDP or WebSocket methods.
     
    ketting00, Oct 12, 2015 IP
  2. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #2
    I would say matching it at server-side will be the only wise way to do it - if not, at minimum you'd have to send an array or xml-file or something containing ALL the possible content-id's, and then send a second query when you've parsed which one you'll want to watch - besides, if you're streaming semi-full HD and want to push 150 different feeds at the same time, you'll be breaking the line quite quickly - that's about (minimum) 560 MB/s (half a GB EVERY SECOND, not bits, BYTES) - even if you could push it, most home-users would never be able to watch it apart from choppy "still-images" because the lag and total bandwidth usage would be ridiculous.
    With an ID, sort it on server, and send only the requested feed to the user. Of course, if the same IP / user should request multiple feeds, you might be able to mitigate some sort of container-feed which could be parsed by the user, but depending on what server / bandwidth-allocation you have, I say go just for single streams pr. request. (Granted, if you have a million viewers at the same time, that will take QUITE a bit of power to push).
     
    PoPSiCLe, Oct 13, 2015 IP
    ketting00 likes this.
  3. ketting00

    ketting00 Well-Known Member

    Messages:
    782
    Likes Received:
    28
    Best Answers:
    3
    Trophy Points:
    128
    #3
    Thank you @PoPSiCLe,

    You have been very helpful. I can't make decision about this for over a month. Google doesn't help at all.

    The other guy suggests to match it at the user's device to help reduced server workload. I'm very suspicious about this.

    It's time to stay focus on single research and put the matter to the round table of not so geeky entrepreneur wannabe. :)
     
    ketting00, Oct 13, 2015 IP
  4. PoPSiCLe

    PoPSiCLe Illustrious Member

    Messages:
    4,623
    Likes Received:
    725
    Best Answers:
    152
    Trophy Points:
    470
    #4
    Uhm... how would matching it at the user reduce server workload - the server will need to push out SOMETHING either way, and pushing out only exactly what the user is asking for seems, to me, as the only smart thing to do.
     
    PoPSiCLe, Oct 14, 2015 IP
  5. ketting00

    ketting00 Well-Known Member

    Messages:
    782
    Likes Received:
    28
    Best Answers:
    3
    Trophy Points:
    128
    #5
    Thanks again. That makes sense.
     
    ketting00, Oct 14, 2015 IP