Peter Kaczowka wrote:
The other problem is the bandwidth of the analog ATVEF data. I think its
maximum is (please correct me if I'm wrong):
2 bytes per line * 11 lines * 60 fields per second = 1320 bytes / second =
10.5 Kbits / second.
ATVEF-A is only line 21, 2 characters on the odd
I believe the standard you're referring to is ATVEF-A, see:
http://www.atvef.com/library/spec1_1a.html
The ATVEF-A data is on line 21 of the odd frames, along with the CC
data. It's teletext-2 format (so you can differentiate it from CC
data). Try watching some of the mid-afternoon
Peter Kaczowka wrote:
You mention "the next few years" - but in the next few years video will be
going digital; much of it already is. Isn't all the below discussion
relevant only to analog video?
Yes and No...
The current ATVEF-A standard is for analog video, but the standard is
Justin Schoeman wrote:
Gerd Knorr wrote:
Remaining overhead is page table lookups + (for bt848) risc code
generation. Even that can be reduced. We could use a flag for that.
If a application plans to reuse that buffer some hint flag can be set,
and the driver can keep the buffer locked
Should the V4L2 API be modified to return the amount of frame buffer
memory used by the video hardware?
Different video devices have different frame buffer allocation
requirements, not just when different video formats are selected (i.e.
YUV422 vs. RGB), but also other considerations for
I've got a Buz card, and want to transfer the MJPEG's to another
computer for realtime viewing.
Lavrec would be easily hackable to output the incoming MJPEG stream to
a pipe rather than a file, but I can't find any mjpeg players that
will play from an incoming stream, rather than a file.
Any
I'm trying out the videoconferencing software VIC, RAT, and SDR with
an Iomega Buz atop V4L (I heard VIC could make use of the MJPEG
hardware encoding).
Xawtv works fine with the camera, so the Buz drivers are working.
Just trying to test this (having a conference with myself), I get a
fuzzy
Problem is, I've got drivers that need to be ported (about 4). Should
I try porting v4l2-cc.[ch] to work with videodevX?
Are there some instructions for weaning these drivers away from
v4l2-cc.[ch]?
Thanks,
Chris
Justin Schoeman wrote:
Chris Worley wrote:
I'm trying to upgrade some
I've got a decoder that selects between composite/s-video/tuner
sources, and also has a CCIR port for a data source coming from an
MPEG decoder.
This seems to be a natural extension for
VIDIOC_CC_S_VIDEO_MUX/VIDIOC_CC_G_VIDEO_MUX, but that doesn't seem to
have any natural categories for an MPEG
Andrew Stevens wrote:
Jim Buzbee wrote:
Alan Cox wrote:
[EMAIL PROTECTED] wrote:
- Put bluntly: ext2 is not good for video capture
Mount the partition with the synchronous option.
uggh. For 2.2 use O_SYNC so you just slow down the video writer thread and
stream
[EMAIL PROTECTED] wrote:
- Put bluntly: ext2 is not good for video capture
Mount the partition with the synchronous option.
Chris
___
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
I haven't been able to get at the millennium.diads.com v4l2 web pages for a few days
now.
Are they mirrored somewhere?
Thanks,
Chris
--
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
Alan Cox wrote:
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
13 matches
Mail list logo
