From owner-freebsd-firewire Sun Feb 16 18:41:31 2003 Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2B7F37B401 for ; Sun, 16 Feb 2003 18:41:29 -0800 (PST) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [133.11.205.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id A310643F75 for ; Sun, 16 Feb 2003 18:41:28 -0800 (PST) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is2.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id AFB723780F9 for ; Mon, 17 Feb 2003 11:41:26 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) by is2.mh.itc.u-tokyo.ac.jp (8.11.3/8.11.3) with ESMTP id h1H2fQR17142; Mon, 17 Feb 2003 11:41:26 +0900 Received: from ett.sat.t.u-tokyo.ac.jp (ett.sat.t.u-tokyo.ac.jp [133.11.135.3]) by mailhosting.itc.u-tokyo.ac.jp (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AHX04995; Mon, 17 Feb 2003 11:41:25 +0900 (JST) Date: Mon, 17 Feb 2003 11:41:25 +0900 Message-ID: From: Hidetoshi Shimokawa To: Richard Tobin Cc: freebsd-firewire@freebsd.org Subject: Re: PAL DV, doesn't quite work In-Reply-To: <200302170153.BAA11342@sorley.cogsci.ed.ac.uk> User-Agent: Wanderlust/2.11.0 (Wonderwall) REMI/1.14.3 (Matsudai) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 8) (Honest Recruiter) (i386--freebsd) X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7: #j7i14gu$jgR\S*&C3R/pJX List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks for the test and investigations. There is another bit which indicates PAL or NTSC. Can you insert printf for 'ciph->fdf.dv.fs' to check whether it is 1 or 0. For PAL, it shold be 1. Actually, for receive part, we use the system information(PAL or NTSC) only for detect bad frame data length(buffer overrun causes this). So we can ignore system information if we give up padding of corrupted data. For sending part, the system information is essential to keep frame timing. /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html At Mon, 17 Feb 2003 01:53:19 GMT, Richard Tobin wrote: > > I wrote: > > > I then used "fwcontrol -R" to capture some video. I used "playdv" to > > look at it, and both audio and video were scrambled. I added a printf > > to fwdv.c, and found that the test > > > > pal = ((dv->payload[0] & DV_DSF_12) != 0); > > > > was returning 0 because dv->payload[0] is 63 (DV_DSF_12 is 128). > > I looked into this. It seems that my PAL camcorder is falsely > claiming to be NTSC (525/60, 10 DIF sequences) in the header section, > and correctly claiming to be PAL (625/50, 12 DIF sequences) in the > VAUX section. > > I looked at the dvlib code, and this seems to be a known problem; there > is a comment in dv_parse_header in parse.c: > > /* > * parse vaux data now to check if there is a inconsistanciy between > * header->dsf and vaux data for auto mode > */ > > and it treats the stream as 625/50 if either the DSF bit is set or > the VAUX data has the 50/60 flag set. > > -- Richard > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-firewire" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-firewire" in the body of the message