Hi again Hans I think I solved it, at least with mplayer. The correct command line was "mplayer -demuxer rawvideo -rawvideo pal:format=hm12 /dev/video32". The tip about hm12 format did I find in an earlier posting from you. Using raw-YUV it just as fast as in Windows, as you assumed. I.e. there is virtually no delay. Now the next step is to see if I can show this videostrem using Gstreamer too since my application is built based on Gstreamer.
Thanks for your help. /Ola -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans Verkuil Sent: den 15 mars 2006 23:43 To: User discussion about IVTV Subject: Re: [ivtv-users] How to lower the latency (delay) on compositevideowhen capturing (PVR 150)? On Wednesday 15 March 2006 23:08, Ola Theander wrote: > Hi Hans > > I guess you've heard it before, but I must say that I am so impressed > how much work you put into answering peoples questions, not to speak > about the work you put into the driver. Now that it's said, to my > actual reply. > > To be honest, I have no idea what differences there was when I tried > it on the Windows platform, but as you say, an mpeg-transformation is > certainly not done in an instant so it might be that it defaulted to > the raw YUV or maybe removed the number of B-frames. I've talked to > Hauppauge before buying the card and asked them about the latency, > since it so important for my application, and they said that on > Windows there should be a registry setting that circumvented the mpeg > encoding, it might be so that it was set to that by default since I > basically just installed the drivers and tried it with the bundled > sample program. > > Anyway, I'll try the B frame setting, but do you perhaps know how I > can use the raw YUV input instead of mpeg as you suggest below? I > noticed that ivtv has some switches concerning YUV but it seems to > have to do with interlacing. /dev/video32 produces a non-standard YUV format (the raw PCM audio arrives at /dev/video24, note that the audio is about 2 frames behind the video if I remember correctly). You can play the YUV with mplayer (search the mailinglist archives for the correct command invocation). I can also mail you a simple prog to convert the ivtv YUV format into something more standardized. Basically you just read a full frame at a time from /dev/video32. Hans > > Kind regards, Ola > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Hans Verkuil > Sent: den 15 mars 2006 22:53 > To: User discussion about IVTV > Subject: Re: [ivtv-users] How to lower the latency (delay) on > compositevideo when capturing (PVR 150)? > > The latency messages you see are totally unrelated. > One option is to use the raw YUV input instead of the MPEG input. > That's near instantaneous (I think). > > I can't think how they would make mpeg encoding instantaneous in > windows since mpeg encoding relies on a history. Perhaps you can play > with the number of B frames (ivtvctl -c bframes=0) so no history is > needed. If the firmware is really smart, then it might have a lower > latency. > > Hans > > On Wednesday 15 March 2006 22:00, Ola Theander wrote: > > Dear subscribers > > > > I'm right now trying out the Hauppauge PVR 150 card for use in a > > project where I need to capture composite video basically in real > > time. The video signal is received by the computer from a manually > > operated camera. The camera is mounted on a long cable which the > > computer operator guides in narrow pipes by the view on the computer > > screen. To make the operation as easy as possible for the operator I > > want as short delay as possible between actually moving the camera > > and until the movement is reflected on the computer screen. > > > > I realize that this isn't important if you e.g. capture a video from > > an analogue video camera since the delay when the video stream > > passes through the hardware/software until it's stored on the hard > > disk isn't noticeable when you later playback the video. > > > > I know that the Hauppauge card is capable of virtually no latency > > since I started out by trying it using Windows and on Windows the > > screen update when moving the camera was more or less instantaneous, > > at least the delay wasn't noticeable. > > > > The basic tests I've performed I just did "mplayer /dev/video0" and > > moved the camera. The delay seems to be in the order of 0.5 - 1.0 > > seconds before the picture is updated. If I look in the output of > > dmesg I notice one line stating "ivtv0: Unreasonably low latency > > timer, setting to 64 (was 32)" and I wonder if that might have > > something to do with this? > > > > Eventually I'll use GStreamer instead and I know that the latency in > > the 0.8 code branch is much worse that it is in the latter 0.9 and > > 0.10. I've tried my solution with GStreamer 0.10 and an external > > composite 2 firewire-dv converter so I know that it's possible to > > have quite a low delay. Now I just hope that I can do the same using > > the PVR 150. > > > > Any help on this matter would be greatly appreciated. > > > > Kind regards, Ola Theander > > > > > > _______________________________________________ > > ivtv-users mailing list > > [email protected] > > http://ivtvdriver.org/mailman/listinfo/ivtv-users > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
