SDTV (480i/p, 576i/p) Satellite TV in the 90s vs today: width conventions

[Cedr00m4kv1x]

Hello world! This thread is published to this forum, with the purpose of asking the following question: Did satellite TV providers like DISH Network(R) or DIRECTV(R), during the 90's, use the 3/4 D1 (544x480 NTSC) format for their broadcasts just to save bandwidth, or did they always use the Full D1 resolution (720x480 NTSC) at a lower bitrate? If I'm not wrong, I know they used to encode (and decode via their receivers) them in MPEG-2 format.

In order to prove this is true, I decided to play with some video files. Here are the commands I used for such task:
3/4 D1 (544-width, NTSC), MPEG-2, SDTV (although it's EDTV rather, because the actual files are in 480p format, I mean, they aren't interlaced):
ffmpeg -i (input) -vf "scale=720:540:force_original_aspect_ratio=decreas e:flags=bilinear,pad=720:540:-1:-1,scale=720:480:flags=bilinear,pad=720:480:0:-1,crop=704:480:8:0,pad=720:480:-1:0,scale=544:480:flags=bilinear,crop=528:480:8:0, pad=544:480:-1:0" -r 29.97 -c:v mpeg2video -pix_fmt yuv420p -b:v 2127.6444k -minrate 0 -maxrate 2659.5555k -qmin 2 -qmax 31 -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -c:a ac3 -b:a 256k -ar 48000 (output in .ts)
Full D1 (720-width, NTSC), MPEG-2, SDTV (although it's EDTV rather, because the actual files are in 480p format, I mean, they aren't interlaced):
ffmpeg -i (input) -vf "scale=720:540:force_original_aspect_ratio=decreas e:flags=bilinear,pad=720:540:-1:-1,scale=720:480:flags=bilinear,pad=720:480:0:-1,crop=704:480:8:0,pad=720:480:-1:0" -r 29.97 -c:v mpeg2video -pix_fmt yuv420p -b:v 2816k -minrate 0 -maxrate 3520k -qmin 2 -qmax 31 -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -c:a ac3 -b:a 256k -ar 48000 (output in .ts)
3/4 D1 (544-width, NTSC), MPEG-2, SDTV (although it's EDTV rather, because the actual files are in 480p format, I mean, they aren't interlaced), suited for 4:3 TVs:
ffmpeg -i (input) -vf "scale=720:540:force_original_aspect_ratio=decreas e:flags=bilinear,pad=720:540:-1:-1,scale=720:480:flags=bilinear,pad=720:480:0:-1,crop=704:480:8:0,pad=720:480:-1:0,scale=544:480:flags=bilinear,crop=528:480:8:0, pad=544:480:-1:0" -r 29.97 -c:v mpeg2video -aspect 4:3 -pix_fmt yuv420p -b:v 2127.6444k -minrate 0 -maxrate 2659.5555k -qmin 2 -qmax 31 -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -c:a ac3 -b:a 256k -ar 48000 (output in .ts)
Full D1 (720-width, NTSC), MPEG-2, SDTV (although it's EDTV rather, because the actual files are in 480p format, I mean, they aren't interlaced), suited for 4:3 TVs:
ffmpeg -i (input) -vf "scale=720:540:force_original_aspect_ratio=decreas e:flags=bilinear,pad=720:540:-1:-1,scale=720:480:flags=bilinear,pad=720:480:0:-1,crop=704:480:8:0,pad=720:480:-1:0" -r 29.97 -c:v mpeg2video -aspect 4:3 -pix_fmt yuv420p -b:v 2816k -minrate 0 -maxrate 3520k -qmin 2 -qmax 31 -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -c:a ac3 -b:a 256k -ar 48000 (output in .ts)

One of the threads published in the forum tells me about the actual LaserDisc resolution and the 544-width situation, as well as the DVB situation, especially in Europe and other countries that use the PAL (Phase Alternating by Line) standard:

[...]
The Officially Laserdisc resolution is 528 X 576/480, but many titles in US, after 1990, are using the 544 X 480 resolution.
The DVB transmissions became mainstream in Europe in 1996 and today are mainstream in US too. The last five years, the European Union (E.U.), force all television and radio providers of E.U. Members, to turn their services digital, for various reasons. So, except Germany and partly France (which the interest for analogue satellite TV still is huge), anything today is digital, on most cases not with the best possible results...
Technically speaking, DVB is based on mpeg 2 (like DVD) and support resolutions from full CCIR - 601 (top quality) to CIF (lowest quality). Almost any resolution between those limits can be a DVB picture resolution, with any bitrate up to 15000Kb/s. The correct output picture aspect is succeeded (if needed), by the use of the pan and scan method, which take place between the Digital/Analogue conversion, before the final picture signal goes to our TV/Videoprojector.
[...]
Some DVB examples:
The Holland channels Canal+ Rood and Canal+Blauw (Astra 1G - 19.2 East), are transmitting in full CCIR 601 resolution with VBR bitrate up to 15000kb/s (!). That is BETTER a standard DVD video.
TMF for Belgium and MTV Italy, both on Eutelsat W2 (16 East) are transmitting in full D1 resolution and bitrates up to 7500kb/s
The MTV/VH1 Channels on Astra 1G, are using 544 X 576.
Viva TV on Astra 1G and Onyx TV on Hotbird 3, are using 480 X 576.
352 X 576 is very common at almost all the Italian Free To Air music channels on Hotbird satellite series.
An example of very low picture resolution, is the Cnes channel (Hotbird 5, 13 east, Freq: 12558, S.R. 27500, F.E.C. 3/4). This channel transmits 352 X 288 with CBR bitrate up to?. 700kb/s!!!).

The known DVB resolutions till today in Europe are: 720 X 576, 704 X 576, 544 X 576, 528 X 576, 480 X 576, 352 X 576 and 352 X 288.
[...]

Apart, if such TV providers used 544x480/576 during the 90s, then it could be true that such quality loss wasn't really noticeable on most CRT TVs.

Back to the experiment, I also decided to take a snapshot of the files (those that start with "IMG_4245-ldish...") and upscale them to 832x624px, in order to compare their quality.

[Attachment 92622 - Click to enlarge]
I also did so with the other two .ts files, and here are the results, separated in figures:

[Attachment 92623 - Click to enlarge]
Figure a: master-544-vs-720-ldish-express.ts at duration 0:02.30
Figure b: master-544-vs-720-ldish.ts at duration 0:02.30
Figure c: master-544-vs-720-ldish-express.ts at duration 0:32.30
Figure d: master-544-vs-720-ldish.ts at duration 0:32.30
Note: these 2 .ts videos are actually well suited for 4:3 TVs via the -aspect 4:3 flag in FFmpeg. The second image's samples are also upscaled.

I'll thank you very much for your answer(s), and if you find one or some mistake(s), I gladly welcome your corrections.

[noemi7]

It's true for Europe, I mean the broadcasts were even 352x576i, albeit main channels were 720x576. At the beginning of the 2000s, MPEG2 was replaced by AVC on DVB-S and later HEVC on DVB-T. However, there are countries which selected 1280x720p AVC with high bitrate for their public TV on DVB-S. Unfortunately there is a tendency to lower DAB audio bitrate which is sufficient for speech but not for music.

[lollo]

In Europe (Italy/France/Germany, I do not know for UK) SDTV mpeg2 transport streams were broadcasted generally at 720x576, 528x576 and 480x576.

The difference in term of quality depends more on the bitrate used than the resolution.

For instance a 720x576 at 7mbps is better than a 480x576 at 4.7mbps.
But a 720x576 at low bitrate, i.e. 3 mbps, is lower quality than 480x576 at 4.7mbps, because macroblocks and mosquito noise increase.
And often the PayTV providers tended to reduce the bandwith of the channels to allocate more of them in a transpoder and save money.

The quality of the mpeg2 encoders used in the 90s and later were good enough, although they started to degrade later, I suspect again for economic reasons.

I have many many dumps of the broadcasted streams across various decades, if you wish some sample just let me know.

[Cedr00m4kv1x]

Since then, effectively pay-TV providers have to squish down the width of the picture and its bitrate, no matter whether is in NTSC (480) or PAL (576).
Many thanks to you for telling me the PAL (Europe) situation of the resolution squish.
If we’re talking about NTSC, especially DISH Network, we have the following, published by an A/V engineer in VideoHelp:

Does anyone know FOR CERTAIN what the maximum Dish Network horizontal resolution is? I have heard it is 480 but I have also heard it is higher for movies and sports.

Anyone know without question?

Thanks

Dish uses 480x480. I took me months to get to the high end tech people at dish to get that info.

Also, if what you’re talking about:

[…]
The difference in term of quality depends more on the bitrate used than the resolution.

For instance a 720x576 at 7mbps is better than a 480x576 at 4.7mbps.
But a 720x576 at low bitrate, i.e. 3 mbps, is lower quality than 480x576 at 4.7mbps, because macroblocks and mosquito noise increase.
[…]

…is in the NTSC plane, according to math (I guess), bitrate would be likely this way:
IN TERMS OF QUALITY:
720 x 480 @ 5.8333MB/s > 480 x 480 @ 3.9166MB/s
Bandwidth saving mode, ideal for DVB-S broadcasts back then
720 x 480 @ 2.5MB/s < 480 x 480 @ 3.9166MB/s
In order to demonstrate what we’re talking about regarding such video and bitrate modes, I, again, decided to encode more samples with FFmpeg, by following these commands:

480 x 576 (PAL), good quality, suitable for 4:3 TVs
ffmpeg -i "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program--HD.ts" -ss 0:30 -to 0:45 -vf scale=768:576:force_original_aspect_ratio=decrease :flags=bilinear,pad=768:576:-1:-1,scale=720:576:flags=bilinear,scale=480:576:flags =bilinear,crop=464:576:8:0,pad=480:576:-1:0,scale=out_color_matrix=bt470bg,minterpolate=fp s=50:mi_mode=dup,interlace -r 25 -c:v mpeg2video -pix_fmt yuv420p -aspect 4:3 -b:v 4.7M -minrate 0 -maxrate 6.2666M -qmin 2 -qmax 31 -flags +ilme+ildct -c:a mp2 -b:a 192k -ar 48000 "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program-pal-ldish-express.ts"

Full D1 (PAL), very good quality, suitable for 4:3 TVs
ffmpeg -i "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program--HD.ts" -ss 0:30 -to 0:45 -vf scale=768:576:force_original_aspect_ratio=decrease :flags=bilinear,pad=768:576:-1:-1,scale=720:576:flags=bilinear,crop=704:576:8:0,pa d=720:576:-1:0,scale=out_color_matrix=bt470bg,minterpolate=fp s=50:mi_mode=dup,interlace -r 25 -c:v mpeg2video -pix_fmt yuv420p -aspect 4:3 -b:v 7M -minrate 0 -maxrate 9.3333M -qmin 2 -qmax 31 -flags +ilme+ildct -c:a mp2 -b:a 192k -ar 48000 "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program-pal-ldish.ts"

Full D1 (PAL), lightweight, suitable for 4:3 TVs
ffmpeg -i "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program--HD.ts" -ss 0:30 -to 0:45 -vf scale=768:576:force_original_aspect_ratio=decrease :flags=bilinear,pad=768:576:-1:-1,scale=720:576:flags=bilinear,crop=704:576:8:0,pa d=720:576:-1:0,scale=out_color_matrix=bt470bg,minterpolate=fp s=50:mi_mode=dup,interlace -r 25 -c:v mpeg2video -pix_fmt yuv420p -aspect 4:3 -b:v 3M -minrate 0 -maxrate 4M -qmin 2 -qmax 31 -flags +ilme+ildct -c:a mp2 -b:a 192k -ar 48000 "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program-pal-ldish-lightweight.ts"

480 x 480, good quality, suitable for 4:3 TVs
ffmpeg -i "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program--HD.ts" -ss 0:30 -to 0:45 -vf scale=720:540:force_original_aspect_ratio=decrease :flags=bilinear,pad=720:540:-1:-1,scale=720:480:flags=bilinear,scale=480:480:flags =bilinear,crop=464:480:8:0,pad=480:480:-1:0,scale=out_color_matrix=smpte170m,minterpolate= fps=59.94:mi_mode=dup,interlace -r 29.97 -c:v mpeg2video -pix_fmt yuv420p -aspect 4:3 -b:v 3.9166M -minrate 0 -maxrate 5.2221M -qmin 2 -qmax 31 -flags +ilme+ildct -c:a mp2 -b:a 192k -ar 48000 "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program-ntsc-ldish-express.ts"

Full D1 (NTSC), very good quality, suitable for 4:3 TVs
ffmpeg -i "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program--HD.ts" -ss 0:30 -to 0:45 -vf scale=720:540:force_original_aspect_ratio=decrease :flags=bilinear,pad=720:540:-1:-1,scale=720:480:flags=bilinear,crop=704:480:8:0,pa d=720:480:-1:0,scale=out_color_matrix=smpte170m,minterpolate= fps=59.94:mi_mode=dup,interlace -r 29.97 -c:v mpeg2video -pix_fmt yuv420p -aspect 4:3 -b:v 5.8333M -minrate 0 -maxrate 7.7777M -qmin 2 -qmax 31 -flags +ilme+ildct -c:a mp2 -b:a 192k -ar 48000 "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program-ntsc-ldish.ts"

Full D1 (NTSC), lightweight, suitable for 4:3 TVs
ffmpeg -i "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program--HD.ts" -ss 0:30 -to 0:45 -vf scale=720:540:force_original_aspect_ratio=decrease :flags=bilinear,pad=720:540:-1:-1,scale=720:480:flags=bilinear,crop=704:480:8:0,pa d=720:480:-1:0,scale=out_color_matrix=smpte170m,minterpolate= fps=59.94:mi_mode=dup,interlace -r 29.97 -c:v mpeg2video -pix_fmt yuv420p -aspect 4:3 -b:v 2.5M -minrate 0 -maxrate 3.3333M -qmin 2 -qmax 31 -flags +ilme+ildct -c:a mp2 -b:a 192k -ar 48000 "hd_dvr_0xF46F6F64-0x23-0xEE_Untitled_DVR_Program-ntsc-ldish-lightweight.ts"

Note: If you want to replicate this formula with your own media, please replace the current input file with yours.

Apart, when talking about HDTV, the document (EBU Technology & Innovation, 2008) cites the following video modes:
720p/50 (also suitable for live TV)
1080p/25 (also suitable for live TV)
1080i/25 fields
1080p/50 (3rd gen HDTV)


Bibliography
EBU Technology & Innovation. (2008). Current Status of High Definition Television Delivery Technology. (EBU-TECH 3328). https://tech.ebu.ch/docs/tech/tech3328.pdf

[lollo]

I am not sure about what you wish to demonstrate. A software like ffmpeg is offline compared to the real-time encoders used by broadcast "hardware". And you applied it on I do not know what.

The only way to compare is to have exactely the same program broadcasted in two different resolution, and bitrate; this last being more difficult to find, as you probably know inside the transponders a dynamic bandwidth allocation is used.

Here just one example:

480x576 chst_1_cut_00.mpg
528x576 chst_2_cut_00.mpg

When you compare, do not just focus on fixed images, but also on running fast movement scenes

[Cedr00m4kv1x]

Well, what I want to demonstrate here is when it comes to quality of downsampled (e.g. 528x480 in NTSC) vs FullD1 videos (720x480 in NTSC) that are encoded in MPEG-2 format.
Have you ever noticed any quality loss in the 90s because of digital video resolution downsampling, on CRT TVs when watching a TV channel from satellite / cable / digital TDT means? Precisely, this is what I want to evidence, as well as the overall quality/size (bandwidth) used, between lightweight FullD1 and subsampled videos at higher bitrates
Thank you for the specimens you gave me!!! Talking about that, unfortunately, my naked eye doesn’t appreciate too much difference. However, when I zoom in both samples, it turns out the S.A.R. values between them are different: the first clip has wider (more stretched) pixels than the second one. In terms of overall, such difference, to me, is specially noticeable on A/V resources that are digital-first (I mean, videos taken with an iPad or an iPhone camera, for example, converted into SDTV formats directly through FFmpeg, rather than CVBS capture tools).
Subsampled to 480-width, PAL

