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