Aegisub's downmixer is terrible for anything with more than two channels
(averaging all the channels together is not even vaguely close to the
correct thing to do for 5.1), so libavresample should be far better.
Audio providers should be responsible for determining whether or not
they can open a URI, since it's not really possible for anything else
to. As such move the (lack of) parsing of dummy audio URIs to
DummyAudioProvider, and try to create DummyAudioProviders in
AudioProvider::CreateProvider.
Creating an indexer can fail for reasons other than the file not
existing. This check is still not completely correct, since FFMS2 uses
the wrong error codes in a bunch of places.
When the set of changed lines is populated, only copy those lines rather
than the entire file. On large files, this makes amend commits roughly
twice as fast when video is open.
Currently this is only populated when commits are amended, for the
simple reason that it's the only time that AssFile knows what lines
changed. It is probably worth expanding this in the future.
Always store the original string form and convert it to the desired type
on demand. In most cases this is significantly faster as typically only
a few of the parameters in a line are actually read. In addition, this
makes it so that parameters which did not actually change are always
reserialized in their original form.
Delete VariableData as it's no longer used by anything.
Closes#1513.
Now that all the other junk is being dropped from the file, script info
lines are the only thing left which was a concrete AssEntry, and
AssEntry wasn't actually a very good way to store them.
Character counts are a pretty terrible measure of anything, but it's
still the main measure of length used in most subtitling standards
(because subtitling standards are written under the assumption that the
tools are terrible (which is generally an accurate assumption)).
100 no-op non-amend commits on a subtitle file with 6689 dialogue lines,
with the undo limit set to 100:
Without flyweight:
No video open:
Initial memory usage: 30.6 MB
Final memory usage: 498.0 MB
Elapsed time: 6.3 seconds
Video open, using libass:
Initial memory usage: 54.3 MB
Final memory usage: 653.3 MB
Elapsed time: 23.7 seconds
With flyweight:
No video open:
Initial memory usage: 26.0 MB
Final memory usage: 104.5 MB
Elapsed time: 3.0 seconds
Video open, using libass:
Initial memory usage: 46.7 MB
Final memory usage: 251.8 MB
Elapsed time: 13.0 seconds
No video open:
Memory usage: -79%
Time: -52%
Video open:
Memory usage: -61.5%
Time: -45%
100 no-op amend commits on a line in the middle of a subtitle file with
6689 dialogue lines, with video open:
Without flyweight:
Initial memory usage: 48.2 MB
Final memory usage: 182.3 MB
Elapsed time: 22.3 seconds
With flyweight:
Initial memory usage: 39.8 MB
Final memory usage: 165.8 MB
Elapsed time: 13.8 seconds
Note: The large jump in memory usage here is due to that the benchmark
is blocking the main thread, so at the end there are ~100 video frames
waiting to be displayed.