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

[burek]

[02:51:40 CET] <cone-015> ffmpeg 03Michael Niedermayer 07master:dc0b9b218c19: avcodec/h264_ps: Forward errors from decode_scaling_list()
[02:51:40 CET] <cone-015> ffmpeg 03Michael Niedermayer 07master:6e913f212907: avcodec/vp56: Reset have_undamaged_frame on resolution changes
[04:13:05 CET] <cone-015> ffmpeg 03Steven Liu 07master:51e3501993e3: ffprobe: add AVCodecContext help message into ffprobe
[05:40:06 CET] <adeel1> durandal_1707: I have tried adding " everywhere even in the middle of pixels section, but it still works fine
[09:59:00 CET] Last message repeated 1 time(s).
[10:28:52 CET] <durandal_1707> adeel1: really? im really dont have time to guide you through every single step
[10:53:45 CET] <durandal_1707> also test with 5k number of colors
[11:03:56 CET] <adeel1> durandal_1707: I was merely stating what I found. Okay, let me check for more colors.
[11:27:26 CET] <adeel1> durandal_1707: Using GIMP, I have converted a 2048x1356 image to XPM, and I'm getting "unsupported number of chars per pixel" error. However, last night I used a web based converted at it worked!
[11:29:36 CET] <durandal_1707> adeel1: im not going to help you this time, you are on your own
[11:57:01 CET] <cone-699> ffmpeg 03Moritz Barsnick 07master:114bbb0b74ed: libavfilter/avf_showwaves: make sqrt and cbrt scale option values available to showwavespic by name
[12:01:41 CET] <adeel1> durandal_1707: got it to work. I had to remove cpp ==2 check, and add 94 * 94 * 94 in av_fast_padded_malloc
[12:02:34 CET] <durandal_1707> but that allocates too much when not needed
[12:04:21 CET] <adeel1> durandal_1707: yes, it allocates 94 * 94 * 94  when cpp !=2. I'll add 3 checks if cpp == 1 then 94... and so on
[12:13:22 CET] <adeel1> durandal_1707: I have added this updated check:     av_fast_padded_malloc(&x->pixels, &x->pixels_size, cpp == 1 ? 94 : cpp == 2 ? 94 * 94 : 94 * 94 * 94);
[12:13:57 CET] <durandal_1707> thats wrong and ugly
[12:23:05 CET] <adeel1> durandal_1707: Would you prefer this?     if (cpp == 1)         av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94);     else if (cpp == 2)         av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94 * 94);     else         av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94 * 94 * 94);
[12:26:51 CET] <durandal_1707> adeel1: no, you missed point
[12:27:13 CET] <adeel1> durandal_1707: it's wrong?
[12:27:25 CET] <nightlingo> I would like to change ffmpegs code, adding an option to skip writing the mdat part when performing a conversion. Would that be too difficult?
[12:28:19 CET] <durandal_1707> adeel1: wrong, incomplete, buggy
[12:53:27 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:31e41350d283: arm: vp9itxfm: Avoid .irp when it doesn't save any lines
[12:53:28 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:52c7366c83ab: aarch64: vp9itxfm: Restructure the idct32 store macros
[12:53:29 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f8fcee0daf42: arm: vp9itxfm: Make the larger core transforms standalone functions
[12:53:30 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:dc47bf3872fd: aarch64: vp9itxfm: Make the larger core transforms standalone functions
[12:53:31 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:3bd9b3910807: arm: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function
[12:53:32 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:a681c793a303: aarch64: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function
[12:53:33 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:824589556cb7: arm: vp9itxfm: Do a simpler half/quarter idct16/idct32 when possible
[12:53:34 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:9532a7d4d060: aarch64: vp9itxfm: Do separate functions for half/quarter idct16 and idct32
[12:53:35 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:1d8ab576a7e4: arm: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function
[12:53:36 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:3006e5253afc: aarch64: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function
[12:53:37 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:19a0f9529ccd: aarch64: vp9itxfm: Use a single lane ld1 instead of ld1r where possible
[12:53:38 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:6752318c7376: aarch64: vp9itxfm: Use the right lane sizes in 8x8 for improved readability
[12:53:39 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:d0fbf7f34e72: aarch64: vp9itxfm: Update a comment to refer to a register with a different name
[12:53:40 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:16ef000799b2: aarch64: vp9itxfm: Fix incorrect vertical alignment
[12:53:41 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:ac6cb8ae5b1c: aarch64: vp9mc: Simplify the extmla macro parameters
[12:53:42 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:bff07715904c: arm: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter
[12:53:43 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:045e33ae3fee: aarch64: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter
[12:53:44 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:758302e4bc14: arm: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling
[12:53:45 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:148cc0bb8908: aarch64: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling
[12:53:46 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f0ecbb13cf1c: arm/aarch64: vp9lpf: Calculate !hev directly
[12:53:47 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:92ab8374b105: arm: vp9lpf: Use orrs instead of orr+cmp
[12:53:48 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:83399cf569c9: arm: vp9lpf: Interleave the start of flat8in into the calculation above
[12:53:49 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:9f3a8863648e: aarch64: vp9lpf: Interleave the start of flat8in into the calculation above
[12:53:50 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:c8d6eec85d6a: aarch64: vp9lpf: Fix broken indentation/vertical alignment
[12:53:51 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:dda45c087b2c: aarch64: Add parentheses around the offset parameter in movrel
[12:53:52 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:3fbbad29847c: arm/aarch64: vp9lpf: Keep the comparison to E within 8 bit
[12:53:53 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f32690a298ba: aarch64: vp9lpf: Use dup+rev16+uzp1 instead of dup+lsr+dup+trn1
[12:53:54 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:a88db8b9a016: arm: vp9lpf: Implement the mix2_44 function with one single filter pass
[12:53:55 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:600f4c9b03b8: arm: vp9itxfm: Avoid reloading the idct32 coefficients
[12:53:56 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:2905657b902f: aarch64: vp9itxfm: Avoid reloading the idct32 coefficients
[12:53:57 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:4f693b56bdcf: arm: vp9itxfm: Reorder the idct coefficients for better pairing
[12:53:58 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:f95227301998: aarch64: vp9itxfm: Reorder the idct coefficients for better pairing
[12:53:59 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:b2e20d89844b: arm: vp9itxfm: Reorder iadst16 coeffs
[12:54:00 CET] <cone-699> ffmpeg 03Martin Storsjö 07master:26ee83acc4eb: aarch64: vp9itxfm: Reorder iadst16 coeffs
[13:09:37 CET] <adeel1> durandal_1707: im working on 83k colors image. its working but pixels not scattered over full height. also code for skipping " ptr += strcspn(ptr, "\"") + 1; was already in there
[13:13:16 CET] <durandal_1707> nope, you are mistaken
[13:14:40 CET] <durandal_1707> that skips just " before, after chars that resembles pixels
[13:41:34 CET] <adeel1> durandal_1707: I have added a strcspn call before the end (meaning " in between are skipped). I have also verified it making changes in xpm file.
[13:44:39 CET] <durandal_1707> not enough
[13:48:30 CET] <durandal_1707> you need good and fast  way to skip comments
[13:58:13 CET] <adeel1> durandal_1707: should both these comment styles (//, /**/) be taken care of?
[13:59:28 CET] <durandal_1707> yes, if you do any of two you did all of them, eg its easily expandable
[14:00:36 CET] <paras2052> durandal_1707: hi
[14:01:00 CET] <durandal_1707> hi
[14:01:26 CET] <paras2052> i have a few doubts
[14:01:54 CET] <paras2052> what should i do when a comment is not proper like i have found /* but ending */ is not there
[14:02:13 CET] <ubitux> i'm starting the merge again
[14:02:24 CET] <ubitux> we just crossed the 1k+ limit
[14:02:32 CET] <durandal_1707> nothing, you function should take care of that
[14:02:37 CET] <ubitux> next commit is b0f36a0043 avconv: stop using setpts for input framerate forced with -r
[14:02:48 CET] <ubitux> if anything has something to say about it, please share
[14:02:55 CET] <ubitux> s/anything/anyone/
[14:03:51 CET] <paras2052> durandal_1707: inside the modified strcspn function, should i ignore '/*' this and continue processing rest of the string ?
[14:04:26 CET] <durandal_1707> no, if its invalid file its invalid
[14:07:13 CET] <paras2052> durandal_1707: okay, i actually added that ignoring thing inside modified strcspn in the lastest patch, that's why it was complicated. Now, should i reimplement or use the previous version created by me ?
[14:08:13 CET] <durandal_1707> paras2052: reimplement it, its very simple actually
[14:09:33 CET] <durandal_1707> see how strcspn is implemented
[14:09:33 CET] <paras2052> durandal_1707: okay, i am doing it
[14:09:50 CET] <paras2052> okay
[14:12:32 CET] <cone-699> ffmpeg 03Steven Liu 07master:70a9407b509f: doc/muxers: move hls_flags temp_file to after SECOND LEVEL hls example
[14:15:27 CET] <adeel1> durandal_1707: I have created a function with two strcspn calls, first it skips till /* then till */
[14:16:21 CET] <adeel1> durandal_1707: however, in case of // comments since there's no closing. should i skip till newline
[14:16:22 CET] <adeel1> ?
[14:16:23 CET] <durandal_1707> and?
[14:16:39 CET] <durandal_1707> off course
[14:16:43 CET] <adeel1> okay
[14:17:37 CET] <ubitux> michaelni: do you have a moment to talk about our lord the pts management in ffmpeg?
[14:18:00 CET] <ubitux> wrt b0f36a0043 it appears that our "best effort timestamp" is enough to deal with this
[14:18:13 CET] <ubitux> like, if i just drop the auto-inserted setpts
[14:18:23 CET] <ubitux> the rate is correctly honored
[14:18:44 CET] <ubitux> this input pts is obtained through av_frame_get_best_effort_timestamp()
[14:19:07 CET] <ubitux> so my question is: will this be always reliable, or i should keep the extra counter in ffmpeg side?
[14:19:48 CET] <ubitux> my simple test was running "./ffmpeg -r 5 -f rawvideo -s cif -pix_fmt rgba -i /dev/zero -f null -" and FATE
[14:19:54 CET] <ubitux> but i assume this might not be enough
[14:24:40 CET] <ubitux> actually, this may have an impact wrt stream tb
[14:24:49 CET] <ubitux> we need tests for this stuff&
[14:26:59 CET] <michaelni> ubitux, i agree, more tests are needed
[14:28:02 CET] <ubitux> we need tests that uses -r for input and output, where both could be cfr or vfr and with different tb
[14:38:43 CET] <adeel1> durandal_1707: okay, done. both style comments are now skipped
[14:38:51 CET] <adeel1> should I share code?
[14:53:20 CET] <ubitux> meh, what happened to gif muxing
[15:28:47 CET] <Mirage20> Hello @BBB, I updated the avx asm code with your suggestions. https://github.com/Mirage20/FFmpeg/blob/vp8-avx2/libavcodec/x86/h264_intrapred.asm#L271
[15:43:33 CET] <paras2052> durandal_1707: Can you review please new strcspn and coding style, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f
[15:55:31 CET] <adeel1> durandal_1707: please review the updated code, check for skipcomments method: https://gist.github.com/adl1995/b8a25d8f81d0b7218e319c25d5427ed1
[16:00:58 CET] <durandal_1707> paras2052: no need to call external functions
[16:05:29 CET] <durandal_1707> adeel1: fragile, i have headache of so many calls and its flawed logic
[16:06:20 CET] <adeel1> durandal_1707: are you refering to the skipcomments method?
[16:07:26 CET] <BBB> mirag20: hi
[16:07:50 CET] <mirag20> hi
[16:08:14 CET] <BBB> mirag20: looks better. few more comments: vextracti128 can go directly to memory, youre doing 8 lines per iteration, but I think thats no faster than 4 per iter, even though that would half the amount of code, youre still using unnamed registers for r2/3/4/5, you need to test this on x86-32
[16:08:46 CET] <BBB> paddw ma, mb, ma is the same as paddw ma, mb but the second is shorter, so please use that
[16:09:02 CET] <BBB> (priority 1: fast code, priority 2: small binary size, priority 3: small source size)
[16:09:42 CET] <durandal_1707> adeel1: yes, also calling it that way is not going to work always
[16:09:47 CET] <mirag20> i will update with vextracti128.i test it with 4 and 2 iterations
[16:09:55 CET] <BBB> ok
[16:10:01 CET] <BBB> I think 4 will be equally fast and 2 will be slower
[16:10:02 CET] <mirag20> after loop is unrolled it get avrage 44 and 45
[16:10:12 CET] <BBB> but Im just randomly guessing, so test is better :)
[16:10:32 CET] <mirag20> i though it get slow bcz of branch prediction
[16:10:45 CET] <mirag20> i will re check with 4 iterations
[16:10:52 CET] <durandal_1707> adeel1: also you havent cleaned other buggy code i pointed out
[16:13:47 CET] <mirag20> "youre still using unnamed registers for r2/3/4/5" how should i declare a variable? I'm bit new to asm :)
[16:15:06 CET] <BBB> cglobal function, num_args, num_gpr_regs, num_xmm_regs, [stack memory (optional)], name1, name2, name3, name4, name5, etc.
[16:15:20 CET] <BBB> name1 refers to r0, name2 to r1, etc.
[16:15:25 CET] <adeel1> if you are refering to the av_fast_padded_malloc call, shouldn't memory be allocated this way? 94 times cpp?
[16:15:29 CET] <BBB> so e.g. r2d would become name3d
[16:15:38 CET] <BBB> and r5 would become name6q
[16:15:40 CET] <BBB> etc.
[16:17:41 CET] <mirag20> thanks. I will update and test the performance.
[16:20:15 CET] <durandal_1707> adeel1: having if/else is unacceptable, it must supports even 5 
[16:20:31 CET] <adeel1> okay, i will simply multipl by cpp
[16:21:06 CET] <adeel1>     av_fast_padded_malloc(&x->pixels, &x->pixels_size, 94 * cpp);
[16:21:10 CET] <adeel1> is this fine?
[16:21:15 CET] <durandal_1707> adeel1: you can not just multiply
[16:21:54 CET] <adeel1> durandal_1707: but it was 94 * 94 for cpp == 2 before. isnt that the same thing? or am i missing something?
[16:22:22 CET] <durandal_1707> basic math
[16:23:50 CET] <JEEB> &32
[16:26:36 CET] <adeel1> durandal_1707: since our character lie in range ' ' to '~' the difference comes to be 94. Also, shouldnt the memory be assigned on the basis of character? 94 * cpp would mean all possible options.
[16:27:17 CET] <durandal_1707> nope
[16:27:45 CET] <durandal_1707> think again
[16:28:16 CET] <durandal_1707> 94*94 != 2 * 94
[16:29:42 CET] <BBB> mirag20: okay, cool
[16:30:20 CET] <BBB> mirag20: its relatively normal for first-time contributors patches to go through review rounds a couple of times, so this is all fairly normal, just so you know ;)
[16:34:25 CET] <adeel1> durandal_1707: my bad. so multiplying 94 by 94 cpp times should be good? or do we add in to the previous result? like for cpp == 3, (94) + (94*94) + (94*94*94)
[16:35:21 CET] <durandal_1707> add to prev result
[16:36:57 CET] <adeel1> durandal_1707: okay, and you mentioned previously that "calling it that way is not going to work always", what other way is there to call the function?
[16:39:32 CET] <durandal_1707> adeel1: you completly missed the point, one should skip commmemnts whenever they occur
[16:43:15 CET] <BBB> mirag20: also please fix your indenting, the code should be aligned by the comma after the first source operand
[16:43:56 CET] <BBB> mirag20: so e.g. if you have paddw m0, m1 followed by mova [address], m0, the two lines should be vertically aligned by their comma
[16:44:01 CET] <cone-699> ffmpeg 03PrzemysBaw Sobala 07master:89c0fda5f43d: lavf/dashenc: update bitrates on dash_write_trailer
[16:44:25 CET] <BBB> mirag20: look at the other functions around there for more practical examples of idnentation
[16:57:17 CET] <paras2052> durandal_1707: Check this one, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f
[17:03:26 CET] <durandal_1707> paras2052: you can simplify that further, checking for 2 chars at once in if 
[17:05:12 CET] <paras2052> okay, by using uint16_t, i guess ?
[17:07:38 CET] <paras2052> not that maybe, if i check two chars inside i, then further inside if i have to add two more if's to check for the type comment because ending style is different for both the comments. Am i wrong ?
[17:08:28 CET] <paras2052> if i check two chars inside if*
[17:20:44 CET] <durandal_1707> paras2052: yes
[17:26:29 CET] <paras2052> okay
[17:30:20 CET] <paras2052> durandal_1707: So, you mean something like this, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f
[17:32:28 CET] <durandal_1707> paras2052: you need to check for 0/NULL
[17:32:36 CET] <durandal_1707> in while loop
[17:36:05 CET] <paras2052> durandal_1707: yup, done, https://gist.github.com/paraschadha2052/b5d663dcf1bdd2dff7ecccf210da038f
[17:37:28 CET] <paras2052> durandal_1707: i have a question, will checking not make it more slow. I mean we are adding two extra operations in the loop ?
[17:43:53 CET] <mirag20> hi I updated the code
[17:43:54 CET] <mirag20> https://github.com/Mirage20/FFmpeg/blob/vp8-avx2/libavcodec/x86/h264_intrapred.asm#L271
[17:44:44 CET] <mirag20> i ran few tests with both 2 and 4 iterations
[17:45:43 CET] <mirag20> x64 2 iterations pred16x16_tm_vp8_sse2: 95.6 pred16x16_tm_vp8_avx2: 37.9
[17:46:07 CET] <mirag20> x64 4 iterations pred16x16_tm_vp8_sse2: 93.8 pred16x16_tm_vp8_avx2: 41.1
[17:46:31 CET] <mirag20> what should i do?
[17:47:54 CET] <mirag20> Also I compiled to x86_32 "./configure --disable-stripping --enable-debug=3 --extra-cflags="-gstabs+" --disable-optimizations --arch=x86_32"
[17:48:30 CET] <mirag20> x86 result is pred16x16_tm_vp8_sse2: 93.1 pred16x16_tm_vp8_avx2: 38.2
[18:05:09 CET] <durandal_1707> paras2052: its fine
[18:05:48 CET] <paras2052> durandal_1707: any coding style changes ?
[18:09:48 CET] <durandal_1707> paras2052: see style of other files and follow thern
[18:09:58 CET] <durandal_1707> dont use tabs
[18:10:38 CET] <paras2052> i will remove tabs with whitespace and also trailing spaces (actually posting on github gist they got automatically added)
[18:11:39 CET] <paras2052> for, loops and conditionals i am following k&r style
[18:11:49 CET] <paras2052> any other style conventions ?
[18:19:35 CET] <durandal_1707> paras2052: no
[18:21:54 CET] <paras2052> durandal_1707: okay, thanks for helping so much. Also, can you give more details of "Please also add xpm_pipe demuxer with its probe function." I don't know much about demultiplexer's and probe functions.
[18:22:53 CET] <durandal_1707> paras2052: look at other code, see for example png_probe
[18:23:09 CET] <BBB> mirag20: if 2 iterations is faster, then we keep the 2
[18:23:23 CET] <BBB> mirag20: the code as-is cannot work on x86-32, thats why I asked you to test it ;)
[18:23:41 CET] <BBB> mirag20: use extra-cflags=-m32 extra-libs=-m32 as configure options
[18:23:47 CET] <BBB> then it compiles a 32bit binary
[18:23:50 CET] <mirag20> so actually --arch=x86_32 is not working?
[18:23:51 CET] <mirag20> :D
[18:23:53 CET] <paras2052> durandal_1707: okay, thanks
[18:23:59 CET] <BBB> mirag20: I suppose ;)
[18:24:37 CET] <durandal_1707> paras2052: libavformat/img2dec.c
[18:26:57 CET] <paras2052> durandal_1707: okay, i have to implement in img2dec.c ?
[18:27:13 CET] <durandal_1707> yes
[18:27:35 CET] <durandal_1707> its easy, just look how others are done
[18:27:36 CET] <mirag20> you mean AVX is not working on 32bit?
[18:27:52 CET] <paras2052> durandal_1707: okay, on it
[18:37:11 CET] <BBB> mirag20: no, it is; but your imlpementation cannot work on 32bit :-p
[18:37:27 CET] <BBB> mirag20: compile it first, then see it crash
[18:37:32 CET] <BBB> mirag20: then Ill help you fix it
[18:51:12 CET] <decepto> BBB: I want to start working on VMAF video filter project for GSoC. For the qualification task, could you please let me know if it's still available?
[18:51:25 CET] <BBB> someone else already took it
[18:51:33 CET] <BBB> so were going to have to find you another qualification task
[18:51:38 CET] <BBB> hm& this is getting rather complicated
[18:51:54 CET] <BBB> I cant keep track of all the qualification tasks anymore
[18:52:21 CET] <BBB> is thilo on IRC?
[18:53:33 CET] <BBB> I guess not
[18:53:46 CET] <BBB> durandal_1707: do you have any filters that need writing and could serve as gsoc qual task?
[18:54:08 CET] <BBB> decepto: Ill be honest, Ive had more interest than anticipated so I ran out of potential qualification tasks :-/
[18:54:49 CET] <durandal_1707> BBB: yes i have
[18:55:26 CET] <atomnuker> send some my way, I have had 1 person for the vorbis encoder who went awol
[18:56:11 CET] <durandal_1707> BBB: write qr code filter source using libqrencode
[18:57:06 CET] <BBB> decepto: interested in that as a qualification task?
[18:58:17 CET] <decepto> BBB: I'll give it a try :)
[18:58:21 CET] <durandal_1707> BBB: what about student that already posted vmaf via some stuff?
[18:58:46 CET] <BBB> durandal_1707: that student is finished& but multiple students can apply for the same project I suppose
[18:58:58 CET] <BBB> its probably better to spread it out over multiple projects if we have no applicants for others
[18:59:30 CET] <durandal_1707> ugh, so what they will do? together?
[18:59:35 CET] <BBB> but it seems to me that if 2 students are interested in A, we should sort of let them fight it out over who gets to do A, and then if theyre both good but only one got A and theres no students for B, we can sort of nudge the other student to do B
[18:59:43 CET] <BBB> (if the other student is interested)
[18:59:52 CET] <BBB> we can also do that during qualification time I suppose
[19:00:17 CET] <BBB> I agree this is all very strange, but googles application structure seems sort of intended for this type of competition
[19:00:22 CET] <durandal_1707> ah yes, if they are interested in minterpolate or dicom or vorbis
[19:00:52 CET] <BBB> vorbis is fun
[19:00:58 CET] <BBB> should do opus also
[19:01:20 CET] <durandal_1707> atomnuker: only you can make vorbus encoder useful
[19:01:41 CET] <BBB> decepto: so, Ill try to be helpful for this qualification task, but I have to be honest that I dont know all the details about it yet, so the first few questions may take me a while to get up to speed also&
[19:03:18 CET] <durandal_1707> http://fukuchi.org/works/qrencode/manual/
[19:10:37 CET] <mirag20> BBB: ok got it, not every one in this world have 64bit :D
[19:10:57 CET] <BBB> right& importantly, chrome for windows is to my knowledge still sometimes 32bit
[19:11:12 CET] <BBB> (maybe thats outdated? ...)
[19:11:26 CET] <mirag20> yes most of the programs
[19:15:53 CET] <mirag20> BBB: here is the update version :) 
[19:15:54 CET] <mirag20> https://github.com/Mirage20/FFmpeg/blob/vp8-avx2/libavcodec/x86/h264_intrapred.asm#L271
[19:18:37 CET] <BBB> ah he found the 32bit bug, nice work
[19:18:43 CET] <BBB> he=you
[19:19:13 CET] <BBB> make r5 a named register also
[19:19:27 CET] <BBB> otherwise it looks OK, send it to the ML so it can be reviewed officially and committed
[19:19:50 CET] <mirag20> how is the process works?
[19:19:59 CET] <mirag20> I mean should i send the git link to mail?
[19:20:10 CET] <BBB> https://ffmpeg.org/developer.html#Submitting-patches-1
[19:43:38 CET] <adeel1> durandal_1707: I have updated code for size calc and skipping comments, please review: https://gist.github.com/adl1995/ff687e9748d5b3b5aad04536f766e89f
[19:45:06 CET] <durandal_1707> adeel1: not good enough
[19:46:24 CET] <adeel1> durandal_1707: because it will only look for comments only after parsing colors?
[19:47:28 CET] <durandal_1707> adeel1: its limited and fragile
[20:02:18 CET] <adeel1> durandal_1707: I have wrapped other calls in the new method and modified return value
[20:05:08 CET] <adeel1> durandal_1707: https://gist.github.com/adl1995/6260b8a88c7bea49393be34b801635bc
[20:10:13 CET] <durandal_1707> adeel1: whats max number of colors you tried?
[20:10:35 CET] <adeel1> 83k
[20:11:11 CET] <durandal_1707> really?
[20:11:37 CET] <adeel1> yes, I used gimp to convert the image. to see no of colors i printed ncolors var.
[20:12:44 CET] <mirag20> BBB: I sent the mail. Thanks for helping :)
[20:13:10 CET] <BBB> mirag20: your patch to the ML needs some more information
[20:14:27 CET] <BBB> mirag20: check e.g. http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/216587, ideally your commit message specifies how much faster the function became (e.g. just by copypasting the cycle counts from checkasm)
[20:16:17 CET] <adeel1> durandal_1707: what is the next step?
[20:19:51 CET] <durandal_1707> adeel1: fixing code and removing unneded code
[20:20:44 CET] <adeel1> I see parse_str_int method isnt being used anywhere
[20:23:57 CET] <durandal_1707> there is more
[20:38:38 CET] <adeel1> durandal_1707: are some methods to be added for mapping to color to correct location?
[20:40:04 CET] <adeel1> the color*
[20:48:18 CET] <durandal_1707> adeel1: no
[21:08:02 CET] <andrey_turkin> BtbN: here?
[21:10:57 CET] <mirag20> BBB: I updated the email with results
[21:31:50 CET] <cone-699> ffmpeg 03Muhammad Faiz 07master:0bab78f7e729: avfilter/af_firequalizer: add av_restrict on convolution func
[00:00:00 CET] --- Sun Mar 12 2017