From owner-freebsd-multimedia@FreeBSD.ORG Wed May 27 22:19:10 2009 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 860D51065703 for ; Wed, 27 May 2009 22:19:10 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 03A4D8FC1C for ; Wed, 27 May 2009 22:19:09 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by bwz9 with SMTP id 9so5100817bwz.43 for ; Wed, 27 May 2009 15:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8NZoo4SDGI/FIC2emoO6+kB64LsY6Fjm3pdm8miEOAA=; b=Vue2NV/3OMTY1xYPHI5PncFxv5+HYtdn6MCrmZ5eNyQghQzErGnQWosZfTWm0SCHtL +X2OUpnatbLOyV3WSN9bxA3i/16i9z73UeFA+FblifgZFUK9OcP8L/7O0zTyeN0/zLJh dvGEKlv4oBmnjyEVdY3tQ0mqI8a9Nfhw59fJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e+RR66GHFBXzPeHeqv1nNJFVvEoCeG1pHs9GNJssGIsxk7spfbddCd4RoZfMYm62Hi xmbxPNXLVRG/BCu6gkleS+RZ9ZiTkHLX3WLSB1vcU1UlAHPW2lxLmCSKCkc8oWHPh5oX kMKua+iijWOxI2PUMJsXk4jdIPwEAo/n39u8w= MIME-Version: 1.0 Received: by 10.103.241.5 with SMTP id t5mr381946mur.127.1243462748822; Wed, 27 May 2009 15:19:08 -0700 (PDT) In-Reply-To: <200905272134.n4RLY6TM071270@triton.kn-bremen.de> References: <2d1264630905270827q4e85376ds530488edf62b4c1a@mail.gmail.com> <200905272134.n4RLY6TM071270@triton.kn-bremen.de> Date: Wed, 27 May 2009 17:19:08 -0500 Message-ID: <2d1264630905271519j639f3355vdb5146c35db8f4d0@mail.gmail.com> From: Jason Harmening To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-multimedia@freebsd.org Subject: Re: cx88 panic, and a (hacky) way to grab composite/svideo in when it's not panicing :) (and vlc...) (Juergen Lock) X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2009 22:19:11 -0000 On Wed, May 27, 2009 at 4:34 PM, Juergen Lock wrot= e: > In article <2d1264630905270827q4e85376ds530488edf62b4c1a@mail.gmail.com> = you write: >> > Actually my vlc invocation, > >>> =A0 =A0 =A0 =A0vlc --demux rawvideo --rawvid-fps 25 --rawvid-width 768 = --rawvid-height 576 --rawvid-chroma I422 vpipe > > uses the raw video from the vpipe directly so there's no mpeg involved. > (But still the video is jerky.) > >>> (I first wanted to do this with mplayer but the closest I got, >>> =A0 =A0 =A0 =A0mplayer -demuxer rawvideo -rawvideo w=3D768:h=3D576:form= at=3D422p:size=3D884736 vpipe >>> still gets false colours.) >>> > =A0And btw doing it with mplayer like this doesn't seem to be affected by > the jerkyness, only the colours are wrong. =A0(Maybe there's a way to do = it > right with a more recent mplayer, but unfortunately there's no mplayer > svn snapshot in ports and they stopped doing formal releases so our > mplayer is now pretty old... ): > > =A0So maybe the above is just a bug in vlc? =A0(And also, mplayer only us= es > ~8% cpu for this here while vlc uses around 20%...) It does seem likely that it's a VLC bug then. How exactly are the colors wrong in mplayer? The cx88 app captures in YUV422 planar IIRC, but the kernel drivers allow selection of different pixel formats. Perhaps a more straightforward RGB format would work better. You'd have to hack the cx88 app to do that right now, since I don't (yet) have a command-line option for it. > > =A0You are talking about these commits, right? > > SVN rev 191011 on 2009-04-13 19:20:32Z by kib > > =A0The bus_dmamap_load_uio(9) shall use pmap of the thread recorded in th= e > =A0uio_td to extract pages from, instead of unconditionally use kernel > =A0pmap. > > =A0Submitted by: =A0 Jason Harmening (amd64 v= ersion) > =A0PR: =A0 =A0 amd64/133592 > =A0Reviewed by: =A0 =A0scottl (original patch), jhb > =A0MFC after: =A0 =A0 =A02 weeks > > SVN rev 191809 on 2009-05-05 09:08:37Z by kib > > =A0MFC r191011: > =A0The bus_dmamap_load_uio(9) shall use pmap of the thread recorded in th= e > =A0uio_td to extract pages from, instead of unconditionally use kernel > =A0pmap. Yep, those are the ones. > =A0I'm running that here now (after applying the patch; my 7-stable > checkout is from May 10 so it has the above commit), and there was no > panic yet. =A0Thanx! :) No problem, sorry about the downtime. I probably should have issued a port update when I found the problem back in April. > >>The cx88 driver in the repo adds a new kernel module. =A0The code in >>mpeg/ now builds a module called cx88mpegcore.ko. =A0cx88mpeg.ko is now >>a wrapper around this module which is built from the cx23880/ >>directory. =A0So now you have to load cx88mpegcore before you can load >>cx88mpeg. =A0The reason for this is that the driver now supports >>cx23885/7-based PCI-e cards, which Konstantin & I are working on >>polishing so we can do a formal release to ports Really Soon Now. > > =A0Will this also include the dvb-s(2) code that was mentioned on > this list once (I think by Konstantin)? I know Konstantin has at least some of it working, but you'd have to ask him to be sure. There will need to be a cx88 update to add support for additional DVB-S(2) tuning params to the XML file, but most of the work will actually have to be done in libtuner. I may end up pushing the big cx23885 update first just to get some breathing room.