Development: The DVB Decoder Challenge

From LinuxTVWiki
Revision as of 22:09, 28 September 2004 by Holger (talk | contribs)
Jump to navigation Jump to search

Introduction

When implementing a Hard- or Software MPEG2 Decoder one will encounter several challenges, most of them are not too hard to solve but very DVB-specific and can be quite annoying if not properly handled.

So this page tries to list them, to discuss common approaches and to outline elegant solutions.


The STC sync problem

Whenever a client has to decode a live stream from a server it has to adjust it's own system time clock to the one of the server, for several reasons:

  • Transmitted data is bursty, the decoder has to display content with a little delay. This delay should get minimized, otherwise you always hear your neighbors celebrating the soccer championship goal 3 seconds before you can see it.
  • The server clock may run continously faster or slower than the host clock, so the time difference may increase with time

The Solution is the PCR (Program Clock Reference) a special clock reference value transmitted every few MPEG2 TS packets in the TS packet header. This reference allows the client to synchronize it's own clock to the one of the server. Hardware MPEG2 decoders use voltage-controlled oscillators or numerically controlled oscillators for this purpose.

Software decoders followed different approaches in the past:

  • naive codes just watch the buffer fuel level and drop or delay frames.
  • VLC low-pass filters the incoming clock references and uses a linear approximation algorithm to approach the server clock reference.
  • A theoretically a little hard to understand but very efficient and easy to implement approach uses Kalman Filtering.


Audio/Video Sync

You should ensure that Audio and video frames are correctly presented to the user at the System Clock Time encoded in the frame's PTS (Presentation Time Stamp).

The STC should get synchronized regularily to the server clock using the PCR. For recorded playback you can either use the host clock, the video frame sync or the audio crystal as clock reference to sync.


Screen/Decoder Sync Aliasing

Unless the Display Refresh rate is at least twice as high as the frame rate of the displayed video you will get aliasing artifacts (jerking video due to dropped or double frames). See Wikipedia:Nyquist and Wikipedia:Nyquist-Shannon_sampling_theorem for a overview over sampling theory and a short explanation of aliasing artifacts when sampling below the Nyquist frequency.


Audio Clock pitching

Since the sample rate of most soundcards can't get smoothly adjusted while playing it may be possible to resample the audio signal in software before sending it to the sound card. Naive nearest-neighbor or sample-drop approaches are trivial to implement, even linear filtering costs only a few lines of code. Most audio libraries have resampling routines built in, there are also resampling libraries available on the net.

ISO/IEC13818-1 allows maximum clock rate changes of 0.075Hz/sec in order to avoid audible artifacts in playback.


Color Correction, the Gamma Question

Computer Monitors and Video Projectors have a different Gamma Curve than Television Screens. Thus you need to apply a proper correction curve to the display. All common graphics libraries like SDL, DirectFB and SDL provide an API to set up the Gamma Color Lookup Tables. Not hard to do, just has to be done correctly otherwise you risk weak colors on the display.