Fedora kernel-2.6.17-1.2142_FC4 patched with stable patch-2.6.17.4-vs2.0.2-rc26.diff

[linux-2.6.git] / Documentation / video4linux / Zoran

diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran
index 01425c2..be9f21b 100644 (file)
--- a/Documentation/video4linux/Zoran
+++ b/Documentation/video4linux/Zoran
@@ -28,7 +28,7 @@ Iomega Buz:
 * Philips saa7111 TV decoder
 * Philips saa7185 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,
 * Philips saa7111 TV decoder
 * Philips saa7185 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,

-                videocodec, saa7111, saa7185, zr36060, zr36067
+               videocodec, saa7111, saa7185, zr36060, zr36067

 Inputs/outputs: Composite and S-video
 Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
 Card number: 7
 Inputs/outputs: Composite and S-video
 Norms: PAL, SECAM (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
 Card number: 7


@@ -39,7 +39,7 @@ Linux Media Labs LML33:
 * Brooktree bt819 TV decoder
 * Brooktree bt856 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,
 * Brooktree bt819 TV decoder
 * Brooktree bt856 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,

-                videocodec, bt819, bt856, zr36060, zr36067
+               videocodec, bt819, bt856, zr36060, zr36067

 Inputs/outputs: Composite and S-video
 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
 Card number: 5
 Inputs/outputs: Composite and S-video
 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
 Card number: 5


@@ -50,7 +50,7 @@ Linux Media Labs LML33R10:
 * Philips saa7114 TV decoder
 * Analog Devices adv7170 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,
 * Philips saa7114 TV decoder
 * Analog Devices adv7170 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,

-                videocodec, saa7114, adv7170, zr36060, zr36067
+               videocodec, saa7114, adv7170, zr36060, zr36067

 Inputs/outputs: Composite and S-video
 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
 Card number: 6
 Inputs/outputs: Composite and S-video
 Norms: PAL (720x576 @ 25 fps), NTSC (720x480 @ 29.97 fps)
 Card number: 6


@@ -61,7 +61,7 @@ Pinnacle/Miro DC10(new):
 * Philips saa7110a TV decoder
 * Analog Devices adv7176 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,
 * Philips saa7110a TV decoder
 * Analog Devices adv7176 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,

-                videocodec, saa7110, adv7175, zr36060, zr36067
+               videocodec, saa7110, adv7175, zr36060, zr36067

 Inputs/outputs: Composite, S-video and Internal
 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
 Card number: 1
 Inputs/outputs: Composite, S-video and Internal
 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
 Card number: 1


@@ -84,7 +84,7 @@ Pinnacle/Miro DC10(old): *
 * Micronas vpx3220a TV decoder
 * mse3000 TV encoder or Analog Devices adv7176 TV encoder *
 Drivers to use: videodev, i2c-core, i2c-algo-bit,
 * Micronas vpx3220a TV decoder
 * mse3000 TV encoder or Analog Devices adv7176 TV encoder *
 Drivers to use: videodev, i2c-core, i2c-algo-bit,

-                videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067
+               videocodec, vpx3220, mse3000/adv7175, zr36050, zr36016, zr36067

 Inputs/outputs: Composite, S-video and Internal
 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
 Card number: 0
 Inputs/outputs: Composite, S-video and Internal
 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
 Card number: 0


@@ -96,7 +96,7 @@ Pinnacle/Miro DC30: *
 * Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
 * Analog Devices adv7176 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,
 * Micronas vpx3225d/vpx3220a/vpx3216b TV decoder
 * Analog Devices adv7176 TV encoder
 Drivers to use: videodev, i2c-core, i2c-algo-bit,

-                videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067
+               videocodec, vpx3220/vpx3224, adv7175, zr36050, zr36016, zr36067

 Inputs/outputs: Composite, S-video and Internal
 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
 Card number: 3
 Inputs/outputs: Composite, S-video and Internal
 Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)
 Card number: 3


@@ -123,11 +123,11 @@ Note: use encoder=X or decoder=X for non-default i2c chips (see i2c-id.h)
 
 The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
 information is not enough. There are several formats of the TV standards.
 
 The best know TV standards are NTSC/PAL/SECAM. but for decoding a frame that
 information is not enough. There are several formats of the TV standards.

-And not every TV decoder is able to handle every format. Also the every 
-combination is supported by the driver. There are currently 11 different 
-tv broadcast formats all aver the world. 
+And not every TV decoder is able to handle every format. Also the every
+combination is supported by the driver. There are currently 11 different
+tv broadcast formats all aver the world.

 
 

-The CCIR defines parameters needed for broadcasting the signal. 
+The CCIR defines parameters needed for broadcasting the signal.

 The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
 The CCIR says not much about about the colorsystem used !!!
 And talking about a colorsystem says not to much about how it is broadcast.
 The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,...
 The CCIR says not much about about the colorsystem used !!!
 And talking about a colorsystem says not to much about how it is broadcast.


