Being the busy person that I am, I don’t usually have much time to watch TV, not that there’s much to watch on Freeview most days. Despite that, I caught wind that Channel 9 will launch a new lifestyle channel called 9Life starting next week, hot on the heels of SBS launching the Food Network on Tuesday just this week. It was a good time for me to take another look at Sydney Freeview services as I hadn’t really kept an eye on it since October 2013 just prior to the analog TV shut-off.
While DVB-T digital TV service is very much a normal part of Australian life now, the continued push towards Freeview “variety” have caused degradation of quality of services. It is understandable, however, that broadcasters have only the rights to a single carrier and that running a higher number of channels offering a larger variety of shows can serve to capture a larger audience and satisfy more viewers. Sadly, it seems that we have only just managed to adopt DVB-T when the reality is that DVB-T is somewhat obsolete already, mostly relying on MPEG-2 Video and MPEG-1 Audio family of codecs.
So, lets once again, take a look at what is on the air right now, so we can compare it to what is on the air at a later date, and while we’re at it, I’ll throw a little bit of Melbourne Cup into this post (you’ll understand why when I get to it).
In terms of what’s new since 2013, admittedly, not that much. Analog has gone, DVB-T is still here. One of the major changes was “the retune”, which was basically a phased realignment of transmitter frequencies around the nation to ensure that frequencies were optimal for the area and to clear out the 700Mhz UHF region to resell as “digital dividend” spectrum, resulting in new 700Mhz (i.e. branded as “4GX” by Telstra, “4G in more places” by Optus) LTE services.
In Sydney, that resulted in the main Sydney transmitter for SBS being taken away from the UHF Channel 34 it once was, to “slot” into VHF Channel 7, vacated by the switch-off of analog Channel 7. As a result, the channels in use by Sydney’s main set of DVB-T transmitters are VHF Channel 6, 7, 8, 11, 12 and 29. Sydney’s DAB transmitters occupy the area of Channel 9A, nestled in-between DVB-T transmissions.
One thing I noticed after this change was that my oldest can-tuners (i.e. Twinhan VP-7045A) started having more difficulty tuning into the VHF services. The reason for this, I theorized, is possibly because the tuners are built with 8Mhz front-end filters for international markets, and the 6 and 7Mhz demodulation modes may not have dedicated filters. With the digital stations basically sitting “shoulder to shoulder” on VHF, it’s likely that adjacent digital channel interference may be causing the tuners more difficulty than adjacent channel analog interference which may affect only a few carriers.
Aside from this, the launch of new channels has been a change. Channel 7’s multiplex has gained a new RACING.COM channel which appears to be a temporary arrangement although it seems to be ongoing. SBS’s multiplex now has a Food Network channel, as mentioned earlier, and soon Channel 9’s multiplex will have 9Life.
Of course, I’ve ended up making more observations, but I won’t spoil them here for the readers. You’ll have to read-on to the full analysis to find out.
The New Methodology
One of the biggest annoyances with my last analysis of Freeview back in 2013 was the wide use of statistical multiplexing (aka stat muxing) which results in an “adaptive” bitrate for each channel. My previous attempt included taking a snapshot of the bitrate at a given time where the bitrate appears to be average, but this was very much subject to error.
This time around, I have adopted a new strategy which involves using my Twinhan VP-7045A and the THTS Capture tool to capture a three hour slice of the transport stream from the air inclusive of all packets. Care was taken to avoid station closure periods (especially for ABC) and poor reception conditions.
Only three hour segments with less than 45 continuity errors/TEI-marked packets were accepted, which results in a net error rate of 8,460 bytes in every 31,200,000,000 bytes or thereabouts which works out into a BER of 2.7 x 10^-7 based on the assumption each TEI error packet is entirely lost. This is notably less than the ATSC 3 x 10^-6 BER for threshold of visibility of errors. This resulted in a need to recapture certain slices where interference caused excessive errors, but also confirms that I am experiencing very good reception in general.
The file creation and modify dates were used to determine the length of the capture (with some error necessarily) by extracting the high resolution timestamps by using the stat command under Cygwin. The measured multiplex bitrate was determined by dividing the size of the TS file by the capture time determined by timestamps, which is likely to underestimate the actual TS rate slightly due to extra time included in the timestamps in starting the recording.
All respective PIDs were determined from the first 1Gb of capture where no TEI packets were seen, and these PIDs (except null) were demultiplexed into separate files whose size were recorded. The size of the null fraction was determined from the incoming captured TS file size, minus the sum total size of all the extracted PID files. This will overestimate the null fraction by up to the number of erroneous packets noted above, which is negligible (i.e. at most 8760 bytes / 3 hours = 6.49 bytes/s). The size of each of the PID files was divided by the file length to determine the average bitrate of each PID over the three hours.
This method would allow the impacts of statistical multiplexing to be much less evident as the period of three hours represents numerous programs (typically 30/60 minutes) and scenarios across the different services. By averaging over the three hours, we should see a bitrate which converges close to the average bitrate normally seen throughout without the instantaneous program influences.
Carrier Modulation Mode Check
As this time around, I had a way to measure the rate of the multiplex, I was able to discover a discrepancy in SBS’ multiplex whose NIT claims to be 64QAM with GI 1/8 and Code Rate 2/3 which would only result in a payload rate of 19353kbit/s. The measured data rate was actually 23041kbit/s which indicates they have likely switched to GI 1/16 and CR 3/4 like the other channels on the air. This results in a payload gain of 3700kbit/s which is pretty handy. Checking from previous records, it was clear from the TSReader screenshot in this post that they did operate at the claimed rate just after the analog switch-off, so this change was likely made recently possibly to gain bitrate for launching their new Food Network channel.
Another change seems to be that TVS’ frequency has changed from 536.625Mhz to 536.500Mhz, thus removing the +125khz offset.
It seems that all other services are operating at pretty much the expected rate, with measured values being typically within 0.01% of expected result, except for SBS’ multiplex which is about 0.05% off the expected result, but that’s well within timing discrepancy for a human clicking buttons on a computer which might have had an NTP synchronization happen mid-recording.
I noticed that I made some mistakes with my previous analysis which included one data entry error, confusion between PMT PID and Service ID (SID), which have now been corrected for this analysis. Some redundant information has also been removed and noted at the bottom to compact the table.
So, what are the changes?
- Most multiplexes have grown one PID for use for “private data”, and more DSM-CC PIDs whose use is not immediately obvious. Some DSM-CC PIDs have changed as well.
- Channel 7 has changed 7TWO to use Joint-stereo audio, and has used “horizontally compressed” 528x576i on TV4ME. They added RACING.COM which is not really compatible with regular standard DVB-T receivers due to use of MPEG-4 H.264 Main@L3 encoding with 640x576i horizontally compressed encoding. It is paired with a roughly 70kbit/s HE-AACv2 parametric-stereo audio stream which is also not compatible with regular DVB-T receivers. Luckily many modern TVs, owing to their smart and 3D capabilities, have inbuilt MPEG-4 decoding abilities. The choice to break compatibility may have been necessary to maintain a level of quality within the bitrate budget available, and is sadly, not really an option for the main channels offered by broadcasters.
- SBS may have changed their encoding to a slightly reduced 704x576i rather than 720x576i to try and improve the video quality slightly by reducing the pixel count especially since 704 is the “active” area and may have certain codec efficiency reasons (i.e. multiple of macroblock size).
- Channel 9 had changed the service name to Nine Sydney, and added a few virtual channel numbers to the mix.
- ABC had changed their audio services to stereo encoding rather than mono encoding.
- TVS seems to have lost their DMS-CC encoding.
Aside from that, the same disappointments persist, namely that there is no 1920×1080 services on the air, only horizontally compressed anamorphic 1440x1080i with shockingly low bitrates for the encoding and the loss of bitrate to less patronized services, a quantity over quality situation.
For this, all non-video and non-audio data was grouped as “system” data except null packets. The discrepancy between the size of the “system” data lies mainly in the frequency and size of EPG (EIT) data, frequency of PMT/PAT transmission, amount of teletext data, and whether PCR packets are embedded inside video (in which case, they are counted as video) or whether they are on a separate PID (in which case, they are counted as system). The remaining video and audio services are grouped as 1st to 5th video/audio services, followed by audio-only services.
On the whole, everyone is doing a good job of utilizing the available multiplex bitrate except Channel 7 which has enough null packets to run another service. Is this a hint that they too are anticipating the launch of a new service, perhaps, a foreign-language service as rumoured earlier this year? Or was it because of a lack of reconfiguration after Fresh Ideas TV got axed at the end of 2014? Sadly, I don’t keep regular records of TS data for analysis, but it seems that the quality of all of Channel 7’s services are needlessly suffering while they continue to pump null packets into the air.
Of all the multiplexes, Channel 10 manages to squeeze down the null packet fraction very impressively, followed closely by Channel 9, SBS, ABC, and TVS.
Multiplex PID Rates
The individual PIDs which make up each multiplex have their average rates calculated and tabulated which makes for some interesting insights as well.
A key for those who aren’t familiar with MPEG-TS can be as follows:
- PAT – Program Allocation Table, tells the receiver where to find the services.
- PMT – Program Map Table, tells the receiver about the services and its streams.
- CAT – Conditional Access Table, tells the receiver about conditional access systems (i.e. DRM) in use on the multiplex, although not necessary with DVB-T.
- NIT – Network Information Table, provides information about the broadcast multiplex itself, e.g. provider, frequency modes, alternate frequencies.
- SDT – Service Description Table, tells the receiver about the name of each of the programs.
- EIT – Event Information Table, which basically means the “EPG”.
- TOT/TDT – Time Offset Table /Time Date Table, provides the time to the receiver.
- Sync – Superframe Synchronization used for Single Frequency Network synchronization co-ordination.
- Private – Private data, for general purpose usage.
- DSM-CC – Digital Storage Media Command and Control, may be used to datacasting purposes.
- Null Pad – Null packets used in place where no data packets are to be transmitted, as the digital transmission is a continuous symbol stream.
Additionally, video services are indicated by the LCN+V, audio services by LCN+A, caption text by LCN+T, and program clock reference (PCR) by LCN+P.
It may not be intuitive, but it seems that up to about 1Mbit/s of the multiplex is chewed up in the system data. It is essentially death by a thousand cuts, mainly because many of the fixed data has to be retransmitted periodically so that new receivers tuning in can receive the program lists and EPG in a timely manner. Almost half a megabit of bitrate is taken in the EPG of SBS, Channel 9, Channel 10, and ABC alone. This is all overhead that takes bitrate away from the picture/audio.
For newly tuned receivers, generally the PAT and PMTs are most important to receive in a timely manner to ensure scanning receivers don’t just time out and show “no services found”. Specifically, it’s probably best to ensure the PAT and PMT are transmitted multiple times in the time window in case marginal reception wipes one copy out. To that end, we can see that SBS, Channel 9, Channel 10 and ABC send their PAT and PMT in lock-step with a frequency to consume 15kbit/s, whereas Channel 7 and TVS only send their PAT and PMT with a frequency consuming 3kbit/s (five times less frequently). This may be an optimization for reducing overhead, but also may lead to scanning difficulties.
One interesting misconfiguration, it seems, is Channel 9 sends the PMT for 257 (GEM) twice as frequently as that resulting in 30kbit/s consumed in PMT. Sending the PMT for one service more frequently than the rest of your services may make it slightly more likely to appear on a frequency scan, but is not otherwise meaningful especially because this is not their primary service.
Another misconfiguration seems to be seen in ABC’s multiplex where PID 2306 seems to be issuing a PCR stream which is not associated to any program. I trawled through the PMTs multiple times to try and work out why it’s there, but I couldn’t work it out. As a result, about 40kbit/s is being consumed for no great reason.
Of course, there is additional overhead from the MPEG-TS packetization system and the need for PCR synchronization itself. Many of the PCR streams can be seen to consume about 40kbit/s alone just for providing a timing reference for the receiver.
Total Service Bitrate
The total service bitrate was taken by summing the measured Video PID rate with the indicated audio bitrate. This was compared with results from 2013 in lighter-coloured bars, although it is to be noted that 2013 results were based on snapshot in time rather than long term averaging so the results are less reliable.
The bitrate allocation is roughly the same although with a few services trading places. The biggest winners and losers were:
- ONE seems to have lost about 2.2Mbit/s. The bitrate seems to have gone almost entirely to ELEVEN and a little bit to Spree.
- 7mate has also lost about 2.2Mbit/s, 7 Digital losing about 0.5Mbit/s, 7TWO losing about 1Mbit/s. TV4ME remains marginally unchanged. About 2Mbit/s has gone towards RACING.COM’s new service, with the rest seemingly going to just more null packets as mentioned earlier.
- SBS HD has fallen dramatically by about 3.1Mbit/s, giving about 2Mbit/s to SBS TWO and 1Mbit/s to NITV, with SBS ONE marginally unchanged. The new Food Network service occupies 3.7Mbit/s – virtually exactly that gained by moving to a more aggressive code rate and guard interval combination despite the NIT claiming otherwise.
Other than that, most of the results indicate slight movements which are not significant due to the nature of the spot measurement made for the 2013 data. The result is still the same, with about 2Mbit/s lost to each shopping channel on the air.
What About the Quality?
Well, sadly there’s no algorithm to gauge the quality of the programming, as some shows can be just shocking. Oh, wait, you meant video quality?
A basic gauge of video quality can be had by computing the bits per pixel*frame. This metric is basically a count of how much information goes into making every visible “dot” on your screen, and generally is a useful way to get an idea if your video is going to look like mush or not.
Of course, such a metric is not infallible, as the final encoded quality for a given amount of information also depends on the characteristics of the encoder. A fast encoder with a limited feature-set that avoids performing the slower but more computationally complex optimization may not be able to extract as much visual quality for the same bitrate as the encoder will be limited to more restrictive encoding techniques. As most of the services are statistically multiplexed – they are subject to real-time encoding processes which can’t extract as much quality as two-pass encoding for example. The needs of the transmission medium with a limited budget will also reduce the perceived quality during peak image demands when keeping the same average bitrate as the bitrate cannot move outside a limited range.
Regardless, it’s worth taking a look at the metric anyhow, which I did in 2013 and I will do again this year. Generally speaking, MPEG-2 is best used with bits/pixel*frame values of 0.3 to 0.6.
On this metric, 7 Digital and TVS trade places this year, but both achieve reasonably good results. SBS TWO’s boost is clearly seen and so is ELEVEN’s. On the whole, most of the commercial standard definition channels you’d want to watch reside in the 0.3 to 0.6 bits/pixel*frame window. It seems the marginal change to resolution made by SBS may have a very marginally positive impact here.
The shopping channels, owing to their limited appeal, can be seen to occupy a lower area of the curve as their bitrate consumption has been constrained to avoid impacting too much on the primary services. RACING.COM utilizes H.264 encoding, which is twice as efficient, so it should have an equivalent value of about 0.4 for comparison.
The rather disappointing result is the low values for all high definition services, which all fall quite a bit short. This explains why watching those channels closely results in a lot of visible quilting/posterization.
However, the metric of bit/pixel*frame penalizes these services more, whereas in reality, a slightly lower value is acceptable due to more redundancy being within the frame as everything is bigger, and because of services like ABC News 24 in 50fps mode have temporal similarities which can be exploited – you don’t expect a 50fps stream of a newscaster to require twice the bitrate of a 25fps stream of the same newscaster.
Another issue has to do with the viewing device. For an imaginary screen of an arbitrary size, an arguably more important result is the amount of information in a given display area over time, as people generally watch their TV with the service “filling the screen” rather than at the broadcasted dimensions. As a result, I’ve instead repeated the computation, as if all the services were 720×576 at 25fps.
I like to think of this as an indicator of “clarity” when displayed on a screen, and it can be seen that the HD services do offer some benefit with more information per screen area, although in the case of SBS HD, only marginally so than the best SD services. This is perhaps, one of the reasons why I’ve never been pleased with SBS HD which has always shown very blocky images at a 1:1 viewing in my experience.
This of course, negates any overheads from encoding a larger number of macroblocks, or the loss of high frequency components in SD images due to the fixed lower-pixel count. But it does go to show that the gain from watching the on-air HD services are not that great compared to the SD services.
Unfortunately, further objective analysis of picture quality is not possible as many of the metrics used to compare compression techniques require access to the original uncompressed original image, and do not represent the perceptual quality.
With larger TVs, and by sitting at appropriate distances, such compression issues are clearly notable. With the bitrate budget practically exhausted, and the spectrum on offer being limited, it’s clear that if DVB-T2 or even H.264 over DVB-T was to become acceptable, services could effectively double their clarity with the more efficient encoding scheme. Of course, HEVC/H.265 offers even more potential, theoretically besting H.264 again by another factor of two.
As a result, I decided to take a quick look at exactly how much bitrate it would cost to deliver a certain resolution at a certain bits/pixel*frame.
Using a guide value of 0.3 to 0.6 for MPEG-2, acceptable standard definition is 3110 – 6221kbit/s, and indeed, mastered DVDs tend to hug the upper-rate. Acceptable full high definition in MPEG-2 would be 15552 – 31104kbit/s, with the horizontally compressed variant needing 11664 – 23328kbit/s.
If using H.264, we can approximately halve the values, with full high definition needing 7776 – 15552kbit/s, which very much meets my experience that good looking two-pass encoded H.264 high definition needs about 16Mbit/s, and studio mastered Blu-ray typically sees 22-26Mbit/s.
If H.265/HEVC were to become common, we could reduce this even further, but of course, I’ve always been dubious of each generation’s claims of “halving” the bitrate. With particularly difficult full-high-definition clips, the HEVC bitrate needed is about 10-12Mbit/s in my experience before I see visible distortion. That is still, a noteworthy improvement.
Sadly, it seems that the streaming generation has seen good video quality completely forgotten, and regularly, H.264 is streamed with bits/pixel*frame values of 0.05-0.15, resulting in muddy smoothed out pictures.
Look at the Bitstream!
Many years back when I first got my Twinhan VP-7045A tuner, I noted a small easter egg in the Channel 10 multiplex null packets. While that was a long time prior to the blog and I didn’t keep any information about it, it inspired me to go looking and gain a better understanding of the private stream and DSM-CC PIDs which have been sprouting up.
As a note to those who are not familiar with MPEG-TS, packets are 188-bytes in length and begin with a synchronization character 0x47 (“G”).
A look at the private stream PIDs results in an obvious conclusion that they contain readable text hyperlinks to a bootstrap xml file for Hybrid Broadcast Broadband TV. In Australia, this fucntionality is marketed under the Freeview Plus branding and helps to bring together the online catch-up TV services with the on-air broadcasts.
In the case of Channel 7 with just one private stream, they have just one HbbTV offering which consists of a two-packet repeating payload as above.
SBS has numerous private streams, one for each service, however all broadcast the same HbbTV configuration data with a two-packet payload as well. This means that they could save the other private streams and just broadcast one and have the PMTs point to the same PID.
Channel 9 operates just as Channel 7 with a single private stream and a two packet payload.
As does ABC for that matter. All of them utilize the freeviewplus.net.au domain name to serve the required data.
The only station making use of the different private streams for different offerings is the Ten network, where the shopping network stations have their own landings, distinct from the primary stations. However, they too broadcast duplicate private streams which represents a slight bandwidth overhead.
Regular Primary Station
Unfortunately, as I don’t know much about the DSM-CC standards, I can’t comment so much about them. The vast majority of them seem to have binary data flowing non-stop, which may be used for MHEG-5 interactivity uses which is rarely implemented, over-the-air set-top-box updates which is also rare. It seems there is one stream out there with readable text, PID 803 on Channel 9.
It is a one-packet payload with mostly all-ones, and the word “NineStreamEvent”. I wonder if this is used to signal FreeviewPlus TV’s to future online-streaming-only supplementary content (e.g. additional camera angles) as previously demonstrated by NHK as a form of “hybrid” TV.
Network Superframe Synchronization Packets
These packets are emitted just for the use of the network transmission equipment to manage the synchronization and time-offset of the transmitters. This helps single-frequency networks “beat” in time so that their signals are received with constructive interference, rather than creating “nulls” due to phasing issues, and to ensure that areas protected by late-arriving transmissions in the guard intervals remain protected.
I examined the packets in multiple channels, which are mostly consisted of all-ones, with the important data just the first few bytes. Of course, due to the nature of the transport stream, everything has to be packaged into 188 byte packets.
These packets are emitted to fill in empty spaces where no data is to be transmitted and generally gets ignored. Except for when I’m looking. Normally, they are filled with either all zeroes …
… as ABC and …
… Channel 9’s equipment does, or they are filled with “all ones”, which …
… Channel 7 and …
… TVS do, rather dutifully. These two most common fills for nulls are not very interesting though. What is interesting is when they deviate from what is standard and put something in there – which …
… both SBS and …
… Channel 10 do, and it seems to be a “feature” of the Ericsson MX8400 Multiplexer advertising itself on the air. Call it smart, or call it silly, but it’s definitely given away some information which I wouldn’t otherwise have known.
Why Melbourne Cup?
Which brings us to the Melbourne Cup and what it has to do with this whole business. Admittedly, I’m not a punter myself, and I don’t bet on horse racing at all. I don’t follow the races, and if given a choice of horses, wouldn’t know a head from a tail. Despite this, the Melbourne Cup is still an Australian tradition, and to stop at 3pm for the duration of the race is practically mandatory.
Of course, there is a video quality side thing to this. Being a prolific RF-guy, I like to chase feeds with several Ku band dishes and a “fabric” of DiSEqC switches. On the day of the cup, very nicely, two un-encrypted feeds popped up on Optus D2 for me to enjoy.
The parameters were 12680Mhz Vertical 7500Ks/s DVB-S2 8PSK FEC 2/3 for the high definition feed and 12662Mhz Vertical 6670Ks/s DVB-S QPSK FEC 3/4 for the standard definition feed. The high definition stream was provided by Globecast HD, and was of the main program, with the standard definition stream looking over the horse entrance area. On the day of the cup, my desktop looked a bit like this:
Of course, when feeds are “open” for the taking with no encryption, tuning in is all part of the fun. The best part with open feeds are that they are used for linking the on-site studio with the master control room and so often do not have advertising and are several seconds ahead of the terrestrial broadcast due to less latency. The other benefit? It has a higher quality, as it is the source material to be cascaded down to the terrestrial broadcast.
In the case of the Melbourne Cup, the satellite stream was a full 1920x1080i at 25fps with 13.5Mbit/s rate coded in MPEG-4 H.264, which is not bad, especially compared to the 720x576i at 25fps MPEG-2 stream at 5.1Mbit/s I would get from terrestrial TV.
It illustrates the difference between modern codecs with a decent bit-rate and antiquated codecs with a less-decent bit-rate and the resolution disparity very adequately. I grabbed the first frame from the 12th second of the race, an overview shot, and resized the standard def 720×576 up to the 1920×1080 of the original and took a crop for comparison. This is realistic because most people own an HDTV now, and they will be viewing standard def “upsized” to full HD.
Look at the jerseys on the horseriders. Can you tell who’s who? Even with the original 800px wide crop downsampled to 640px for display (click for full), it’s not that clear, but the compression “ringing” around the edges is.
Contrast it with the raw feed image which is basically “post” all on-site production at full high def and the difference is immediately obvious. You could have watched it at this quality with a DVB-S2 satellite card, Ku band dish and LNB, or if they used H.264 for HD transmissions with 13.5Mbit/s bitrate terrestrially. If the government were not as greedy for spectrum, it may have been possible to give each broadcaster two multiplexes, and relieve bitrate starvation immediately. It would take more frequency co-ordination and planning, but it just sucks knowing it “could” be better.
For those who are interested, the raw frame grabs are below. Note the standard definitions’ 720×576 is exported as is without display-aspect-ratio correction.
It was also the first Melbourne Cup to be watchable online due to the efforts of Channel 7 to bring online live streaming of their channels. Sadly, I did have some difficulties initially, and the quality wasn’t that much different from the terrestrial although with additional buffering delays.
I guess it is the beginning of a “hybrid” broadcast world now, where internet-based on-demand catch-up and streaming will eventually make the “antenna” obsolete. I welcome this, as a converged IP-based world is one that does simplify many things, but sadly, I am yet to find that these services match the quality of the services they’re attempting to replace.
The state of Freeview is much the same as it was before, with constrained bitrate and increasing variety putting strain on the quality of the delivered services. After the transition to digital and the retuning, minor difficulties with tuning stations were seen with my oldest tuners, which is probably due to the closeness of the adjacent stations.
By doing some careful work, it was possible to reanalyze the state of the services in a manner more resilient to the short term bitrate perturbations which occur due to statistical multiplexing and arrive at a more robust and representative answer. New services were seen, and changes to configuration of existing services noted. Some interesting misconfigurations were noted, resulting in possibly diminished image quality to viewers. A look at some of the quality metrics also revealed acceptable-to-low bandwidth allocations for standard definition services and critically low bitrates for high definition services which only offer marginal clarity benefit. Changes to the services for Freeview Plus interactive hybrid broadband broadcasting was also noted.
As we move to an internet-centric society with IP based services, streaming has a good potential to supplant existing traditional broadcast and physical distribution channels. Unfortunately, such services are still in their infancy, constrained by slow internet connections sadly bought upon us by the destruction of a FTTP NBN, costly connection bandwidth quota and a desire to minimise cost. Somehow, I don’t think delivery of quality 4k content will be achieved in the near future, especially as a quality image will need about 30-50Mbit/s to deliver in H.265/HEVC. Even Blu-ray full-HD in HEVC would cost 10-12Mbit/s per stream in my experience. Anything less is, for all intents and purposes, a compromise.
It will be interesting to see what happens to the Channel 9 multiplex once 9Life has launched. The bits have to come from somewhere.