Formula una domandaFormula una domanda
 

DomandaReal-Time Streaming

  • giovedì 11 giugno 2009 21.34pascalh Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     
    When i use Expression Encoder 2 in Live Encoding Mode and set output to broadcast stream and start 'Lunch Preview' i have a delay arround 6 seconds. How can I bring this delay down to <1 second?
    I also tried to stream to a WMS to test delays, but this unfortunately did not work.

    Thanks in advance!

Tutte le risposte

  • venerdì 12 giugno 2009 0.06SlickWillie Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     

    Latency of 6 seconds is pretty good.  There are buffering and fast start tweaks for the encoder and server.  Once the h.264 codec is implemented in v.3 you should see significantly less latency.  I've been looking for real-time web broadcasting for years and currently there are none that I've found.

  • venerdì 12 giugno 2009 15.02Dino V Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     

    Will Silverlight 3 and expression encoder be able to stream in "REAL TIME" as Flash claims they can currently?  Although I believe it is not "REAL TIME" and would be considered "NEAR REAL TIME" (NRT) due to some latency.  And what is the exact meaning of the RTSP (Real Time Streaming Protocal) protocal due to latency?  -dino

  • venerdì 12 giugno 2009 15.11pascalh Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     
    thanks for ur reply. good is relative. depends on the scenario. not good enough for me actually. :)
    yes, some delay is caused due to buffering. but it seems as the buffers are much too large. id like to shrink the buffers. but i have not found an option in the expression encoder. also id would be nice to have a prefered buffer size for the client in the protocol so that the client buffer can be shrunken too if near real time is needed.
    i think there are better (real time?) broadcasting solutions. but they are far more expensive.
    do have any more information about this version v.3 of the h.264 codec?
    thanks again!
  • venerdì 12 giugno 2009 16.33Dino V Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     
    Even though expensive, could you provide the better (real time?) broadcasting solutions?  thanks
  • venerdì 12 giugno 2009 19.59pascalh Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     
    to Dino V: It is some time ago since i looked into this. i searched for non-expensive streaming solutions. i found references to multiple products from discussions and so on. the problem was all of those companies were aquired by avid. it seems they bought all the competitors. therefore i suggest you have a look at www.avid.com .
    also i recently came about microsoft iptv. seems they renamed it to microsoft mediaroom http://www.microsoft.com/mediaroom/ . but i was not able to get much information about it and it seems this is only available for larger service providers.
    in both cases i have no clue about latency/realtime. but both seem to be capable to provide better solutions than the 6 seconds.
    as a side note, currently i'm using windows media encoder along with windows media services. but the latency is in the same order (6-10 seconds).
    good luck!
  • domenica 16 agosto 2009 4.48chuckdawit Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     
    what about Skype? There's no delay when I use Skype with video, why is that?
    chuckdawit
  • domenica 16 agosto 2009 5.17WilliamStacey Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     
    Just curious what the <1 sec requirement is for. Unless your doing a realtime news style interview, would it matter?
  • martedì 18 agosto 2009 21.46pushbomb internet.tv platform Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     
    There is really no such thing as 'real-time' as all communication networks have latency.

    So your correct in 'near-real time' assessment. Same for TV broadcasts (and not just for FCC bleeping).

    Now (as we saw with the MJ Tribute as well as Wimbleton) Microsoft is not pLAYING AROUND. The smooth streaming live technology is really really cool. The problem is you need almost roll your own infrastructure to use it (SEE NBC Olympic architecture).

    As long as you have a guarantee of consumers receiving a seamless stream, be in 10 seconds or five minutes delayed, it is good. Exceptions are of course timeliness critical domains such nas financial trading, etc.

    Same goes for RTSP. No magic there at all. In the end we are all slaves to physics.

    Damon
    Damon Wilder Carr http://blog.domaindotnet.com
  • sabato 3 ottobre 2009 1.20Martin Fallenstedt Medaglie utenteMedaglie utenteMedaglie utenteMedaglie utenteMedaglie utente
     

    What is acceptable depends on the application for real-time broadcast. I work with surgical robots where we have to provide ideally < 1 second HD video transmission for proctoring. If somebody watches Sunday night football and there is 6 second delay in the broadcast I agree that this isn't a bid deal. But if a surgeon would like to caution the other to watch out for that artery under that tissue before you make an incision into it, that 6 second delay is unacceptable.

    Now, the 6 second delay I also confirm from my evaluation on a screaming fast computer that is dished out with all the latest goodies and no network devices between the two endpoints. IMHO 6 seconds is unacceptable under these condition to call it real-time. When I perform the test where I stream the broadcast to another dished out Streaming Server that provides unicast, another 5-7 seconds are added on top of it. ???? What on earth is going on in there?

    Guys in MS: You are doing some wonderful stuff, but please optimize this for performance. With another home brewed setup using VLC we are down to 1.5 seconds streaming h.264/ACC across the town.

    Martin


    MartinF