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
