A 4 GB Laptop, a 2.6 GB Video and a 100 MB Portal
A student preparing a general-awareness presentation records a 25-minute screen video at 1080p. The raw recording is 2.6 GB. Her laptop has 4 GB of installed RAM, a 64-bit processor running a 32-bit edition of Windows 10, and a 500 GB hard disk with 462 GB free. The video editor states that it needs at least 4 GB of addressable memory for smooth playback, and that exporting needs 3 GB of scratch space. The submission portal accepts uploads of at most 100 MB and only the .mp4 or .zip formats. The student has already tried 'compressing' the file by right-clicking and sending it to a compressed folder; the resulting .zip was 2.58 GB. She now plans to free more disk space and to install the 64-bit edition of Windows so that, in her words, 'the laptop will have 8 GB of memory'.
1. Explain why the laptop reports only about 3.2 GB of usable memory, and evaluate whether freeing disk space or switching to the 64-bit edition will solve the editor's 4 GB requirement.
Read the worked answer
Why ~3.2 GB. A 32-bit edition of Windows can address 2^32 bytes = 4,294,967,296 bytes = 4 GiB in total. That address space is not all available to applications: memory-mapped I/O, firmware and device reservations consume a chunk, typically leaving roughly 3.2–3.5 GB visible to Windows. So 4 GB installed → about 3.2 GB usable, which is below the editor's 4 GB requirement.
Freeing disk space: irrelevant. The requirement is about memory the program can address, not storage. The laptop already has 462 GB free, far more than the 3 GB scratch requirement, so storage is not the bottleneck.
Switching to 64-bit Windows: partially helpful, not a doubling. The 64-bit edition removes the roughly 4 GiB address-space ceiling, so nearly all of the physically installed 4 GB becomes usable (typically 3.7–3.9 GB after hardware reservations). It does not create memory: the physical modules are still 4 GB, so the student's expectation of '8 GB' is simply wrong. In practice the 64-bit edition also uses somewhat more memory for itself, so the editor's 4 GB figure would be met only marginally.
Real fix: add physical RAM (for example, 8 GB) if a slot is free, or use another machine. Note also that the '500 GB' disk showing about 462 GB of free space reflects decimal (10^9) versus binary (2^30) units, not lost storage.
2. The 2.6 GB file must pass a 100 MB portal that accepts .mp4 or .zip. Evaluate the zipping approach with numbers, and state what must actually be done.
Read the worked answer
Zipping an .mp4 is nearly useless. The student's own result shows it: 2.6 GB → 2.58 GB, about a 1% saving. H.264/H.265 video is already entropy-coded, so a general-purpose lossless compressor finds almost no redundancy. No amount of zipping will close a 26:1 gap.
The size of the gap: 2.6 GB ≈ 2,600 MB (decimal) against a 100 MB limit → about 26:1 compression required. Lossless methods cannot deliver that on compressed video; only lossy re-encoding (or cutting the video) can.
Bitrate arithmetic. 25 minutes = 1,500 s. 100 MB = 100 × 8 = 800 Mbit. Total bitrate budget = 800 / 1,500 ≈ 0.53 Mbps for video plus audio. That is very low for 1080p, so the realistic options are:
- re-export at 480p or a low frame rate with a bitrate around 0.5 Mbps (heavily degraded but acceptable for a screen recording of static slides);
- reduce the running time, since bitrate and duration are interchangeable in the same budget;
- check whether the portal accepts multiple parts, in which case split the export.
Judgement point: 'compress the file' and 'compress the video' are different operations. The first is lossless and bounded by the data's existing entropy; the second changes the encoding and is the only one that can move a 2.6 GB file into a 100 MB box.
3. The export needs 3 GB of scratch space. Given 462 GB free, is this a constraint? What would you check before starting the export, and why does the editor still risk failing?
Read the worked answer
Scratch space is not the constraint. 462 GB free against 3 GB required leaves a margin of 459 GB. Even with temporary peak usage several times the stated figure, the disk is not the limiting resource, and deleting files to 'make room' will change nothing.
What to check before exporting:
- Whether the 64-bit edition and enough RAM are actually available - this is the binding constraint, and an export is the most memory-intensive stage, so a playback that stutters will usually crash during export.
- The pagefile setting: with only ~3.2 GB addressable, Windows will lean on virtual memory, which is disk-backed. That works, but it is slow and can fail outright if the pagefile is capped or the disk is nearly full - which is not the case here.
- The export preset: resolution and bitrate determine both memory pressure and the final size that must fit the portal's 100 MB limit. Choosing the 480p preset first avoids a second full export.
Why failure is still likely: the editor's stated requirement is about addressable memory, and the machine sits below it. The student's two planned remedies - freeing disk and installing a 64-bit OS - address storage and the address-space ceiling respectively, and neither adds a single byte of RAM. The correct diagnosis is a memory shortfall; the correct remedy is more physical RAM, a lighter export preset and, if necessary, a different machine.