PCBUILD Archives

Personal Computer Hardware discussion List

PCBUILD@LISTSERV.ICORS.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Thomas Holmes <[log in to unmask]>
Reply To:
PCBUILD - Personal Computer Hardware discussion List <[log in to unmask]>
Date:
Thu, 28 Oct 1999 12:31:02 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (57 lines)
In a message dated 10/27/99 9:36:01 PM Central Daylight Time,
[log in to unmask] writes:

> Hello Shakeel,
>
>  Sunday, October 24, 1999, 11:41:31 AM, you wrote:
>
>> But it was not what i really meant. By "full action" i mean, action
>> scenes:  i.e the running of a man...then you see cristal squares being
displayed
> >in the background on the screen. But whenever the image is focused on
> >someon or something, then it is ok. you 've got clear crystal image. A
close
>> friend of mine has also reported the same problem and unable to know what
>> exactly causes this.
>
>  In the format you view the video, the bit rate (amount of information
>  transferrable per second) is limited. The still scenes are what they
>  are - the picture doesn't change much; may be lip movement and facial
>  expressions, some 10-20% of the screen, and those changes can be
>  described in fine detail (while the not-changed parts are inherited
>  from the previous frame).
>
>  On the other extreme, action scenes have 90-100% of the screen
>  changing from frame to frame, and to keep the bitrate in bounds the
>  picture has to be compressed with image loss, and quite severely. This is
>  what you see - the squares are the result of approximated color
>  described by some arcane math formula, and it is normal.
                                  < snip >

>  | Max Timchenko [MaxVT]


     It is our understanding that this is a manifestation of a characteristic
MPEG-2 coding of the DVD-ROM video.  Source material is coded in a certain
number of frames per second - it seems that we recall that number to be 30.
Each frame is displayed separately, but in so rapid a sequence as to appear
to the eye to be a reproduction of the visual perception of actual motion.
Each frame is subdivided into a number of subsections.  The data stream from
the MPEG-2 coded source attempts to communicate only changes in any one of
these subsections from the prior screen to the current screen.   This results
in a significant reduction of the amount of data that must be transferred to
support the current frame.  When the frames are displaying full action, this
suggests that there is a large amount of change in each subsection of the
current frame and consequently, a large amount of data needed to communicate
all the changes.  The mismatch in time between that needed to decode and
communicate all the data and that time allotted for the display of the next
frame leads to the unsatisfactory rendering of the image on your screen.
     That is the way we understand the process.
Tommy Holmes, Jr.
[log in to unmask]

         The PCBUILD web site always needs good submissions.  If
          you would like to contribute to the website, send any
               hardware tech tips or hardware reviews to:
                           [log in to unmask]

ATOM RSS1 RSS2