mirror of
https://github.com/raspberrypi/linux.git
synced 2026-01-03 00:03:44 +00:00
378af48333
As described above fillin_formats()
"""
/*
* THE 16-BIT easycap_format.mask HAS MEANING:
* (least significant) BIT 0: 0 => PAL, 25 FPS; 1 => NTSC, 30 FPS
* BITS 2-4: RESERVED FOR DIFFERENTIATING STANDARDS
* BITS 5-7: NUMBER OF BYTES PER PIXEL
* BIT 8: 0 => NATIVE BYTE ORDER; 1 => SWAPPED
* BITS 9-10: RESERVED FOR OTHER BYTE PERMUTATIONS
* BIT 11: 0 => UNDECIMATED; 1 => DECIMATED
* BIT 12: 0 => OFFER FRAMES; 1 => OFFER FIELDS
* BIT 13: 0 => FULL FRAMERATE; 1 => REDUCED
* (most significant) BITS 14-15: RESERVED FOR OTHER FIELD/FRAME OPTIONS
* IT FOLLOWS THAT:
* bytesperpixel IS ((0x00E0 & easycap_format.mask) >> 5)
* byteswaporder IS true IF (0 != (0x0100 & easycap_format.mask))
*
* decimatepixel IS true IF (0 != (0x0800 & easycap_format.mask))
*
* offerfields IS true IF (0 != (0x1000 & easycap_format.mask))
*/
"""
bytes-per-pixel is stored in bits 5-7 of calculated mask.
But when calculating bytes-per-line we were extracting wrong value
instead of bytes-per-pixel, which was usually 2 times bigger -- e.g. for
PAL YUV 422 I was getting ((mask3 & 0x00F0) >> 4) = 4 bytes instead of 2.
The error here is that even in comments there is a line saying
* bytesperpixel IS ((0x00E0 & easycap_format.mask) >> 5)
but we were using
((0x00F0 & easycap_format.mask) >> 4)
With 2 times bigger bytesperpixel and automatically bytesperline, the
video was shown halfheight'ed, which is understandable if we look at
video-memory layout:
<------- bytesperline -------->
<- real bpl ->
x0----------y0 x1-----------y1
x2----------y2 x3-----------y3
xn----------yn xn-----------yn
<garbage>
for each line, we should display width pixels, then move to next line
with bytesperline, and oops, if bytesperline = 2*real-bytesperlin, we'll
skip one line and move to next-next line, and so only half lines will be
shown.
Initially I've debugged the problem with my video application[1], but
I've checked that after this patch both rawv (mine app) and tvtime work
correctly.
[1] http://repo.or.cz/w/rawv.git
P.S. why at all we use those mask/shifts? Why not use bitfields?
Cc: Mike Thomas <rmthomas@sciolus.org>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
***********************************************************
* EasyCAP USB 2.0 Video Adapter with Audio, Model DC60 *
* and *
* EasyCAP002 4-Channel USB 2.0 DVR *
***********************************************************
Mike Thomas <rmthomas@sciolus.org>
SUPPORTED HARDWARE
------------------
This driver is intended for use with hardware having USB ID 05e1:0408.
Two kinds of EasyCAP have this USB ID, namely:
* EasyCAP USB 2.0 Video Adapter with Audio, Model DC60,
having input cables labelled CVBS, S-VIDEO, AUDIO(L), AUDIO(R)
* EasyCAP002 4-Channel USB 2.0 DVR, having input cables labelled
1, 2, 3, 4 and an unlabelled input cable for a microphone.
BUILD OPTIONS AND DEPENDENCIES
------------------------------
Unless EASYCAP_DEBUG is defined during compilation it will not be possible
to select a debug level at the time of module installation.
KNOWN RUNTIME ISSUES
--------------------
(1) Intentionally, this driver will not stream material which is unambiguously
identified by the hardware as copy-protected. Normal video output will be
present for about a minute but will then freeze when this situation arises.
(2) The controls for luminance, contrast, saturation, hue and volume may not
always work properly.
(3) Reduced-resolution S-Video seems to suffer from moire artefacts.
INPUT NUMBERING
---------------
For the EasyCAP with S-VIDEO input cable the driver regards a request for
inputs numbered 0 or 1 as referring to CVBS and a request for input
numbered 5 as referring to S-VIDEO.
For the EasyCAP with four CVBS inputs the driver expects to be asked for
any one of inputs numbered 1,2,3,4. If input 0 is asked for, it is
interpreted as input 1.
MODULE PARAMETERS
-----------------
Three module parameters are defined:
debug the easycap module is configured at diagnostic level n (0 to 9)
gain audio gain level n (0 to 31, default is 16)
bars whether to display testcard bars when incoming video signal is lost
0 => no, 1 => yes (default)
SUPPORTED TV STANDARDS AND RESOLUTIONS
--------------------------------------
The following TV standards are natively supported by the hardware and are
usable as (for example) the "norm=" parameter in the mplayer command:
PAL_BGHIN, NTSC_N_443,
PAL_Nc, NTSC_N,
SECAM, NTSC_M, NTSC_M_JP,
PAL_60, NTSC_443,
PAL_M.
In addition, the driver offers "custom" pseudo-standards with a framerate
which is 20% of the usual framerate. These pseudo-standards are named:
PAL_BGHIN_SLOW, NTSC_N_443_SLOW,
PAL_Nc_SLOW, NTSC_N_SLOW,
SECAM_SLOW, NTSC_M_SLOW, NTSC_M_JP_SLOW,
PAL_60_SLOW, NTSC_443_SLOW,
PAL_M_SLOW.
The available picture sizes are:
at 25 frames per second: 720x576, 704x576, 640x480, 360x288, 320x240;
at 30 frames per second: 720x480, 640x480, 360x240, 320x240.
WHAT'S TESTED AND WHAT'S NOT
----------------------------
This driver is known to work with mplayer, mencoder, tvtime, zoneminder,
xawtv, gstreamer and sufficiently recent versions of vlc. An interface
to ffmpeg is implemented, but serious audio-video synchronization problems
remain.
The driver is designed to support all the TV standards accepted by the
hardware, but as yet it has actually been tested on only a few of these.
I have been unable to test and calibrate the S-video input myself because I
do not possess any equipment with S-video output.
UDEV RULES
----------
In order that the special files /dev/easycap0 and /dev/easysnd1 are created
with conveniently relaxed permissions when the EasyCAP is plugged in, a file
is preferably to be provided in directory /etc/udev/rules.d with content:
ACTION!="add|change", GOTO="easycap_rules_end"
ATTRS{idVendor}=="05e1", ATTRS{idProduct}=="0408", \
MODE="0666", OWNER="root", GROUP="root"
LABEL="easycap_rules_end"
MODPROBE CONFIGURATION
----------------------
The easycap module is in competition with the module snd-usb-audio for the
EasyCAP's audio channel, and its installation can be aided by providing a
file in directory /etc/modprobe.d with content:
options easycap gain=16 bars=1
install easycap /sbin/rmmod snd-usb-audio; /sbin/modprobe --ignore-install easycap
ACKNOWLEGEMENTS AND REFERENCES
------------------------------
This driver makes use of information contained in the Syntek Semicon DC-1125
Driver, presently maintained at http://sourceforge.net/projects/syntekdriver/
by Nicolas Vivien. Particularly useful has been a patch to the latter driver
provided by Ivor Hewitt in January 2009. The NTSC implementation is taken
from the work of Ben Trask.