In the 2 FILTER_INIT usages, the source is already preloaded so that
extra complexity taken from FILTER_UPDATE is not necessary.
Also add forgotten "mask" argument in FILTER_{INIT,UPDATE} comments.
First pixel was computed based on invalid address read, and then
corrected by the following memcpy. After the commit, it's not computed
anymore, and memcpy fills the appropriate area.
Fixes Ticket #3387
9680 decicycles in loop_filter_v_88_16_c, 4193765 runs, 539 skips
9233 decicycles in loop_filter_h_88_16_c, 4193751 runs, 553 skips
1929 decicycles in ff_vp9_loop_filter_v_88_16_ssse3, 4194118 runs, 186 skips
2738 decicycles in ff_vp9_loop_filter_h_88_16_ssse3, 4193861 runs, 443 skips
5.978 → 5.417 overall decode time on ped1080p.webm (-threads 1)
Adding SSE2 support should be relatively trivial (just a matter of
changing the pshufb [mask_mix] with something else), patch welcome.
Introduce 2 additional registers for stride3 and mstride3 to allow
direct accesses (lea drops).
3931 → 3827 decicycles in ff_vp9_loop_filter_v_16_16_ssse3
Also uses defines to clarify the code.
Fixes use of uninitialized memory
Fixes: msan_uninit-mem_7f91f2de7764_2649_PJS_capability_tester.pjs
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to http://doc.iridas.com/index.php?title=LUT_Formats
for 3D textures, the data is also RGB, and ordered in such a way
that the red coordinate changes fastest, then the green coordinate,
and finally, the blue coordinate changes slowest:
Fixes Ticket #3236.
before:
./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv.webm -f null - 16.29s user 0.02s system 99% cpu 16.323 total
./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv.webm -f null - 16.32s user 0.01s system 99% cpu 16.351 total
./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv.webm -f null - 16.27s user 0.05s system 99% cpu 16.335 total
after:
./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv.webm -f null - 15.22s user 0.03s system 99% cpu 15.257 total
./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv.webm -f null - 15.20s user 0.02s system 99% cpu 15.237 total
./ffmpeg -v 0 -nostats -i ~/samples/vp9/etv.webm -f null - 15.19s user 0.02s system 99% cpu 15.227 total
w and h are both read as uint16 + 1 so this can not happen. A similar
change was introduced in 97962b2 / 72ca830, with the
av_log()+AVERROR_INVALIDDATA form, suggesting it could be triggerable
somehow.
Change suggested by Ronald S. Bultje.
vp8_rac_get_tree() is called with a tree of size 3, so the returned
value can not be outside [0;3]. All of the [0;3] cases are handled in
the switch, so the assert should not be triggerable by any means. A
similar change was introduced in 97962b2 / 72ca830, with the
av_log()+AVERROR_INVALIDDATA form, suggesting it could be triggerable
somehow. This assert might help static analyzer, or simply the reader.
a758c5e added probing for various tools, such as AS. Unfortunately, GNU
AS is reading stdin with -v, and thus configure is stalled with
configure arguments such as --as=as.
Fixes Ticket #1898.
1789 decicycles in idct_idct_4x4_add_c, 262136 runs, 8 skips
1839 decicycles in idct_idct_4x4_add_c, 524270 runs, 18 skips
1864 decicycles in idct_idct_4x4_add_c, 1048548 runs, 28 skips
529 decicycles in ff_vp9_idct_idct_4x4_add_ssse3, 262138 runs, 6 skips
516 decicycles in ff_vp9_idct_idct_4x4_add_ssse3, 524282 runs, 6 skips
474 decicycles in ff_vp9_idct_idct_4x4_add_ssse3, 1048565 runs, 11 skips
(~3.9x faster)
7726 decicycles in idct_idct_8x8_add_c, 1048433 runs, 143 skips
7732 decicycles in idct_idct_8x8_add_c, 2096882 runs, 270 skips
7731 decicycles in idct_idct_8x8_add_c, 4193772 runs, 532 skips
1145 decicycles in ff_vp9_idct_idct_8x8_add_ssse3, 1048549 runs, 27 skips
1137 decicycles in ff_vp9_idct_idct_8x8_add_ssse3, 2097097 runs, 55 skips
1086 decicycles in ff_vp9_idct_idct_8x8_add_ssse3, 4194188 runs, 116 skips
(~7.1x faster)
Overall decode time before commit:
16.48s user 0.03s system 99% cpu 16.526 total
16.54s user 0.01s system 99% cpu 16.566 total
16.46s user 0.03s system 99% cpu 16.511 total
Overall decode time after commit:
16.34s user 0.02s system 99% cpu 16.378 total
16.28s user 0.02s system 99% cpu 16.315 total
16.32s user 0.03s system 99% cpu 16.366 total
Tested on i7 920 with 40s 1080p footage.
This reverts commit fc5fe4804f, reversing
changes made to ffe3350098.
The factoring is broken; it's not calling the ssse3 code anymore, and
calling the mmx2 code with bad alignment. It also broke some FATE
instances.
Conflicts:
libavfilter/x86/vf_gradfun_init.c
If there is only 1 stream and seek isn't called with a specific stream
index, we pick the first (and only) one.
Regression since dbfe6110.
Fixes CID1108591.
Here is an extract of fate-samples/sub/vobsub.idx, with an additional
text at the end of each line to better identify each bitmap:
timestamp: 00:04:55:445, filepos: 00001b000 Ace!
timestamp: 00:05:00:049, filepos: 00001b800 Wake up, honey!
timestamp: 00:05:02:018, filepos: 00001c800 I gotta go to work.
timestamp: 00:05:02:035, filepos: 00001d000 <???>
timestamp: 00:05:04:203, filepos: 00001d800 Look after Clayton, okay?
timestamp: 00:05:05:947, filepos: 00001e800 I'll be back tonight.
timestamp: 00:05:07:957, filepos: 00001f800 Bye! Love you.
timestamp: 00:05:21:295, filepos: 000020800 Hey, Ace! What's up?
timestamp: 00:05:23:356, filepos: 000021800 Hey, how's it going?
timestamp: 00:05:24:640, filepos: 000022800 Remember what today is? The 3rd!
timestamp: 00:05:27:193, filepos: 000023800 Look over there!
timestamp: 00:05:28:369, filepos: 000024800 Where are they going?
timestamp: 00:05:28:361, filepos: 000025000 <???>
timestamp: 00:05:29:946, filepos: 000025800 Let's go see.
timestamp: 00:05:31:230, filepos: 000026000 I can't, man. I got Clayton.
Note the two "<???>": they are basically split subtitles (with the
previous one), which the dvdsub decoder is now supposed to reconstruct
with a previous commit. But also note that while the first chunk has
increasing timestamps,
timestamp: 00:05:02:018, filepos: 00001c800
timestamp: 00:05:02:035, filepos: 00001d000
...it's not the case of the second one (and this is not an exception in the
original file):
timestamp: 00:05:28:369, filepos: 000024800
timestamp: 00:05:28:361, filepos: 000025000
For the dvdsub decoder, they need to be "filepos'ed" ordered, but the
FFDemuxSubtitlesQueue is timestamps ordered, which is the reason of the
introduction of a sub sort method in the context, to allow giving
priority to the position, and then the timestamps. With that change, the
dvdsub decoder get fed with ordered packets.
Now the packet size estimation was also broken: the filepos differences
in the vobsub index defines the full data read between two subtitles
chunks, and it is necessary to take into account what is read by the
mpegps_read_pes_header() function since the length returned by that
function doesn't count the size of the data it reads. This is fixed with
the introduction of total_read, and {old,new}_pos. By doing this change,
we can drop the unreliable len16 heuristic and simplify the whole loop.
Note that mpegps_read_pes_header() often read more than one PES packet
(typically in one call it can read 0x1ba and 0x1be chunk along with the
relevant 0x1bd packet), which triggers the "total_read + pkt_size >
psize" check. This is an expected behaviour, which could be avoided by
having a more chunked version of mpegps_read_pes_header().
The latest change is the extraction of each stream into its own
subtitles queue. If we don't do this, the maximum size for a subtitle
chunk is broken, and the previous changes can not work. Having each
stream in a different queue requires some little adjustments in the
seek code of the demuxer.
This commit is only meaningful as a whole change and can not be easily
split. The FATE test changes because it uses the vobsub demuxer.
This fixes a bunch of possible overread in avformat with the idiom p +=
strcspn(p, "\n") + 1 (strcspn() can focus on the trailing '\0' if no
'\n' is found, so the +1 leads to an overread).
Note on lavf/matroskaenc: no extra subtitles.o Makefile dependency is
added because only the header is required for ff_subtitles_next_line().
Note on lavf/mpsubdec: code gets slightly complex to avoid an infinite
loop in the probing since there is no more forced increment.
Clément Bœsch
