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 do have one *more* question, do the video buffers start filling >>> up during the open call or during the first read? This determines >>> where the open call goes. > > During the first read. The first read starts the capture streams. > >> Is it a known feature of the ivtv driver that the SCR (system clock >> reference) times in the private stream 0xBD are very incorrect? > > I've suspected as much for a long time. > >> Here's some output showing the times. >> >> PACK_HEADER size=14 >> => scr=303423737 scr27=3371.375 >> SYSTEM_HEADER size=24 >> VIDEO_STREAM n=2010 hn=22 >> VIDEO_STREAM_0: SEQUENCE_HEADER >> VIDEO_STREAM_0: EXTENSION >> VIDEO_STREAM_0: GROUP_OF_PICTURES >> VIDEO_STREAM_0: PICTURE >> VIDEO_STREAM_0: EXTENSION >> VIDEO_STREAM_0: SLICE_0 >> PACK_HEADER size=16 >> => scr=36036 scr27= 0.400 >> PRIVATE_STREAM_1 n=804 hn=16 >> PACK_HEADER size=14 >> => scr27=3371.376 >> VIDEO_STREAM n=2034 hn=10 >> VIDEO_STREAM_0: SLICE_1 >> >> I guess that the vbi data applies to the previous picture packet. > > Yes.
Thanks, this clears up at lot. Duncan _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
