On Friday 24 August 2007 00:23:10 Hans Verkuil wrote: > On Friday 24 August 2007 00:06:04 Mark Paulus wrote: > > Hans Verkuil wrote: > > > On Thursday 23 August 2007 18:00:50 Daniel Selinger wrote: > > >> Hi, > > >> > > >> I have a problem where you hopefully can help me with. > > >> > > >> > > >> closing the device and reopening it is also no option because this > > >> way i loose around 2 seconds between two files. > > > > > > The second option is to use the new VIDIOC_ENCODER_CMD ioctl to > > > stop and start the encoder each hour. You have to set the > > > V4L2_ENC_CMD_STOP_AT_GOP_END flag for the STOP command which > > > ensures that the stream is ended correctly at a GOP boundary (even > > > the program stream end marker is filled in). After executing the > > > STOP command you will need to keep on reading until read() returns > > > 0 (end of file). Only then can you close the file and open a new > > > one. > > > > > > After that you can either just read() again (this will kickstart > > > the encoder) or explicitly call the VIDIOC_ENCODER_CMD ioctl with > > > the V4L2_ENC_CMD_START command. > > > > > > Based on some experimentation it looks like the second option > > > might be > > > > > > best: the MPEG files are guaranteed to be well-formed and the time > > > lost between the stop/start looks to be minimal. > > > > > > Regards, > > > > > > Hans > > > > Once he does the close ioctl call, couldn't he start writing the > > output to both files? The first file would be closed/truncated > > correctly, and the 2nd file would have an additional little bit of > > overlap, so there wouldn't be anything lost, and just a tiny bit of > > extra? Then when he gets the 0 return, just close the old file? > > No, that doesn't work because the second file wouldn't start with a > proper MPEG header. That's just what we try to avoid. I should also > mention that the reads after the stop command finishes are effectively > instantaneous: you just empty the internal buffers, there is no > additional capturing involved. > > Regards, > > Hans > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users
hiho, after some trouble getting vanilla to boot on ubuntu feisty... they fuck around a lot in initrd, in fact a kernel without initrd won't boot the system without a lot of work on the actual root filesystem, and a kernel with built in swraid support + initrd somehow messes up the superblocks on the raid with the root filesystem on it because it tries to add partitions which were allready added by the kernel itself in some nasty way (which also renders the ubuntu default kernel unable to boot the system), didn't go deeply into that but verfied it 3 times -.- had to rebuild the raid devices manually. enough on that so switched to vanilla (finally built with ubunutu .config) + initrd. now i have running 2.6.22.5 with your latest v4l-dvb tree, v4l-utils from ivtv 1.0.2 and latest firmware. stoping and restarting the encoder just works as expected, i'm sending the start command immediately after the stop in my controlling thread, the reader thread receives an eof, next read gets data again. mpg files are fine, audio doesn't get out of sync when joining them together again. but the loss of video between two files is still noticeable, better as if i reopen the device, but still around a half up to a second. i assume this is a matter of hardware and can't be optimized.. or maybe not? if i manually stop and immediately restart the encoder with ioctl, does it depend on how fast i reread from the device after receiving eof how much video i loose between the files? or is the card buffering the data for me until the first read? (logically thinking, i asume it doesn't - will test this) this is also interesting for me just from the technical point of view, what happens when i start reading from a video device, stop reading for e.g. 5 minutes, what happens when i reread? is data between the 2 reads silently dropped? what happens when the os is on heavy load and the reads of my app occur very unregular? - video with missing parts? regards daniel _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
