HD DTT Licences awarded

Java Jive wrote:
Mark investigated this a few weeks ago, and IIRC found a great deal of
uncertainty as to whether this is actually true, but I'll leave it to
him to clarify further.

As far as my own LCDs are concerned, I do not believe they are
converting interlaced to progressive:
http://tinyurl.com/6mf87k
... standing in for ...
http://s28.photobucket.com/albums/c2...DInterlace.png


While an interesting photo, it doesn't show if the LCD is being updated
in a progressive or interlaced way. As in, is the screen being
completely refreshed at 50Hz (or whatever) or is it having the odd &
even lines independently altered (without the other field having to be
renewed).

I wouldn't expect the lines to be smooth, as the picture is being
transmitted in an interleaved format - so the odd field is slightly time
shifted to the even field. The only way around this isso called
"progressive segmented frames", but I don't know if it is actually used
in real life.

"J G Miller" wrote in message ...
On Mon, 20 Oct 2008 18:54:39 +0100, Stuart Clark wrote:

1080p would be best, but uses far too much bandwidth to be feasible
at the current time.

Which begs the question, how are they ever going to broadcast Super
HiVision (7680x4320) developed by NHK? ;+)





because that wont be for decades - just think what our data tranmission
methods could do in the 70s compared to now.



--
Gareth.

that fly...... is your magic wand....

On Mon, 20 Oct 2008 21:49:26 +0100, Stuart Clark
wrote:

Java Jive wrote:
Mark investigated this a few weeks ago, and IIRC found a great deal of
uncertainty as to whether this is actually true, but I'll leave it to
him to clarify further.

As far as my own LCDs are concerned, I do not believe they are
converting interlaced to progressive:
http://tinyurl.com/6mf87k
... standing in for ...
http://s28.photobucket.com/albums/c2...DInterlace.png


While an interesting photo, it doesn't show if the LCD is being updated
in a progressive or interlaced way. As in, is the screen being
completely refreshed at 50Hz (or whatever) or is it having the odd &
even lines independently altered (without the other field having to be
renewed).

My only doubts about the picture are the actual interlacing effects
themselves, which are slight - I would have preferred something more
unarguably pronounced - but if you accept, as I do, that's what they
are, then there is little room for doubt about the interpretation.

The *simplest* explanation of the photo, which is the one that should
be accepted until and unless better evidence comes to light, is that
the screen is being refreshed in an interleaved manner exactly
reproducing the source signal. Any other explanation introduces
complexity unnecessary to explain the picture (and presumably would
also require unnecessary manufacturing cost to achieve).

I wouldn't expect the lines to be smooth, as the picture is being
transmitted in an interleaved format - so the odd field is slightly time
shifted to the even field.

No. Individual frames from a stream changing at 25Hz are each split
into two fields which are sent over successive 50Hz cycles. Of course
individual frames are taken at different times and therefore may well
show movement between them, but pairs of fields are from the same
frame, and therefore are not and should not - they should make a
self-consistent 'still' when reassembled through de-interlacing.

Therefore, if the LCD is de-interlacing, the result of taking a photo
at, IIRC, 1/100s should always be a single picture, not a mixture of
two. Or, at worst case if the LCD takes a significant amount of time
compared with the exposure to propagate the following frame, and I'd
happened to catch in the act, possibly a step change somewhere in the
middle of it. If you accept that the picture shows interlacing
effects, then by far and away the simplest and most obvious
explanation is that the source is not being de-interlaced by the LCD.

Java Jive wrote:

The *simplest* explanation of the photo, which is the one that should
be accepted until and unless better evidence comes to light, is that
the screen is being refreshed in an interleaved manner exactly
reproducing the source signal. Any other explanation introduces
complexity unnecessary to explain the picture (and presumably would
also require unnecessary manufacturing cost to achieve).


I'd actually have suggested the opposite!

To save cost I'd be using a standard LCD panel and controller (eg. as
used by the computer monitor industry) which would be updating in a
progressive manner (whole screen at once).

To allow the interlaced signal to be displayed I'd just need a bank of
memory which is copied to the LCD at 50Hz. The input signal then updates
alternate rows of the memory block, causing a basic de-interlace effect.

In reality you can do more (eg. interpolation) and might also need to do
scaling anyway.

I wouldn't expect the lines to be smooth, as the picture is being
transmitted in an interleaved format - so the odd field is slightly time
shifted to the even field.

No. Individual frames from a stream changing at 25Hz are each split
into two fields which are sent over successive 50Hz cycles. Of course
individual frames are taken at different times and therefore may well
show movement between them, but pairs of fields are from the same
frame, and therefore are not and should not - they should make a
self-consistent 'still' when reassembled through de-interlacing.


