Nils and I were just talking about this on a separate ticket actually, the idea of putting up a page where people could list the agent specifications they use, the configuration files, and their contact info. I think it would be a great addition to the reference specification.
I'm shocked to hear someone universities need an i7 for capture; this must be for either very aggressive encoding (high quality h264) of > 1080p content. The heat from those devices would be too much for our cabinets. I'll reiterate that the current process, sd capture with 1024 or maybe 1280 on vga, shouldn't require this kind of power. (vendors are all doing this capture on embedded ARM devices with miniscule amounts of memory, a high end desktop shouldn't be neccessary) Chris On Wed, 08 Feb 2012 09:14:49 -0800 Kevin Chan <[email protected]> wrote: > Hi Nils, > > Thanks for your info. While I have heard of other universities > running different hardware, this is the first documented case (as far > as I know) of someone specifically stating that someone is running > capture agents using i5/i7 cores. > > At UC Berkeley, we are likely to need some higher powered capture > agents to do some HD camera captures (and possibly for SD camera > captures) and that's why I have been trying to get the Opencast > Community to share their hardware/software/config setup on this list > (and even better would be on the Opencast Wiki). > > As such, can you share some basic information about your setup > (perhaps with a note on the path that led you to your particular > setup)? > > Even though we are still in our very early stages of testing/silent > piloting, if I have a few minutes today, I will try to get a "capture > agent setup page" for UC Berkeley started on the Opencast wiki so > that others can benefit from this information. > > Kevin Chan > > Operations Team > Educational Technology Services > UC Berkeley > > > On 2/7/12 10:46 PM, Nils Birnbaum wrote: > > Hi Kevin, > > besides Gallicaster, this is a general problem. Most Universities > > run i5 or i7 processor to capture sufficient framerates for > > 2-stream-recording. So you have a trade off between CPU-Power and > > framerate (and some RAM) to get a result that match with the needs > > of your institution. > > > > Regards > > Nils > > > > > >> Hi Ruben, > >> > >> Thanks for the info, your approach sounds reasonable to me. > >> > >> I am still unclear on what hardware setup you are using. I found > >> this page - > >> http://wiki.teltek.es/display/Galicaster/Hardware+recommendations > >> - so I am guessing you are probably running your captures against > >> an Intel i3 processor with some sort of Hauppauge card. > >> > >> So in summary: > >> > >> a) using the above hardware setup, you had some video sync/dropped > >> frame rate issues > >> b) these issues were fixed with "a different pipeline structure > >> with the element 'videorate' to guarantee the video stream > >> synchronization" > >> > >> In theory, adding "videorate" to the MH capture agent pipeline > >> should also fix this issue, but the placement of this element is > >> probably key to the whole thing! > >> > >> Let me know if I got any of the above wrong. > >> > >> Kevin Chan > >> > >> Operations Team > >> Educational Technology Services > >> UC Berkeley > >> > >> > >> On 2/6/12 4:51 AM, Rubén Pérez wrote: > >>> Hi all, > >>> > >>> The pipeline we are using in Galicaster is rather different than > >>> the one used in the standard capture agent in many ways, the > >>> first one coming to my mind being the fact that Galicaster needs > >>> to provide video feedback and the CA doesn't. > >>> > >>> Still, I will take a look and see if we can commit some changes to > >>> improve the synchronization quality. I cannot guarantee though. > >>> > >>> The pipeline used is in the code of Galicaster, available at > >>> www.galicaster.org<http://www.galicaster.org> . > >>> > >>> Sorry I cannot be more specific right now. When I have some spare > >>> time I'll try to document myself on this topic and try to apply a > >>> patch based on our research in Galicaster, if that's feasible > >>> without altering the current CA pipeline too much. Does this > >>> sound reasonable? > >>> > >>> Regards > >>> > >>> 2012/2/2 Kevin Chan<[email protected] > >>> <mailto:[email protected]>> > >>> > >>> Hi Ruben, > >>> > >>> Was this "fix" done against the referenced MH capture > >>> hardware or some other hardware setup? > >>> > >>> In any case, thanks for the info, it would be great if you > >>> can provide this info for the MH developers in: > >>> http://opencast.jira.com/browse/MH-8505 > >>> > >>> Also, if you can provide the full pipeline structure, that > >>> would be great (for novice pipeline constructors like me). > >>> > >>> Kevin Chan > >>> > >>> Operations Team > >>> Educational Technology Services > >>> UC Berkeley > >>> > >>> > >>> On 1/30/12 5:38 AM, Tobias Wunden wrote: > >>>> Hi Ruben, > >>>> > >>>> any chance that fix will make it back into trunk anytime > >>>> soon? It would have been great to have this in for 1.3 as well, > >>>> given that you seem to have sorted out that issue a while ago. > >>>> > >>>> Tobias > >>>> > >>>> On 30.01.2012, at 09:15, Rubén Pérez<[email protected] > >>>> <mailto:[email protected]>> wrote: > >>>> > >>>>> Hi Kevin, > >>>>> > >>>>> I can also confirm that we experienced the same frame > >>>>> drop/out of sync problem in long recordings, both in the > >>>>> capture agent and also in Galicaster's development stages. > >>>>> Finally, we discovered that the key was a different pipeline > >>>>> structure with the element 'videorate' to guarantee the video > >>>>> stream synchronization. > >>>>> > >>>>> Maybe you could try and add this element to the CA's > >>>>> standard pipeline, and see what happens. Of course, you can > >>>>> also try Galicaster :) > >>>>> > >>>>> Good luck > >>>>> Rubén > >>>>> > >>>>> On 25 Xan, 2012 07:18, "Kevin > >>>>> Chan"<[email protected] > >>>>> <mailto:[email protected]>> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> During preliminary testing of a 2h 15m capture (which > >>>>> we intend to post produce for YouTube), UC Berkeley discovered > >>>>> that the capture files for video and screen were off > >>>>> by 15m (with the screen capture via Epiphan being 15m short), > >>>>> which is more or less unacceptable to our post production folks > >>>>> (as it is very difficult for them to stitch this back > >>>>> together). This is likely to be due to dropped frame > >>>>> rate, but it is a bit difficult to confirm. > >>>>> > >>>>> I am wondering if anyone else (besides Saskatchewan > >>>>> folks, who confirmed this issue) has encounter this issue and > >>>>> how they are working around it. I imagine that lowering > >>>>> framerates and bitrates would work, though some initial > >>>>> testing using various capture agent configurations > >>>>> seems to suggest that the capture files are still off by a few > >>>>> minutes even with the CPUs being not fully taxed. > >>>>> > >>>>> We are using the reference capture agent hardware and > >>>>> very basic capture agent settings. This issue has been filed in > >>>>> MH Jira if anyone is interested: > >>>>> http://opencast.jira.com/browse/MH-8505 > >>>>> > >>>>> Finally, we have heard that there are various hardware > >>>>> and configuration setups for Matterhorn Capture Agents in > >>>>> production. I think it would be great if that we, as a > >>>>> community, can share this information (via the MH > >>>>> wiki) to help each other understand and learn about the various > >>>>> use cases and setups that are employed. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> -- > >>>>> Kevin Chan > >>>>> > >>>>> Operations Team > >>>>> Educational Technology Services > >>>>> UC Berkeley > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Matterhorn-users mailing list > >>>>> [email protected] > >>>>> <mailto:[email protected]> > >>>>> > >>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >>>>> > >>>>> _______________________________________________ > >>>>> Matterhorn-users mailing list > >>>>> [email protected] > >>>>> <mailto:[email protected]> > >>>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >>>> > >>>> _______________________________________________ > >>>> Matterhorn-users mailing list > >>>> [email protected] > >>>> <mailto:[email protected]> > >>>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >>> _______________________________________________ > >>> Matterhorn-users mailing list > >>> [email protected] > >>> <mailto:[email protected]> > >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > _______________________________________________ > > 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 -- Christopher Brooks, BSc, MSc ARIES Laboratory, University of Saskatchewan Web: http://www.cs.usask.ca/~cab938 Phone: 1.306.966.1442 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
