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
