Hi Adam and Ruben, we have Epiphan VGA2USB LR here. The http://www.epiphan.com/products/frame-grabbers/vga2usb-lr/specifications/ website states something about 15-60 fps with a resolution of 1024x768, which is what we are using atm.
The problem of the bad framerate is not easily reproducible; my favorite unproved explanation of the occurance is the "USB-port theory". It comes from the experience, that plugging the Epiphan into a different port resolved the problem completely and now delivers beautiful captures. Maybe an Ubuntu problem, that if Epiphan joins a bus with the keyboard/mouse it goes down to USB 1.1 instead of 2.0; I don't know, and will not go deeper into that, until unavoidable (the problem comes back) or requested to do so :) Thanks for your input regarding setting the framerate. Atm I am happy not to have to limit anything. Funny enough also the audio recordings now are clear and without any interruptions/stoppings/leftouts. Regards, Andreas Rubén Pérez-2 wrote: > > Hi > > Nice to know that everything is working fine, despite the long time to get > it done. > > Just a remark: fwiw, in our experience, the factor that affected the > epiphan > quality was always a too high framerate, that the card couldn't handle (in > the epiphan website there's a chart depicting the maximum allowed > framerates > for each model). > > Good luck and congratulations for your success so far. > > 2011/2/9 Adam Mckenzie <[email protected]> > >> Hi Andreas, >> >> Which card are you using to capture the screen? If you are using the >> Epiphan VGA2USB like we do it actually runs at a really low FPS, around >> 5ish. I would first try using gstreamer from the command line to show >> what >> you are capturing with something like >> >> gst-launch v4l2src device=/dev/video1 ! xvimagesink >> >> or >> >> gst-launch v4lsrc device=/dev/video1 ! xvimagesink >> >> and see if you are getting the same bad FPS. >> >> If you do have a better card than this it might be that you are getting >> too >> many fps and so it can't keep up. In your >> >> /opt/matterhorn/conf/services/org.opencastproject.capture.impl.ConfigurationManager.properties >> >> >> file you can specify the framerate for each device like so: >> >> capture.device.SCREEN.framerate=15 >> >> Where SCREEN is the friendly name of your capture device. I would first >> try >> setting it to something like 30fps if you think the capture card can >> handle >> it and throttle it down to see what it can handle. If this doesn't seem >> to >> help try increasing your buffer size in the same config file like so: >> >> # Keep up to 200 frames in memory (at 5 fps, this is 2 minutes worth of >> data) >> capture.device.SCREEN.buffer.size=600 >> >> # Keep up to 512 megabytes of frames, roughly 200 frames at 1024x768 >> 24bpp >> capture.device.SCREEN.buffer.bytes=536870912 >> >> # Keep up to 2 minutes of data >> capture.device.SCREEN.buffer.time=120000000000 >> >> Cheers, >> Adam >> >> >> On Wed, Feb 9, 2011 at 10:43 AM, shinymonk >> <[email protected]>wrote: >> >>> >>> Hi, >>> >>> Yipii ! I can now successfully record from my camera ! >>> What helped was to modify the PipelineFactory.getBluecherryPipeline() >>> method >>> like this: >>> (Class located in >>> >>> /opt/matterhorn/capture-agent/matterhorn-source/modules/matterhorn-capture-agent-impl/src/main/java/org/opencastproject/capture/pipeline/PipelineFactory.java) >>> ... >>> // added/modified the highlighted parts, by AK >>> fpsCaps = Caps.fromString("video/x-raw-rgb"); >>> fpsfilter.setCaps(fpsCaps); >>> >>> Element ffmpegcolorspace = ElementFactory.make("ffmpegcolorspace", >>> null); >>> >>> pipeline.addMany(v4l2src, queue, videorate, fpsfilter, >>> ffmpegcolorspace, >>> enc, muxer, filesink); >>> logger.info("Set rgb and colorspace by AK"); >>> ... >>> if (confidence) { >>> boolean trace = >>> >>> Boolean.valueOf(properties.getProperty(CaptureParameters.CAPTURE_CONFIDENCE_DEBUG)); >>> if (!VideoMonitoring.addVideoMonitor(pipeline, fpsfilter, >>> ffmpegcolorspace, interval, imageloc, device, trace)) { >>> logger.info("VideoMonitor wont match - AK"); >>> error = formatPipelineError(captureDevice, fpsfilter, >>> ffmpegcolorspace); >>> } >>> } else { >>> if (!fpsfilter.link(ffmpegcolorspace)) >>> error = formatPipelineError(captureDevice, fpsfilter, >>> ffmpegcolorspace); >>> } >>> if (!ffmpegcolorspace.link(enc)) >>> error = formatPipelineError(captureDevice, ffmpegcolorspace, enc); >>> >>> .... >>> >>> So, this part is solved after like 25 hours of research, trying and >>> failing, >>> but thats just the way is is. >>> Thanks again for your hints and tricks ! >>> >>> Btw. if my camera.mpg shows fine now (fluent), but my screen.mpg seems >>> to >>> be >>> like on 2 pictures per second (sometimes), ie. the flow is usually not a >>> flow but sometimes a jump from picture to picture, what can I look at >>> first >>> to detect/correct the cause, in your experience ? (example: >>> http://derpi.tuwien.ac.at/krieger/Screen.mpg ) >>> >>> Regards, Andreas >>> >>> >>> shinymonk wrote: >>> > >>> > Hi Greg, Adam, Ruben, >>> > >>> > Answers inline ;) >>> > >>> >>> The camera shows OK when starting VLC-Player after fresh boot of >>> Ubuntu >>> >>> 10.4.1.LTS. >>> >>> Starting a simple capture results in a green capture with a very >>> thin >>> >>> stripe >>> >>> on the top showing camera content (ie. contents change with the >>> moving >>> >>> of >>> >>> the camera). >>> >>> And after that capture, VLC-Player won't display the camera anymore, >>> >>> instead >>> >>> we see the green picture described above. >>> >>This is a symptom of an incorrect standard setting (PAL vs NTSC) >>> > >>> >> When you installed the system, did it prompt you for the capture >>> >> standard? Which did you choose? >>> > I chose 5=PAL and 1=Composite0, and the file >>> > /opt/matterhorn/capture-agent/device_config.sh >>> > shows this, which I understand to be correct: >>> > >>> > #! /bin/bash >>> > v4l2-ctl -s 4 -d /dev/camera >>> > v4l2-ctl -d /dev/camera -i 0 >>> > >>> >>> To me it seems, that the capture client somehow modifies the v4l2 >>> >>> settings, >>> >>> since VLC shows OK before the capture, but bad after the capture. >>> How >>> >>> can >>> >>> this be prevented or circumvented ? >>> > >>> >> So the card works correctly on bootup? There is a file at (by >>> default) >>> >> /opt/matterhorn/capture-agent/device_config.sh which controls what >>> the >>> >> camera is set to. If this file is blank then Matterhorn will not >>> change >>> >> any v4l settings. >>> > >>> > The card works correctly directly after bootup, and even with >>> matterhorn >>> > started (which happens on bootup): >>> > I can see video on VLC (v4l2://). >>> > But with starting a capture 2 things happen: >>> > 1. The capture is green (except for a thin line at the right upper >>> corner >>> > showing moving content) >>> > 2. A subsequent call to VLC (v4l2://) also gives me a green picture. >>> > >>> > Only remedy atm is >>> > to switch over to NTSC (before capture) and then back to PAL (during >>> > capture) as mentioned in my previous post; then the capture will be >>> all >>> > right (lest the few seconds in the beginngin NTSC was set) >>> > >>> > As posted in my answer to Ruben I confirm this to be Adam Mckenzie's >>> issue >>> > https://opencast.jira.com/browse/MH-5404, >>> > and hope for some soon fix/workaround. >>> > >>> > ATM I'm checking the matterhorn Trunk version, whether it does any >>> better, >>> > and will report on any success/failure. >>> > -> No, also green videos is all I see. Sigh. >>> > >>> > Greetings and lots of thanks for the detailed support and ideas, >>> Andreas >>> > >>> >>> -- >>> View this message in context: >>> http://opencast.3480289.n2.nabble.com/Matterhorn-users-Problem-with-customProducer-in-capture-impl-configurationmanager-properties-tp5970958p6008507.html >>> Sent from the Matterhorn Users mailing list archive at Nabble.com. >>> _______________________________________________ >>> Matterhorn-users mailing list >>> [email protected] >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >>> >> >> >> >> -- >> Adam McKenzie >> MSc Student >> ARIES Laboratory, University of Saskatchewan >> >> Web: http://aries.usask.ca/aiwiki/Adam_McKenzie >> Mail: Advanced Research in Intelligent Educational Systems Laboratory >> Department of Computer Science >> University of Saskatchewan >> 176 Thorvaldson Building >> 110 Science Place >> Saskatoon, SK >> S7N 5C9 >> >> _______________________________________________ >> Matterhorn-users mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> >> > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > -- View this message in context: http://opencast.3480289.n2.nabble.com/Matterhorn-users-Problem-with-customProducer-in-capture-impl-configurationmanager-properties-tp5970958p6157718.html Sent from the Matterhorn Users mailing list archive at Nabble.com. _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