@@ -136,18 +136,18 @@ The CCIR standards A,E,F are not used any more.
 
 When you speak about NTSC, you usually mean the standard: CCIR - M using
 the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada
 
 When you speak about NTSC, you usually mean the standard: CCIR - M using
 the NTSC colorsystem which is used in the USA, Japan, Mexico, Canada

-and a few others. 
+and a few others.

 
 When you talk about PAL, you usually mean: CCIR - B/G using the PAL
 
 When you talk about PAL, you usually mean: CCIR - B/G using the PAL

-colorsystem which is used in many Countries. 
+colorsystem which is used in many Countries.

 
 

-When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem 
+When you talk about SECAM, you mean: CCIR - L using the SECAM Colorsystem

 which is used in France, and a few others.
 
 There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,
 which is used in France, and a few others.
 
 There the other version of SECAM, CCIR - D/K is used in Bulgaria, China,

-Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others. 
+Slovakai, Hungary, Korea (Rep.), Poland, Rumania and a others.

 
 

-The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in 
+The CCIR - H uses the PAL colorsystem (sometimes SECAM) and is used in

 Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
 
 The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
 Egypt, Libya, Sri Lanka, Syrain Arab. Rep.
 
 The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,


@@ -158,30 +158,30 @@ and is used in Argentinia, Uruguay, an a few others
 
 We do not talk about how the audio is broadcast !
 
 
 We do not talk about how the audio is broadcast !
 

-A rather good sites about the TV standards are: 
+A rather good sites about the TV standards are:

 http://www.sony.jp/ServiceArea/Voltage_map/
 http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
 and http://www.cabl.com/restaurant/channel.html
 
 Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
 used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same
 http://www.sony.jp/ServiceArea/Voltage_map/
 http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/
 and http://www.cabl.com/restaurant/channel.html
 
 Other weird things around: NTSC 4.43 is a modificated NTSC, which is mainly
 used in PAL VCR's that are able to play back NTSC. PAL 60 seems to be the same

-as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would 
-be the same as NTSC 4.43. 
+as NTSC 4.43 . The Datasheets also talk about NTSC 44, It seems as if it would
+be the same as NTSC 4.43.

 NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
 to split coma and luma instead of a Delay line.
 
 But I did not defiantly find out what NTSC Comb is.
 
 Philips saa7111 TV decoder
 NTSC Combs seems to be a decoder mode where the decoder uses a comb filter
 to split coma and luma instead of a Delay line.
 
 But I did not defiantly find out what NTSC Comb is.
 
 Philips saa7111 TV decoder

-was introduced in 1997, is used in the BUZ and 
-can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM 
+was introduced in 1997, is used in the BUZ and
+can handle: PAL B/G/H/I, PAL N, PAL M, NTSC M, NTSC N, NTSC 4.43 and SECAM

 
 Philips saa7110a TV decoder
 was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and
 
 Philips saa7110a TV decoder
 was introduced in 1995, is used in the Pinnacle/Miro DC10(new), DC10+ and

-can handle: PAL B/G, NTSC M and SECAM 
+can handle: PAL B/G, NTSC M and SECAM

 
 Philips saa7114 TV decoder
 
 Philips saa7114 TV decoder

-was introduced in 2000, is used in the LML33R10 and  
+was introduced in 2000, is used in the LML33R10 and

 can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
 
 Brooktree bt819 TV decoder
 can handle: PAL B/G/D/H/I/N, PAL N, PAL M, NTSC M, NTSC 4.43 and SECAM
 
 Brooktree bt819 TV decoder


@@ -206,7 +206,7 @@ was introduced in 1996, is used in the BUZ
 can generate: PAL B/G, NTSC M
 
 Brooktree bt856 TV Encoder
 can generate: PAL B/G, NTSC M
 
 Brooktree bt856 TV Encoder

-was introduced in 1994, is used in the LML33 
+was introduced in 1994, is used in the LML33

 can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
 
 Analog Devices adv7170 TV Encoder
 can generate: PAL B/D/G/H/I/N, PAL M, NTSC M, PAL-N (Argentina)
 
 Analog Devices adv7170 TV Encoder


@@ -221,9 +221,9 @@ ITT mse3000 TV encoder
 was introduced in 1991, is used in the DC10 old
 can generate: PAL , NTSC , SECAM
 
 was introduced in 1991, is used in the DC10 old
 can generate: PAL , NTSC , SECAM
 

-The adv717x, should be able to produce PAL N. But you find nothing PAL N 
-specific in the the registers. Seem that you have to reuse a other standard
-to generate PAL N, maybe it would work if you use the PAL M settings. 
+The adv717x, should be able to produce PAL N. But you find nothing PAL N
+specific in the registers. Seem that you have to reuse a other standard
+to generate PAL N, maybe it would work if you use the PAL M settings.

 
 ==========================
 
 
 ==========================
 


@@ -261,7 +261,7 @@ Here's my experience of using LML33 and Buz on various motherboards:
 
 VIA MVP3
        Forget it. Pointless. Doesn't work.
 
 VIA MVP3
        Forget it. Pointless. Doesn't work.

