Hans Verkuil wrote: > On Friday 03 November 2006 22:16, Duncan Webb wrote: > >> Hans Verkuil wrote: >> >>> On Friday 03 November 2006 20:00, Duncan Webb wrote: >>> >>>> Hans Verkuil wrote: >>>> >>>>> On Friday 03 November 2006 18:19, Duncan Webb wrote: >>>>> >>>>>> Hans Verkuil wrote: >>>>>> >>>>>>> On Thursday 02 November 2006 19:50, Duncan Webb wrote: >>>>>>> >>>>>>>> Duncan Webb wrote: >>>>>>>> >>>>>>>>> Hans Verkuil wrote: >>>>>>>>> >>>>>>>>>> On Tuesday 31 October 2006 07:09, Duncan Webb wrote: >>>>>>>>>> >>>>>>>>>>>>> Aha, need to use VIDIOC_STREAMOFF. I'll try this out in >>>>>>>>>>>>> the next few days and let you know. >>>>>>>>>>>>> >>>>>>>>>>>> Thanks, this works quite nicely. >>>>>>>>>>>> >>>>>>>>>>>> There are a couple of things that I've noticed: >>>>>>>>>>>> >>>>>>>>>> Oops, I missed the following questions in your original >>>>>>>>>> email. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> 1) If the video device is read again after >>>>>>>>>>>> VIDIOC_STREAMOFF and reading 0 bytes, it does continue >>>>>>>>>>>> streaming. This means that it's not possible to use >>>>>>>>>>>> VIDIOC_STREAMOFF and VIDIOC_STREAMON to pause the >>>>>>>>>>>> recording. AFAICS Not a problem for what I'm doing but >>>>>>>>>>>> could be a problem if anybody wants to pause the video >>>>>>>>>>>> recording. >>>>>>>>>>>> >>>>>>>>>> STREAMOFF is not meant for pausing (there are ivtv ioctls >>>>>>>>>> for that). STREAMON is not implemented at all currently. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> 2) The end of program marker is written by >>>>>>>>>>>> VIDIOC_STREAMOFF instead of during the close. >>>>>>>>>>>> >>>>>>>>>> That's correct. You should interpret STREAMOFF as a close() >>>>>>>>>> that waits for the end of the GOP. You should not try to do >>>>>>>>>> anything after the STREAMOFF. >>>>>>>>>> >>>>>>>> I've done some more testing on this, attached is a tiny >>>>>>>> program to turn off the stream. >>>>>>>> >>>>>>>> Am I correct that to pause the stream the >>>>>>>> IVTV_IOC_PAUSE_ENCODE and IVTV_IOC_RESUME_ENCODE should be >>>>>>>> used? >>>>>>>> >>>>>>>> Two thing that I've noticed both cause an "Interrupted System >>>>>>>> Call" error. >>>>>>>> >>>>>>>> 1) If IVTV_IOC_S_GOP_END is not called >>>>>>>> 2) If the PAUSE and RESUME calls are made. >>>>>>>> >>>>>>>> After the interrupted system call a reboot is required, or at >>>>>>>> least I've not found a way to reset the driver. >>>>>>>> >>>>>>>> I'm wondering if the calls have been made incorrectly? >>>>>>>> >>>>>>> Hi Duncan, >>>>>>> >>>>>>> You are clearly going into uncharted territories here :-) >>>>>>> >>>>>>> The good news is that your code is correct, the bad news is >>>>>>> that the driver code is really broken. I've attached a patch >>>>>>> for ivtv-0.8 that fixes the bugs. The pause bug was really bad: >>>>>>> pause and resume were swapped internally! And after stopping >>>>>>> with END_GOP on an important flag wasn't cleared, so the next >>>>>>> time the read() would stop working. >>>>>>> >>>>>>> Let me know how it goes. If this is working fine for you, then >>>>>>> I'll commit the changes. >>>>>>> >>>>>> The IVTV_IOC_S_GOP_END has worked like a dream, thanks. >>>>>> >>>>>> The IVTV_IOC_PAUSE_ENCODE and IVTV_IOC_RESUME_ENCODE still seem >>>>>> to be broken. >>>>>> >>>>>> It reads two blocks after the resume and then blocks. >>>>>> >>>>>> I've done a bit more tweaking on the program, so I've attached >>>>>> it. >>>>>> >>>>> Works fine for me. Can you run ivtvctl -D95 to enable debugging? >>>>> And mail me what the kernel log says around the time the resume >>>>> blocks? >>>>> >>>> Here's the log and a patch I use to determine if the V4L2 calls >>>> are correct. >>>> >>>> Otherwise I'm using 0.8.0. >>>> >>> 0.8.0 with my patch from my previous mail, I hope. I can't tell >>> 100% but it looks like the pause/resume commands are still the >>> wrong way around >>> >>> in the driver you are using. An easy check would be to swap the >>> IVTV_IOC_PAUSE_ENCODE and IVTV_IOC_RESUME_ENCODE ioctls in your >>> test program. If it works, then you are still using the unpatched >>> driver. >>> >>> What's the output of streamoff-test when compiled with -DVERBOSE >>> and -DPAUSE? >>> >> I thought about not using the patched driver, but since the GOP_END >> worked, I decided that it had patched ok. I checked the driver times >> in the /lib/modules and they were correct. The patch applied >> cleanly, but with a few shifts: >> >> patch -Np0 -i ~duncan/ivtv-pause.diff >> patching file ivtv-ioctl.c >> Hunk #1 succeeded at 1364 (offset -31 lines). >> patching file ivtv-streams.c >> Hunk #1 succeeded at 925 (offset 21 lines). >> Hunk #3 succeeded at 1359 (offset 21 lines). >> patching file ivtv-fileops.c >> > > Weird, it works perfectly for me. I've committed the changes to the > ivtv-0.8 branch. Can you check it out from svn yourselves and use that > particular version? (or just download this: > http://ivtvdriver.org/viewcvs/ivtv/branches/0.8.tar.gz?view=tar) > > That way I'm sure you are using the correct sources. > > If that still doesn't work, then please try the trunk version of ivtv > (http://ivtvdriver.org/viewcvs/ivtv/trunk.tar.gz?view=tar). I've > committed the same changes in the trunk as well. I know it's difficult to fix when you can't reproduce the problem.
Against the http://ivtvdriver.org/viewcvs/ivtv/branches/0.8.tar.gz?view=tar I get: (It's the same with and without GOP_END) streamoff-test /dev/video1 Opened output "test.mpeg" Opened input "/dev/video1" ioctl IVTV_IOC_S_GOP_END ok IVTV_IOC_S_GOP_END 1 0, Running, bytes_read=90048, bytes_written=90048 1, Running, bytes_read=12288, bytes_written=12288 2, Running, bytes_read=32768, bytes_written=32768 3, Running, bytes_read=51200, bytes_written=51200 4, Running, bytes_read=18432, bytes_written=18432 5, Running, bytes_read=32768, bytes_written=32768 6, Running, bytes_read=51200, bytes_written=51200 7, Running, bytes_read=18432, bytes_written=18432 8, Running, bytes_read=28672, bytes_written=28672 9, Running, bytes_read=51200, bytes_written=51200 10, Running, bytes_read=20480, bytes_written=20480 11, Running, bytes_read=28672, bytes_written=28672 12, Running, bytes_read=61440, bytes_written=61440 13, Running, bytes_read=18432, bytes_written=18432 14, Running, bytes_read=18432, bytes_written=18432 15, Running, bytes_read=36864, bytes_written=36864 16, Running, bytes_read=18432, bytes_written=18432 17, Running, bytes_read=20480, bytes_written=20480 18, Running, bytes_read=32768, bytes_written=32768 19, Running, bytes_read=12352, bytes_written=12352 ioctl IVTV_IOC_PAUSE_ENCODE ok IVTV_IOC_PAUSE_ENCODE set ioctl IVTV_IOC_RESUME_ENCODE ok IVTV_IOC_RESUME_ENCODE set 30, Resumed, bytes_read=83904, bytes_written=83904 I've just tested this against the beta 3508 you posted tonight, still doesn't work, but is different. The bytes read seem a bit too big. 30, Resumed, bytes_read=131072, bytes_written=131072 31, Resumed, bytes_read=131072, bytes_written=131072 ./vbi2srt/streamoff-test Opened output "test.mpeg" Opened input "/dev/video0" 0, Running, bytes_read=131072, bytes_written=131072 1, Running, bytes_read=118720, bytes_written=118720 2, Running, bytes_read=28672, bytes_written=28672 3, Running, bytes_read=40960, bytes_written=40960 4, Running, bytes_read=36864, bytes_written=36864 5, Running, bytes_read=28672, bytes_written=28672 6, Running, bytes_read=36864, bytes_written=36864 7, Running, bytes_read=34816, bytes_written=34816 8, Running, bytes_read=38912, bytes_written=38912 9, Running, bytes_read=40960, bytes_written=40960 10, Running, bytes_read=24576, bytes_written=24576 11, Running, bytes_read=34816, bytes_written=34816 12, Running, bytes_read=34816, bytes_written=34816 13, Running, bytes_read=24640, bytes_written=24640 14, Running, bytes_read=1984, bytes_written=1984 15, Running, bytes_read=40960, bytes_written=40960 16, Running, bytes_read=45056, bytes_written=45056 17, Running, bytes_read=34816, bytes_written=34816 18, Running, bytes_read=22528, bytes_written=22528 19, Running, bytes_read=28672, bytes_written=28672 ioctl IVTV_IOC_PAUSE_ENCODE ok IVTV_IOC_PAUSE_ENCODE set ioctl IVTV_IOC_RESUME_ENCODE ok IVTV_IOC_RESUME_ENCODE set 30, Resumed, bytes_read=131072, bytes_written=131072 31, Resumed, bytes_read=131072, bytes_written=131072 32, Resumed, bytes_read=131072, bytes_written=131072 33, Resumed, bytes_read=131072, bytes_written=131072 34, Resumed, bytes_read=131072, bytes_written=131072 35, Resumed, bytes_read=131072, bytes_written=131072 36, Resumed, bytes_read=131072, bytes_written=131072 37, Resumed, bytes_read=131072, bytes_written=131072 38, Resumed, bytes_read=131072, bytes_written=131072 39, Resumed, bytes_read=131072, bytes_written=131072 ioctl VIDIOC_STREAMOFF ok VIDIOC_STREAMOFF set 40, Off, bytes_read=131072, bytes_written=131072 41, Off, bytes_read=131072, bytes_written=131072 42, Off, bytes_read=131072, bytes_written=131072 43, Off, bytes_read=131072, bytes_written=131072 44, Off, bytes_read=131072, bytes_written=131072 45, Off, bytes_read=77824, bytes_written=77824 The command prompt eventually returns, but the video devices are blocked. BTW It's a PVR-500. The machine is relatively slow P3 733MHz Regards, Duncan _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
