[Ffmpeg-devel-irc] ffmpeg-devel.log.20161115

[burek]

[00:07:48 CET] <nevcairiel> it appears varying  hardware either interprets the slices inside the single slicer buffer, or it doesnt
[00:07:55 CET] <nevcairiel> wonder how much I need to poke the  code to work
[00:08:20 CET] <nevcairiel> lets see if the dxva2 vc1 spec has any insight
[00:59:32 CET] <nevcairiel> wee the test passes
[00:59:37 CET] <nevcairiel> and its only slightly ugly
[01:05:15 CET] <jamrial_> nevcairiel: poke me if you need me to test anything on my hd7xxx
[01:05:24 CET] <jamrial_> although i doubt vc1 decoding changed at all compared to your rx480
[01:05:42 CET] <nevcairiel> i dont have any amd gpus ready for testing
[01:34:31 CET] <nevcairiel> none of the fate samples test field mode with slices :(
[01:42:11 CET] <nevcairiel> jamrial_: jkqxz: if you feel like testing, this works for me on dxva2 on 10091 and 20021 https://github.com/Nevcairiel/FFmpeg/commit/72aec0deece401f7a9bd776396ac3bfda639a6c0
[01:42:20 CET] <nevcairiel> (too tired to split into proper commits)
[01:43:03 CET] <jkqxz> sa10091 and sa20021 already pass on AMD with both VDPAU and VAAPI.
[01:43:57 CET] <nevcairiel> the main problem I had was that dxva2_vc1 was not designed to handle multiple slices, so that may be true for vdpau or vaapi as well, if it fails after applying the patch
[01:45:31 CET] <nevcairiel> i wonder where these samples come from
[01:45:33 CET] <jamrial_> nevcairiel: no, that commit broke vc1 dvxa for every test here
[01:45:43 CET] <nevcairiel> they smell like reference samples
[01:46:02 CET] <nevcairiel> every? lets see if i pushed the right version
[01:46:10 CET] <jamrial_> no hangs or crashes, just different crc output
[01:47:06 CET] <nevcairiel> how odd, the non-slice tests shouldnt be affected, unless i broke something, which is always possible :D
[01:47:31 CET] <jkqxz> For me the only change is that it breaks AMD VDPAU on the slice tests.  AMD VAAPI continues to work and Intel VAAPI continues to not work.
[01:49:12 CET] <jamrial_> nevcairiel: output is wrong, tons of green squares, at least on vc1_sa00040
[01:50:01 CET] <nevcairiel> guess i'll diff the data structures send to the driver then and see whats different
[01:50:16 CET] <nevcairiel> cue my handy  debug dxva2.dll wrapper that just dumps everything into a file :D
[01:50:19 CET] <nevcairiel> but tomorrow
[01:52:23 CET] <nevcairiel> its unfortunate that vdpau breaks in some way, its slice handling code is the most simple so if it would work, i would assume it would work now
[01:59:13 CET] <jkqxz> The mesa video stuff is very hacky, so I wouldn't read too much into that.  For vdpau it would be better to see it running with the nvidia driver (in some sense the reference implementation) and then work to get mesa to accept that.
[02:33:52 CET] <jamrial_> nevcairiel: any way to check if a vc1 sample uses field mode with slices?
[02:34:26 CET] <jamrial_> i have a bunch of wmv/vc1 video game trailers from years ago
[02:36:18 CET] <kierank> jamrial_: afaik the only one is planet earth blu-ray 1080i59
[02:37:54 CET] <kierank> jamrial_: https://lists.libav.org/pipermail/libav-bugs/2011-December/000608.html
[02:38:06 CET] <kierank> 1080i50 it seems
[02:39:09 CET] <kierank> nevcairiel: ^
[02:39:15 CET] <kierank> 59 actually
[02:39:18 CET] <kierank> interesting
[09:34:28 CET] <nevcairiel> kierank: thats field coded but without slices
[09:35:06 CET] <nevcairiel> the conformance samples have some some that should work like that, but i dont have the full conformance set, and I couldn't dig it up on the interwebs
[09:40:51 CET] <kierank> nevcairiel: I think mike has them
[09:40:58 CET] <kierank> And kostya
[15:09:01 CET] <cone-922> ffmpeg 03Michael Niedermayer 07master:6ea271576822: avcodec/movtextdec: Fix potential integer overflow
[15:09:02 CET] <cone-922> ffmpeg 03Michael Niedermayer 07master:a609905723c0: avcodec/movtextdec: Fix tsmb_size check==0 check
[15:09:03 CET] <cone-922> ffmpeg 03Michael Niedermayer 07master:0eb319800567: avcodec/movtextdec: Add error message for tsmb_size check
[16:43:24 CET] <wm4> michaelni: this file is detected as mpeg, even though it seems to be a perfectly normal mp3 file, are you possibly interested in looking at it? https://0x0.st/_ij.mp3
[16:47:59 CET] <jamrial> mp3 detected as something else instead of something else detected as mp3, heh
[16:56:44 CET] <nevcairiel> gotta keep our life interesting
[17:02:44 CET] <cone-922> ffmpeg 03Ronald S. Bultje 07master:83a139e3d85a: vp9: add avx2 iadst16 implementations.
[18:28:01 CET] <cone-922> ffmpeg 03Michael Niedermayer 07master:2baf36caed98: avcodec/ituh263dec: Avoid spending a long time in slice sync
[21:04:55 CET] <wbs> BBB: care to push the vp9/arm patchset?
[21:05:02 CET] <BBB> okiedokie
[21:14:05 CET] <BBB> wbs: pushed
[21:14:08 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:6409e9b6ccde: vp9dsp: Deduplicate the subpel filters
[21:14:09 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:86c5a23ee523: arm: Clear the gp register alias at the end of functions
[21:14:10 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:68caef9d48c4: arm: vp9: Add NEON optimizations of VP9 MC functions
[21:14:11 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:b4dc7c341eb0: arm: vp9: Add NEON itxfm routines
[21:14:12 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:6bec60a683a5: arm: vp9: Add NEON loop filters
[21:14:13 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:7fe898dbb949: aarch64: Add an offset parameter to the movrel macro
[21:14:14 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:1f7801c2bc93: aarch64: vp9: Add NEON optimizations of VP9 MC functions
[21:14:15 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:f43079e11cb4: aarch64: vp9: Add NEON itxfm routines
[21:14:16 CET] <cone-922> ffmpeg 03Martin Storsjö 07master:f1212e472b5f: aarch64: vp9: Implement NEON loop filters
[21:14:25 CET] <wbs> BBB: \o/ thanks!
[21:14:38 CET] <wbs> BBB: I'll do some benchmarks for showoff now
[21:14:51 CET] <BBB> very cool
[21:15:10 CET] <BBB> lets see whos faster-than-c-er, amd64 or aarch64
[21:15:51 CET] <wbs> I guess amd64, since aarch64 still only has got only 16 byte vectors
[21:15:59 CET] <wm4> michaelni: thanks
[21:21:21 CET] <BBB> wbs: we shall see, right? :-p
[21:21:37 CET] <BBB> and thanks for the patches, thats some amazing work
[21:21:49 CET] <BBB> now if only chrome would start using it
[21:23:02 CET] <wbs> BBB: the benchmarks are pretty fun, at least in the earlier ones I've done while working on it; in single thread mode, we're like marginally faster, a few percent or so. and then boom, you stop limiting it to a single thread, and it's just ridiculously faster :P
[21:25:32 CET] <BBB> you mean compared to libvpx?
[21:25:34 CET] <wbs> yeah
[21:25:37 CET] <BBB> right
[21:25:41 CET] <BBB> it doesnt really have threading
[21:26:00 CET] <BBB> I mean, it has tiling and lpf threading, but ...
[21:26:20 CET] <wbs> yeah, and when you've got a phone with 8 cores, not being able to use them is a bit of a waste
[21:30:25 CET] <BBB> maybe they want to encourage you to get hw support ;)
[21:48:14 CET] <gnafu> BBB: Gotta wait for a phone with AV1 support in hardware ;-D.
[21:49:12 CET] <gnafu> (Which considering how long I tend to keep a phone, my next one probably will have VP9 and AV1 in hardware.)
[21:50:48 CET] Action: llogan still uses free iPhone 4 girlfriend hand-me-down
[22:02:07 CET] <cone-922> ffmpeg 03Andreas Cadhalpun 07master:1abcd972c4c0: mlz: limit next_code to data buffer size
[23:12:27 CET] <cone-922> ffmpeg 03Michael Niedermayer 07master:1546d487cf12: avcodec/rv40: Test remaining space in loop of get_dimension()
[00:00:00 CET] --- Wed Nov 16 2016