VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 8 of 8
Thread
  1. hello all
    new here and i have a question.how much speed is really needed for streaming live tv in 720p? now i am aware of the speeds stated by sites like netflix etc.what i am looking for is some input from end users who actually have the experience streaming and what their experience has taught them.
    thanks in advance
    Quote Quote  
  2. Not all providers use the same bitrates so there is no single answer to your question. I would assume the providers' numbers are a reasonable estimate of what you need to get their expected picture quality without constant buffering. Beware that your ISP may not provide the full speed they claim.
    Quote Quote  
  3. You can use this as a reference for encoding.
    https://support.google.com/youtube/answer/1722171?hl=en

    Checking my network activity on my router, I only use 3Mbps for a 720p@60 stream from Youtube. You might need to do some research to figure it out what you need (software) and run tests to see how it goes, VLC and OBS Studio does streaming.
    Quote Quote  
  4. If you are wanting to watch 720p video from a site like Netflix, Amazon, Netflix, or YouTube and do so on a family room TV, it is my experience that the absolute minimum is 4 mbps. I do quite a bit of consulting on this subject with the local neighborhood, and also have my own experience.

    For the best experience you do not want to add any additional bottlenecks when you are streaming at this bare minimum rate, so even though your wireless may be spec'd at 54 mbps or higher, I have found that you always get smoother results using a wired connection, if your TV or playback device (e.g., Fire Stick) supports it.

    That 4 mbps rate is the absolute minimum and, depending on how much variation you get, you won't have any headroom at all for slowdowns, like you get with cable and other shared Internet delivery architectures. Thus, if you have a choice in how much you are willing to pay for, I would recommend that you try to get a service that can deliver at least twice that.

    In the early days of streaming, I started with 4 mbps, so I know it can work with 720p, which what most sites delivered back then. Then, in 2012, I switched to AT&T Uverse which provided 12 mbps. This is what I've had until recently, when Uverse decided to give me double that, without any extra fees (how often does that happen?). I noticed absolutely no difference in video streaming when I got this extra speed, even at 1080p, so I can say with confidence that you don't need anything more than 12 mbps.
    Last edited by johnmeyer; 11th Jul 2019 at 12:10. Reason: typo
    Quote Quote  
  5. Back when we had only 15 Mb/s (and our ISP consistently delivered that speed) we had no trouble with two simultaneous1080p24 Netflix streams.
    Quote Quote  
  6. A wired connection is always better because it's full-duplex, it can send and receive data at the same time while wireless connection it's half-duplex, it need to stop receiving data to send a confirmation and vice versa. The performance of a wireless connection depends on to many variables.
    Quote Quote  
  7. Thanks for your responses guys. They were very helpful.
    Quote Quote  
  8. If you have 2 computers , at least one of them is able to be connected to access point trough wire then with help of Zap (made by Ruckus) you can check your WiFi performance and you may try to optimize it (for example by changing AP place - sometimes 20 - 30cm makes huge difference)

    You can use script provided bellow - some files will be logged but you can just observe screen searching for best speed especially on long time interval (it will describe real link quality).

    Look at this article https://www.revolutionwifi.net/revolutionwifi/2012/01/measuring-wi-fi-performance-using.html
    Sadly to say this tool (Ruckus Zap) was lost thus i will upload it now, also documentation provided as separate file (it may be present inside install file).

    Promised script:

    Code:
    @set SAVESTAMP=%DATE:/=-%_%TIME::=-%
    @set SAVESTAMP=%SAVESTAMP:.=-%
    @set FILENAME=%SAVESTAMP: =%.zap
    @set LOGNAME=%SAVESTAMP: =%.zaplog
    @set DBGNAME=%SAVESTAMP: =%.zapdbg
    @set FOLDER=%CD%\
    
    @rem -LAUX00_%LOGNAME% 
    @echo ----
    
    @zap -s192.168.3.6 -d192.168.3.16 -X7200 -r10000 -l1472 -p50000 -q0x30 -n1000000 -FAUX00_%FILENAME% -DAUX00_%DBGNAME%,0,0
    @pause
    and Zap command help:
    Code:
    zap [options] -s<IP_D>[,<IP_C>] [options]
       Zap has the following options: NOTE: options are CaSe sensitive!
         -s<IP_D>[,<IP_C>]  - Specify the IP address of the source station. Traffic will be sent FROM this station.
                              <IP_D> The IP address the station will use for data communication.
                              <IP_C> The ( optional ) IP address the controller will use to communicate with the station.
                              This option is required.
         -d<IP_D>[,<IP_C>]  - Specify the IP address of the destination station. Traffic will be sent TO this station.
                              <IP_D> The IP address the station will use for data communication.
                              <IP_C> The ( optional ) IP address the controller will use to communicate with the station.
                              This value defaults to the local station. Multiple may be specified for multicast.
         -i                 - Invert Connection Opening - Opens initial connection from destination to source.
                              Used to alieviate testing issues with NAT devices. Defaults off.
         -l<length>         - Specifies a payload length of <length>. The largest payload in a single packet is:
                              UDP: 1472 bytes.
         -f<frames>         - Specifies how many full-length frames you want to use for framelength. Takes
                              fragmentation into account. Completely overrides -l
         -M<pmtudisc hint>  - Specifies Path MTU Discovery (PMTUDISC) strategy. Options are:
                              do (always DF); want (do and fragment locally); dont (never DF).
         -a<sample size>    - <sample size> is the number of payloads sampled for performance measurement.
                              This is the near-equivalent of zing's -E option. Defaults to 50.
                              This option is mutually exclusive from -p option.
         -p<period>         - Each sample lasts the specified ( in microseconds ) period.
                              Successfully crosses sample boundaries.
                              This option is mutually exclusive from -a option.
         -q#                - Send frames with the specified 8 bit DSCP ( TOS bits ).
                              NOTE: The frames coming back will NOT have these bits set, necessarily.
                              On WinXP, the following registry key must be REG_DWORD,
                              and ZERO to enable TOS bit setting: Local Machine\System\CurrentControlSet\
                              Services\Tcpip\Parameters\DisableUserTOSSetting
                              Common fields for Lowest  #: 0x08, 0x20: Background
                              Common fields for Low     #: 0x00, 0x18: Best Effort
                              Common fields for High    #: 0x28, 0xa0: Video
                              Common fields for Highest #: 0x30, 0xe0: Voice
                              Common fields for Unknown #: 0x88:       Video 2?
         -n<number samples> - Specifies the number of samples in the test. Defaults to 1000.
         -o<outstanding>    - Specifies the number of samples that may be outstanding ( in the air )
                              at any given time. Defaults to 1.
         -m<IP_M>           - Specify the destination multicast address to use for data communication.
                              Defaults to none. Setting this enables multicast transmission via UDP.
         -r<mbps>           - Controls the rate in mbits/s for transmitting data. Decimal values accepted
                              Defaults to a very high data rate.
         -R                 - Reverses the direction ( swaps source and destination ). Only works with unicast
         -F<filename>       - Dump results ( appended ) to a comma seperated value file <filename>
         -L<logfilename>    - Dump the log file and stop zap tool when some packet drop
         -D<file><,start,stop>
                            - Dump result to file for debugging
                              Instruction: -Dfilename,start_point,stop_point.
                              In order to dump all log file, using -Dfilname,0,0
         -w<value>          - Get the average value of throughput
         -T<tag>            - Tag used to describe this test case within the dumped file, required with -F
         -S<sub>            - Sub tag used to describe this test case within the dumped file.
         -N<note>           - Note used to describe this test case within the dumped file.
         -X<sec>            - Test for specified number of seconds.
         --server           - Runs zap in server mode. No other arguments required.
    Image Attached Files
    Quote Quote  



Similar Threads