On Sunday 11 March 2007 17:43, Daniel Glöckner wrote:
> On Sun, Mar 11, 2007 at 02:04:10PM +0100, Hans Verkuil wrote:
> > The actual operation of a video output overlay interface is
> > identical to that of the video overlay, see section 4.2 for more
> > information.
>
> Where to set the pixel format of the video output overlay?
> Video (input) overlays don't need it to be set, because they adapt to
> the frame buffer or override the video signal.

You don't. In that respect it is the same as for input overlays from the 
point of view of v4l2.

Note that changing the contents of the framebuffer is done using a 
normal linux framebuffer device. Through that device it is possible to 
change the pixel format of the framebuffer. But mixing the framebuffer 
(aka OSD) and the video output is done transparently by the cx23415 
hardware.

> For v4l3 maybe some parts of video outputs should be moved to video
> output overlays. IMHO video outputs should define only things like tv
> standard, audio output, modulation, cropping rectangle, etc. and all
> rendering should be done via video output overlays (f.ex. one for
> MPEG and one for OSD). Then we wouldn't need that
> V4L2_CAP_VIDEO_OUTPUT_POS kludge and could use v4l2_window instead
> (which should be relative to the cropping rectangle of the video
> output).

I agree, it is a bit of a kludge, if only the spec had specified that 
applications have to zero the struct before use, then I wouldn't have 
needed that new capability. But since many apps still use v4l1 I think 
v4l3 is a loooonng way off in the future. :-)

> Video output overlays not associated with a video output should be
> able to do what vidix has tried to do: Provide access to the video
> scalers on graphics cards.
>
>   Daniel

Regards,

        Hans

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to