As far as I'm aware that isn't the normal way for interlacing to be
used. Progressive Segmented Frames (eg. 1080PsF) would work as you
suggested, but I don't believe that is commonly used. Instead the two
fields are very slightly displaced in time. Indeed in a purely analogue
system the top left of the frame would be earlier in time to the bottom
right of the frame (ie. it isn't a snapshot, but a progression over time).

The advantage of PSF is the "perfect" de-interlacing result, but it
comes as the cost of a lower frame rate - for a 50Hz interlaced signal
the input is a 50Hz signal, while for a PSF 50Hz signal the input signal
is only 25Hz.

Therefore, if the LCD is de-interlacing, the result of taking a photo
at, IIRC, 1/100s should always be a single picture, not a mixture of
two. Or, at worst case if the LCD takes a significant amount of time
compared with the exposure to propagate the following frame, and I'd
happened to catch in the act, possibly a step change somewhere in the
middle of it. If you accept that the picture shows interlacing
effects, then by far and away the simplest and most obvious
explanation is that the source is not being de-interlaced by the LCD.

Brian McIlwrath wrote:
wrote:
:
: 720p has been shown to give better picture quality. 720p is much
: better for sport where fast moving objects are in the picture.
:
: 1080i and 720p uses about same bandwidth. the 'i' format is
: a 'left-over' from the analogue systems.

Pardon? Where is your reference for 720p giving "better quality"????


See
http://www.ebu.ch/CMSimages/en/tec_t...tcm6-60599.pdf (page 4):

"Interlaced image format (1080i/25) requires about 20% more bit-rate
than the progressive image format (720p/50) to obtain the same
subjective image quality."

So for the same bitrate you should expect the 720p to be higher
subjective quality than 1080i.

Stuart Clark wrote:
Brian McIlwrath wrote:

Pardon? Where is your reference for 720p giving "better quality"????


See
http://www.ebu.ch/CMSimages/en/tec_t...tcm6-60599.pdf (page 4):

"Interlaced image format (1080i/25) requires about 20% more bit-rate
than the progressive image format (720p/50) to obtain the same
subjective image quality."

So for the same bitrate you should expect the 720p to be higher
subjective quality than 1080i.

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 ?

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

On Tue, 21 Oct 2008 18:23:56 +0100, Stuart Clark
wrote:

Java Jive wrote:

The *simplest* explanation of the photo, which is the one that should
be accepted until and unless better evidence comes to light, is that
the screen is being refreshed in an interleaved manner exactly
reproducing the source signal. Any other explanation introduces
complexity unnecessary to explain the picture (and presumably would
also require unnecessary manufacturing cost to achieve).

I'd actually have suggested the opposite!

To save cost I'd be using a standard LCD panel and controller (eg. as
used by the computer monitor industry) which would be updating in a
progressive manner (whole screen at once).

To allow the interlaced signal to be displayed I'd just need a bank of
memory which is copied to the LCD at 50Hz. The input signal then updates
alternate rows of the memory block, causing a basic de-interlace effect.

Well, no! Exactly the opposite! If that is really how it's done, and
I can certainly see a logic for doing it that way, it's not
de-interlacing the signal at all! The picture is still being
displayed field by field, almost as a CRT would display it - the
only difference being that the CRT's scanning action changes each
'pixel' - if I may be allowed some looseness of speaking for
convenience's sake - progressively along and down each field as the
signal is being received, while the LCD memorises the signal until
each new field has been completely received and then displays it all
in one go. Whether each cycle it re-displays the entire picture or
just the new field wouldn't really matter with an LCD, as the previous
field would not have changed, so it would be almost impossible for the
user, or even my camera, to differentiate between these two
possibilities.

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

I'm aware that you're not alone in this belief: Wikipedia, for
example states without any supporting evidence ...
http://en.wikipedia.org/wiki/Interlacing

1) That LCDs have problems with interlaced signals

"Interlacing causes problems on certain display devices such as
LCDs[1]" (BUT the linked reference makes no mention of this! It's
entirely about the advantages of progressive over interlaced scan).

2) That they deinterlace them

"Only CRTs can display interlaced video directly – other display
technologies require some form of deinterlacing."

.... whereas you have described very well above a method for LCDs to
display interlaced video! And Mark also found that things were rather
less well defined when he investigated (post 19) ...
http://tinyurl.com/6bv6qt
.... standing in for ...
http://groups.google.com/group/uk.te...74e160d6 f42f

I am beginning to think that this just another of these technological
old-wives' tales regarding LCDs ...

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

What nonsense!

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

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