bzczb
commented
4 months ago Idea to fix problems like this:
ffmpeg_reader should be very forgiving for out of bounds reads.
- for video, reads before the start get the first frame, reads after the end get the last frame
- for audio, out-of-bounds reads get 0-samples
The enforcement of duration should be in subclip(). subclip() could take a parameter elasticity with the following values:
-
elasticity=='infinite': ignores whether it's in bounds of the original duration. result:new_clip.duration == end_time - start_time -
elasticity=='strict': assertoriginal_clip.duration >= end_time - start_time, plus a small epsilon to take floating-point error into account. result:new_clip.duration == end_time - start_time -
elasticity=='truncate': truncate the ends so it fits in the old clip. result:new_clip.duration <= end_time - start_time -
elasticity=='truncatewarn': same astruncate, but does awarn()if it truncates more than an epsilon.
The default should be truncatewarn
abingham
This little program uses
subclip()to take more than the available data in an input file, and then write the result to file:In the file writing phase I end up with an exception:
Expected Behavior
The ultimate problem with the program is that I'm trying to subclip more data than is available. So I would expect for
subclip()to complain when I ask for the impossible.If it's actually the case that out-of-bounds
subclip()calls are desirable, then I'd expect a more informative exception when the file writing eventually fails. That is, I'd like an error reporting the actual mistake I made (subclipping too much data) rather than some implementation detail (theOSErrorabove).Actual Behavior
As listed above, I get a relatively obscure and not terribly helpful exception when I do this. Here's the stack trace (trimmed to my call into
moviepycode):Steps to Reproduce the Problem
Run the little program at the top, mutatis mutandis the filenames.
Specifications