Re: [PATCH/RFC v1 0/7] Videobuf2 framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote:
> Hello,
> 
> On 2010-09-10 13:27, Mauro Carvalho Chehab wrote:
> 
> >>> 1) it lacks implementation of read() method. This means that vivi driver
> >>> has a regression, as it currently supports it.
> >>
> >> Yes, read() is not yet implemented. I guess it is not a feature that would
> >> be deprecated, right?
> >
> > Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv
> > allows receiving simultaneous streams, one via mmap, and another via read().
> > This is used by some applications to allow recording video via ffmpeg/mencoder
> > using read(), while the main application is displaying video using mmap.
> 
> Well, in my opinion such devices should provide two separate /dev/videoX 
> nodes rather than hacking with mmap and read access types.

1) It is in use so you can't just drop it.
2) The read() API is actually very useful for video devices that deal with
   compressed video streams. E.g. you can do things like 'cat /dev/video0 >foo.mpg'

It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf,
but it's always been too complex. With a new vb2 implementation it may become
actually possible.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux