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
