> 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.
So you stop first (you are using the V4L2_ENC_CMD_STOP_AT_GOP_END flag,
right), then start, then read until eof?
If so, then I'm not sure what the driver does in this case: the start
might be ignored or it might flush buffers. You should stop (with
V4L2_ENC_CMD_STOP_AT_GOP_END flag), read until eof and then start.
I saw almost no loss of video here.
Also note that the play back method is also a factor here. Simply doing
cat test.mpg >/dev/video16 will not show the full video since when 'cat'
reaches the end of the file the decoder is forced to stop, flushing
pending video. You need to control it using a small C program that tells
the decoder to keep going until all internal buffers are flushed.
> i assume this is a matter of hardware and can't be optimized.. or maybe
> not?
Unlikely, IF it is a hardware matter.
> 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)
As I said, I'm not 100% sure of the behavior of the driver in this
scenario. The sequence should be stop - read to eof - start.
The 'read to eof' step should be very fast as it is just emptying the
driver's internal buffers.
> 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?
If you stop reading a message will be put in the kernel log that the
application is reading too slow. Until the application starts up reading
again all new incoming frames are still read but they overwrite the
previously read frame. Think of it like a queue where the last entered
element is continuously being overwritten. Ones the read process starts up
again the queue starts moving again.
How quickly you will have to read from the device before data is lost
depends on the total size of the allocated buffers for that stream. For
the MPEG stream it's by default 4 MB which is roughly equal to 4 seconds
of data (the default settings give you about 1 MB/second of MPEG data).
But you can enlarge the allocated buffer size using an ivtv module option.
Regards,
Hans
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
