Tech Insider					     Technology and Trends


		   Video for Linux Mailing List Archives

To: Gerd Knorr <kraxel@xxxxxxxxxxx> 
Subject: v4l and v4l-2 
From: Billy Biggs <vektor@xxxxxxxxxxxx> 
Date: Wed, 17 Oct 2001 10:08:36 -0700 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
User-agent: Mutt/1.2.5i 

  Hey,

  I've spent the past few weeks attempting to write a high quality video
recording application using v4l, and being mostly successful.  My
(unfinished) source is available at:

  http://www.sf.net/projects/reetpvr/

  I wrote a simple huffyuv-style codec so I get about 50%-60% lossless
compression on my frames.  I want to reliably capture full 720x240/59.94
or 720x288/50 for recompression to MPEG-2 (so storing 4:2:0 is ok).  I'm
pretty much there.  I've also written a very accurate 3:2 pulldown
inverter, and a reliable method of ensuring audio sync accuracy over
long recording periods (with some thoughts on handling deviations in
video framerate for dealing with VCRs etc).  I record closed-captions as
well (using diz' decoder) and I wrote a timecode decoder for kicks
(kinda neat!).  My recorder threads run SCHED_FIFO and fills an
mlockall()'d buffer.  I usually use my bttv with gbuffers=8.

  To detect when I've dropped a video frame (which _should_ never
happen), I'm currently using the /dev/vbi device, which places the field
number in the last 4 bytes of the VBI data (is that even documented
anywhere?  The v4l docs are confusing and vague).  There's also the
FIELDNR ioctl for bttv, but this doesn't seem to be as reliable as using
the number from /dev/vbi.  There seems to be an inconsistency in the
numbers when I start recording and before I've started.

  So, I'm doing ok, but I'm missing:

  1) An accurate way of correllating /dev/vbi frames with the video, to
     make my timecode decoder more useful.  I could try and compare
     lines 20/21 of the VBI, but that seems ridiculous.  This problem
     seems easily fixable in the API.  Why not throw another int into
     the vbi data saying which buffer the frame was filled into?  Nasty
     hack, but regardless it seems like we can trivially fix the API.

  2) An accurate timestamp on the video frames could help.  Having this
     for all soundcard drivers would be ideal too though, so at this
     point I'm not too worried since I need a statistical model anyways.

  3) Confirmation that how I'm using /dev/vbi will work with other
     VBI-supporting capture cards, and/or a method of getting the field
     count number for cards which don't.

     Seems again like we could trivially improve the v4l API by adding a
     performance ioctl to return the field number and maybe a small list
     of timestamps for the last n frames captured (or synced).  This
     could also be compared to a timestamp in the VBI for correlation.

  I don't want to support two APIs, and it seems silly for me to switch
to v4l-2 since it's a pain to get working (at least it was for me) and
I'm sure none of my users could figure it out.

  Thoughts?  Advice?  How can I help?

-- 
Billy Biggs
vektor@xxxxxxxxxxxx

To: video4linux-list@xxxxxxxxxx 
Subject: Re: v4l and v4l-2 
From: M.Hunold@xxxxxxxxxxx (Michael Hunold) 
Date: Thu, 18 Oct 2001 08:38:27 +0200 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 

Hello Billy,

please be warned: I'm a strong v4l2 advocate. 8-)

I'm very interested in applications like yours, but unfortunately
most of the promising stuff is v4l-based, very bttv-dependend
or both.

I have written a v4l2 driver for video cards that are based
on the "saa7146" chipset. I decided to drop v4l completely,
because I spend most of the developing time to make my
driver "as bttv as possible" which is ridiculous for a device
driver.

I admit that there a not many non-bttv cards on the market, but
for example the "saa7146" can be found on many "professional"
cards, because it's more expensive. 

I personally know my v4l2 driver, the driver for Winnov cards
and a v4l2 driver for the Matrox Meteor cards.

>   1) An accurate way of correllating /dev/vbi frames with the video, to
>      make my timecode decoder more useful.  I could try and compare
>      lines 20/21 of the VBI, but that seems ridiculous.  This problem
>      seems easily fixable in the API.  Why not throw another int into
>      the vbi data saying which buffer the frame was filled into?  Nasty
>      hack, but regardless it seems like we can trivially fix the API.

Everybody will tell you that you have to maintain binary compatiblity.
Breaking the API and existing applications has to be avoided by all
means.

>   2) An accurate timestamp on the video frames could help.  Having this
>      for all soundcard drivers would be ideal too though, so at this
>      point I'm not too worried since I need a statistical model anyways.

