Fixes Ticket #5032
The samples in Ticket #5032 is using \r\r\n as line breaks. Since we
already are handling \r, or \n, or \r\n as line breaks, \r\n\n will be
considered as a double line breaks. This is an issue because
ff_subtitles_read_text_chunk() will as a result stop extracting a chunk
after just one line.
So instead of parsing the SRT by "chunks" (which means splitting every
double LB), this new parser is detecting timing lines, and split the
events on this basis. While this sounds safe and simple, it needs to
take into account the event number preceding the timing line while
handling situations such as:
- event number starting at 0 or actually any number instead of 1
- event numbers not being ordered at all
- event number being followed by text garbage (this really happened,
see Ticket #4898)
- event payload containing one or multiple number (a protagonist saying
a count-down, a date or whatever) which could be confused with a
chapter number
- event number being empty (see Ticket #2167)
- all kind of weird line breaks can appear randomly like wild pokémons
- untrustable line breaks (Ticket #5032)
The sample madness.srt tries to sum up most of this into one sample,
ticket5032-rrn.srt is the file containing \r\r\n line breaks. and
empty-events-2167.srt contains empty events.
The vector mode was deprecated in ARMv7-A/VFPv3 and various cpu
implementations do not support it in hardware. Vector mode code will
depending the OS either be emulated in software or result in an illegal
instruction on cpus which does not support it. This was not really
problem in practice since NEON implementations of the same functions are
preferred. It will however become a problem for checkasm which tests
every cpu flag separately.
Since this is a cpu feature newer cpu do not support anymore the
behaviour of this flag differs from the other flags. It can be only
activated by runtime cpu feature selection.
This should fix this test failing on kfreebsd, a regression since
6e5dbe7, which decreased the CMP_TARGET by 1.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
When the interpolated value is divided by the sum of weights, no
rounding is done, which means the value is truncated. This results in
a slight bias towards dark green in the interpolated area. Rounding
properly removes the bias.
I measured this change to reduce the interpolation error by 1 to 2 %
on average on a number of sample input and logo area combinations.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
With only 7 coefficients per short window at most the extra precision
makes a difference and seems to reduce crackling and stddev even
further.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This patch does 4 things, all of which interact and thus it
woudln't be possible to commit them separately without causing
either quality regressions or assertion failures.
Fate comparison targets don't all reflect improvements in
quality, yet listening tests show substantially improved quality
and stability.
1. Increase SF range utilization.
The spec requires SF delta values to be constrained within the
range -60..60. The previous code was applying that range to
the whole SF array and not only the deltas of consecutive values,
because doing so requires smarter code: zeroing or otherwise
skipping a band may invalidate lots of SF choices.
This patch implements that logic to allow the coders to utilize
the full dynamic range of scalefactors, increasing quality quite
considerably, and fixing delta-SF-related assertion failures,
since now the limitation is enforced rather than asserted.
2. PNS tweaks
The previous modification makes big improvements in twoloop's
efficiency, and every time that happens PNS logic needs to be
tweaked accordingly to avoid it from stepping all over twoloop's
decisions. This patch includes modifications of the sort.
3. Account for lowpass cutoff during PSY analysis
The closer PSY's allocation is to final allocation the better
the quality is, and given these modifications, twoloop is now
very efficient at avoiding holes. Thus, to compute accurate
thresholds, PSY needs to account for the lowpass applied
implicitly during twoloop (by zeroing high bands).
This patch makes twoloop set the cutoff in psymodel's context
the first time it runs, and makes PSY account for it during
threshold computation, making PE and threshold computations
closer to the final allocation and thus achieving better
subjective quality.
4. Tweaks to RC lambda tracking loop in relation to PNS
Without this tweak some corner cases cause quality regressions.
Basically, lambda needs to react faster to overall bitrate
efficiency changes since now PNS can be quite successful in
enforcing maximum bitrates, when PSY allocates too many bits
to the lower bands, suppressing the signals RC logic uses to
lower lambda in those cases and causing aggressive PNS.
This tweak makes PNS much less aggressive, though it can still
use some further tweaks.
Also update MIPS specializations and adjust fuzz
Also in lavc/mips/aacpsy_mips.h: remove trailing whitespace
"Fast seek" uses linear interpolation to find the position of the
requested seek time. For CBR this is more direct than using the
mp3 TOC and bypassing the TOC avoids problems with TOC precision.
(see https://crbug.com/545914#c13)
For VBR, fast seek is not precise, so continue to prefer the TOC
when available (the lesser of two evils).
Also, some re-ordering of the logic in mp3_seek to simplify and
give usetoc=1 precedence over fastseek flag.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
As noted in a comment, pe.min in the reference encoder
is centered around current pe. The bit reservoir algo
needs pe.min to be a local minimum, because it can only
account for local PE variations. If it's set to a global
minimum as was being done, bit reservoir logic doesn't
work as efficiently.
This patch tries to forget old minimums and converge to
a local minimum without losing the stability of the
previous solution. Listening tests until now suggest this
solves numerous RC issues.
* commit '823fa7004571cb8404ca5785f9fa6e85f0f9f3d3':
fate: Rework sgi tests into a suite and add the missing ones
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This is never mentioned in the specifications, and decoders work
just as fine without it. Update the fate references since the compressed
file is smaller.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '1d62ee38894afb696674db78cee8f8d89204a8fe':
movenc: Add a unit test for signaling of the track start times
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This way, it never starts with 0xFFF0, and never trips the
ADTS "Detection" code in movenc.c.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '3eeb7edfc2a1157b7b0e0ce21ac2cd44d55d405b':
movenc: Add a unit test for frag_discont with edit lists
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
All diferences in unit tests have been acounted for.
* commit '59e8ec0aa8ab174701d01a3bfe96fedd0b7fcead':
movenc: Add an API unit test for fragmenting options/calls
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
a set ost->frame_rate does not imply CFR in ffmpeg
The changed fate tests had all wrong packet durations
(like 1/1000 or 1/90000)
There might be more cases in which is_cfr could be set
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also support disabling them as they seem to cause problems to some
Users. They are also not allowed in IRT D-10 thus the default for
mxf_d10 is not to write them
This also decreases the filesize when no user comment are stored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Contrary to the normal fate tests that run via avconv, this tests
nontrivial call sequences that are only doable via the API
(mainly for different corner cases when using the muxer for
segmenting).
The test muxes fake packet data (with extradata that looks
enough like proper data to make the file be viewable with e.g.
boxdumper) and checks the hash of the produced files. The test also
verifies that fragments produced via different call sequences remain
identical (to avoid e.g. updating the output hashes and suddenly
having fragments that used to be identical suddenly diverging), for
fragments written with frag_discont and/or delay_moov.
Signed-off-by: Martin Storsjö <martin@martin.st>
