One of recent bug reports (#216 ) has an interesting use case - metadata track that starts after selection range end. Current logic never advances far past the end of selection, so we never process that metadata track thus "hanging" indefinitely.
Changing trim logic to handle cases like this:
introduce new "end of range" transcoder state. It is similar to "end of stream" state, but it is less "final" - track transcoder is still allowed to advance to next track or end of current track.
new logic that correctly detects "end of range" and "end of stream" states
track transcoder's "end of range" state is still reported as "end of stream" to TransformationJob, to indicate that processing of that track is done and it is ok to complete the job.
if TransformationJob is not completed, it asks a TrackTranscoder to processNextFrame. If TrackTranscoder is in "end of range" state, it will simply advance to next track or its own EoS (whichever is first) without processing any frames. This way we can reach frames in all tracks.
Fix was tested manually with the test file provided in that bug report, fix worked. Unit tests were added.
One of recent bug reports (#216 ) has an interesting use case - metadata track that starts after selection range end. Current logic never advances far past the end of selection, so we never process that metadata track thus "hanging" indefinitely.
Changing trim logic to handle cases like this:
TransformationJob, to indicate that processing of that track is done and it is ok to complete the job.TransformationJobis not completed, it asks aTrackTranscodertoprocessNextFrame. IfTrackTranscoderis in "end of range" state, it will simply advance to next track or its own EoS (whichever is first) without processing any frames. This way we can reach frames in all tracks.Fix was tested manually with the test file provided in that bug report, fix worked. Unit tests were added.