Announcing libv4l 0.3.1 aka "the vlc release"

Hi All,

I'm happy to announce version 0.3.1 of libv4l:
http://people.atrpms.net/~hdegoede/libv4l-0.3.tar.gz

This release has the following changes (baby steps now):

libv4l-0.3.1
------------
* Only serialize V4L2_BUF_TYPE_VIDEO_CAPTURE type ioctls
* Do not return an uninitialized variable as result code for GPICT (fixes vlc, but see below)
* Add a patches directory which includes:
* vlc-0.8.6-libv4l1.patch, modify vlc's v4l1 plugin to directly call into libv4l1, in the end we want all apps todo this as its better then LD_PRELOAD tricks, but for vlc this is needed as vlc's plugin system causes LD_PRELOAD to not work on symbols in the plugins
* camorama-0.19-fixes.patch, small bugfixes to camorama's v4l1 support, this patch only fixes _real_ bugs in camorama and does not change it to work with v4l1compat. Although it does work better with these bugs fixed :) With this patch and LD_PRELOAD=<path>/v4l1compat.so it works flawless.

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

You might want to submit those VLC specific patches upstream ...

Antoine Cellerier
dionoea

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

A very valid point, and I will as soon as libv4l gets something resembling an official release (as port of the v4l-dvb tree). I see that you are from upstream. So what are your thoughts on this, is libv4l proven enough already to submit patches?

The patches will probably need a couple of #ifdefs added to allow compilation on systems without libv4l, right?

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hi,

and another patch. The sar instruction allows only an immediate or cl as shift width.

Thanks,
Gregor

Index: libv4lconvert/jidctflt.c
===================================================================
RCS file: /var/cvs/vidsoft/extern/libv4l/libv4lconvert/jidctflt.c,v retrieving revision 1.1
diff -r1.1 jidctflt.c
95c95
< : "0"(x), "Ir"(shift), "ir"(1UL<<(shift-1)), "r" (0xff), "r" (0)
---

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Hi,

I've just included libv4l2 in our app. After after a short debugging session I noticed the following:

In the man page the ioctl prototype is defined as
int ioctl(int d, int request, ...). To catch the EINTR case I wrote a wrapper function:

int xioctl (int fd, int request, void *arg)

But as long as the request argument is int instead of unsigned long, the request gets sign extended:

xioctl (fd, VIDIOC_TRY_FMT, &fmt)
(gdb) p/x request
$2 = 0xc0d05640

int v4l2_ioctl (int fd, unsigned long int request, ...); (gdb) p/x request
$3 = 0xffffffffc0d05640

Maybe you should mention this "issue" in the FAQ or documentaion.

Cheers,
Gregor

PS: Should I submit the sar-constraint patch to Thierry myself?

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Thanks for reporting this, this has saved me quite some time while debugging issues with xawtv and kopete. I believe that the upper 32 bits added by this (obviously wrong code) get thrown away somewhere down the path to the kernel on 64 bit archs, so I've modified libv4l to just ignore the upper 32 bits to match this behavior.

Regards,

Hans

Nope I was just being slow, just like with answering this. Thanks for the testing and the patches!

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list