Re: bttv848 and mjpegtools-1.6beta

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



Hi all, 

(since many people are having the same problem with lavrec, I'd better
handle them all together, since they seem all the same) 

I suppose everyone here reporting this problem has an Athlon or a
P-III/IV as CPU, which would mean that everyone has the same problem
:-). 

On Sun, 2002-01-06 at 18:28, Hakan Lennestal wrote: 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 3076 (LWP 26316)]
> 0x400b4ccd in jcquant_sse () from /usr/lib/liblavfile-1.6.so.0
> (gdb) bt
> #0  0x400b4ccd in jcquant_sse () from /usr/lib/liblavfile-1.6.so.0
> #1  0x400b3be2 in forward_DCT_x86float32 () from /usr/lib/liblavfile-1.6.so.0
> #2  0x400af1ce in compress_data () from /usr/lib/liblavfile-1.6.so.0
> #3  0x400ac1a2 in jpeg_write_raw_data () from /usr/lib/liblavfile-1.6.so.0
> #4  0x40413622 in encode_jpeg_raw () from /usr/lib/liblavjpeg-1.6.so.0
[...]
This seems as a problem in libjpeg-mmx' SSE optimalizations during JPEG
encoding at first sight. The thing is, I cannot reproduce it when using
encode_jpeg_raw() in yuv2lav (my desktop is a P-II w/o SSE, the only
P-III here is my laptop w/o a TV-card... In other words, I can't test it
with lavrec directly...). Neither could you Andrew... 

Could it be a thread problem? Either in libjpeg-mmx or in liblavrec
itself (unproper locking, for example, between the capture and the
encoding thread?). I don't think it's a problem but it could be the
case, of course... 
A second possibility: could jcquant_sse() - in some way - be trying to 
write data to the YUV buffer? This is not really possible since it's a
kernel buffer and I'm mmap()'ing it read-only (PROT_READ) in liblavrec's
lavrec_software_init(). Of course, this can easily be changed, by
applying the following patch: 
========================================================== 
--- liblavrec.c Sun Jan  6 21:32:32 2002 
+++ liblavrec_quick_hack.c Sun Jan  6 21:32:09 2002 
@@ -1032,7 +1032,7 @@ 

    /* Map the buffers */ 
    settings->YUV_buff = mmap(0, settings->softreq.size, 
-      PROT_READ, MAP_SHARED, settings->video_fd, 0); 
+      PROT_READ | PROT_WRITE, MAP_SHARED, settings->video_fd, 0); 
    if (settings->YUV_buff == MAP_FAILED) 
    { 
       lavrec_msg(LAVREC_MSG_ERROR, info, 
========================================================== 
In the case of yuv2lav, it's not a kernel but a userspace buffer which
can be written on, so that could be an potential problem (for the ones
who have compiled from source, please test the above patch)... 

That's about all I can think of... Any other ideas, Andrew? 

Ronald 

-- 
-   .-.
-   /V\    | Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx>
-  // \\   | Running: Linux 2.2.19 and OpenBSD 2.8
- /(   )\  | http://ronald.bitfreak.net/
-  ^^-^^





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux