[linux-dvb] Re: problems with dvb-kernel

[Michael Hunold <hunold@convergence.de>]

Hello Guido,

> I thought this would only apply to the UYVY-mode? So it's wrong for both 
> 16bit modes which are available for Xv only?
No, let me clarifiy this:

VIDEO_PALETTE_YUV422 and VIDEO_PALETTE_UYVY are both YUV422 formats.
VIDEO_PALETTE_YUV422 has a YUYV byteorder,
VIDEO_PALETTE_UYVY   has a UYVY byteorder. The only difference is, that 
every two bytes are swapped.

The Xv extension of the OSS Nvidia driver now supports both of these 
formats:
- id: 0x32595559 (YUY2) corresponds to VIDEO_PALETTE_YUV422
- id: 0x59565955 (UYVY) corresponds to VIDEO_PALETTE_UYVY

To be on the safe side, you should use VIDEO_PALETTE_UYVY for 
Video4Linux-1 and V4L2_PIX_FMT_UYVY if you're using Video4Linux-2
and then use 0x59565955 (UYVY) for Xv.

Btw: at http://bytesex.org/v4l/spec/ you can find the V4L-2 specifications.

> I guess then this kind of 
> support (software-swapping) has to be reimplemented, otherwise one can just 
> throw away the dvb-s card, for me thats 2 :(((
Only if your gfx card does not support the UYVY format. In that case, 
you can grab in YUYV and swap the bytes for yourself.

> so it's of no use at all! If it would have been a car, one would get a 
> replacement for free.
This bug persists even in later revisions of the chipset.

> > 2) With V4L-1, capturing was set frame size and format, SYNC frame,
> > CAPTURE frame. V4L-2 however requires request_buffers(),
> > query_buffers(), stream_on(), queuebuffer(), dequeuebuffer() and
> > stream_off(). This semantic cannot be mapped adequately.
> > So if you resize the window, you'll get "setting format not allowed
> > during streaming capture" error messages.
> Why? it did work for v4l1... 
The problem with v4l1 is, that you cannot be sure that everything works 
the way you expect it. Mapping capture buffers was indepentent of the 
format selection and the actual capture process. You could basically 
capture frames, change the input, change the video norm and the like, 
without every being notified if it really worked, how much frames were 
captured and when the frame was captured (timestamping).

> will that not make the resizing very slow?

It will slow down the resizing, yes. One possibility is that you don't 
updated the picture when the resizing operation is in progress, ie. you 
stop capture when the user starts to resize the window and start again 
when he has finished.

But keep in mind that resizing is not a common operation if you do 
streaming capture for example for digitizing something from your analog 
video camera. Most likely you set the size once for the whole process.

> Well, currently i'am not sure which is core and which is capture - anything 
> is so strongly interwoven to make the little wonders possible at all ;-)
You should abstract this on the V4L-2 level, ie. for v4l2 write 
functions that simply wrap the REQBUFS, QUERYBUF, STREAMON, STREAMOFF,
QBUF, DQBUF, (for queueing and dequeueing) and mmap() function calls. 
You can emulate these functions with v4l1 easily. (The other way around 
it's much more painful...)

> I would really like to see if v4l2 is worth the effort, for now i do not even 
> get the bttv-v4l2 module loaded (unresolved externals) not to mention that 
> porting kvdr to the dvb-kernel would make it impossible to use for me at all 
> - for now i can at least use kvdr+vdr1.2.1+dvb_0.94 and it works.
Some facts: V4L1 will stay in the kernel after 2.6, old applications 
might work through the compatibility layer. The 2.5.x kernel series has 
the "dvb-kernel" driver incorporated, so Video4Linux-DVB means 
Video4Linux-2 in the future.

You can have both DVB and dvb-kernel driver on your system and load and 
unload them flawlessly. You could try to separate the capture functions 
from your core and write two subsystems, one for v4l1 and one for v4l2.
"xawtv" and "nvrec" do this, too, but "nvrec" is easier to understand IMHO.

> Unless things have stabilized (v4l2 _and_ the signalless-operation-problem) 
> i can't do further development.
The saa7146 v4l2 subsystem is quite stable. The only thing that's not 
working properly for "kvdr" is the backward compatibility layer.

Have a look at the appended patch: it tries to use UYVY byteorder for 
both v4l1 and xv. This gives a working picture with xv for me.

Perhaps it's possible to add the additional logic for stopping the 
capture process before setting a new format without major pain. But I'm 
quite sceptical, because this has to deal with memory mappings...

CU
Michael.




--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.