HD DTT Licences awarded

Stuart Clark wrote:
Mark Carver wrote:

When broadcasters don't have to worry so much about bandwidth (i.e
satellite ) they vote with their feet, and most choose 1080i for tx.
Why is that ?


Because it is the only option if they want to be part of the Sky EPG

I have heard stories that the Thomson Sky HD box will fall over if it's asked
to decode 720p signals, which *might* be a factor. However I was taking about
broadcasters all over Europe, not just the UK trio on Sky's HD platform.

--
Mark
Please replace invalid and invalid with gmx and net to reply.

Java Jive wrote:
On Tue, 21 Oct 2008 20:47:57 +0100, Mark Carver
wrote:
We've come full circle. I still believe that UK DTT HD broadcasts will be at
720p because that requires less bandwidth than the delivery of 'equivalent
quality' 1080i pictures, and not because 720p provides better quality pictures
per se. And I do acknowledge the comments about temporal vs spacial
resolution, 'horses for courses', etc etc.

When broadcasters don't have to worry so much about bandwidth (i.e satellite )
they vote with their feet, and most choose 1080i for tx. Why is that ?

You, Stuart, and others may care to read this, which I found while
answering another of Stuart's posts (it turned out to be completely
different in subject matter to what I expected, so I've only skimmed
through some of it, but it seems more relevant in this subthread than
the other)
http://www.vxm.com/Progvsinter.html


Quoting from that article's conclusion:-

"The idea that 1080I has higher resolution than 720P has been shown to be
false. The resolution actually achieved in the interlaced system is far below
the nominal 1080x1920. The reduction in vertical resolution is due to the need
to lessen the interline flicker that would otherwise be present. "

End Quote.

In this brave new world of LCD and Plasma displays, where are we with the
consideration of interline flicker when dealing with interlaced images ?

--
Mark
Please replace invalid and invalid with gmx and net to reply.

Java Jive wrote:

I would call that buffering, it's certainly NOT de-interlacing.


What would you describe de-interlacing as?

As previously described, combining fields arriving at 50Hz back into
their original frames being displayed at 25Hz. A fundamental aspect
of this process is that no matter how often it is redisplayed,
displayed picture content *changes* at 25Hz, whereas the buffering you
describe *changes* the picture on the completion of each field, at
50Hz.

On Wed, 22 Oct 2008 08:43:32 +0100, Stuart Clark
wrote:

Java Jive wrote:

I would call that buffering, it's certainly NOT de-interlacing.


What would you describe de-interlacing as?

Java Jive wrote:
As previously described, combining fields arriving at 50Hz back into
their original frames being displayed at 25Hz. A fundamental aspect
of this process is that no matter how often it is redisplayed,
displayed picture content *changes* at 25Hz, whereas the buffering you
describe *changes* the picture on the completion of each field, at
50Hz.


As I've mentioned before, the usual situation is that the input signal
is changing at 50Hz so that the two fields don't relate to the exact
same point in time - that is why if you de-interlace a pair of fields
from a single frame you end up with the non-smooth lines, etc in the
case of movement.

Stuart Clark wrote:

As I've mentioned before, the usual situation is that the input signal
is changing at 50Hz so that the two fields don't relate to the exact
same point in time - that is why if you de-interlace a pair of fields
from a single frame you end up with the non-smooth lines, etc in the
case of movement.

Yes. And this system was chosen by Sky just as CRTs were going out of
fashion to be replaced by flat-panels that *had* to deinterlace.

It would have been better to have gone with 25Hz progressive, allowing
clever interpolation to be developed in the future that could smooth out
the movement somewhat while retaining full backwards compatibility. Less
messy than trying to process the "mice teeth" artifacts away.

--
Dave Farrance

On Wed, 22 Oct 2008 18:13:17 +0100, Stuart Clark
wrote:

Java Jive wrote:
As previously described, combining fields arriving at 50Hz back into
their original frames being displayed at 25Hz. A fundamental aspect
of this process is that no matter how often it is redisplayed,
displayed picture content *changes* at 25Hz, whereas the buffering you
describe *changes* the picture on the completion of each field, at
50Hz.


As I've mentioned before, the usual situation is that the input signal
is changing at 50Hz so that the two fields don't relate to the exact
same point in time - that is why if you de-interlace a pair of fields
from a single frame you end up with the non-smooth lines, etc in the
case of movement.

For material that was photographed with 'moving' interlace (originally
I believe most or all TV work, I don't know what the situation is now
with modern digital cameras), there would indeed be little point in
trying to de-interlace it, because it would create a mess.

However, when a progressive source such as some DVDs are interlaced
for broadcasting, it should be possible to reconstitute the original
frames exactly, or at least as exactly as our chronic over-compression
allows, and there might be some point to doing it, but what percentage
of broadcast material would that be?

Why would a TV manufacturer attempt de-interlacing, when it would be
so much simpler, easier, and probably therefore cheaper, to
field-buffer interlaced material and frame buffer progressive
material?

If you want me to believe that LCD TVs attempt to de-interlace
everything that comes their way, then find me some real evidence.