> 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
