Hi Kevin, For HD video recording I'd say you want to be looking at your disk I/O before your %CPU, I've seen dropped frames and even broken streams happening right there with %CPU below 20% , of course that is assuming you have no bottleneck upstream.
Cheapest reliable disks I've used in HD setups are the Seagate Cheetahs 10k. ************* Jaime Gago Systems Engineer [email protected] Entwine - Knowledge In Motion www.entwinemedia.com @entwinemedia on Twitter On Feb 8, 2012, at 9:14 AM, Kevin Chan 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 _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
