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

[burek]

[00:19:51 CET] <atomnuker> jdarnley: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225867.html
[00:19:59 CET] <atomnuker> forgot I had this lying around for a month now
[00:44:15 CET] <jdarnley> thanks
[01:08:31 CET] <BBB> atomnuker: re:quant, the diff is not in C, but in that the new code is SIMDable, no? (vc2enc)
[01:09:12 CET] <atomnuker> sure
[01:13:37 CET] <atomnuker> fuck it, someone give me a time limit as a challenge for me to simd that
[01:15:14 CET] <jamrial> friday
[01:16:16 CET] <atomnuker> too long, was expecting something of the order of 30 mins, I'll try to do that in an hour
[01:22:37 CET] <atomnuker> grr, maybe even friday's too optimistic, I'd have to do golomb coding in simd and there's a large chance I'll end up with something slower than gcc
[01:23:30 CET] <atomnuker> sure I could do what the decoder does and store the quantized coeffs to a buffer but considering that depending on the subband you end up with barely a few coeffs the calling overhead will kill any gains
[02:03:34 CET] <rcombs> "this looks easy, should have it done in an hour" [10 minutes later] "on second thought"
[02:12:25 CET] <atomnuker> welp, that's why it wasn't done in the first place
[02:23:23 CET] <iive> what function exactly are you talking about?
[02:27:45 CET] <atomnuker> golomb coding
[02:30:27 CET] <iive> what function exactly are you talking about?
[02:31:11 CET] <atomnuker> put_vc2_ue_uint
[02:31:30 CET] <atomnuker> + a bit at the end for the sign if value is non-zero
[02:32:32 CET] <atomnuker> its doable on a simd reg from quantization to part of the bitstream writing (you'll need to merge the buffer you get) but I doubt you'll gain much
[02:45:51 CET] <iive> the C function looks very inefficient 
[02:47:17 CET] <iive> so, if i am getting it right, it takes a value and turns it into two bit pairs. one of the bits signals zero, the other signals the data bit?
[02:48:18 CET] <iive> one of the bits signals end of the sequence (not zero)
[02:48:39 CET] <iive> the other sis the data bit.
[02:50:01 CET] <iive> n8 ppl
[13:33:53 CET] <iive> are you still interested in optimized put_vc2_ue_uint() function?
[13:34:32 CET] <iive> I think I have something very fast and there isn't even need for SIMD.
[13:39:06 CET] <atomnuker> sure, does fate pass?
[13:39:25 CET] <atomnuker> (just needs the vsynth test)
[14:02:08 CET] <iive> atomnuker, i haven't tested with fate, but the functions are giving binary identical results, at least of the uint16_t range.
[14:02:20 CET] <iive> bigger input would overflow both functions.
[14:02:42 CET] <atomnuker> got a diff?
[14:03:11 CET] <atomnuker> we need 32 bits of precision, 16 bits overflow the transforms, especially on larger block sizes and more complex transforms
[14:03:13 CET] <BtbN> Why do people comment on random code lines on github to ask about issues?
[14:05:55 CET] <iive> atomnuker, are you still talking to me?
[14:06:13 CET] <iive> the current committed function cannot handle bigger values.
[14:08:03 CET] <iive> i see it is used for writing metadata, things like resolution, flags etc.
[14:08:37 CET] <iive> it just doesn't look efficient for writing coefficients data.
[14:17:42 CET] <atomnuker> in current git master yes, but the patch on the ml uses it to write coeffs
[14:21:29 CET] <iive> is the put_bits64 ?
[14:21:39 CET] <iive> is there put_bits_64 ?
[14:23:26 CET] <atomnuker> yes
[14:27:38 CET] <iive> what is the name of the patch?
[14:28:14 CET] <atomnuker> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225867.html
[14:39:32 CET] <iive> gah... a lookup table that does quantization and code lookup at once...
[14:51:20 CET] <iive> atomnuker, your changes should not change the generated bitstream? you are not touching/improving the current git master function to work with 32bit input...
[14:54:26 CET] <atomnuker> iive: they should work with 32bit inputs
[14:54:40 CET] <atomnuker> (well, more than 16 bits in any case)
[14:55:16 CET] <atomnuker> the function is used when the coefficient is more than 2048 in current git master
[14:55:37 CET] <iive> they use only 32 bit variables and write the result at once... there is no way to double 32 bits and keep them in single 32 bit variable.
[14:56:09 CET] <iive> so, 65535>x>2048
[14:57:12 CET] <iive> ok, I'll put another if to handle that case.
[14:57:45 CET] <atomnuker> no ifs, just do the quantization in 64 bits
[14:59:50 CET] <iive> ff_log2() is 32 bit one...
[15:01:09 CET] <iive> yff...
[15:01:14 CET] <iive> that's ok.
[15:04:56 CET] <atomnuker> add a ff_log2l which uses __builtin_clzl
[15:05:39 CET] <iive> no need, it is used on the original input, so it is 32 bit.
[15:06:47 CET] <iive> imho, the if would be better because it would handle rare (never used) case. the put_bits_64 would definitely have additional if() in it, so it might just move there.
[21:14:38 CET] <iive> atomnuker, patch sent to ml, please test it.
[21:33:01 CET] <JEEB> BBB: thank you for bringing out that side of the thing, too.
[21:38:58 CET] <jdarnley> iive: neat.  does it require atomnuker's previous patch?
[21:39:13 CET] <atomnuker> nope
[21:39:20 CET] <atomnuker> jdarnley: can you test both patches?
[21:40:12 CET] <jdarnley> Yeah
[22:07:20 CET] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/347367509 the hell is wrong with it? It just does... absolutely nothing?
[22:09:07 CET] <jdarnley> Internet issues, no?
[22:09:28 CET] <gagandeep> kierank: in line 97 of cfhd.c you have defined 'filter' function, is that something that i need to look into, as just by looking into the definition i can't figure out what it is doing or you could tell me what to look into to understand it's working
[22:09:38 CET] <jdarnley> It can't connect to the package server or something.
[22:11:24 CET] <gagandeep> kierank: also after that are buffers, there are many terms used in those functions (relating to buffers) that are new to me, so any good documentation that i can look into
[22:11:31 CET] <BtbN> https://hub.docker.com/r/ffmpeg/coverity/builds/ something seems to be horrible broken there
[22:12:20 CET] <durandal_1707> gagandeep: iirc thats core of wavelet decoding
[22:17:02 CET] <gagandeep> durandal_1707: so the filter and buffers function used in cfhd.c are something local to wavelet codecs
[22:19:41 CET] <gagandeep> also i want to know some good resource on wavelet based codecs
[22:20:15 CET] <gagandeep> or wavelet based programming standards, if available
[22:20:18 CET] <durandal_1707> gagandeep: it is just transformation 
[22:20:32 CET] <gagandeep> yeah
[22:21:04 CET] <durandal_1707> it splits low from high freq content into several layers
[22:21:55 CET] <gagandeep> k, let me check on the net for wavelet transformation resources
[22:22:14 CET] <durandal_1707> you could look at cineform ref code and compare with our native
[22:23:02 CET] <durandal_1707> it will be slow, but you would find bug immediately
[22:23:45 CET] <gagandeep> k, thanks i'll let you know if i get stuck somewhere
[23:49:52 CET] <wm4> can anyone explain why the qscale stuff in AVFrame is deprecated (but only partially?), and what the proper way to get/set it is?
[23:51:03 CET] <BtbN> Isn't qscale an mpeg2 thing, but other codecs used it for some reason, and that's what's deprecated?
[23:54:31 CET] <nevcairiel> qscale has always been badly reused by codecs it wasnt designed for
[00:00:00 CET] --- Thu Mar  1 2018