Development: The DVB Decoder Challenge - Revision history

Ngolian: Updated deinterlace_bottom_field() link (CVS replaced by SVN).

2008-08-30T13:05:23Z

Updated deinterlace_bottom_field() link (CVS replaced by SVN).

← Older revision		Revision as of 13:05, 30 August 2008
Line 68:		Line 68:

	In order to use ffmpeg's deinterlacer you would need to implement a matching deinterlace_top_field() function in addition to the existing		In order to use ffmpeg's deinterlacer you would need to implement a matching deinterlace_top_field() function in addition to the existing
-	[http://~~www1~~.mplayerhq.hu/~~cgi-bin~~/~~cvsweb.cgi/ffmpeg~~/libavcodec/imgconvert.c?~~rev~~=~~1.52~~&~~content-type~~=~~text/x-cvsweb-~~markup~~&cvsroot=FFMpeg~~ deinterlace_bottom_field()].	+	[http://svn.mplayerhq.hu/ffmpeg/trunk/libavcodec/imgconvert.c?revision=14513&view=markup deinterlace_bottom_field()].

	When using OpenGL the Deinterlacer can get implemented completely on the graphics card. Enable the multitexturing engines: use one texture unit for the previous frame, one for the blend grid (where the lines have e.g. alternating alpha=0.9 and alpha=0.25 to simulate the decaying phosphor glow), and one for the new frame. Be sure to offset the texture coordinates so that the correct field from the previous frame shines through the gridlines. If the graphics card has not enough texture units available you can let it do the work in multiple passes.		When using OpenGL the Deinterlacer can get implemented completely on the graphics card. Enable the multitexturing engines: use one texture unit for the previous frame, one for the blend grid (where the lines have e.g. alternating alpha=0.9 and alpha=0.25 to simulate the decaying phosphor glow), and one for the new frame. Be sure to offset the texture coordinates so that the correct field from the previous frame shines through the gridlines. If the graphics card has not enough texture units available you can let it do the work in multiple passes.

CityK: The DVB Decoder Challenge moved to Development: The DVB Decoder Challenge: name

2008-01-07T18:53:08Z

The DVB Decoder Challenge moved to Development: The DVB Decoder Challenge: name

← Older revision

Revision as of 18:53, 7 January 2008

CityK: minor edits

2008-01-07T18:52:53Z

minor edits

← Older revision		Revision as of 18:52, 7 January 2008
Line 1:		Line 1:
-	~~== Introduction ==~~	+	One will encounter several challenges over the course of implementing either a hardware or software based [[MPEG-2 Decoder]]. Most of these hurdles are not too hard to solve, but they are very DVB-specific and can be quite annoying if not properly handled.
-		+
-	~~When~~ implementing a ~~Hard-~~ or ~~Software~~ [[MPEG-2 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~~.	+

		+	This page attempts to list some of these common obstacles that a developer may encounter, as well as provide discussion on common approaches around them and outline elegant solutions.

	== The 0x47 MPEG frame Aligner ==		== The 0x47 MPEG frame Aligner ==

CityK: fixed links

2008-01-06T21:32:28Z

fixed links

D.s: "it's"

2007-12-27T00:03:47Z

"it's"

← Older revision		Revision as of 00:03, 27 December 2007
Line 20:		Line 20:
	== The STC sync problem ==		== The STC sync problem ==

-	Whenever a client has to decode a live stream from a server it has to adjust ~~it's~~ own STC (System Time Clock) relative to the one of the server, for several reasons:	+	Whenever a client has to decode a live stream from a server it has to adjust its own STC (System Time Clock) relative 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.		* 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.

Holger: /* The STC sync problem */

2005-07-23T10:57:19Z

The STC sync problem

← Older revision		Revision as of 10:57, 23 July 2005
Line 20:		Line 20:
	== The STC sync problem ==		== The STC sync problem ==

-	Whenever a client has to decode a live stream from a server it has to adjust it's own STC (System Time Clock) to the one of the server, for several reasons:	+	Whenever a client has to decode a live stream from a server it has to adjust it's own STC (System Time Clock) relative 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.		* 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.

Holger: /* The STC sync problem */

2005-07-23T10:57:02Z

The STC sync problem

← Older revision		Revision as of 10:57, 23 July 2005
Line 20:		Line 20:
	== The STC sync problem ==		== 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:	+	Whenever a client has to decode a live stream from a server it has to adjust it's own STC (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.		* 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.

Holger: /* Downscaling */

2005-07-23T10:31:55Z

Downscaling

← Older revision		Revision as of 10:31, 23 July 2005
Line 84:		Line 84:
	* Now scale, again using linear interpolation filters, down to the target resolution (this scale factor is somewhere in the range [0.5...1.0] and thus scaling not susceptible to aliasing).		* Now scale, again using linear interpolation filters, down to the target resolution (this scale factor is somewhere in the range [0.5...1.0] and thus scaling not susceptible to aliasing).

-	This algorithm can get implemented completely in hardware on the graphics card using OpenGL, simply enable linear filtering, render to texture and scale by 0.5 until you reached the last but one level and then render your texture into the framebuffer with the final scale correction somewhere between [0.5...1.0].	+	This algorithm can get implemented completely in hardware on the graphics card using OpenGL: simply enable linear filtering, render to texture and scale by 0.5 until you reached the last but one level and then render your texture into the framebuffer with the final scale correction somewhere between [0.5...1.0].
-		+

	== Color Correction, the Gamma Question ==		== Color Correction, the Gamma Question ==

Holger: /* The STC sync problem */

2005-07-23T10:25:10Z

The STC sync problem

← Older revision		Revision as of 10:25, 23 July 2005
Line 26:		Line 26:
	* The server clock may run continously faster or slower than the host clock, so the time difference may increase with time		* 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.	+	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:		Software decoders followed different approaches in the past:

Holger: /* Color Correction, the Gamma Question */

2005-07-23T10:22:48Z

Color Correction, the Gamma Question

← Older revision		Revision as of 10:22, 23 July 2005
Line 89:		Line 89:
	== Color Correction, the Gamma Question ==		== 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.	+	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 OpenGL, 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.


	[[Category:Development]]		[[Category:Development]]

← Older revision		Revision as of 21:32, 6 January 2008
Line 1:		Line 1:
	== Introduction ==		== 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.	+	When implementing a Hard- or Software [[MPEG-2 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.		So this page tries to list them, to discuss common approaches and to outline elegant solutions.
Line 8:		Line 8:
	== The 0x47 MPEG frame Aligner ==		== The 0x47 MPEG frame Aligner ==

-	Most DVB cards don't output the ~~MPEG2~~ data aligned to 188byte or 204byte ~~MPEG2~~ packet boundaries: this would be hard to achieve on most hardware since DMA controllers are much simpler and cheaper to implement if they can rely on some alignment assumptions.	+	Most DVB cards don't output the MPEG-2 data aligned to 188byte or 204byte MPEG-2 packet boundaries: this would be hard to achieve on most hardware since DMA controllers are much simpler and cheaper to implement if they can rely on some alignment assumptions.

-	So the incoming data needs to get aligned to packet boundaries, this is achievable by a simple state machine, see the [[~~MPEG2~~ Frame Aligner]] article for a detailled discussion and some sample code.	+	So the incoming data needs to get aligned to packet boundaries, this is achievable by a simple state machine, see the [[MPEG-2 Frame Aligner]] article for a detailled discussion and some sample code.


	== PID Filtering/Demultiplexing ==		== PID Filtering/Demultiplexing ==

-	The incoming [[~~MPEG2~~ Transport Stream]] contains ~~MPEG2~~ packets of all transmitted services on this transponder, so we need to peel out the ones that are interesting for us. See the [[PID Filter - Demultiplexer]] section for details and code.	+	The incoming [[MPEG-2 Transport Stream]] contains MPEG-2 packets of all transmitted services on this transponder, so we need to peel out the ones that are interesting for us. See the [[PID Filter - Demultiplexer]] section for details and code.


Line 26:		Line 26:
	* The server clock may run continously faster or slower than the host clock, so the time difference may increase with time		* 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.	+	The Solution is the [[PCR]] (Program Clock Reference): a special clock reference value transmitted every few MPEG-2 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 MPEG-2 decoders use voltage-controlled oscillators or numerically controlled oscillators for this purpose.

	Software decoders followed different approaches in the past:		Software decoders followed different approaches in the past: