Judy, Yes, my mention of the Engage Player was in response to your mention of the QT Player. Now I understand your chain of thoughts. The way I see it, it's not that MH cannot handle tracks with different lengths, but some assumptions were made when implementing some services that may cause conflicts. However, if that's so, extreme care must be taken so that recordings with tracks that differ in length won't make it to the system, to avoid the unexpected problems that this may cause, and in Matterhorn such "length check" is not done. At least, not in MH 1.2, which is the version we have in production currently. When I was testing the trim "threshold" feature in our 1.2 development MH, I didn't have any problem to ingest one media package with a track more than 10 minutes longer than the other. The MP got processed and made it to the trim operation, several times.
I'm saying this because I'm all against adding unneeded data, when all can be correctly handled just by making the right assumptions in the source code. I totally agree with your last paragraph, except for the "we have no conditional hold" part. I do think we could include a conditional hold if the inspection operation detects an difference in track durations too large, and perhaps allow the admins to edit metadata (e.g. to change the description) or take adequate measures. I think the Episode Service and the new retry strategies can add some value to this, too. Regards Rubén 2012/5/8 Judy Stern <[email protected]> > Hi, Ruben. > > If the full content of a track never makes it to Engage (e.g. because no > threshold was specified or because the mediapackage duration was set to the > shortest track) , does it matter what the Engage player is capable of? (I'm > not sure if you're bringing up the Engage Player because I mentioned > QuickTime Player, but QT Player was an editing tool not just a viewing > tool. Or maybe there's something I'm missing.) The reason I suggested > "padding" is in order to make the tracks equally long so that MH (which > can't handle tracks of different lengths) could handle *content* of > different lengths. > > I agree that a user (student) is likely to be confused if one track is > longer than the other, but it still feels like it should be allowed in some > cases (e.g. the recording of one track failed partway thru but the part > that was successfully recorded was valuable and the full content of the > other track is valuable), as long as the admin user is warned (and could > potentially include text in the media description to explain the oddity to > viewers). If your proposal makes it not too burdensome for the admin to > knowingly permit the distribution of a mediapackage with tracks of > different lengths, I'm all for it. (In the case where there is no trim hold > is selected, since we have no "conditional hold", e.g. "hold only if a > problem is detected", I'd still lean towards distributing the whole thing, > but with a warning sent to the admin so that he/she can fix & redistribute > a trimmed version.) > > Judy > > > > On May 3, 2012, at 2:51 PM, Rubén Pérez wrote: > > Judy, > > The Engage player has no problems to play streams with different lengths. > The shorter simply stops playing while the other keeps going until the end. > That's why it doesn't matter if we trim the tracks at different points. The > difference limit is not about technical problems, but about perception > --users will notice something is wrong if one of the tracks is much longer > than the other. > > With my proposal, you can specify the "tolerance" or "threshold" you want. > The point is, that threshold doesn't apply to the difference between the > initial duration of the tracks, but to the difference between the duration > AFTER the tracks are trimmed. In other words, I'm implicitly assuming that > the important tracks are those resulting from the trimming operation, while > the original ones are somewhat less important. Then, it doesn't matter that > the tracks differ 5 minutes, if then I set the trimming point 6 minutes > before the end of the longer track, which means those 6 minutes are > unimportant or not wanted. The difference between this and taking the > shortest track duration as the "Mediapackage duration" is that in this > latter case we don't control the interval that's being (implicitly) trimmed. > > Still, I agree that perhaps the difference should be specified in seconds > rather than in milliseconds. That will allow to specify longer intervals, > while I don't think this application needs a finer precision. > > Regards > Rubén > > 2012/5/3 Judy Stern <[email protected]> >> >> still may contain relevant or interesting contents which would be ignored. >> >> I am worried about this, too, and wonder if it doesn't make sense (and if >> there isn't a technical reason) to take Ruben's work even a step further >> and default to a large tolerance/threshold, and/or simply "pad" the shorter >> track(s) with silence/blank screen in order to equal the length of the >> longest track. (Maybe not a great model, but this was the way QuickTime >> Player worked for adding tracks together, i.e. in parallel, and it always >> felt okay to me.) I'd include a warning, too, about the difference in track >> content lengths. I think this is better than what would effectively be >> deleting content if MP is truncated to length of shortest track. >> >> Judy >> >> On May 2, 2012, at 5:13 AM, Rubén Pérez wrote: >> >> Hi Tobias, >> >> I'm aware that the track length is never *exactly* the same, mostly >> because Gstreamer does not stop the pipeline elements synchronously, but >> that differences are minimal and shouldn't affect the correct behavior of >> the composer. Still, we have seen issues when the trim point is set at the >> end (or in the very final part) of the recording, which obviously means >> that at least one of the tracks was significantly shorter than the others, >> but the inspection service didn't complain about that. >> >> You mention the inspection service should detect tracks are different in >> length, but then you ask about a reasonable threshold (or "tolerance", as I >> called it) in those length differences. This makes me wonder about the >> mechanism the inspection service uses to tell when tracks have the same >> length or not, and some threshold is already assumed when checking that. >> For the record, I ingested (using the upload UI) two tracks from different >> recordings which were more than 10 minutes different in length, in our 1.2 >> installation, and the inspection didn't fail. >> >> I'm not sure if making the mediapackage's duration being that of the >> shortest track makes sense, because it implicitly discards the last part of >> the tracks longer than that duration, but that still may contain relevant >> or interesting contents which would be ignored. Besides, I believe we >> shouldn't be strict in the inspection part, because that way the videos can >> make it to the trimming operations, where that differences can be solved. >> If more editing operations are added in the future, incorrect videos should >> be allowed to go through, so that they can be fixed using the tools >> available. >> >> What I have done locally, and I'm willing to commit to the trunk if it >> seems reasonable, is adding a new parameter to the trimming operation. I >> called it "duration-tolerance", but perhaps something with the word >> "threshold" would be more understandable. The parameter indicates a length >> in milliseconds, which represents how shorter than the trimming point a >> certain track can be, without making the operation fail. Specifically, for >> each track, it may occur that: >> >> - The trimming point is within the track length: The operation works >> as expected. >> - The trimming point is *beyond* the track length: >> - If a tolerance (threshold) hasn't been specified, the operation >> fails. >> - If a tolerance (threshold) is specified, then: >> - If the difference between the track duration and the trimming >> point is less than the tolerance, then the track is trimmed at its >> end >> instead. So, it remains shorter than the other tracks, but the >> difference >> is considered acceptable. >> - If the difference between the track duration and the trimming >> point is greater than the tolerance, then the operation fails. >> >> >> On a more theoretical aspect, if we allow for tracks of different lengths >> to coexist in the same MP, the MP's "duration" parameter loses a part of >> its meaning. This can be clearly seen in the trim operation handler, which >> checks that the trim "out" point is within the MediaPackage duration, but >> it may still fail afterwards, when the composer tries to trim a track at >> the point X, but the track is shorter than X. >> >> 2012/5/1 Tobias Wunden <[email protected]> >> >>> Hi Ruben, >>> >>> > I just created http://opencast.jira.com/browse/MH-8783 and I would >>> like to know if people is observing the same issues as ourselves here in >>> our installation. >>> >>> up until now, service implementations are expecting tracks to be of >>> equal length. There used to be a check in the inspection service that would >>> reject mediapackages that contained tracks of varying lengths. However, >>> what do you do if tracks differ by miliseconds? Or in other words, what's a >>> reasonable threshold? >>> >>> That being said, it would probably make sense to change the current >>> behavior of the mediapackage's duration to be that of the shortest track. >>> If we are going to allow tracks of differing lengths, some of the services >>> will need to be reworked beforehand. >>> >>> Tobias >>> _______________________________________________ >>> 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 > > > > _______________________________________________ > 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
