Which recordings take the most space?

Bit of an esoteric one.

Which recordings take the most disk space per hour or minute?

Is there a difference by channel?

Is there a difference by genre?

This occurred to me as I was seeing which recordings I could bear to delete and how much space I would gain.

Maybe I should add that I record almost exclusively from HD channels, so the HD/SD factor is, er, factored in.
 
Last edited:
Generally in descending order of space taken per minute it's HD programmes, SD programmes and then radio programmes.

Any particular channel does vary slightly. To get an idea of the size of a channel you could refer to the bitrate

On that site there is a small table further down for each mux that lists the average bitrate that they have recently polled for each channel on the mux.

You have posted a few times on the custom firmware of this forum. Do you not still use that? On the webif you can browse your recordings and see exactly how much space each is taking. Also if you click on the pie chart in the top right of the webif this will give you a breakdown of space taken by each folder.

There is also the package FlexView which enables you to sort a list of your recording by size.
 
if you click on the pie chart in the top right of the webif this will give you a breakdown of space taken by each folder.
I think a lot of people will not have discovered that. I had, but since forgotten.

Within StDef or HiDef, the better quality creates the biggest files (per minute of recording time). HiDef is frequently only 720i/p, so will be smaller than 1080i/p. I have noticed that, say, Quest (StDef) is a lower grade image than BBC1 (StDef).
 
I record in HD wherever possible and notice that bitrates vary quite a lot even for programmes on the same channel.

E.g. I've just take a look at two BBC1 HD recordings (neither shrunk)
1. Today's Coronavirus Daily Update: 85 minutes, 2.34 GiB
2. Part of last year's Men's Wimbledon Final: 65 minutes, 2.91 GiB - about 60% higher bitrate.

I think the rate is varied according to the broadcaster's view of how important is the 'best' image quality. Also there has been a tendency for HD bitrates to fall over the years.
 
When using the custom firmware you can shrink recordings to remove unneeded data packets and you can also detect and crop out ad breaks.
Shrinking is worthwhile for recordings you intend to keep but not really needed for watch and delete programmes.
 
I record in HD wherever possible and notice that bitrates vary quite a lot even for programmes on the same channel.
It will vary with the content.
A scene of a newsreader against a static background has little information to change over successive frames - a scene of a detailed landscape being panned or filmed from the air has a lot of change from frame to frame.
The latter is where you are most likely to see pixellation or fuzziness creeping in if the bitrate isn't enough.
 
I heard a story in the early days of digital TV when bandwidth was harder to come by that the broadcasters would progressively over a period of time ‘sneak’ down the bit-rate of the coders (usually overnight) until a set level of complaints regarding picture quality were received. They’d then hold at that level for a while to allow ‘acclimatisation’ before starting again!
 
