<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7655.1">
<TITLE>RE: VIC release delay</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Andrew,<BR>
<BR>
In tcl/ui-resource.tcl saturation is set to 230 (where possible values are 0 - 255 and it's not just for V4L2), while other controls are set to 128. I'm guessing it's a historical reason as to why it was set to 230, I can't see why it shouldn't be set to 128.<BR>
<BR>
Regarding the Access Grid service config menu and adding sliders and combo-menus, I have done that in the past, but there wasn't enough screen realestate (especially on 1024x768 projector screens) to add all the controls I wanted (or had requests for, like the UVC webcam controls such as zoom, manual focus, etc), there were about 12 sliders and several combo-menus, I guess a scrollbar could somehow be added to fit everything on the screen. With V4L2 it is possible to interrogate the driver to determine what controls it supports and the type of values they take, but things got complicated on how to expose that to Tcl and even more complicated on how to expose that to the AGTk. I might raise the issue with Tom at the next Town Hall.<BR>
<BR>
Regarding the bttv driver patch and kernel module arguments, I'm not sure how it could be addressed from within VIC. The patches were for the bttv drivers that came with kernels 2.4.26 & 2.6.6, perhaps it might already be incorporated in newer versions of the bttv driver? You could try adding the bttv kernel module argument in /etc/modprobe.conf or pass them as arguments to insmod, e.g:<BR>
insmod bttv combfilter=1 lumafilter=1<BR>
but I'm guessing the bttv drivers would need to be rebuilt with an adapted patch.<BR>
<BR>
I'll look into applying the unapplied patch from <A HREF="https://mediatools.cs.ucl.ac.uk/nets/mmedia/ticket/162">https://mediatools.cs.ucl.ac.uk/nets/mmedia/ticket/162</A> when I get back from holiday.<BR>
<BR>
Sorry I can't make much comment about the other ffmpeg issues you raise at moment, I might get back to you on some of the issues when I get back from holiday leave next week or Piers may have something to say.<BR>
<BR>
The VDPAU support which uses an Nvidia GPU to do the H.264 decoding looks interesting as does the new ffmpeg-mt branch:<BR>
<A HREF="http://www.mplayerhq.hu/design7/news.html">http://www.mplayerhq.hu/design7/news.html</A><BR>
<BR>
Cheers,<BR>
Doug<BR>
<BR>
-----Original Message-----<BR>
From: adhesionmusic@gmail.com on behalf of Andrew Ford<BR>
Sent: Thu 6/18/2009 6:15 AM<BR>
To: Douglas Kosovic<BR>
Cc: sumover-dev@cs.ucl.ac.uk; Piers O'Hanlon<BR>
Subject: Re: FW: VIC release delay<BR>
<BR>
Hi guys,<BR>
<BR>
I hate to pile on the bug reports before a major release, but here they are<BR>
anyway :) A few relatively minor issues with vic:<BR>
<BR>
-There's apparently a known quality issue when using bt8x8 capture cards<BR>
with ffmpeg: <A HREF="http://ffmpeg.org/faq.html#SEC20">http://ffmpeg.org/faq.html#SEC20</A> which manifests itself as<BR>
noticeable encoding artifacts when using mpeg4 with vic. Has this been<BR>
addressed at all? I didn't notice any reference to it in the ffmpeg_codec or<BR>
encoder_mpeg4 files.<BR>
-Somewhat related to that, I've noticed that the saturation in the v4l2<BR>
settings is seemingly always at least 3/4 of the way up upon startup. Is<BR>
this modifiable via command line or some other method? (If so, it should<BR>
probably be added to the Access Grid service config menu.)<BR>
<BR>
-The patch related to this bug:<BR>
<A HREF="https://mediatools.cs.ucl.ac.uk/nets/mmedia/ticket/162">https://mediatools.cs.ucl.ac.uk/nets/mmedia/ticket/162</A> has yet to be merged<BR>
into the mpeg4 branch.<BR>
<BR>
-Occasionally I'll see obvious encoding artifacts when using mpeg4 - it<BR>
looks as if the edges of the macroblocks (16x16 pixels? haven't measured it<BR>
exactly) get very sharp over the period of about 1 second, then return to<BR>
normal and repeat. I haven't been able to consistently reproduce this, nor I<BR>
have I tried it with ffmpeg 0.5, which I'm attempting to do now. I've<BR>
observed this on Windows and Linux, both from analog capture cards as well<BR>
as from a DV camera via firewire.<BR>
<BR>
A related bug: when trying to compile the newest SVN vic, it fails on<BR>
ffmpeg_codec.cpp, since it can't find avcodec.h - there are two issues here:<BR>
-the include in ffmpeg_codec.h is way too specific, referring to<BR>
/usr/include/ffmpeg, and<BR>
-for the codec directory (and other directories that have files that use<BR>
ffmpeg) the makefile (or should this be in the configure script?) needs to<BR>
specify -I../ffmpeg/include instead of -Iffmpeg/include.<BR>
<BR>
Some issues with the configure script - when it calls ffmpeg's configure the<BR>
threads option isn't turned on, and --enable-x264-co doesn't actually work -<BR>
it seems to only checkout when only using --with-x264-ver=version (plus<BR>
enable-gpl).<BR>
<BR>
In addition: a number of other includes need to be changed, in<BR>
video/deinterlace.h, codec/x264encoder.cpp, codec/rtp_h264_depayloader.h,<BR>
and render/color-swscale.cpp, in order to be consistent with the ffmpeg 0.5<BR>
directory structure. Should libname/header.h, with the root ffmpeg directory<BR>
being added through -I, be the standard include style? I suppose that<BR>
-I../ffmpeg/libavcodec, libavutil, etc. could work too - thoughts?<BR>
<BR>
--Andrew<BR>
</FONT>
</P>
</BODY>
</HTML>