Hey Rüdiger, so we have to do an additional decoding and re-encoding to h.264 for the > streaming.
Doesn't your Hauppauge model provide a "raw" video output? Have you considered using it instead the mpeg2-encoded one? We have tested two or three different models and all of them "created" three devices in the OS: one corresponding to the raw audio, other to the raw video, and other to the mpeg2-encoded combination of the former. I know that decoding mpeg2 is not very cpu-consuming, but you can give it a try anyway. Best regards 2012/2/9 Ruediger Rolf <[email protected]> > Hi Kevin, > > we only use two i7 for capturing. One of these is a Windows PC using the > Blackmagic H.264 Pro Recorder box (that's why windows) for HD-recording. > But as this box is still missing the APIs that Blackmagic promissed the > recording is still manual. The machine is quite over-powered (20-30% CPU > load while capturing 1280x800 vga and 1080i video simultanous). > The second i7 is in use for our live streaming test system, that we use > for over a semester now. If we record, enable confidence monitoring and do > h.264-live-streaming for 2 streams (SD-video only) with the Matterhorn > Capture Agent we are getting to 40-50% CPU load. So again this machine > could be slower. I production we used only single stream live-streaming, > which ran at about 30% CPU load. We are using the Hauppauge PVR-150 in all > our machines, so we have to do an additional decoding and re-encoding to > h.264 for the streaming. > Both machines are Dell Optiplex MT 980 with the cheapest quad-core i7 and > 4 GB RAM. > > In general we use Dell Optiplex 780 as recorders with a Pentium 4 Dual > Core with 2.8 Ghz and 4GB RAM. They run at 70-80% CPU load while recording > 2 streams. With the optimisations in Matterhorn 1.3 these machines can do > recording and live streaming at 90-100% CPU load, what may cause some frame > drops if we are unfortunate. For only recordings the general CPU load will > go down significantly too with 1.3. Again we are using Hauppauge PVR-150 > and epiphan VGA2USB LR on all of these machines. > > Currently if I would need to buy new computers as recorders I would > recommend a Dell Optiplex MT 790 with a i5-2400. As this would probably > have enough power for reliable live-streaming at least. > > If you are interested I can try to check how much CPU load it will take on > the i7 to capture from the epiphan device and a Blackmagic Intensity Pro > HD-capture-card. This is already on my to do list, but I had no time to > evaluate this yet. The capture card is lying on my desk for a a while > already... > > Rüdiger > > Am 08.02.2012 18:14, schrieb Kevin Chan: > > 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<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<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].**edu <[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<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].**edu <[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<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 >>>>>>> >>>>>>> Matterhorn-users@**opencastproject.org<[email protected]> >>>>>>> <mailto:Matterhorn-users@**opencastproject.org<[email protected]> >>>>>>> > >>>>>>> http://lists.opencastproject.**org/mailman/listinfo/** >>>>>>> matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >>>>>>> >>>>>>> ______________________________**_________________ >>>>>>> Matterhorn-users mailing list >>>>>>> >>>>>>> Matterhorn-users@**opencastproject.org<[email protected]> >>>>>>> <mailto:Matterhorn-users@**opencastproject.org<[email protected]> >>>>>>> > >>>>>>> http://lists.opencastproject.**org/mailman/listinfo/** >>>>>>> matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >>>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> Matterhorn-users mailing list >>>>>> >>>>>> Matterhorn-users@**opencastproject.org<[email protected]> >>>>>> <mailto:Matterhorn-users@**opencastproject.org<[email protected]> >>>>>> > >>>>>> http://lists.opencastproject.**org/mailman/listinfo/** >>>>>> matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >>>>>> >>>>> ______________________________**_________________ >>>>> Matterhorn-users mailing list >>>>> >>>>> Matterhorn-users@**opencastproject.org<[email protected]> >>>>> <mailto:Matterhorn-users@**opencastproject.org<[email protected]> >>>>> > >>>>> http://lists.opencastproject.**org/mailman/listinfo/** >>>>> matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >>>>> >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> Matterhorn-users mailing list >>>>> Matterhorn-users@**opencastproject.org<[email protected]> >>>>> http://lists.opencastproject.**org/mailman/listinfo/**matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >>>>> >>>> ______________________________**_________________ >>>> Matterhorn-users mailing list >>>> Matterhorn-users@**opencastproject.org<[email protected]> >>>> http://lists.opencastproject.**org/mailman/listinfo/**matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >>>> >>>> ______________________________**_________________ >>> Matterhorn-users mailing list >>> Matterhorn-users@**opencastproject.org<[email protected]> >>> http://lists.opencastproject.**org/mailman/listinfo/**matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >>> >> ______________________________**_________________ >> Matterhorn-users mailing list >> Matterhorn-users@**opencastproject.org<[email protected]> >> http://lists.opencastproject.**org/mailman/listinfo/**matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >> >> > > -- > > ______________________________**__________________ > Rüdiger Rolf, M.A. > Universität Osnabrück - Zentrum virtUOS > Heger-Tor-Wall 12, 49069 Osnabrück > Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 > E-Mail: [email protected] > Internet: www.virtuos.uni-osnabrueck.de > > > ______________________________**_________________ > Matterhorn-users mailing list > Matterhorn-users@**opencastproject.org<[email protected]> > http://lists.opencastproject.**org/mailman/listinfo/**matterhorn-users<http://lists.opencastproject.org/mailman/listinfo/matterhorn-users> >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
