[Sumover-dev] RE: VIC release delay

Douglas Kosovic douglask at itee.uq.edu.au
Thu Jun 18 02:13:43 BST 2009


Hi Andrew,

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.

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. 

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:
  insmod bttv combfilter=1 lumafilter=1
but I'm guessing the bttv drivers would need to be rebuilt with an adapted patch.

I'll look into applying the unapplied patch from https://mediatools.cs.ucl.ac.uk/nets/mmedia/ticket/162 when I get back from holiday.

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.

The VDPAU support which uses an Nvidia GPU to do the H.264 decoding looks interesting as does the new ffmpeg-mt branch:
http://www.mplayerhq.hu/design7/news.html

Cheers,
Doug

-----Original Message-----
From: adhesionmusic at gmail.com on behalf of Andrew Ford
Sent: Thu 6/18/2009 6:15 AM
To: Douglas Kosovic
Cc: sumover-dev at cs.ucl.ac.uk; Piers O'Hanlon
Subject: Re: FW: VIC release delay
 
Hi guys,

I hate to pile on the bug reports before a major release, but here they are
anyway :) A few relatively minor issues with vic:

-There's apparently a known quality issue when using bt8x8 capture cards
with ffmpeg: http://ffmpeg.org/faq.html#SEC20 which manifests itself as
noticeable encoding artifacts when using mpeg4 with vic. Has this been
addressed at all? I didn't notice any reference to it in the ffmpeg_codec or
encoder_mpeg4 files.
-Somewhat related to that, I've noticed that the saturation in the v4l2
settings is seemingly always at least 3/4 of the way up upon startup. Is
this modifiable via command line or some other method? (If so, it should
probably be added to the Access Grid service config menu.)

-The patch related to this bug:
https://mediatools.cs.ucl.ac.uk/nets/mmedia/ticket/162 has yet to be merged
into the mpeg4 branch.

-Occasionally I'll see obvious encoding artifacts when using mpeg4 - it
looks as if the edges of the macroblocks (16x16 pixels? haven't measured it
exactly) get very sharp over the period of about 1 second, then return to
normal and repeat. I haven't been able to consistently reproduce this, nor I
have I tried it with ffmpeg 0.5, which I'm attempting to do now. I've
observed this on Windows and Linux, both from analog capture cards as well
as from a DV camera via firewire.

A related bug: when trying to compile the newest SVN vic, it fails on
ffmpeg_codec.cpp, since it can't find avcodec.h - there are two issues here:
-the include in ffmpeg_codec.h is way too specific, referring to
/usr/include/ffmpeg, and
-for the codec directory (and other directories that have files that use
ffmpeg) the makefile (or should this be in the configure script?) needs to
specify -I../ffmpeg/include instead of -Iffmpeg/include.

Some issues with the configure script - when it calls ffmpeg's configure the
threads option isn't turned on, and --enable-x264-co doesn't actually work -
it seems to only checkout when only using --with-x264-ver=version (plus
enable-gpl).

In addition: a number of other includes need to be changed, in
video/deinterlace.h, codec/x264encoder.cpp, codec/rtp_h264_depayloader.h,
and render/color-swscale.cpp, in order to be consistent with the ffmpeg 0.5
directory structure. Should libname/header.h, with the root ffmpeg directory
being added through -I, be the standard include style? I suppose that
-I../ffmpeg/libavcodec, libavutil, etc. could work too - thoughts?

--Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/sumover-dev/attachments/20090618/031a9ddb/attachment.html


More information about the Sumover-dev mailing list