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