It's true that the bit rates are a lot lower now than when HD started 10 years ago. The broadcasters' excuse is that they justify this by having new coders which compress things better (and add ever more delay) while maintaining the same quality. This may be true to some extent, but picture quality off-air is a whole lot worse than it used to be, by the evidence of my Mk I eyeball (and that's not just courtesy of my deteriorating eyesight either).
Off-air HD is little better than good SD in the old days. SD these days is just sh!te and horrid to watch (VHS quality), even on the mainstream channels (the rest are even worse), with mosquito noise all over.
 
Most content is pre-recorded, if not stock, so could be compressed in slow time ahead of broadcast if they wanted.

My recent examination of video encoding re GPU v CPU indicates the compression algorithm can do a much better job if allowed deeper pattern searches and dual-pass.
 
I thank everyone for their interesting replies.

I had no idea about the clicking on the pie chart - Thanks, Luke.

Yes, I did think that the amount of screen action might be the key - Thanks, MikeSh.

In fact combining these two things, I can see that these Work From Home programmes seem to be taking less space than the traditional studio versions.
 
I think a lot of people will not have discovered that. I had, but since forgotten.

Within StDef or HiDef, the better quality creates the biggest files (per minute of recording time). HiDef is frequently only 720i/p, so will be smaller than 1080i/p. I have noticed that, say, Quest (StDef) is a lower grade image than BBC1 (StDef).


There are no broadcast sources of 720p - there never has been. NOW TV uses 720p. All HD channels on satellite are now the full 1920 x 1080 interlaced. The BBC have the most efficient HD H264 AVC encoders so use a lower bitrate than the other broadcasters so has smaller file sizes. Freeview-HD can use 1080p25 or 1080i 50. They can switch between either in sequential GOPs. This created some issues with the earliest Freeview-HD kit.

The average bitrate is actually lower than the best SD channels have to use as the mpeg 2 encoding used is much less efficient than H264/AVC. If the broadcasters could use the encoding used for 4K H265/EHVC they could use even lower bitrates. Other HD broadcasters typically average around 12000 kb/s so have significantly larger files.


Typical BBC 1 HD satellite broadcast details


General
ID : 2050 (0x802)
Complete name : D:\Strictly\TSFiles\Strictly Come Dancing_20170930_1844.ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 7.68 GiB
Duration : 2 h 6 min
Overall bit rate mode : Variable
Overall bit rate : 8 699 kb/s
FileExtension_Invalid : m2ts mts ssif

Video
ID : 5400 (0x1518)
Menu ID : 6941 (0x1B1D)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, RefFrames : 4 frames
Format settings, GOP : M=8, N=24
Codec ID : 27
Duration : 2 h 6 min
Bit rate : 7 893 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Scan type, store method : Interleaved fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.152
Stream size : 6.96 GiB (91%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1
ID : 5401 (0x1519)
Menu ID : 6941 (0x1B1D)
Format : AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : 6
Duration : 2 h 6 min
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -1 s 156 ms
Stream size : 173 MiB (2%)
Language : English
Service kind : Complete Main

Audio #2
ID : 5402 (0x151A)
Menu ID : 6941 (0x1B1D)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Duration : 2 h 6 min
Bit rate mode : Constant
Bit rate : 256 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : -1 s 96 ms
Stream size : 231 MiB (3%)
Language : nar

Text
ID : 5404 (0x151C)
Menu ID : 6941 (0x1B1D)
Format : DVB Subtitle
Codec ID : 6
Duration : 2 h 6 min
Delay relative to video : 5 s 648 ms
Language : English

Other
ID : 5403 (0x151B)-888
Menu ID : 6941 (0x1B1D)
Format : Teletext
Language : English

Menu
ID : 260 (0x104)
Menu ID : 6941 (0x1B1D)
Duration : 2 h 6 min
 
Last edited:
I thank everyone for their interesting replies.

I had no idea about the clicking on the pie chart - Thanks, Luke.

Yes, I did think that the amount of screen action might be the key - Thanks, MikeSh.

In fact combining these two things, I can see that these Work From Home programmes seem to be taking less space than the traditional studio versions.

They reduce the amount of space by using variable bitrates (stat muxing) using a higher rate for groups of pictures with more movement.
 
Playing some C5HD cricket highlights (why not watch Stokes's brave but fluky salvation from last year's 3rd test again?) using DLNA broke up, while a drama series (The First) from C4HD played fine. The cricket came at 6.6Mbit/s overall while the drama was 4.3Mbit/s. This is using a WiFi connection reporting 48Mbit/s.

Strangely I can't get ffprobe (4.1) to give me the details of the .ts files ("End of file") although it works for .mp4, and, I thought, for .m2ts previously.
 
Playing some C5HD cricket highlights (why not watch Stokes's brave but fluky salvation from last year's 3rd test again?) using DLNA broke up, while a drama series (The First) from C4HD played fine. The cricket came at 6.6Mbit/s overall while the drama was 4.3Mbit/s. This is using a WiFi connection reporting 48Mbit/s.

Strangely I can't get ffprobe (4.1) to give me the details of the .ts files ("End of file") although it works for .mp4, and, I thought, for .m2ts previously.

MediaInfo will give you virtually everything there is to know about the contents of a Video Container file (like .ts transport stream) Select View- Tree. You can export the data to a .txt file.


You need to use a box that can remove the encryption Like a Foxsat-HDR (with the CF and nowsters patch) or HDR-FOX-T2 or the two newer Humax Freeview pvrs.
 
Colour me idiotic. Of course these hadn't been decrypted yet. MediaInfo didn't care for them either.

Note to self:
Code:
myffprobe() { # ffprobe, or say file is encrypted
    # get the last param (.ts) in a subshell to avoid losing params
    (while [ -n "$2" ]; do shift; done
     hmt "$1" ) | 
        grep  "encrypted on disk" || 
    ffprobe "$@"
}
 
Last edited:
Sorry, I wasn't aware this is a discussion in the Foxsat/Freesat section of the forum.


Matters not a sod. Neither platform has ever broadcast 720p. In fact true 720p has a higher bitrate than 1080i because it's 50 fps. Your post was complete rubbish. The encoder remarks re the BBC apply equally to Freeview and satellite.
 
For my own amusement/satisfaction, I pasted the values from the Web-If Media Details box for various recordings into Excel.

Quite surprised to see the variation between similar recordings on the same channel broadcast at the same time of day.

TitleLength
(Minutes)
FileSize
(GB)
GB/Min.ChannelType
Mister John
90​
2.24​
0.02489​
BBC ONE HDFilm
Jimi: All Is by My Side
109​
2.84​
0.02606​
BBC TWO HDFilm
Agatha Christie's Crooked House
121​
3.33​
0.02752​
Channel 5 HDTV
Carefree
84​
2.55​
0.03036​
BBC TWO HDFilm
Porridge
45​
1.41​
0.03133​
BBC TWO HDTV
Beat The Chasers
60​
2.15​
0.03583​
ITV HDTV
Joe Lycett
56​
2.12​
0.03786​
Channel 4 HDTV
Tropic Thunder
98​
4.22​
0.04306​
BBC ONE HDFilm
The Gay Divorce
101​
4.75​
0.04703​
BBC TWO HDFilm
The Conversation
109​
5.22​
0.04789​
BBC TWO HDFilm

These two Fred Astaire - Ginger Rogers films, Carefree and The Gay Divorce, are poles apart.
 
For my own amusement/satisfaction, I pasted the values from the Web-If Media Details box for various recordings into Excel.

Quite surprised to see the variation between similar recordings on the same channel broadcast at the same time of day.

TitleLength
(Minutes)
FileSize
(GB)
GB/Min.ChannelType
Mister John
90​
2.24​
0.02489​
BBC ONE HDFilm
Jimi: All Is by My Side
109​
2.84​
0.02606​
BBC TWO HDFilm
Agatha Christie's Crooked House
121​
3.33​
0.02752​
Channel 5 HDTV
Carefree
84​
2.55​
0.03036​
BBC TWO HDFilm
Porridge
45​
1.41​
0.03133​
BBC TWO HDTV
Beat The Chasers
60​
2.15​
0.03583​
ITV HDTV
Joe Lycett
56​
2.12​
0.03786​
Channel 4 HDTV
Tropic Thunder
98​
4.22​
0.04306​
BBC ONE HDFilm
The Gay Divorce
101​
4.75​
0.04703​
BBC TWO HDFilm
The Conversation
109​
5.22​
0.04789​
BBC TWO HDFilm

These two Fred Astaire - Ginger Rogers films, Carefree and The Gay Divorce, are poles apart.

Were they 4:3 with big side borders ? If so less pixels to encode.
 
Back
Top