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
