[opendtv] Re: MPEG2 system clock recovery

Most PC software decoders synchronize playout to the audio clock (which
can be phase locked to a regenerated broadcast clock for push mode, or
run off the system clock for pull mode).

The audio frame rate of 48ks/s is much more demanding than video frame
rates (24, 25, 30, 50 60), so video slaves to audio.  Considering that
normal video display processing results in judder/jitter of 48ms to 32ms
=3D 18ms because of 3:2 pulldown, a few 48kHz audio frames more or less
duration of a video frame vs. 27MHz or 90kHz A/V alignment is small
potatoes.

PCs also typically have decoupled refresh where 24 decoded frames of
film source content might get sampled and "refreshed" at 72Hz (or 60,
75, 90, 100, 120, etc.).  That results in occasionally repeating a frame
two or four times, instead of the average of three (72Hz case, for
example).  Gen lock will only be built in to a new PC operating system,
which shall remain nameless. =20

That's the way it was when CRTs roamed the earth and the image processor
was in the video source.  In the modern world, the image processor is in
the progressive display (LCD, DLP, PDP, LCOS, etc.), and will accept a
signal over HDMI at some frequency both source and display negotiate,
then do something totally different with the input signal, like extract
P24 from the i30 input signal and "refresh" it at 60 or 72 or 120Hz,
depending on the display technology.  PCs aren't drawing rasters
anymore, and neither are most other HD displays, so image updating is
handled on the other end of the wire.

Kilroy Hughes


-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx]
On Behalf Of Ron Economos
Sent: Saturday, June 24, 2006 07:38
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: MPEG2 system clock recovery

If the bitstream is being "pushed" over some channel
(the situation for OTA ATSC, satellite and cable),
you must recover the PCR clock if you want the decoder
to run properly 24/7. Otherwise you are guaranteed
to experience underflows or overflows with the elementary
streams after a period of time determined by the clock error.
This leads to stuttering video and audio dropouts.

I don't know of any decoder manufacturer that doesn't do
PCR recovery. It's fundamental to any (MPEG-2, VC-1,
H.264) decoder system. For IPTV (or any network delivered
stream), you have to de-jitter the PCR somehow. This can
be accomplished with higher layer network packet timestamps.

You can find very inexpensive VCXO chips tailored for this
application. For example:

http://www.icst.com/pdf/mk3720.pdf

http://www.pericom.com/pdf/datasheets/PI6CX100-27.pdf

As for PC's as decoders, I'll make an inverse Will Rogers
comment. I've never met one that I liked (or thought worked
properly).

Ron

Steve Wilson wrote:

>The MPEG2 system spec 13818-1 (H.222), Appendix D, describes a process=20
>whereby the decoder time clock get synchronized with the encoder time=20
>clock.  This is done by comparing SCR values in the transport stream=20
>with the decoders local clock and taking appropriate action.  There
were=20
>many papers written on various ways to do this quite a few years ago.
>I am told some (hardware) decoder implementations don't do this=20
>anymore.   I was wondering if anyone could shed some light on this? =20
>Presumably the PTS time stamps provide enough information to accurately

>decode and present the content....isn't this all PC decoders use?   Are

>modern day STB designs foregoing this "SCR clock sync" at the input to=20
>the decoder?   Is there any resulting inaccuracy in the output?  Maybe=20
>the when the spec was put in place, system designers thought it was=20
>needed.  Then as technology and people got better/smarter, we figured=20
>out how to eliminate that step?  Anyone have first hand knowledge they=20
>can share?? or comment?
>
>Also, I dont think this step applies in MPEG over IP.....
> =20
>

=20
=20
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org=20

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.

 
 
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 
FreeLists.org 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: