summaryrefslogtreecommitdiff
path: root/v4l2-apps/libv4l/libv4lconvert/libv4lconvert-priv.h
AgeCommit message (Collapse)Author
2009-03-13libv4l: add hm12 support for the cx2341x MPEG encoder devices.hans@rhel5-devel.localdomain
From: Hans Verkuil <hverkuil@xs4all.nl> Priority: normal Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: libv4lconvert support for SQ905Chans@rhel5-devel.localdomain
From: Theodore Kilgore <kilgota@auburn.edu> Support the decompression used by the SQ905C cameras (0x2770:0x905C) and some other related cameras. There is at the moment no support module for these cameras in streaming mode, but I intend to submit one. This contribution was created in whole by me, based upon code in libgphoto2 which was created in whole by me, and which was licensed for libgphoto2 under the LGPL license. Priority: normal Signed-off-by: Theodore Kilgore <kilgota@auburn.edu> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: Add MR97310A decompressionhans@rhel5-devel.localdomain
From: Kyle Guinn <elyk03@gmail.com> libv4l: Add MR97310A decompression Priority: normal Signed-off-by: Kyle Guinn <elyk03@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: add sn9c20x-i420 decoderhans@rhel5-devel.localdomain
From: Vasily Khoruzhick <anarsoul@gmail.com> Recent sn9c20x driver written by microdia project (http://groups.goolge.com/group/microdia) introduce new output format - sn9c20x-i420. This format is actually scrambled yuv420, so it's very easy and fast to convert it to yuv420. This patch adds sn9c20x-i420 decoder to the libv4l-0.5.7 This decoder is much faster than jpeg one (sn9c20x supports JPEG too): sn9c20x-i420 decoder eats only 10% of 1GHz CPU at 640x480x25fps vs 40% of 1GHz CPU in jpeg at same frame size/rate. This format should be preffered for sn9c20x, because sn9c20x driver supports SBGGR8 too, so it should go before SBGGR8 in supported_src_pixfmts. Priority: normal Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com
2009-03-11libv4l: us USB-id's instead of USB product string in upside down dev tablehans@rhel5-devel.localdomain
From: Hans de Goede <hdegoede@redhat.com> Switch to using USB-id's instead of USB product string, as not all devices set a unique product string. This fixes the upside down issues with genius e-messenger 112 cams Priority: normal Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: remove duplicate v4lconvert_yvyu_to_yuv420 functionhans@rhel5-devel.localdomain
From: Hans de Goede <hdegoede@redhat.com> Remove v4lconvert_yvyu_to_yuv420 function as its functionality is duplicate with v4lconvert_yuyv_to_yuv420 Priority: normal Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: add UYVY supporthans@rhel5-devel.localdomain
From: Julien BLACHE <jb@jblache.org> Attached is a patch to add UYVY support to libv4lconvert. It's obviously a shameless respin of the YVYU conversion routines :P Tested on a USB Apple iSight, which only supports UYVY. Priority: normal Signed-off-by: Julien BLACHE <jb@jblache.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: avoid try_fmt on UVC cams if possiblehans@rhel5-devel.localdomain
From: Hans de Goede <hdegoede@redhat.com> Avoid the use of try_fmt as much as possible on UVC cams, instead use the results of the enum_framesizes ioctl. This is because: 1) try_fmt actually causes IO with UVC cams making apps which do lot of querying of device capabilities slow (cheese) 2) some buggy cams don't like getting lots of UVC video probes and crash when they do Priority: normal Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: add support for converting to YV12 planarhans@rhel5-devel.localdomain
From: Hans de Goede <hdegoede@redhat.com> Add support for converting to YV12 planar (next to the already supported YU12 / I420) and implement RGB/BGR24 -> YU/YV12 conversion Priority: normal Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: dont try to allocate large buffers on the stackhans@rhel5-devel.localdomain
From: Hans de Goede <hdegoede@redhat.com> When conversion requires multiple passes don't alloc the needed temporary buffer on the stack, as some apps (ekiga) use so much stack themselves this causes us to run out of stack space Priority: normal Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-03-11libv4l: Add software cropping from CIF to VGA modes (fix skype)hans@rhel5-devel.localdomain
From: Hans de Goede <hdegoede@redhat.com> * Add support for software cropping from 352x288 -> 320x240 / 176x144 -> 160x120, so that apps which will only work with vga resolutions like 320x240 (Skype!) will work with cams/drivers which do not support cropping CIF resolutions to VGA resolutions in hardware. This makes all 2.6.27 gspca supported cams, except for the pac7302 which only does 640x480 (and skype wants 320x240), work with skype * The v4lconvert_convert function was becoming a bit of a mess, so split the functionailiy into seperate v4lconvert_convert_pixfmt, v4lconvert_rotate and v4lconvert_crop functions, and make v4lconvert_convert a frontend to these Priority: normal Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2009-02-13v4l2-apps: move libraries around to make the directory tree flatterHans Verkuil
From: Hans Verkuil <hverkuil@xs4all.nl> Instead of having libv4l2util in v4l2-apps/lib and libv4l in v4l2-apps/lib/libv4l, both are now moved to v4l2-apps/libv4l2util and v4l2-apps/libv4l. This is much cleaner and less confusing. Priority: normal Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>