I'm willing to confirm if this is really working or not, so I'm attaching the patch to this email, so that you can test it by yourselves. Adam had to slightly modify it because it would not apply cleanly to his local code, and that is the version I'm attaching here.
The changes are simple enough so you can even apply them by hand. I'm looking forward to hearing from your experiences. Best regards Rubén 2012/7/12 Rubén Pérez <[email protected]> > Rüdiger, > > In theory, the "videoscale" element can handle resolution changes if it's > well configured and its output capabilities are fixed. It does not need > external signals at all. So, in theory, you don't need to unplug the cable > for it to work. > > Now, I'm not saying there was no misunderstanding between me and Adam. He > told me he had tested it and it worked, with one and several changes in the > same recording, and recordings of different lengths. I assumed he was > changing the resolution without unplugging the cable. > > > 2012/7/12 Ruediger Rolf <[email protected]> > >> Adam is on vacation, so this might take a while. >> >> But what you are talking about Rubén is not the same issue Andreas is >> adressing, I guess. You found something where we might had typo and I can >> tell that the Kangaroo patch worked with this minor bug as well. Andreas >> problem is more general: >> When I'm recording the vga and I change the resolution of the vga signal >> WITHOUT reconnecting the vga plug my image gets scrumbled. >> If I plug and unplug my vga-cable the recording is okay again! >> Matterhorn already scales the VGA-signal if it notices the resolution >> change. But unfortunatly there is not event/signal to catch for a >> resolution change if you change the resolution without reconnecting the >> cable. Waldemar spend quite some time on this with very serious debugging >> and the resolution that he can't fix this. >> >> Rüdiger >> >> Am 12.07.2012 14:20, schrieb Rubén Pérez: >> >> I couldn't test the code myself, but I asked Adam Mckenzie, who kindly >> took a look and saw no issues with resolution whatsoever. Maybe I didn't >> totally understand him, but as far as I know, the patch worked. >> >> To get a little more in detail, the code that was already in place >> defined some "caps" to be applied to the output of the kangaroo patch. >> Those caps are set at the beginning and never change along the recording. >> To "protect" those caps from change, they are accessed via a method called >> "getCaps", so that the correct values are always returned. At one point of >> the code, the "caps" variable was used instead of using "getCaps", so I >> guess that could be the source of the problem. >> >> As far as I know, with that little change, Adam couldn't reproduce the >> bug, but I invite him to answer and clarify it. >> >> Best regards >> Rubén >> >> 2012/7/12 Ruediger Rolf <[email protected]> >> >>> From what we know in Osnabrück it can not work. But maybe Ruben was >>> much mor successful than we were. >>> >>> Am 12.07.2012 12:22, schrieb Andreas Krieger: >>> >>> Then I must have misunderstood Ruben's mail. >>> To me it said that there was a one-line patch: >>> >>> Rubén Pérez wrote on Fri, 22 Jun 2012 >>> >>> I was assigned the ticket to fix the problems with the resolution >>> changes, >>> but it turns out that the code was already in place (I think it is >>> Waldemar's work). There was a bug (a one-liner) that I think was causing >>> the problems. However I couldn't test it myself since we have no >>> official >>> capture agents in Vigo anymore, so Adam Mckenzie kindly tested the patch >>> in their agents. In his experience, it seems that the agent deals well >>> resolution changes, and the resulting media is OK. >>> >>> >>> Regards, Andreas >>> >>> Ruediger Rolf schrieb am Thu, 12 Jul 2012 betreff "Re: [Opencast...": >>> >>> Andreas, >>> >>> As I pointed out several times already: there is no fix to this problem. >>> And if you want to get this fixed you have to turn to epiphan or gstreamer, >>> as this is not a Matterhorn related problem. It is somewhere within the >>> epiphan driver or gstreamer modules that the signal about a resolution >>> change gets lost. >>> >>> Rüdiger >>> >>> Am 12.07.2012 11:42, schrieb Andreas Krieger: >>> >>> Hi, >>> >>> http://opencast.jira.com/browse/MH-8655 >>> This fix did'nt make it into 1.3.1 it seems :) >>> >>> What can I do to implement the fix locally? >>> >>> Regards, Andreas >>> >>> >>> Rubén Pérez schrieb am Fri, 22 Jun 2012 betreff "[Opencast >>> Matterhorn]...": >>> >>> Date: Fri, 22 Jun 2012 12:34:15 +0200 >>> From: Rubén Pérez <[email protected]> <[email protected]> >>> Reply-To: Opencast Matterhorn >>> <[email protected]><[email protected]> >>> To: Opencast Matterhorn >>> <[email protected]><[email protected]> >>> Subject: [Opencast Matterhorn] Patch to support resolution changes not >>> in >>> 1.3.1? >>> >>> Hi all, >>> >>> This comes from this message: >>> >>> http://opencast.3480289.n2.nabble.com/Matterhorn-users-Release-1-3-1-when-to-come-tp7580482p7580503.html >>> *Rüdiger said:* >>> >>> There will be no fixes for the epiphan device regarding resolution >>> changes >>> in 1.3.1 that are not in 1.3.0 already. And the API for the epiphan >>> devices >>> has some bugs that we can not catch every resolution change. So you will >>> need the scaler. >>> >>> >>> >>> I was assigned the ticket to fix the problems with the resolution >>> changes, >>> but it turns out that the code was already in place (I think it is >>> Waldemar's work). There was a bug (a one-liner) that I think was causing >>> the problems. However I couldn't test it myself since we have no >>> official >>> capture agents in Vigo anymore, so Adam Mckenzie kindly tested the patch >>> in >>> their agents. In his experience, it seems that the agent deals well >>> resolution changes, and the resulting media is OK. >>> >>> I'm not aware of any other bugs in the API for the Epiphan devices. You >>> mean the v4l, low-level API, or you mean the Matterhorn part? If the >>> problem is in the drivers, then I agree with Rüdiger since the problem >>> is >>> outside our control and we cannot fix it. But if it's about the >>> Matterhorn >>> part, I don't think there's anything else to add. Waldemar (or whoever >>> did >>> this) did a good work and the pipeline dynamically adapts to changes in >>> the >>> video size using the 'videoscaler' element, which does not need external >>> signals to detect resolution changes. >>> >>> I'd say this was a bug fixing rather than a new feature, since no new >>> code >>> has been added. I'd very much like this to be included in the release, >>> so >>> that we can save the new adopters some money.There are still two months >>> until the winter semester, so if the agent does still have problems with >>> resolution changes (which, as I said, shouldn't happen anymore), they >>> will >>> not go undetected and people will still have time to buy scalers if they >>> really need to. >>> >>> Best regards >>> Rubén >>> >>> >>> ----------------------- >>> [email protected] >>> 01/58801 DW 41523 >>> mobil: 0664/60 588 4523 >>> TU Wien >>> DVR-Nummer: 0005886 >>> ----------------------- >>> >>> >>> _______________________________________________ >>> Matterhorn mailing list >>> [email protected] >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please email >>> [email protected] >>> _______________________________________________ >>> >>> >>> >>> -- >>> >>> ________________________________________________ >>> 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 >>> >>> >>> >>> ----------------------- >>> [email protected] >>> 01/58801 DW 41523 >>> mobil: 0664/60 588 4523 >>> TU Wien >>> DVR-Nummer: 0005886 >>> ----------------------- >>> >>> >>> _______________________________________________ >>> Matterhorn mailing >>> [email protected]http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please [email protected] >>> _______________________________________________ >>> >>> >>> >>> -- >>> >>> ________________________________________________ >>> 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 mailing list >>> [email protected] >>> http://lists.opencastproject.org/mailman/listinfo/matterhorn >>> >>> >>> To unsubscribe please email >>> [email protected] >>> _______________________________________________ >>> >> >> >> >> _______________________________________________ >> Matterhorn mailing >> [email protected]http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please [email protected] >> _______________________________________________ >> >> >> >> -- >> >> ________________________________________________ >> 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 mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ >> > >
rubenResolutionChangeFixed.diff
Description: Binary data
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
