If your home PC is watching a YouTube Live property-tour loop, it receives video data, so the relevant traffic is download usage. The amount depends on the stream’s actual playback bitrate and how long you watch; there is no single fixed allowance for every live tour.
A useful estimate is about 0.45 decimal GB per hour for each sustained 1 Mbps of playback bitrate. That is a conversion, not a measured rate for this property tour. If you mean that the PC is sending the tour to YouTube rather than watching it, that is upload traffic and you should use the encoder’s configured outgoing bitrate instead.
First establish whether the PC is watching or broadcasting
The phrase “from a home PC” can describe two different jobs. When the PC opens YouTube and plays the property-tour loop, YouTube sends video to the PC: that is download data. When the PC is running an encoder and sending a live tour to YouTube, it sends data out: that is upload usage. The direction matters because the bitrate you need to estimate is different in each case.
For a viewer, begin with the playback selected in the YouTube player, not with the broadcaster’s encoder settings. A creator may send one encoded feed into YouTube, which then makes versions for viewers. The creator’s outgoing bitrate therefore is not automatically the rate received by a particular home PC. YouTube describes its live encoder settings as ingestion guidance and explains that it transcodes live streams for viewer formats in its live encoder guidance.
This distinction also helps when you are troubleshooting a data cap. If a PC is only watching, its outgoing traffic is not the video stream in question. If it is both broadcasting and monitoring its own channel in a browser, it can use upload for the broadcast and download for the preview at the same time. Count the two activities separately rather than treating a single bitrate as the total.
Convert bitrate into data per hour
Bitrate describes how much data is transmitted over time. For a rough hourly estimate, convert megabits to megabytes and multiply by the number of seconds in an hour. There are eight bits in a byte, and an hour has 3,600 seconds: 1 megabit per second multiplied by 3,600 seconds, divided by 8, gives 450 megabytes in an hour.
Using decimal units, that is 0.45 GB per hour for every 1 Mbps sustained. The working formula is:
Estimated data in decimal GB ≈ playback bitrate in Mbps × hours watched × 0.45
For example, a hypothetical bitrate of 2 Mbps watched for three hours gives 2 × 3 × 0.45, or about 2.7 GB. The arithmetic assumes that the bitrate stays roughly steady for the period. It does not account precisely for stream variation, connection overhead, player behaviour or other network activity on the PC.
The formula is useful because you can change either input. If you know an approximate bitrate, extend the estimate for your planned viewing hours. If you know your data allowance and viewing hours, divide the available gigabytes by hours and by 0.45 to work backwards to an approximate sustained bitrate. Treat the result as a planning figure, not a bill prediction to the last byte.
Hypothetical bitrate examples
The table applies the conversion directly. Every bitrate in it is hypothetical; none is a claim about the measured playback rate of a particular property-tour loop.
| Hypothetical sustained playback bitrate | Calculation for one hour | Approximate data per hour |
|---|---|---|
| 1 Mbps | 1 × 0.45 | 0.45 GB |
| 2.5 Mbps | 2.5 × 0.45 | 1.125 GB |
| 5 Mbps | 5 × 0.45 | 2.25 GB |
| 8 Mbps | 8 × 0.45 | 3.6 GB |
The 2.5 Mbps and 5 Mbps rows are particularly useful for comparing the calculation with YouTube’s published recommended sustained connection speeds for some playback formats. They remain calculations using those speed figures as inputs, not measured YouTube data totals. A connection-speed recommendation says what connection YouTube advises for playback; it does not promise that the stream will transfer continuously at exactly that rate.
A property tour may contain changing scenes, camera movement, text overlays or long static shots. Those characteristics can affect how much data an encoded stream uses, but without the actual playback bitrate you should not assign a specific number to this tour. If the channel is showing a repeating video file, the loop itself does not make a viewer’s data use reset or stop: as long as the player continues receiving video, data continues to arrive.
Include the hours you will actually watch
At a similar sustained bitrate, duration scales the estimate. Two hours at a given rate use about twice the video data of one hour, and a full day of uninterrupted viewing scales the same way. This is simply the bitrate-over-time calculation, not a separate YouTube allowance for live streams.
| Viewing period | At hypothetical 2.5 Mbps | At hypothetical 5 Mbps |
|---|---|---|
| 1 hour | 1.125 GB | 2.25 GB |
| 4 hours | 4.5 GB | 9 GB |
| 8 hours | 9 GB | 18 GB |
These figures make a difference when a property business leaves a tour open on a lobby screen or a staff member watches a feed throughout a shift. A short check on a phone or computer has a different total from a display that plays through a whole business day. If a screen is left running, include the hours it will genuinely remain connected, not only the time someone actively looks at it.
Playback rate may also change during that period. YouTube says quality can adapt to factors including internet speed, player or screen size, the original video quality and browser; a computer viewer can also select quality manually. See YouTube’s guidance on changing video quality on a computer. A chosen resolution is informative, but it still does not tell you the exact bytes that will arrive in every session.
If the tour needs to stay visible for customers, consider what the display is doing outside viewing hours. Closing the player, turning the display off, or selecting a lower quality when detail is not needed can reduce data use, though the exact saving depends on the resulting playback. Lower resolution may make signage, room details or property text harder to read, so check the image at the intended viewing distance before making it the default.
Use playback quality as a planning clue, not a data guarantee
YouTube publishes recommended sustained connection speeds by resolution: 0.7 Mbps for 360p, 1.1 Mbps for 480p, 2.5 Mbps for 720p, 5 Mbps for 1080p and 20 Mbps for 4K UHD. Those values are recommended connection speeds for playback. Multiplying them by 0.45 gives approximate hourly equivalents for planning, but those equivalents are not YouTube’s direct measurements of data consumed by viewers.
| YouTube playback resolution | Published recommended sustained speed | Approximate hourly equivalent if multiplied by 0.45 |
|---|---|---|
| 360p | 0.7 Mbps | 0.3 GB/hour |
| 480p | 1.1 Mbps | 0.5 GB/hour |
| 720p | 2.5 Mbps | 1.1 GB/hour |
| 1080p | 5 Mbps | 2.25 GB/hour |
| 4K UHD | 20 Mbps | 9 GB/hour |
The speed recommendations and the approximate equivalents in this table come from a calculation based on YouTube Help’s system requirements and supported devices guidance. Use them to compare planning scenarios, not to claim that a 1080p live stream will use exactly 2.25 GB each hour. Actual playback can vary, and a recommendation is not a promise of a transfer rate.
A common mistake is to copy a creator-side number into a viewer estimate. YouTube’s encoder recommendations depend on resolution, frame rate and codec. For example, its H.264 live ingestion guidance lists 5 Mbps for 1080p at 30 frames per second and 3 Mbps for 720p at 30 frames per second. Those are recommended outgoing settings for a creator’s feed, not fixed received rates for each viewer. If you are broadcasting instead, use your actual configured outgoing bitrate in the conversion and allow connection headroom; YouTube’s streaming tips discuss outbound bandwidth considerations.
Estimate the use for your own viewing pattern
For a practical estimate, write down three things: approximate playback quality, hours per day, and days you expect to leave the stream playing. Choose a hypothetical bitrate for each quality scenario, multiply it by the total hours and then by 0.45. If you do not know the bitrate, use the resolution-based equivalents above only as rough planning proxies, and make it clear to anyone sharing the estimate that these are not observed transfer totals.
Suppose you are deciding whether to leave a tour on a shop display for a working day. Compare a lower-quality scenario with a higher-quality one using the same number of hours, then check whether the image remains legible. If the display runs for several days, multiply the daily estimate by the number of days. Do not assume that a loop is cheaper just because the same scenes repeat; the viewer still receives the video as it plays.
For a result specific to your own PC and network, run the loop for a timed interval at the intended quality and inspect the computer’s network usage counter or the router’s device-level counter before and after. Keep other downloads and devices in mind, because their traffic can contaminate the comparison. This is a practical measurement suggestion, not a YouTube-prescribed test. A longer interval may better reveal a typical pattern if playback quality is changing, but no short test guarantees that later conditions will match.
YouTube’s Help page for mobile filming includes a rule of thumb of about 10 MB per minute in mobile-streaming guidance. Do not apply that as a fixed home-PC viewer rate: it is not presented as a guarantee for computer playback. For the PC watching this property tour, the bitrate conversion and a timed check are more relevant.
If your actual concern is maintaining a tour broadcast while the home computer is unavailable, that is a different operating problem from estimating viewer download data. StreamNeo removes the need to leave that particular PC running by turning an uploaded video into a YouTube live broadcast that can continue with the computer switched off, monitored and restarted if it drops.
Choose the next step based on the job
If you are only watching, focus on download data, selected quality and viewing time. If you are sending the tour live from the PC, focus on the encoder’s configured upload bitrate and whether the connection has enough outbound capacity with room for other use. In either case, distinguish an estimate from a measured session before using it to choose a plan or make a promise to a customer.
For channel operators planning a continuous promotion, a YouTube Live playlist for rotating store promos may help frame what should play, while a comparison of scheduling approaches for multiple 24/7 channels in India covers a broader operating decision. Those topics concern how to run programming, not how many bytes a specific viewer receives; keep the data estimate tied to actual playback.
If the problem is instead a creator feed that looks softer than the source sent by OBS, see why YouTube Live can show a lower resolution than OBS is sending. That is a useful distinction when setting expectations for staff viewing a live tour: resolution observed in the player is not a direct measurement of the source encoder bitrate.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How much data does YouTube Live use per hour?
There is no one hourly total for every live stream. As a calculation, a sustained 1 Mbps is about 0.45 decimal GB per hour, so multiply the actual playback bitrate by 0.45. If you only have a resolution, YouTube’s recommended connection speeds can provide rough planning proxies, not guaranteed data-use figures.
Does a looping live stream use data continuously?
Yes, when the player is continuing to receive and display the stream, data continues to arrive even if the footage repeats. Estimate the total from the hours played and approximate playback rate. Pausing or closing the player stops that playback transfer, though other activity on the device may still use data.
Is it upload or download bandwidth from a home PC?
Watching a YouTube Live property tour uses download data because the PC receives the video. Broadcasting a tour from an encoder uses upload data because the PC sends the feed to YouTube. A PC doing both at once can use both directions.
Can I use the broadcaster’s bitrate to estimate what I watch?
Not reliably as an exact viewer total. YouTube may transcode a live feed into formats for viewers, and playback quality can adapt to the connection, screen or player, source quality and browser. Use the actual playback rate if available, or treat a calculation from a chosen bitrate as an estimate.