-Intel 430FX (Pentium 200) 
+Intel 430FX (Pentium 200)

        LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
 Intel 440BX (early stepping)
        LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)
        LML33 perfect, Buz tolerable (3 or 4 frames dropped per movie)
 Intel 440BX (early stepping)
        LML33 tolerable. Buz starting to get annoying (6-10 frames/hour)


@@ -438,52 +438,52 @@ importance of buffer sizes:
 > -q 25 -b 128 : 24.655.992
 > -q 25 -b 256 : 25.859.820
 
 > -q 25 -b 128 : 24.655.992
 > -q 25 -b 256 : 25.859.820
 

-I woke up, and can't go to sleep again. I'll kill some time explaining why 
+I woke up, and can't go to sleep again. I'll kill some time explaining why

 this doesn't look strange to me.
 
 this doesn't look strange to me.
 

-Let's do some math using a width of 704 pixels. I'm not sure whether the Buz 
+Let's do some math using a width of 704 pixels. I'm not sure whether the Buz

 actually use that number or not, but that's not too important right now.
 
 actually use that number or not, but that's not too important right now.
 

-704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block; 
-3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block; 
-1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum 
-output becomes 512 bits per block. Actually 510, but 512 is simpler to use 
+704x288 pixels, one field, is 202752 pixels. Divided by 64 pixels per block;
+3168 blocks per field. Each pixel consist of two bytes; 128 bytes per block;
+1024 bits per block. 100% in the new driver mean 1:2 compression; the maximum
+output becomes 512 bits per block. Actually 510, but 512 is simpler to use

 for calculations.
 
 for calculations.
 

-Let's say that we specify d1q50. We thus want 256 bits per block; times 3168 
-becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes 
-here, so we don't need to do any fancy corrections for bits-per-pixel or such 
+Let's say that we specify d1q50. We thus want 256 bits per block; times 3168
+becomes 811008 bits; 101376 bytes per field. We're talking raw bits and bytes
+here, so we don't need to do any fancy corrections for bits-per-pixel or such

 things. 101376 bytes per field.
 
 things. 101376 bytes per field.
 

-d1 video contains two fields per frame. Those sum up to 202752 bytes per 
+d1 video contains two fields per frame. Those sum up to 202752 bytes per

 frame, and one of those frames goes into each buffer.
 
 frame, and one of those frames goes into each buffer.
 

-But wait a second! -b128 gives 128kB buffers! It's not possible to cram 
+But wait a second! -b128 gives 128kB buffers! It's not possible to cram

 202752 bytes of JPEG data into 128kB!
 
 202752 bytes of JPEG data into 128kB!
 

-This is what the driver notice and automatically compensate for in your 
+This is what the driver notice and automatically compensate for in your

 examples. Let's do some math using this information:
 
 examples. Let's do some math using this information:
 

-128kB is 131072 bytes. In this buffer, we want to store two fields, which 
-leaves 65536 bytes for each field. Using 3168 blocks per field, we get 
-20.68686868... available bytes per block; 165 bits. We can't allow the 
-request for 256 bits per block when there's only 165 bits available! The -q50 
-option is silently overridden, and the -b128 option takes precedence, leaving 
+128kB is 131072 bytes. In this buffer, we want to store two fields, which
+leaves 65536 bytes for each field. Using 3168 blocks per field, we get
+20.68686868... available bytes per block; 165 bits. We can't allow the
+request for 256 bits per block when there's only 165 bits available! The -q50
+option is silently overridden, and the -b128 option takes precedence, leaving

 us with the equivalence of -q32.
 
 us with the equivalence of -q32.
 

-This gives us a data rate of 165 bits per block, which, times 3168, sums up 
-to 65340 bytes per field, out of the allowed 65536. The current driver has 
-another level of rate limiting; it won't accept -q values that fill more than 
-6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be 
-a safe bet. Personally, I think I would have lowered requested-bits-per-block 
-by one, or something like that.) We can't use 165 bits per block, but have to 
-lower it again, to 6/8 of the available buffer space: We end up with 124 bits 
-per block, the equivalence of -q24. With 128kB buffers, you can't use greater 
+This gives us a data rate of 165 bits per block, which, times 3168, sums up
+to 65340 bytes per field, out of the allowed 65536. The current driver has
+another level of rate limiting; it won't accept -q values that fill more than
+6/8 of the specified buffers. (I'm not sure why. "Playing it safe" seem to be
+a safe bet. Personally, I think I would have lowered requested-bits-per-block
+by one, or something like that.) We can't use 165 bits per block, but have to
+lower it again, to 6/8 of the available buffer space: We end up with 124 bits
+per block, the equivalence of -q24. With 128kB buffers, you can't use greater

 than -q24 at -d1. (And PAL, and 704 pixels width...)
 
 than -q24 at -d1. (And PAL, and 704 pixels width...)
 

-The third example is limited to -q24 through the same process. The second 
-example, using very similar calculations, is limited to -q48. The only 
-example that actually grab at the specified -q value is the last one, which 
+The third example is limited to -q24 through the same process. The second
+example, using very similar calculations, is limited to -q48. The only
+example that actually grab at the specified -q value is the last one, which

 is clearly visible, looking at the file size.
 --
 
 is clearly visible, looking at the file size.
 --