Fair enough. It's just that when I read "we have to do an additional decoding", I thought "there's a way you don't need to decode". Anyway, your reasons seem more than reasonable :)
2012/2/9 Ruediger Rolf <[email protected]> > Hi Ruben, > > we don't have performance problems currently, so why should I consider > this. And we write the MPEG2-stream directly to file, so that this can not > have framedrops or whatever, because it is harware encoded. We would only > encounter problems in the live-streaming, but who cares about a few dropped > frames there. > > Rüdiger > > Am 09.02.2012 11:01, schrieb Rubén Pérez: > > 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 >>>>> - 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 >>> >>> >> >> -- >> >> ________________________________________________ >> 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 >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >> > > > > _______________________________________________ > Matterhorn-users mailing > [email protected]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 > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