[Attachment 92645 - Click to enlarge]
Subsampled to 528-width, PAL

[Attachment 92647 - Click to enlarge]
With my samples, however, because they are digital-first, such different is more notorious (well, not too much), which likely means, quality is also lost if bitrate isn’t managed properly. It could introduce more noise than analog-based samples, which, if true, leads to detail loss. And it’s not just for PAL at MPEG-2
Subsampled to 480-width, PAL

[Attachment 92648 - Click to enlarge]

Subsampled to 528-width, PAL

[Attachment 92649 - Click to enlarge]


If we applied this to DISH Network(R)‘S broadcasting discipline during late 90s, for example, then, I think, if LCD TVs were used massively in the late 90s, then DISH(R) customers would’ve seen such an embarrassing quality loss because of the width squeeze compared to high-quality DVDs.

Whether this thread is dedicated to talking solely about SDTV or not, how can we apply this to satellite HDTV (like DishHD in DISH Network) during early 2000s, e.g. 1440x1080 @ 16:9, just to fill an 1920x1080 screen?
EBU Technology & Innovation (2008), through its document talking about the HDTV situation in Europe, I learned about the following pieces of data:

VIDEO MODES
1280x720p/50 (also suitable for live TV)
1920x1080p/25 (also suitable for live TV)
1920x1080i/25 fields
1920x1080p/50 (3rd gen HDTV)
1440x1080i/25 fields
960x720p/50
1280x1080i/25 fields
960x1080i/25 fields
Italic = Subsampled
BITRATE
World Cup 2006: 10.5MBit/s (TF1) / 19MBit/s (German TV provider “Premiere”) / 20MBit/s (BBC/SVT)
DRAWBACKS
A/V delay: Audio goes ahead of the video because of processing
SECURITY: GEOLOCATION TYPES
Physical: The coverage beam is arranged so that only viewers in a given area may watch the broadcast, e.g. FTA channels that can only be watched in the UK or in the U.S.A.
Electronic / signal scrambling: Availability exclusive to devices that support smart cards and have a particular smart card, e.g. DISH Network(R) boxes

On a trip with my family in the State of Mexico (near Michoacán), I came up with a clever idea: why not record something with my iPad and convert it into MPEG-2 .ts @ 1080p, albeit the lack of “interlace” filter support in FFmpeg on my iPad?

I’ll thank you very much for another answer regarding this kind of situations.

Bibliography
EBU Technology & Innovation. (2008). Current Status of High Definition Television Delivery Technology. (EBU-TECH 3328). https://tech.ebu.ch/docs/tech/tech3328.pdf

Note (a piece of advice): You should click on the pictures to see them in 1:1 quality. Please note the sample pictures are upscaled to 832x624. Please message me if you find some mistake(s), either in the forum or in the pictures, or both.

[lollo]

Well, what I want to demonstrate here is when it comes to quality of downsampled (e.g. 528x480 in NTSC) vs FullD1 videos (720x480 in NTSC) that are encoded in MPEG-2 format.

What is the scope of downsampling at this stage? The starting point is the master of the program used by the TV channels, which can be digital (which is generally a D1 resized by the encoder) or analog (which can be telecined and sized at any resolution).
In the sample I provided, the master was a digital betacam, resized by the encoder to 480x576 for a first transmission and to 528 for a few years later broadcast.

Have you ever noticed any quality loss in the 90s because of digital video resolution downsampling, on CRT TVs when watching a TV channel from satellite / cable / digital TDT means?

For sure not in real time, and probably not even now comparing the streams.

Precisely, this is what I want to evidence, as well as the overall quality/size (bandwidth) used, between lightweight FullD1 and subsampled videos at higher bitrates.

Sure, but once more for that you need a dump of the original streams, do some experiment today with ffmpeg does not entirely convince me.

Thank you for the specimens you gave me!!! Talking about that, unfortunately, my naked eye doesn’t appreciate too much difference.

Yes, see above. Unfortunately I do not have a 720x576 stream of the same program.

However, when I zoom in both samples, it turns out the S.A.R. values between them are different: the first clip has wider (more stretched) pixels than the second one.

If for SAR you mean Storage Aspect Ration, they are different by nature, the horizontal resolution of one being 480 and the other 528. The DAR (Display Aspect Ratio) of 4:3 will tell to the Player/TV to "stretch" the 480 or the 528 points in the lines to 768 final resolution (because 576 * 4 / 3 = 768).
It is expected the 528 video to look sligthly better then, but is very marginal, and in practice there are no/little difference. (Also remember that all this is true if the original file contains all that information of distinguishable points inside a line, before digitizing it or before downsampling it; not always the case)

In terms of overall, such difference, to me, is specially noticeable on A/V resources that are digital-first (I mean, videos taken with an iPad or an iPhone camera, for example, converted into SDTV formats directly through FFmpeg, rather than CVBS capture tools).

I see. In any case I and not a fan of a re-encode or resize of a digital media (it's always a loss of quality). What the TV channel did/do is out of our control

With my samples, however, because they are digital-first, such different is more notorious (well, not too much), which likely means, quality is also lost if bitrate isn’t managed properly. It could introduce more noise than analog-based samples, which, if true, leads to detail loss. And it’s not just for PAL at MPEG-2

Yes, as we said the bitrate play a major role, somehow even more important than resolution, especially for the old mpeg2 codec, introducing defects when configured at low bitrates.
I remember the first pioneering times of the digital satellite broadcast when for some of the channels we missed the (better) analog counterpart. For the "serious" channels (full D1 at high bitrate), the advantage compared to analog satellite signal was very evident.

[Cedr00m4kv1x]

Well. S.A.R., under this context, is the Sampling Aspect Ratio (a.k.a. Pixel Aspect Ratio)
Oh, I’ve forgotten to encode the digital-first FullD1 PAL sample. Obviously, with the equivalent bitrates, it offers better picture quality, but the file becomes slightly bigger than the previous ones. Here you have the file.

[Attachment 92656 - Click to enlarge]
If you’re curious about where I recorded such PAL samples (video files that start with sample289C7921A83D-pal…), I did so near the Tlalpan center in Mexico City circa July 2025)

Now, imagine there’s a TV provider that operates in a country that employs PAL. If we did broadcast these files (start with sample289C7921A83D-pal…) to the satellite, then,… Hold on! Before that, we should think twice: let’s suppose the files’ size represent satellite bandwidth. In this case, albeit how much time the video lasts, we may think of the video size as a mathematical factor:
The FullD1 video is 1x the size.
The 528-width one, at its equivalent bitrate to the FullD1 one, is approx. 1.3x lighter than the D1 one.
The 480-width one, at its equivalent bitrate to the FullD1 one, is approx. 1.5x lighter than the D1 one.
I’m sure you’ll ask for the source of such info. The following image explains why those mathematical values. Please focus on the file sizes; here’s the reason.

[Attachment 92658 - Click to enlarge]
If those values were true, then if we suppose a satellite lets you store up to 16 channels in a single transponder and those are in FullD1 at 1x bitrate (1:1 quality from the sample), then that satellite lets you store up to 16 channels.
If we squeeze each channel’s video to 528-px in terms of width, given all these channels are broadcast in 528x576 (in this case), in a satellite transponder that theorically lets you store max 16 channels, then supposedly you can air up to 20 or 21 channels in the same transponder.
If we squeeze each channel’s video to 480-px in terms of width, given all these channels are broadcast in 480x576 (in this case), in a satellite transponder that theorically lets you store max 16 channels, then supposedly you can air up to 24 channels in the same transponder.
Note: that piece of info may be inaccurate; it may depend on your bitrate settings, the video content itself, and other factors that make the comparison really subjective. This info may be fictional, unless it agrees with reality.
So, back then, during the first steps of satellite TV, such TV providers, effectively, had to subsample the video in order to store more channels in a single transponder.
So yes, that was the pro, but you bet on storage by sacrificing quality: the drawback of it was (and is, if true nowadays) the slight (or notable) quality loss! Wasn’t it?