Hi Everyone,
Two clarifications:
1) At the UofS we have been using the reference hardware to capture lectures
for 2 years now without issue capturing two video streams. The bluecherry card
that Kevin is using does not do any hardware encoding so it is fairly
lightweight to capture from and dump to the hard drive.
2) The V4LSRC code I wrote already has a videorate:
if (!v4lsrc.link(queue))
throw new UnableToLinkGStreamerElementsException(captureDevice, v4lsrc,
queue);
else if (!queue.link(videorate))
throw new UnableToLinkGStreamerElementsException(captureDevice, queue,
videorate);
else if (!videorate.link(fpsfilter))
throw new UnableToLinkGStreamerElementsException(captureDevice,
videorate, fpsfilter);
I've created a two hour capture successfully and will see if it runs into
difficulty going longer.
Cheers,
Adam
Adam McKenzie
ITS, University of Saskatchewan
Rm 61 Physics, 116 Science Place
Saskatoon SK S7N 5E2 Canada
(306) 966-8241
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Nils Birnbaum
Sent: Wednesday, February 08, 2012 12:47 AM
To: Matterhorn Users
Subject: Re: [Matterhorn-users] Capture Agent sync/dropped frame rates issue
and what are people using for their CAs?
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