But why don't you use v4l2? v4l2 features timestamping by the driver
for both video- and vbi-frames at no extra cost (something which is
completly missing with v4l). Correllating frames then is trivial.

>   3) Confirmation that how I'm using /dev/vbi will work with other
>      VBI-supporting capture cards, and/or a method of getting the field
>      count number for cards which don't.

>   To detect when I've dropped a video frame (which _should_ never
> happen), I'm currently using the /dev/vbi device, which places the field
> number in the last 4 bytes of the VBI data (is that even documented
> anywhere? 

The vbi-stuff in v4l is mostly bttv-dependend and documented "only in
the source". As you said by yourself:

> The v4l docs are confusing and vague)

In contrast to that, the v4l2 docs are excellent. The user parts
are mostly complete and there is also a drivers' writer guide. 
So you can be mostly sure that every driver behaves as describes.

> There's also the
> FIELDNR ioctl for bttv, but this doesn't seem to be as reliable as using

Again a bttv-only extension of the api.

>      Seems again like we could trivially improve the v4l API by adding a
>      performance ioctl to return the field number and maybe a small list
>      of timestamps for the last n frames captured (or synced).  This
>      could also be compared to a timestamp in the VBI for correlation.

There shouldn't be too much "intelligence" in the driver itself. Most
of the stuff can be done in user space.

>   I don't want to support two APIs, and it seems silly for me to switch
> to v4l-2 since it's a pain to get working (at least it was for me) and

Unfortunately I don't use a bttv card at all, so someone else has
to help you out here. 

But I don't agree that it's that difficult: for my driver, you simply
have to install the latest "videodevX" package
(http://www.the-dirks.org/v4l2/)
which encapsulates both v4l and v4l2.

Then simply install my driver and you're gone.

> I'm sure none of my users could figure it out.

Any body who is really interested in serios video capture
should be able to do this. If not, he or she can learn it.

Many times I have read a question like "I'm using kernel
2.4.x and can't get my xyz card to work with bttv" in
the mailing list.

Most of the time, the first answer was "Upgrade your bttv
driver, use the newest version from Gerd Knorr's website".

So people need to upgrade / patch / whatever there installation
anyway.

>   Thoughts?  Advice?  How can I help?

I can send you some programming examples, which show the
basic usage of v4l2's capture facilities if you are
interested.

CU
Michael.

To: video4linux-list@xxxxxxxxxx 
Subject: Re: v4l and v4l-2 
From: Gerd Knorr < kraxel@xxxxxxxxxxx> 
Date: 18 Oct 2001 09:11:24 GMT 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
Newsgroups: lists.linux.video4linux 
Organization: SuSE Labs, Außenstelle Berlin 
User-agent: slrn/0.9.7.1 (Linux) 

> > There's also the
> > FIELDNR ioctl for bttv, but this doesn't seem to be as reliable as using
>  
>  Again a bttv-only extension of the api.

... and it is gone in bttv 0.8.x ...

  Gerd

-- 
Netscape is unable to locate the server localhost:8000.
Please check the server name and try again.


To: video4linux-list@xxxxxxxxxx 
Subject: Re: v4l and v4l-2 
From: Billy Biggs < vektor@xxxxxxxxxxxx> 
Date: Thu, 18 Oct 2001 15:00:03 -0700 
Delivered-to: video4linux-list@xxxxxxxxxxxxxxxxxx 
In-reply-to: < 3BCE78E3.FCDEADBE@xxxxxxxxxxx>; 
from M.Hunold@xxxxxxxxxxx on Thu, Oct 18, 2001 at 08:38:27AM +0200 
User-agent: Mutt/1.2.5i 

Michael Hunold (M.Hunold@xxxxxxxxxxx):

> please be warned: I'm a strong v4l2 advocate. 8-)

  Hey. :)

  I'm worried about v4l2 because if it was clearly 'the right thing' it
would already be in the kernel.  So, there must be some reason every
time I say 'v4l2' in certain circles that people go 'uuugh'.

  But if this situation has changed, please let me know.  Doesn't seem
like it: the bttv driver only now has initial support for v4l2, and it
doesn't support the VBI API.  So, I'm just confused.

  If everyone thinks that v4l is dead and v4l2 forever, great, I'll
switch.  Please let me know now.  But I'm not going to support both.

  I'd love to hear some more opinions.  But my conversations on IRC
still show me three camps:

  1) let's fix v4l.  I hear a big no from this list so far.
  2) let's go v4l2.  I hear a few yays from this list. :)
  3) both are broken, let's start over.  I've definitely heard that
     before too.

  Thoughts?

-- 
Billy Biggs
vektor@xxxxxxxxxxxx

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/