Build Your Own Netflix — A Home Video Server
What If Your Next Streaming Service Was Running in the Spare Room?
You sit down, open an app and browse a collection of videos. There are thumbnails, descriptions and familiar playback controls. Choose something, press play, and it appears on your screen.
That experience does not have to depend on a large streaming company.
The server could be a computer in your own home. The programmes could be your own films, family recordings, sailing footage or science demonstrations.
With software such as Jellyfin, you can organise your video collection and stream it around your home network.
For GCSE and A-level Computing students, this is an excellent practical project. It brings together client–server systems, networks, compression, storage and access permissions in something people might actually want to use.
The interesting question is not simply “Can I play a video?” It is “What has to happen between pressing play and seeing the picture?”
What Does “Build Your Own Netflix” Actually Mean?
We are borrowing the idea of a browsable streaming library.
Jellyfin does not supply Netflix programmes or give access to commercial streaming catalogues. You provide the media files; Jellyfin provides the organisation and playback system.
It is free, open-source software, and its server and official clients do not require a subscription. Running the computer and providing storage still have costs.
Your collection might include:
Family films and holiday recordings.
Your own short films and animations.
Sailing footage and boat-maintenance videos.
Recorded science demonstrations.
Music performances you have recorded.
Other videos you have permission to store and stream.
For my own teaching and media interests, the attraction is easy to see. A collection of experiments becomes much more useful when I can find “standing waves” or “transpiration” without searching through several drives and a collection of vaguely named folders.
A video archive should help us watch and learn from our recordings.
The Server Serves; the Client Requests
The central computer runs the server software. It has access to the video files and manages the library.
The device used to watch them is the client. That might be a laptop, tablet, phone or suitable television app.
Imagine watching a sailing video on an iPad:
The client connects to the server.
You sign in and browse the library.
The client requests a particular video.
The server supplies video data across the network.
The client decodes the data and displays the pictures and sound.
The server and client perform different jobs. They do not need to use the same operating system.
A Linux computer can serve a Windows laptop. A Windows server can supply a tablet.
This is one reason I like practical networking projects: they help students move beyond thinking of computers as isolated machines.
A server is a role performed by software on a computer. It does not have to be a large machine in a data centre.
What Do You Need?
Start with a modest aim: play one of your own videos on another device in the house.
You need:
A computer capable of running Jellyfin.
Storage containing a few video files.
A home network.
A second device for playback.
Some time to organise and test the system.
An existing Windows or Linux computer is a sensible starting point. You do not need to buy a dedicated machine before discovering whether you find the project useful.
For a permanent installation, connect the server to the router or network switch using Ethernet where possible. Wireless clients can still watch over Wi-Fi. Jellyfin’s hardware guidance recommends a wired connection for the server.
What About a Raspberry Pi?
A Raspberry Pi can be an interesting learning platform for a small library when clients can play the files directly.
However, do not assume that a small computer will comfortably convert demanding video formats during playback.
A reused desktop or suitable mini PC gives more scope for experiments, particularly when compatible hardware acceleration is available.
Choose hardware according to the work it must do, rather than the number of videos you own.
A First Build: From Folder to Streaming Library
1. Choose a Few Test Videos
Begin with five or six short recordings you made yourself.
For example:
A science demonstration.
A sailing clip.
A family recording.
A short animation.
Two exports of the same video at different bitrates.
Short clips make troubleshooting quicker.
Keep the originals safely backed up and use copies for experiments.
2. Organise the Files
Create a main folder such as Home Videos, with subfolders including:
Science DemonstrationsSailingFamilyStudent Films
Use meaningful filenames:
Standing Waves - Demonstration.mp4
is easier to recognise than:
final_export_NEW_3.mp4
Good organisation helps both people and software.
3. Install Jellyfin
Download Jellyfin through its official website.
On Windows, follow the installer instructions. On Linux, use the official instructions for your distribution. Debian and Ubuntu have a documented repository installation route.
For a first project, install directly on the operating system you already understand. Containers can make a useful later extension.
4. Complete the Setup
The initial setup includes creating an administrator account and adding media folders.
Choose a library type appropriate to your material. Personal recordings should not be treated as commercial films that the software is expected to identify from an online film database.
Give the Jellyfin process permission to read the media folders. On Linux, remember that a folder you can open in your own account may still be inaccessible to the service account running Jellyfin.
Create a separate ordinary user account for everyday viewing.
5. Connect from Another Device
Suppose your server has this example local IP address:
192.168.1.50
Using Jellyfin’s default HTTP port, another device on the same trusted home network could connect to:
http://192.168.1.50:8096
Use your server’s actual address.
The IP address identifies the machine; the port identifies the service. On the client, localhost would mean the client itself.
If necessary, allow Jellyfin through the server’s firewall for the trusted local network. Keep this first project local: router port forwarding is unnecessary. Jellyfin’s documentation advises against exposing its HTTP port directly to the internet.
6. Press Play
Open a video on the second device.
You have now built a working client–server application.
The next step is to investigate what it is doing.
Streaming: Watching Before the Whole File Arrives
Downloading and streaming both involve transferring data.
The practical difference is that streaming allows playback to begin while further data is still arriving.
The client normally keeps a buffer: some video data ready ahead of the current playback position.
Think of a water tank:
Incoming water represents arriving data.
Outgoing water represents the data consumed during playback.
Stored water represents the buffer.
Short interruptions can be absorbed by the buffer. If data arrives too slowly for too long, the buffer empties and playback pauses.
A larger buffer can help with temporary disruption. It cannot permanently compensate for a connection that is too slow.
Compression: Why Video Files Can Be So Large
Video contains a great deal of information.
Consider an illustrative uncompressed recording with:
1,920 x 1,080 pixels per frame.
24 bits per pixel.
30 frames per second.
Ignoring audio and additional overhead:
Bits per frame = 1920 x 1080 x 24
Bits per frame = 49,766,400
Bits per second = 49,766,400 x 30
Bits per second = 1,492,992,000
That is approximately 1.49 gigabits per second.
An hour would occupy roughly 672 GB, using decimal units.
This calculation assumes full-colour, uncompressed frames. Real recording formats can represent colour differently, but it illustrates why compression matters.
How Does Compression Help?
A video codec represents pictures more efficiently.
It can exploit patterns within a frame and similarities between frames. A fixed-camera recording of someone speaking may contain a background that changes very little. Detailed leaves moving in the wind are harder to represent efficiently.
Many familiar video formats use lossy compression: some information is discarded to reduce the amount of data.
Compression therefore involves choices about picture quality, file size, processing demands and compatibility.
A File Extension Does Not Tell the Whole Story
An MP4 file is a container. It can contain video, audio and other information.
The codec describes how a stream inside that container is encoded.
Two MP4 files may therefore behave differently on the same device.
“Both files end in .mp4” does not guarantee identical playback support.
Bitrate: Connecting Storage to Network Demand
Bitrate measures how much data is used per second.
For an illustrative video with an average total bitrate of 8 megabits per second:
File size in bytes = bitrate in bits per second x duration in seconds / 8
For one hour:
File size = 8,000,000 x 3600 / 8
File size = 3,600,000,000 bytes
That is approximately 3.6 GB, using decimal units.
Notice the distinction:
Mbps means megabits per second.
MB means megabytes.
One byte contains eight bits.
If three people watch separate 8 Mbps videos simultaneously, the combined media bitrate is approximately:
3 x 8 = 24 Mbps
Allow additional capacity for protocol overhead, bitrate peaks and other network traffic.
Also distinguish internet speed from local network performance. A video travelling from your home server to a device in the same house does not normally need to pass through your broadband connection.
Direct Play and Transcoding: Two Very Different Workloads
This is the most useful distinction in the project.
| Playback method | What happens | Typical demand |
|---|---|---|
| Direct Play | The client receives the original file without conversion. | Low processing demand on the server. |
| Remux | The container changes while the audio and video remain unchanged. | Usually modest. |
| Direct Stream | Jellyfin converts audio while preserving the video stream. | More processing, but video is untouched. |
| Video transcoding | The server decodes and re-encodes video during playback. | Potentially substantial. |
Jellyfin reports the playback method in its dashboard. Hardware acceleration can help with transcoding when the hardware, drivers and configuration support it.
A computer may serve several compatible files comfortably yet struggle with one demanding conversion.
The challenge is not simply “How many viewers?”
It is also:
“What must the server do for each viewer?”
Subtitles can add another complication. Some can be rendered by the client; others may need to be burned into the video, triggering video conversion.
A Practical Investigation for Computing Students
Can You Make the Server Work Harder Without Changing the Film?
Take a short video you recorded yourself and prepare two exports:
1080p H.264 video with AAC audio in an MP4 container.
A second version using a different codec or a substantially higher bitrate.
Keep the originals.
Test each version in a browser and another available client.
Record:
| Test | What to observe |
|---|---|
| Playback method | Direct Play, Remux, Direct Stream or Transcode |
| Startup | How long before playback begins? |
| Processor use | Does server CPU activity increase? |
| Network activity | How much data is transferred? |
| Seeking | How quickly does playback resume after jumping ahead? |
| Picture quality | What differences can you actually see? |
Do not assume which version will transcode. Observe the result.
A compatible client may play both directly. That is a finding worth explaining.
Then try lowering the client’s playback quality setting and observe whether the server changes its behaviour.
The educational value comes from predicting, measuring and explaining.
Add a Small Compression Experiment
Export the same 30-second clip at several target bitrates, keeping resolution, frame rate and codec settings otherwise comparable.
Try:
2 Mbps
5 Mbps
10 Mbps
Compare the resulting files.
Look particularly at:
Moving water.
Grass and leaves.
Fine lettering.
Dark areas.
Rapid movement.
Sailing footage would be useful here. Water, reflections, rigging and movement create a more demanding subject than a largely stationary classroom scene.
Ask students:
Which version would you keep, and what evidence supports your decision?
The largest file is not automatically the best practical choice.
Why This Is a Good OCR H446 Learning Project
The project gives concrete examples for several important Computing concepts.
| Concept | Practical connection |
|---|---|
| Client–server systems | A viewing device requests media from a central service. |
| IP addresses and ports | Clients locate the machine and its application. |
| Protocols | Requests and media data travel using agreed rules. |
| Compression | Encoding choices affect size, quality and compatibility. |
| Bandwidth | Available capacity constrains simultaneous playback. |
| Buffering | Temporary storage helps manage uneven delivery. |
| Metadata | Descriptions and thumbnails help organise the collection. |
| Access control | Accounts determine who can use the service. |
| Performance | Processing, storage and networking can each become bottlenecks. |
A particularly useful written question would be:
Two devices play the same video from the same server. One plays smoothly; the other repeatedly buffers. Explain why.
A strong answer considers client compatibility, transcoding, wireless conditions and settings.
It goes beyond “the internet is slow”.
A Video Library Has to Be Maintained
A working demonstration is the beginning of a useful system.
For regular use:
Back up irreplaceable recordings separately.
Keep the operating system and Jellyfin updated.
Use strong passwords and appropriate account permissions.
Consider a router DHCP reservation so the server keeps a predictable address.
Remember that a sleeping or switched-off server cannot serve videos.
Jellyfin can operate locally without an internet connection, although online metadata retrieval requires internet access.
Also consider electricity use.
For illustration, a machine averaging 30 W continuously uses:
Energy per day = 0.03 kW x 24 hours
Energy per day = 0.72 kWh
Over 365 days:
Energy per year = 0.72 x 365
Energy per year = 262.8 kWh
Multiply that by your electricity unit rate to estimate the cost.
Measure the actual machine where possible. A label showing the power supply’s maximum rating does not tell you its normal consumption.
If you only watch occasionally, running the server when needed may be sufficient.
From a Pile of Files to Something Worth Watching
What appeals to me about this project is the connection between computing and the material we create.
A science demonstration, a short film or a sailing recording takes effort to produce. Making it easy to find and watch gives that work a longer useful life.
For students, the project also changes the questions they ask.
Why does this device need a conversion? Why does one file use more bandwidth? Why can playback continue briefly when the connection is interrupted?
Those questions lead directly into the underlying computing.
Start with one computer, a few recordings and one other screen. Get them talking. Then investigate what happens when you press play.
Your own streaming library can be useful entertainment—and an excellent practical Computing lesson.





