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

[burek]

[00:29:37 CET] <cone-521> ffmpeg 03Michael Niedermayer 07master:a0341b4d74f4: avcodec/error_resilience: update indention after last commit
[01:27:24 CET] <iive> michaelni: the commit messaage have a typo "blcok"
[01:58:45 CET] <cone-521> ffmpeg 03Michael Niedermayer 07master:e371f031b942: avcodec/pngdec: Fix off by 1 size in decode_zbuf()
[12:54:23 CET] <cone-334> ffmpeg 03Rodger Combs 07master:2b202900618d: lavf/segment: fix crash when failing to open segment list
[14:15:08 CET] <wm4> man we should kill MAKE_ACCESSORS before it spreads
[15:47:02 CET] <ubitux> michaelni: http://b.pkh.me/0001-lavc-h264dec-abort-frame-threading-in-some-cases.patch
[15:47:05 CET] <ubitux> any comment?
[15:56:22 CET] <BBB> which of these projects is most appropriate for gsoc: (1) a vmaf filter, (2) vp9 loopfilter avx2, 10/12bit avx2 and tile (slice) multi-threading
[15:56:36 CET] <BBB> I also had some other ideas a few months ago but forgot about them, I should learn to make notes of good ideas :-/
[15:57:00 CET] <BBB> ubitux: I think last time I came up with mentoring ideas, it was in a discussion with you, do you remember what my idea was?
[15:57:31 CET] <ubitux> "swscale"?
[15:57:38 CET] <ubitux> ARM stuff?
[15:58:47 CET] <wm4> what's vmaf, is it yummy
[15:59:08 CET] <BBB> wm4: netflix perceptual quality metric, think psnr but not shit
[15:59:19 CET] <BBB> swscale & hmm &
[15:59:28 CET] <BBB> what did I want to do with swscale again
[15:59:40 CET] <wm4> (2) sounds like there are multiple goals to be implemented, which progressively get harder?
[15:59:46 CET] <atomnuker> BBB: everything is, slice threading isn't that difficult, vmaf would be mainly just converting c++ to c and you'd just need someone who knows SIMD
[16:00:02 CET] <atomnuker> (for the loopfilter)
[16:00:02 CET] <BBB> I dont mind if vmaf is initially C
[16:00:17 CET] <BBB> for vp9, yes I need someone that knows or is willing to learn performance programming
[16:00:53 CET] <BBB> wm4: yes that is the idea
[16:00:59 CET] <wm4> this is for ffmpeg, right?
[16:01:02 CET] <BBB> wm4: and if the student is excellent, I have some more ideas
[16:01:07 CET] <BBB> yes of course, its for gsoc
[16:01:10 CET] <BBB> ffmpeg gsoc
[16:01:32 CET] <BBB> swscale might be nice& let me think of useful things to do with it in gsoc
[16:01:35 CET] <durandal_1707> FITS decoder and encoder 
[16:01:40 CET] <wm4> not sure how vmaf fits into ffmpeg
[16:01:54 CET] <durandal_1707> Dwa decoder in exr
[16:02:35 CET] <BBB> wm4: yeah Im not 100% sure how to do it yet
[16:02:45 CET] <durandal_1707> wm4: there is already ssim and psnr in lavfi
[16:02:45 CET] <BBB> wm4: it may be partially hacking vmaf to be a lib you can link against
[16:02:58 CET] <BBB> or alternatively copying the relevant base algos into ffmpeg and copying it
[16:03:04 CET] <BBB> but that would kind of suck maybe
[16:03:14 CET] <wm4> durandal_1707: eh, ok
[16:03:15 CET] <BBB> I guess we can start with ext lib and then reimplement
[16:03:38 CET] <durandal_1707> doesnt vmaf actua:ly sucks big time?
[16:03:44 CET] <wm4> (2) sounds nicer for a gsoc, because the goals can be adjusted according to the student's talent
[16:03:59 CET] <wm4> while vmaf it's a boolean "works and done" or "crap"
[16:20:41 CET] <BBB> durandal_1707: what do you mean?
[16:22:10 CET] <cone-106> ffmpeg 03wm4 07master:c16fe1432d88: hwcontext_cuda: implement frames_get_constraints
[16:22:46 CET] <atomnuker> durandal_1707: I'd be interested in a FITS encoder/decoder too so I put myself as a backup mentor
[16:23:40 CET] <durandal_1707> BBB: there was some results on doom9 showing thats some noonsense results
[16:23:57 CET] <BBB> -eneedmoreinfo
[16:24:23 CET] <BBB> the question is not whether it can theoretically suck in some cases
[16:24:25 CET] <BBB> it probably does
[16:24:42 CET] <BBB> the question is whether it provides more useful information than other metrics, like ssim or psnr (or maybe vqf)
[16:24:53 CET] <durandal_1707> atomnuker: imho that task should not be hard at all, compared to ffa1 its piece of cake
[16:25:09 CET] <atomnuker> TD-Linux can tell more about how good vqf is
[16:28:47 CET] <durandal_1707> what we should do with sonic codecs?
[16:28:59 CET] <wm4> jkqxz: I'm confused, does vaapi need a "GPU memcpy" or not for efficient operation?
[16:37:18 CET] <BBB> ah I remember
[16:37:25 CET] <BBB> vp9/8 native decoder alpha support
[16:37:26 CET] <BBB> that was it
[16:38:04 CET] <wm4> does vp9 use the same terrible hack for webm alpha as vp8?
[16:50:21 CET] <BBB> wm4: yes
[16:50:28 CET] <BBB> I added two gsoc tasks
[16:50:31 CET] <BBB> well see if anyone wants them
[16:51:11 CET] <michaelni> ubitux, why does the nal based check not work / is not sufficient ?
[16:52:35 CET] <ubitux> michaelni: i don't know, it's just a restauration of the previous code
[16:53:24 CET] <ubitux> restoration*
[17:11:54 CET] <philipl> BtbN: will you merge Pavel's updated change (dimensions only) or do you want me to do it?
[17:20:59 CET] <wm4> I'm still slightly against them, but whatever
[17:31:22 CET] <michaelni> ubitux, iam not sure the comment matches the code
[17:32:02 CET] <ubitux> i can drop the comment
[17:32:38 CET] <michaelni> i dont mind if the code is put back but i like to know why its needed
[17:34:33 CET] <ubitux> well the question is the same as why was it needed before
[17:34:47 CET] <ubitux> i'm not the one who wrote it :p
[17:36:21 CET] <michaelni> well before the change that was added changed a never multithread to a sometimes continue now it does a always to sometimes IIUC
[17:38:35 CET] <michaelni> i dont mind if you disable multithread for 2 fields per packet but this also disables it for 1 field per packet i think
[17:38:48 CET] <michaelni> it might be a very obvious issue that i just forgot
[17:41:08 CET] <Chloe> TimothyGu: do you qualify for GSoC yet?
[17:44:06 CET] <TimothyGu> Chloe: nope
[17:45:02 CET] <Chloe> :/
[17:46:06 CET] <TimothyGu> at least I don't think so
[17:46:43 CET] <Chloe> pm?
[17:47:07 CET] <BtbN> philipl, haven't looked at the new patch yet.
[18:01:05 CET] <jkqxz> wm4:  By "GPU memcpy" you mean "CPU memcpy using special instructions suitable for GPU memory", right?  If so, no.  The double copy, the hard half of which is GPU-driven, is of similar performance.
[18:02:41 CET] <wm4> yes, copy from uncached memory, or something
[18:03:20 CET] <wm4> I thought that it was required with vaapi under some situations
[18:04:13 CET] <wm4> this was apparently on ivybridge
[18:06:04 CET] <jkqxz> On the platforms I tested (admittedly only back to Haswell), the double copy was always much better for single-thread.  Magic memcpy wasn't immensely worse, but could only actually win with many threads.
[18:07:24 CET] <jkqxz> Also magic memcpy was relatively terrible on Braswell, double copy always wins by a large margin there.
[18:08:18 CET] <jkqxz> Also also, you can't map multiple-plane VAAPI surfaces with mesa, so you can't use magic memcpy there at all.
[18:14:48 CET] <wm4> hm sounds good enough, maybe
[18:20:01 CET] <cone-106> ffmpeg 03Pavel Koshevoy 07master:9ea299858657: avcodec/cuvid: fail early if GPU can't handle video resolution
[18:29:21 CET] <TD-Linux> BBB, maybe you mean VQM?
[18:29:34 CET] <BBB> yes
[18:31:04 CET] <TD-Linux> VQM is a collection of tools with PSNR-like measurements that I think are useless
[18:31:11 CET] <TD-Linux> VMAF, as far as I can tell, is pretty good
[18:31:40 CET] <TD-Linux> it also does have the property of saturating. e.g. 100 is "visually lossless" and it won't score above that. it can be handy or not
[18:32:32 CET] <TD-Linux> it's luma-only, but does have the unique property of being the only metric we have that does frame differences.
[19:12:04 CET] <atomnuker> TD-Linux: it does frame differences? how is that worked into the score then?
[19:21:33 CET] <ubitux> michaelni: afaict it was disabling multithreading also before the merge
[19:21:49 CET] <ubitux> i'm pretty fine if you make that condition finer
[19:22:07 CET] <ubitux> i'm trying to fix a regression here though
[19:29:10 CET] <TD-Linux> atomnuker, I think it's a simple subtraction between frames to compute difference, then fed into the SVD. I haven't looked closely.
[19:32:42 CET] <TD-Linux> err what I said was mostly wrong:
[19:32:43 CET] <TD-Linux> https://github.com/Netflix/vmaf/blob/master/feature/src/motion.c
[19:33:09 CET] <TD-Linux> but it is just one of the metric inputs to svd. and it's very simple, no motion compensation or anything.
[19:51:18 CET] <michaelni> ubitux, how can the regression be reproduced ?
[19:51:42 CET] <ubitux> make fate-h264-attachment-631 THREADS=8
[20:01:08 CET] <michaelni> ubitux, thats the only one failing ? (here its the only fate test)
[20:02:04 CET] <ubitux> yes
[20:02:16 CET] <michaelni> ok
[21:35:00 CET] <TD-Linux> one also caution for a ffmpeg implementation of VMAF, if it produces different results than the reference VMAF implementation I'd consider its existence a net loss
[21:35:17 CET] <TD-Linux> in particular it might be tempting to reuse SSIM calculation from other parts of ffmpeg. don't.
[21:36:36 CET] <durandal_1707> TD-Linux: why?
[21:37:20 CET] <TD-Linux> durandal_1707, the implementation in vmaf gives different scores from the ffmpeg one, because of rescaling and image border behavior
[21:37:54 CET] <TD-Linux> I mean, you can share code between them, but you need to be really careful.
[21:40:03 CET] <durandal_1707> what rescaling?
[21:43:30 CET] <bofh_> t/win 22
[21:43:44 CET] <bofh_> bleh.
[21:45:07 CET] <bofh_> atomnuker: yeah it turns out during testing I had a bug somewhere that was being hard to ferret out and then the term started. apologies, I think I found it now. btw, it would be nice if I could do another transpose in the pre-order so the fft5 stride is 1 instead of 3 (otherwise the only sensible thing is merging the fft5s into the function)
[21:46:01 CET] <bofh_> also that Metasound bug sounds similar but not quite identical to a similar issue I found with the TwinVQ decoder (comparing against Yamaha's encoder/decoder), though I never did track down where the issue was
[21:47:01 CET] <bofh_> (should I make a separate thread for that since it's in a different codec? though I suspect it's in the shared code)
[21:50:51 CET] <atomnuker> bofh_: so you'd do 3 5-point ffts on [0:4], [5:9] and [10:14] and then recombine them in the 15 point fft?
[21:51:50 CET] <atomnuker> that sounds fine, would remove the very annoying and costly loads in fft5 to account for the stride
[21:53:44 CET] <atomnuker> and it's just a transpose so you only need to adjust the LUT
[22:35:29 CET] <michaelni> ubitux, alternative patch fixing it posted
[22:37:21 CET] <ubitux> what does "has_slice" mean? maybe "// slice NAL is found in the last packet"?
[22:37:28 CET] <michaelni> yes
[22:37:35 CET] <ubitux> please add such a comment
[22:38:01 CET] <ubitux> and fine with me if it works, you know that decoder better than me ;)
[22:39:14 CET] <ubitux> michaelni: btw, why not local to the function?
[22:39:21 CET] <ubitux> does it really needs to be in the context?
[22:39:47 CET] <ubitux> it looks like it could be local to decode_nal_units
[22:39:47 CET] <michaelni> we need to get it to ff_h264_field_end or we need a different condition in it
[22:39:56 CET] <ubitux> ah
[22:39:59 CET] <ubitux> OK
[22:40:01 CET] <michaelni> it doesnt need to be in the context
[22:40:33 CET] <michaelni> i can add a argument to ff_h264_field_end() if preferred ?
[22:41:04 CET] <ubitux> it could be better as i'm not a big fan of that stateful logic
[22:41:15 CET] <ubitux> but that's just my opinion
[22:46:37 CET] <ubitux> you could reuse that "in_setup" variable
[22:46:46 CET] <ubitux> unless i'm missing something
[22:46:52 CET] <ubitux> maybe that's chaning its meaning
[22:47:43 CET] <michaelni> ubitux, how do you prefer i get has_slices out of decode_nal_units() ?
[22:51:38 CET] <ubitux> i don't see much possibilities
[22:51:56 CET] <ubitux> unless you move ff_h264_field_end inside decode_nal_units
[22:52:24 CET] <ubitux> i'd pass a pointer
[22:53:19 CET] <ubitux> but i'm fine with any fix as long as it is documented you know
[22:53:26 CET] <ubitux> i won't bikeshed about it
[00:00:00 CET] --- Tue Jan 24 2017