Hi Chris, I've seen dropped frames and broken streams due to disk issues on HD ProRes@160Mbps and DVC Pro HD@120 Mbps so yes fairly high bitrates compare to average HD H.264@24Mbps but I wouldn't qualify as very high, these were already dropped down from the 1.4 Gbps of the HD SDI coming out of the camera.
I think Kevin mentioned they were going to need "higher powered capture agents to do some HD camera captures" but did not specify any codec nor camera output, unless of course I missed something which is quite possible indeed =) J. On Feb 9, 2012, at 1:03 PM, Christopher Brooks wrote: > 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 _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
