List: linux-video
Subject: V4L(2)
From: Steve Russo <stever () solo ! denning ! com>
Date: 2000-05-09 19:38:18
Does anyone have any good documentation (Possibly a HOWTO) for setting
up V4L2? I use V4L and have had great luck, but I installed MP1E and it
said that there were some things that were only supported with
V4L2...... Does anyone know what things are better supported for MP1E
running under V4L2 than V4L? I know that there was work underway for
timestamping. Is this done? I did a quick try at compiling V4L2 and it
seemed to work, but if I can remember right, I didn't know what to do
AFTER I installed it to get it working with Xawtv and MP1E. Any insights
would be appreciated!
PS Is this the way that things will go from now on? Is everyone going to
dump V4L for V4L2? If anyone hasn't created a HOWTO for V4L2, I would be
more than happy to do it myself. All I need is input.
--
Thanks as always!
Steve
mailto://stever@denning.com
_______________________________________________________________________________
Stephen Russo
Denning Consulting Services
9400 Golden Valley Rd. Don't phear the Penquin
Golden Valley, MN 55427 http://www.freshmeat.net
_______________________________________________________________________________
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Justin Schoeman <justin () suntiger ! ee ! up ! ac ! za>
Date: 2000-05-12 7:15:21
Steve Russo wrote:
>
> Does anyone have any good documentation (Possibly a HOWTO) for setting
> up V4L2? I use V4L and have had great luck, but I installed MP1E and it
> said that there were some things that were only supported with
> V4L2...... Does anyone know what things are better supported for MP1E
> running under V4L2 than V4L? I know that there was work underway for
> timestamping. Is this done? I did a quick try at compiling V4L2 and it
> seemed to work, but if I can remember right, I didn't know what to do
> AFTER I installed it to get it working with Xawtv and MP1E. Any insights
> would be appreciated!
>
> PS Is this the way that things will go from now on? Is everyone going to
> dump V4L for V4L2? If anyone hasn't created a HOWTO for V4L2, I would be
> more than happy to do it myself. All I need is input.
>
> --
>
> Thanks as always!
>
> Steve
> mailto://stever@denning.com
1) There is no HOWTO that I know of.
2) Setting up v4l2 depends a lot on the capture card you are using.
Read the docs that come with the driver you are using.
3) MP1E works relatively well with v4l (except for lack of timestamping,
which also makes multibuffering pretty pointless).
4) It does not look like v4l2 will become the standard. Instead some
sort of hybrid (I think Alan called it V4L+) will come in.
-justin
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: "Ben Bridgwater" <bennyb () ntplx ! net>
Date: 2000-05-14 15:52:48
> Justin Schoeman wrote:
> >
> > PS Is this the way that things will go from now on? Is everyone going
to
> > dump V4L for V4L2? If anyone hasn't created a HOWTO for V4L2, I would
be
> > more than happy to do it myself. All I need is input.
> >
> 4) It does not look like v4l2 will become the standard. Instead some
> sort of hybrid (I think Alan called it V4L+) will come in.
I had previously understood that V4L2, perhaps with some modifications,
would replace V4L. What changed?
Is there any roadmap for V4L, or indication of what new features will be
included in it?
Is there any alternate multimedia infrastructure being developed for Linux
that will include CODEC support?
Ben
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Alan Cox <alan () redhat ! com>
Date: 2000-05-19 1:09:22
> I had previously understood that V4L2, perhaps with some modifications,
> would replace V4L. What changed?
o Lots of people want to keep the existing API as the basis
o The Buz folks did a really nice codec API
o Stephen Tweedie got rid of all the existing constraints of DMA to
user space
> Is there any roadmap for V4L, or indication of what new features will be
> included in it?
Im working on putting a proposal together: Basically
- Original V4L interfaces
- V4L2/Buz multiple buffer posting (non mmap)
- V4L2 format descriptions/table
- V4L2 style enumerate supported formats
- Buz codec setup/control - done in a style like the Stradis if possible
- Stradis V4L extensions for remote input/media control
Alan
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Justin Schoeman <justin () suntiger ! ee ! up ! ac ! za>
Date: 2000-05-19 8:34:57
Ben Bridgwater wrote:
>
> > Justin Schoeman wrote:
> > >
> > > PS Is this the way that things will go from now on? Is everyone going
> to
> > > dump V4L for V4L2? If anyone hasn't created a HOWTO for V4L2, I would
> be
> > > more than happy to do it myself. All I need is input.
> > >
> > 4) It does not look like v4l2 will become the standard. Instead some
> > sort of hybrid (I think Alan called it V4L+) will come in.
>
> I had previously understood that V4L2, perhaps with some modifications,
> would replace V4L. What changed?
>
> Is there any roadmap for V4L, or indication of what new features will be
> included in it?
None that I know of :->
> Is there any alternate multimedia infrastructure being developed for Linux
> that will include CODEC support?
V4L2 does include codec specifications, but is intended mainly for
hardware CODECs.
gstreamer (can't remember the URL but a search engine should get it)
aims to be a complete, open codec structure.
LiVid (www.linuxvideo.org) has "oms" which is supposed to develop into a
complete streaming media solution (probably the OpenStream you
mentioned, but I am not sure).
-justin
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Brian Ristuccia <brianr-v4l () osiris ! 978 ! org>
Date: 2000-05-21 14:07:56
On Thu, May 18, 2000 at 09:09:22PM -0400, Alan Cox wrote:
> > I had previously understood that V4L2, perhaps with some modifications,
> > would replace V4L. What changed?
>
> o Lots of people want to keep the existing API as the basis
> o The Buz folks did a really nice codec API
> o Stephen Tweedie got rid of all the existing constraints of DMA to
> user space
>
> > Is there any roadmap for V4L, or indication of what new features will be
> > included in it?
>
In particular, will it have the video frame timestamping feature of v4l2 so
I can capture video and sound with accurate audio sync?
--
Brian Ristuccia
brian@ristuccia.com
bristucc@cs.uml.edu
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Alan Cox <alan () redhat ! com>
Date: 2000-05-21 15:09:29
> In particular, will it have the video frame timestamping feature of v4l2 so
> I can capture video and sound with accurate audio sync?
Yes. There needs to be some thinking here - it wouldbe nice to have the same
timstamping api available on the audio too so you can tally stuff.
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Bill Dirks <bdirks () micron ! com>
Date: 2000-05-22 19:10:03
Alan Cox wrote:
> > In particular, will it have the video frame timestamping feature of v4l2 so
> > I can capture video and sound with accurate audio sync?
>
> Yes. There needs to be some thinking here - it wouldbe nice to have the same
> timstamping api available on the audio too so you can tally stuff.
Linux should have a multimedia clock. I would like something similar to
the Unadjusted System Time (UST) of SGI systems, a 64-bit signed integer
that counts nanoseconds. For multimedia you need a clock that counts
monotonically upward, and that cannot be set. The time-of-day is not
appropriate because a call to settimeofday would mangle any capture in
progress.
http://reality.sgi.com/cpirazzi_engr/lg/time/intro.html
I started to move in this direction with V4L2, using __s64 for a
timestamp type, but never took it as far as to release a UST-like API
for Linux. The TSC of various modern CPUs is an obvious choice for a
timebase.
The obstacle is adding the new timestamping to all the relevant drivers
and APIs.
Bill.
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Alan Cox <alan () redhat ! com>
Date: 2000-05-22 19:47:50
> for Linux. The TSC of various modern CPUs is an obvious choice for a
> timebase.
You probably ant to scale it but that isnt hard. Also for SMP boxes the
TSC may vary in start,rate per cpu and you dont want to go there.. you really dont !
> The obstacle is adding the new timestamping to all the relevant drivers
> and APIs.
Audio, video, maybe input devices - anything else ?
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Bill Dirks <bdirks () micron ! com>
Date: 2000-05-22 22:12:57
Alan Cox wrote:
> > The obstacle is adding the new timestamping to all the relevant drivers
> > and APIs.
>
> Audio, video, maybe input devices - anything else ?
I don't think so, but that's already plenty. A lot of stuff falls under
those categories. Remember user-mode code, libraries, and X Windows
video overlay displays. It's most useful if everybody is using the same
system.
Practically speaking, how doable is changing the audio APIs?
Bill.
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.
List: linux-video
Subject: Re: V4L(2)
From: Alan Cox <alan () redhat ! com>
Date: 2000-05-23 13:48:26
> video overlay displays. It's most useful if everybody is using the same
> system.
>
> Practically speaking, how doable is changing the audio APIs?
Doing surgery on the audio side is on the 2.5 list, it would have been a pre
2.4 job but we ran out of time
Alan
--
To unsubscribe: mail video4linux-list-request@redhat.com with
"unsubscribe" as the Subject.