[opendtv] MPEG2 system clock recover

Steve;

Answerer in reverse order:

MPEG-2 over IPTV uses a different mechanism to provide the same result, and the 
PCR timestamps are removed from the elementary streams; too much network jitter.

All services that use audio or video or captioning MUST use the PCR values in 
order to properly render the streams and to sync them together.  This becomes 
clear when you start to parse a transport stream, because the video, audio and 
captioning data isn't sent in the order that they are rendered.

Why is that?  Well, you can't render an interpolated frame until you have in 
memory the preceding and succeeding reference frame, and then you have to 
reorder them according to the timestamps for everything to work out.

There are display time stamps (DTS) and presentation time stamps (PTS).

The underlying time base is 27,000,000 +/- 810 hz (or better).  PCs have come a 
long way, but you're lucky toget a PC to be anywhere close to that accurate 
without a gps device.

Video and audio have different buffer sizes per the spec, so one needs 
timestamps at the receiver to get them in the same sync they were in at the 
studio. (A dirty little secret is that they aren't always synced well at the 
origin point -- there is current work at SMPTE and the EBU to change that for 
the better.)

In the few elementary data streams I have parsed, I have yet to see timestamps. 
 That doesn't mean that somebody, somewhere ... 

I've been waiting for the suitable moment to show the fallacy of Bert's 
arguments from a month or two back that with home networks, nobody needs MPEG-2 
transport and such.  Can't wait until he tries to switch IPTV streams that have 
stripped out the timestamps (or not) and reconstruct them without a 27,000,000 
+/- 810 hz reference, as will happen in homebrew networks.

But then, as with all dilletantes ...

Anyway, your query let me kill two birds with one stone.  Thanks.

John Willkie

------
Steve Wilson [stevenjwilson@xxxxxxxxxxx] wrote

The MPEG2 system spec 13818-1 (H.222), Appendix D, describes a process whereby 
the decoder time clock get synchronized with the encoder time clock.  This is 
done by comparing SCR values in the transport stream with the decoders local 
clock and taking appropriate action.  There were 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 
anymore.   I was wondering if anyone could shed some light on this?  
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 
the decoder?   Is there any resulting inaccuracy in the output?  Maybe 
the when the spec was put in place, system designers thought it was needed.  
Then as technology and people got better/smarter, we figured out how to 
eliminate that step?  Anyone have first hand knowledge they can share?? or 
comment?

Also, I dont think this step applies in MPEG over IP.....
 
 
 
----------------------------------------------------------------------
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: