[mythtv-users] High end, state of the art Myth Frontend

[Andre Newman]

On 19 Sep 2013, at 15:13, Joseph Fry <joe at thefrys.com> wrote:

>>>> Within the limits that the ATSC allows, it's true.  Theoretically,
>>>> compressing a 1080p/60 video would use twice the bandwidth of
>>>> compressing a 1080i/60 video at the same level of quality.  In reality
>>>> that's not true because a) file size is not directly related to
>>>> resolution, b) the higher amount of detail would allow a greater
>>>> percentage of compression without a perceptible difference quality.
>>>> 
>>>> But the fact of the matter is, compressing a 1080p/60 signal will
>>>> result in a larger bandwidth file than compressing 1080i/60 to the
>>>> same perceptible quality level.
>> 
>> Incorrect, the EBU have been running a trade roadshow for many years disproving this commonly held belief.
>> 
>> This is not a proper paper from the EBU but I am not permitted to pass on the studies this derives from, it covers the concept quite well I think and the engineers I saw watching this (if they understood what they were watching) left quite amazed. Sadly I was told that most visitors told the EBU they had the labels wrong :-(
>> 
>> http://tech.ebu.ch/docs/techreview/trev_308-hdtv.pdf
>> 
>> This is not a proper paper from the EBU but I am not permitted to pass on the studies this derives from.
>> 
>> From the emission section: referring to the effect of high compression on 1080p50 over 1080i50 and 720p50
>> 
>> "However, at the lower bitrates (i.e. <10...13 Mbit/s) the 1080p/50 encoder becomes more overloaded with information, depending on the content, and this information overload appears to become the dominant factor affecting quality. The impairments with high compression are not as bad as those for 1080i/25 but more visible than 720p/50."
>> 
> 
> Which exactly confirms what I said.  In order to have the same
> perceived image quality, a 1080p signal requires more bandwidth than a
> 1080i stream.

Please read it again: The sentence refers to 1080p50 not being as bad as 1080i at high compression…

"The impairments with high compression [1080p50] are not as bad as those for 1080i/25 but more visible than 720p/50."

I've seen the demo, I've recreated the demo for a client, I can confirm the point being made by the demo.


>  This is contrary to one some people would think as it
> suggests that interlacing, as a means of compression, results in
> higher quality perception than what can be achieved with MPEG encoding
> alone.

Most people including almost all broadcast engineers think that 1080i is half the bits therefore _obviously_ more bits are required after compression for equivalent quality. This was the reason for the roadshow and a view taken very often on this list.

Including yourself it seems earlier in the thread:

> 
> 
>> I understand what your saying, it seems crazy that MPEG2 cannot simply
>> discard the same amount of information as interlacing does and end up
>> with the same or better quality.. but it's true... MPEG 2 cannot,

An important caveat:

>> within ATSC allowed specifications, compress a video as effectively as
>> the combination of interlacing then compression.

However the EBU conducted the same tests with equipment commonly used for ATSC broadcast, the mpeg2 demo I re-created used the same Tandberg encoder.

> 
> 
> 
> It also confirms what I said about the higher amount of detail
> allowing a greater percentage of compression without perceptible
> difference in quality, from the article, sentence before yours (which
> you quote below): "1080p/50 provides more information in the
> spatio-temporal domain and encoders can conduct the compression more
> efficiently."

My point (and the EBU's) exactly.

> 
> Essentially, the article seems to confirm everything I said…

Then I should apologise, and continue this thread with the other Joseph Fry who I see to have mixed you up with ;-)


> but of
> course the MPEG4 used in the EU is different than MPEG2 used here in
> the US.  I suspect that 1080p compressed with the MPEG2 settings
> allowed here would be simply unwatchable.

I re-created the demo with mpeg2 as well as mpeg4 h264, h263 is much the same, I will try h265 when I get the chance.


> 
>> 
>>>> Your starting with double the data,
>> 
>> Which is irrelevant, please see the above techreview doc.
>> 
>> "1080p/50 provides more information in the spatio-temporal domain [than 1080i] and encoders can conduct the compression more efficiently."
>> 
> 
> Yes, the compression is more efficient... but more efficient doesn't
> mean that it can compress a stream to the same bandwidth at the same
> quality.

Yes that's exactly what it means, same quality less bits or better quality same bits whichever you prefer, it's not referring to power consumption or code efficiency.

>  Lets make up some numbers:
> 
> Say I am allowed to broadcast a 10Mbps stream, and I have to choose
> between compressing a 20Mbps 1080i stream, or a 40Mbps 1080p stream...
> I need to achiveve 50% compression on the interlaced and 75%
> compression on the progressive streams and have the resulting stream
> look comparable in quality.  This may not be possible as compressing
> the stream by 75% will introduce too many artifacts, thus the 1080i
> actually looks better because it started with 1/2 the data and thus
> did not need to be compressed as much.

Ok this is meaningless outside of HD-PVRs and home recompressing DVDs, any broadcast 1080i source will be 1.5Gbps or perhaps 50Mbps long gop (e.g. Discovery), 130Mbps or 220Mbps Quicktime ProRes, maybe 28mbps AVCi at the bottom feeder end. Any 1080p50or60 source will be 3Gbps, or course it's not exactly that, I can do the math(s) but it will be delivered down a 3Gbps coax or fiber, perhaps it will also be a 50M long gop or 220M ProRes, note same bitrates.

If you are dealing with KDG in Germany 1.5Gbps uncompressed is the only acceptable source because they would love to be able to use 10Mbps for HD, they are more a 3 to 5Mbps kind of place. They will tell you a lot about compression realities.

> 
> This diminishing return at greater compression can be summed from the
> articles conclusion too: "The 1080p/50 format was rated equal or
> better than 720p/50 for the higher bitrates – the extent depending on
> the test sequence. However, 720p/50 was rated better than 1080p/50 at
> the lower bitrates."
> 
> Essentially, starting with less information resulted in less
> compression artifacts when going to a lower bitrate…

When comparing progressive with progressive, absolutely, no argument there.

Just to stir the pot for fun, 1080p150 or 120 or even 300 with the right encoder _can_ result in less artefacts for a given bitrate than 1080p50...

> and the
> perceived quality is better, the same holds true for 1080i vs 1080p
> compression; there is a level of compression where 1080p starts to
> look worse than 1080i.. and I suspect that the bitrate that happens is
> somewhat higher than what ATSC (US MPEG2 broadcast standard) allows.

Possibly, although I seriously doubt it, I don't have old enough firmware available for any encoders I have access to, to make a test. The reality of the start of ATSC for HD was there was no 1080p60 equipment in existence, the only choices were 1080i or 720p, it's only now that 1080p60/50 is starting to be readily achievable in a broadcast setting that these phenomena are coming to light.

When the equivalent UK service to ATSC (DVBT2 with H264, in time for the Olympics) started, the BBC had just discovered that 1080p50 didn't actually need any more bandwidth than 1080i50 in fact usually less. Unfortunately they were too late to change the STB specification agreed with OfCom, I don't have a reference for this (and Google can't find me one) but I was told this by BBC R&D.

BTW in avoidance of confusion I'll admit thatI'm still using the old designations for 1080 formats, should stop.

1080i25 is 1080i from a source that was 25fps (or 24fps speeded up), easy to de-interlace, usually called PSF.
1080i50 is 1080i from a source that was 50fps, not easy to de-interlace well, usually just called 1080i.

None of this discussion is about 1080i25, that's really easy to de-interlace and compress (well actually there's another thread in this one but not today) and doesn't have much impact on my choice of MythTV Frontend.

The issues are all with 1080i50 which is 1080i where there has been movement between video fields such that clean frames cannot be easily assembled.

Andre