Jaime, What kind of encoding were you using? If you're using h264 you shouldn't be pushing too much data to a 7200rpm disk to break a stream unless you're using very high bitrates...
Chris On Thu, 09 Feb 2012 13:02:39 -0800 Jaime Gago <[email protected]> wrote: > 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 -- 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
