On Thursday 23 August 2007 18:00:50 Daniel Selinger wrote: > Hi, > > I have a problem where you hopefully can help me with. > > I'm developing a tv-recording project for my company i work at, using > a bunch of pvr-350 cards. > The complete recording rack consists of 5 recording stations with > each 4 pvr-350 in it. 2 quatro core xeons machines for real time > transcoding to xvid and 2 SANs with each 4tb of storage for archiving > the recorded material for 6 weeks. > > lets come to my problem now, we need those recordings in pieces of 1 > hour per pvr card and recording 24/7. i tried to find some tool > which can cut mpegs into pieces but wasn't able to find one which > doesn't seek around in the inputfile - which is not possible in a > video device. > > closing the device and reopening it is also no option because this > way i loose around 2 seconds between two files. > > i put together some c code which reads the device and begins a new > file every hour to write the output to. this works kinda nice, but as > you maybe can imagine this messes up the resulting mpeg files. in > other words in some files sound starts before the video does and > video continues after the sound, some files the other way round. a/v > sync is still correct. > > does any have a idea how to cut /dev/video into hour pieces and still > producing valid mpeg2 files?
Interesting problem. I thought of three options and one of them I wanted to try myself first. I promptly discovered two driver bugs :-( The good news is that I've fixed both problems, so you really have three working options, although you will need the bleeding edge driver to get the latter two working :-) The first option is not to use some of the advanced driver functionality but instead adapt the ps-analyzer.cpp utility that's included with ivtv. It's small, simple and while it does use seeks it isn't that difficult to adapt it by adding some internal buffering code. I've never been motivated enough to add it myself, but it isn't very difficult. But there are two other, more interesting options that rely on functionality introduced when ivtv entered the kernel. Unfortunately, both options have bugs so you will need to use my v4l-dvb tree instead (http://www.linuxtv.org/hg/~hverkuil/v4l-dvb). I'll try to get the fixes in 2.6.23, but I'm not sure if I can get it backported to 2.6.22. I doubt that. You also need a preview of the new V4L2 spec containing the new ioctls, which can be found here: http://v4l2spec.bytesex.org/preview/v4l2/. 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. As far as I can tell you loose very little video if any if you do it this way, and the streams are guaranteed to be completely correct. The third option is to use the VIDIOC_G_ENC_INDEX ioctl. The firmware on the card keeps track of where each frame starts and with this ioctl you can query the driver for this data. Based on the file offsets you can split up the MPEG file at the right boundaries. 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. The ivtvrec program I used to test this is available here: http://ivtvdriver.org/viewcvs/ivtvtv/trunk.tar.gz?view=tar Note that these sources are for testing and so contain hardcoded device paths and are in no way meant to be proper programs. But ivtvrec nicely demonstrates how to use these commands. Let me know if you have more questions, this was a nice one :-) Regards, Hans _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
