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

[burek]

[00:03:07 CEST] <michaelni> Chloe, you mean the openh264 patch ? martin should have write access
[00:05:14 CEST] <Chloe> michaelni: I meant the JACK patch. You said LGTM, which in previous occasions resulted in the other person pushing (and if they didn't have access then you would apply it yourself). but I'm not the maintainer of the JACK dev, so I wasn't quite sure if I was supposed to push it.
[00:06:33 CEST] <michaelni> Chloe, yes "LGTM" replies mean you can push it 
[00:06:44 CEST] <Chloe> ok thanks for clearing that up :)
[00:07:20 CEST] <michaelni> LGTM == "Looks good to me"
[00:11:43 CEST] <cone-418> ffmpeg 03Josh de Kock 07master:c2fcf4fa0b12: avdev/jack: remove duplicated dispatch macros
[00:51:59 CEST] <cone-418> ffmpeg 03dericed 07master:461073e80914: ffprobe.xsd: add missing timecode attribute to frameSideDataType
[00:52:57 CEST] <wyatt8740> this is driving me crazy
[03:17:38 CEST] <cone-418> ffmpeg 03James Almer 07master:54a0a52be100: checkasm/vp9dsp: use declare_func_emms in check_loopfilter
[03:44:14 CEST] <wyatt8740> finally got it, but I have no idea how. setting CFLAGS to a literal '' (not unset) fixed SDL, though, somehow.
[03:44:47 CEST] <Timothy_Gu> wyatt8740: so it turned out to be a SDL compilation issue?
[03:45:02 CEST] <wyatt8740> yes, but I have no idea what was wrong that I fixed because CFLAGS wasn't set to begin with
[03:45:31 CEST] <Timothy_Gu> okay, well glad to hear that
[03:46:10 CEST] <wyatt8740> no idea how this guy figured this out but it fixed it. https://trac.ffmpeg.org/ticket/939
[03:46:24 CEST] <wyatt8740> (comment 5)
[03:50:34 CEST] <wyatt8740> http://i.imgur.com/kaKcGCx.png
[03:51:23 CEST] <wyatt8740> I have absolutely no idea why no one else seems to encounter this building for windows; it's happened to me for years, ever since 2010 or so when I started using mingw32+msys in winXP
[03:52:18 CEST] <wyatt8740> and continuing to now when I'm cross compiling with mingw-w64 from cygwin
[03:54:22 CEST] <wyatt8740> but for whatever reason, mplayer still worked with the 'sdl' output with the bad SDL build
[04:43:16 CEST] <Compn> wyatt8740 : do what now
[04:45:11 CEST] <Compn> are you using mingw or mingw-w64 ?
[04:45:47 CEST] <Compn> mingw is pretty outdated now :\
[09:23:52 CEST] <cone-517> ffmpeg 03Martin Storsjö 07master:c5d326f551b0: Add an OpenH264 decoder wrapper
[09:23:52 CEST] <cone-517> ffmpeg 03Martin Storsjö 07master:293676c47673: libopenh264: Support building with the 1.6 release
[10:21:13 CEST] <rcombs> does swscale perform better at particular exact scale factors on x86?
[10:23:52 CEST] <ubitux> there are multiple scaler based on filter size
[10:24:05 CEST] <ubitux> which depends on i/o size
[13:41:30 CEST] <Gramner> so according to the avx-512 manual opmask unpack instructions are inverted compared to all other x86 unpack instructions, because that obviously somehow makes a lot of sense apparently. e.g. punpckldq dst,a,b => aaaabbbb while kunpckdq dst,a,b => bbbbaaaa
[13:42:19 CEST] <Gramner> although it's possible that the manual is just wrong and mixed up src1 and src2 I guess
[14:00:16 CEST] <BBB> kunpckdq?
[14:00:22 CEST] <BBB> is that like vunpackdq for zmm?
[14:00:38 CEST] <Gramner> punpck for opmask registers (k1-k7)
[14:00:50 CEST] <BBB> k?
[14:01:15 CEST] <BBB> I clearly have not been keeping up with avx512
[14:01:18 CEST] <BBB> what is k?
[14:01:21 CEST] <Gramner> most avx-512 instructions take an optional opmask for conditionally blending/zeroing individual elements in dst
[14:01:51 CEST] <BBB> oh, sweet
[14:02:41 CEST] <BBB> but so the opmask is not an imm8, but its a k register?
[14:02:51 CEST] <Gramner> new registers
[14:03:08 CEST] <BBB> interesting
[14:03:21 CEST] <BBB> Im going to assume the manual is mixed up, otherwise it makes little sense
[14:03:25 CEST] <Gramner> k0-k7, but k0 is a static reg with all bits set (so basically that's the opmask used if you don't specify any)
[14:04:19 CEST] <BBB> is there also a vanilla unpackdq without a opmask?
[14:04:26 CEST] <BBB> or is that the kunpackdq with k0?
[14:04:55 CEST] <Gramner> that's for unpacking opmask registers with each other
[14:05:35 CEST] <BBB> oh god
[14:05:38 CEST] <BBB> I see now
[14:05:53 CEST] <BBB> so they actually created a completely new instruction set for creating what is essentially imm8s?
[14:06:10 CEST] <BBB> very engineery of them
[14:06:31 CEST] <BBB> my brain says overdesigned, but maybe Im underestimating what you can do with this
[14:06:33 CEST] <Gramner> opmasks are 64-bit when used with bytes registers (each bit corresponds to an element in the vector)
[14:06:44 CEST] <Gramner> bytes instructions*
[14:08:14 CEST] <Gramner> I guess it's possible to use them for some calculated conditional shenanigans
[14:08:39 CEST] <Gramner> a lot of stuff is likely designed to make it easier for compilers to autovectorize things
[14:09:42 CEST] <BBB> whenever I hear autovectorization, I have to think about this gstreamer blog post about it
[14:09:48 CEST] <Gramner> in handwritten asm that uses opmasks you're most likely just gonna set up the required value in the prologue and then just that in every loop iteration
[14:10:04 CEST] <iive> BBB: link?
[14:10:12 CEST] <BBB> its from this guy that doesnt really understand assembly at all, but hes very excited to enable it and get things that are a lot faster - which doesnt happen
[14:10:27 CEST] <BBB> and then he essentially finds out after a while that all autovec does is to use simd for memset(0)
[14:11:02 CEST] Action: iive facepalms
[14:11:10 CEST] <Gramner> one thing that could be really useful with opmasks is dealing with array overwrites (probably one of the design goals behind it)
[14:11:26 CEST] <Gramner> just mask out all elements that are past the end of the array and you're golden
[14:11:39 CEST] <BBB> gotta go, brb
[15:11:31 CEST] <bofh_> BBB: autovectorizers start to almost become useful once you add restrict/__restrict to every single relevant pointer
[15:14:30 CEST] <ubitux> i'm not sure i can actually merge the next commit
[15:15:10 CEST] <ubitux> i mean, it's passing fate but it's not exactly an improvement
[15:16:07 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_slice.c;h=ee7dedbe2d744b6cbd1a3e07bc0be235526e87b9;hb=HEAD#l1415
[15:16:57 CEST] <ubitux> in this h264_slice_header_parse(), everything changing current_slice (basically the chunk on top) is supposed to go out of the function
[15:17:13 CEST] <ubitux> and be called *after* h264_slice_header_parse()
[15:17:36 CEST] <ubitux> but the chunk i hilighted is supposed to make a skip or not based notably on current_slice
[15:18:01 CEST] <ubitux> so if i moved also it with the other chunk on top
[15:18:13 CEST] <ubitux> it means the whole slice will be parsed completely
[15:18:19 CEST] <ubitux> while it wasn't before
[15:18:41 CEST] <ubitux> and this can actually be a problem
[15:19:14 CEST] <ubitux> first it might be slower, but also a decoding failure that could have been avoided by skipping specific slices will now actually fail
[15:20:04 CEST] <ubitux> one thing i'm thinking to do is skip the slices if and not return an error there is actually an error in that h264_slice_header_parse()
[15:20:25 CEST] <ubitux> sorry mistyped
[15:21:11 CEST] <ubitux> one thing i'm thinking to do is to ignore h264_slice_header_parse() return value if the skip code is set
[15:21:23 CEST] <ubitux> but that won't prevent from at least trying to perform a whole parsing
[15:22:14 CEST] <ubitux> but that's kind of tricky
[15:23:48 CEST] Action: ubitux not happy
[16:00:16 CEST] <mateo`_> ubitux: can i push a commit or will it annoys you regarding the merge ?
[16:00:38 CEST] <ubitux> go ahead
[16:01:13 CEST] <cone-958> ffmpeg 03Matthieu Bouron 07master:376d8fb2c574: lavc/ffjni: replace ff_jni_{attach,detach} with ff_jni_get_env
[16:08:21 CEST] <ubitux> michaelni: available for some h264 testing?
[16:15:13 CEST] <ubitux> michaelni: if you can test my merge-libav branch, that would be great
[16:16:56 CEST] <ubitux> ah, i found an issue
[16:17:39 CEST] <michaelni> ubitux, yes i can test
[16:18:10 CEST] <ubitux> it seems to fail with fate + THREADS 
[16:18:15 CEST] <ubitux> :(
[16:19:13 CEST] <ubitux> if you feel like looking at the diff and see something obvious, comment welcome ofc
[16:47:49 CEST] <ubitux> ah, fixed it, i think
[16:48:18 CEST] <ubitux> ah, no.
[16:49:30 CEST] <michaelni> btw i didnt spot anythng from looking at the diff but it failed with frame threads while passing fate with slices
[16:50:19 CEST] <ubitux> yeah i made the same observation
[17:01:09 CEST] <ubitux> michaelni: fixed
[17:04:47 CEST] <ubitux> (i dropped an essential chunk by mistake in the 2nd commit)
[17:18:45 CEST] <ubitux> michaelni: i'll push in about 40 min unless you want to do extended tests
[17:18:57 CEST] <ubitux> (which i'd recommend to do at the end of the wave though)
[17:20:59 CEST] <michaelni> ubitux, iam not sure how you did this but none of the files i try crash, so i think you dont need to wait 40min
[17:21:20 CEST] <ubitux> heh ok cool, i'll push then, thank
[17:21:22 CEST] <ubitux> +s
[17:22:29 CEST] <cone-958> ffmpeg 03Anton Khirnov 07master:8d36932c8d33: h264: move the block starting a new field out of slice_header_parse()
[17:22:30 CEST] <cone-958> ffmpeg 03Anton Khirnov 07master:54dd9b1cdd9e: h264: set mb_aff_frame in frame_start()
[17:22:31 CEST] <cone-958> ffmpeg 03Clément BSsch 07master:78c7197ea0e5: Merge commit '54dd9b1cdd9e54f1ee39ae25af0324f8aba2831b'
[17:25:26 CEST] <cone-958> ffmpeg 03Clément BSsch 07master:f8ce1e828299: lavc/h264_slice: adjust a few line breaks to reduce diff with Libav
[17:37:37 CEST] <cone-958> ffmpeg 03Anton Khirnov 07master:f966498e433f: h264: decode the poc values from the slice header into the per-slice context
[17:37:38 CEST] <cone-958> ffmpeg 03Clément BSsch 07master:87d1f820591b: Merge commit 'f966498e433fead2f5e6b5b66fad2ac062146d22'
[17:39:35 CEST] <ubitux> weekly call: still no one to update ffmpeg.c to codecpar?
[18:08:41 CEST] <cone-958> ffmpeg 03Anton Khirnov 07master:debca90863e4: h264: store {curr,max}_pic_num in the per-slice context
[18:08:42 CEST] <cone-958> ffmpeg 03Clément BSsch 07master:6c41eda18ec0: Merge commit 'debca90863e4ee53447efd02483c500f89766384'
[18:09:39 CEST] <ubitux> michaelni: any comment on git show 17e7c03 -w ?
[18:10:37 CEST] <ubitux> git show 17e7c03 -w -U10 is clearer
[18:10:58 CEST] <ubitux> i'll try a merge if you want to test
[18:13:28 CEST] <michaelni> ubitux, iam happy to test if you have a merge to test
[18:16:22 CEST] <michaelni> i wonder if this is reimplementing some setup_finished check we have 
[18:16:32 CEST] <ubitux> yeah that's what i wonder
[18:16:46 CEST] <ubitux> i don't know how i could merge that
[18:17:29 CEST] <ubitux> if you see a way to reduce the number of differences...
[18:17:38 CEST] <ubitux> i'll probably skip that one
[18:18:55 CEST] <ubitux> it looks a bit sensible though
[18:40:44 CEST] <michaelni> ubitux, posted a patch that would turn the merge into a NOP basically
[18:41:10 CEST] <michaelni> not sure you want to change indention of anything n the merge so it matches closer
[19:02:06 CEST] <Chloe> ubitux: is there a list of the codecpar changes?
[19:13:06 CEST] <CFS-MP3> Not sure if here or #ffmpeg would be the best place to ask... is there a "best card money can buy for ffmpeg on linux"? FFmpeg being the only important tool (don't care about desktop, opengl, etc). I know there's a grid of supported chipsets etc but I couldn't find useful benchmarks. First use case would be decode many channels (UDP live stream) and produce different composites 
[19:14:01 CEST] <ubitux> michaelni: doesn't this check replace if(current_slice) with if(!current_slice)?
[19:14:18 CEST] <ubitux> Chloe: it's basically to redo 15e84ed for ffmpeg
[19:14:51 CEST] <ubitux> (according to bbf5ef9d, "This commit is a no-op. We want to do this ourselves, since avconv and ffmpeg differ quite a bit."
[19:14:53 CEST] <ubitux> )
[19:16:42 CEST] <ubitux> michaelni: oh my bad, missed the ||
[19:17:13 CEST] <ubitux> i guess that's fine, but you know the code better than me
[19:24:15 CEST] <Chloe> ubitux: I'll take a look at it when I get home
[19:35:01 CEST] <cone-958> ffmpeg 03Xinzheng Zhang 07master:cd141e71bd34: avformat/flvdec: splitting add_keyframes_index() out from parse_keyframes_index()
[19:35:02 CEST] <cone-958> ffmpeg 03Xinzheng Zhang 07master:ad14aab3b4f8: avformat/flvdec: parse keyframe before a\v stream was created add_keyframes_index() when stream created or keyframe parsed
[19:35:03 CEST] <cone-958> ffmpeg 03Michael Niedermayer 07master:8385e1718ee1: avcodec/h264_slice: Make setup_finished check cover more cases
[19:37:52 CEST] <BBB> jamrial: I think hes looking for input on whether its ok for vlc to use threaded+hwacceled libavcodec
[19:38:42 CEST] <jamrial> BBB: right, i assumed he sent that patch thinking it was for our tree
[19:38:46 CEST] <jamrial> i see now it was forwarded
[20:06:24 CEST] <wyatt8740> oh, ubitux, thanks for the blog post about the HQX filter I requested a couple years ago. It's been insanely helpful
[20:46:56 CEST] <ubitux> wyatt8740: i wrote that 2yrs ago you know
[20:46:58 CEST] <ubitux> :D
[20:47:07 CEST] <JEEB> :D
[20:47:08 CEST] <ubitux> you should probably use xbr btw
[20:47:16 CEST] <JEEB> better late than never... I guess?
[20:47:23 CEST] <mateo`_> just about time ... ubitux 
[20:47:26 CEST] <JEEB> (kind of like my earthsoft DV demuxer and decoder patches)
[20:47:37 CEST] <JEEB> (WIP since VDD '13 or so)
[20:48:02 CEST] <ubitux> well i actually *posted* it 2yrs ago :p
[20:48:14 CEST] <JEEB> yeah, with that difference of course
[20:48:48 CEST] <JEEB> maybe when I'll have my first days off after working 1.5 years without vacation
[20:49:02 CEST] <JEEB> and get something done
[20:49:14 CEST] <mateo`_> Chloe: are you going to port ffmpeg to codecpar ?
[20:52:43 CEST] <wyatt8740> ubitux: yeah XBR is better :p
[20:53:08 CEST] <wyatt8740> Having trouble getting GLC to losslessly output video unfortunately
[20:53:27 CEST] <wyatt8740> (so the pixels aren't exactly the same color and the filter doesn't work on it)
[22:48:34 CEST] <Chloe> mateo`_: yes
[23:02:24 CEST] <cone-107> ffmpeg 03Burt P 07master:bfe9155aee1c: fate: Add HDCD filter tests for false positive and error detection
[23:02:24 CEST] <cone-107> ffmpeg 03Burt P 07master:91854b8ef644: af_hdcd: Improve HDCD detection
[23:05:22 CEST] <Chloe> Why does ffmpeg.c use AVCodecContext->delay for audio at line 3010?
[23:39:02 CEST] <cone-107> ffmpeg 03Burt P 07master:c7ba34b6ea37: af_hdcd: more comments in state struct
[23:39:03 CEST] <cone-107> ffmpeg 03Burt P 07master:c26305f6aec0: af_hdcd: Add counter for cdt expirations
[23:41:52 CEST] <jamrial> Chloe: should be the same as initial_pading, afaik
[23:43:00 CEST] <Chloe> That would be my guess, I was just wondering because initial_padding was being used as well
[23:44:45 CEST] <JEEB> yeah, there's like 3 different variables for initial delay by now ^^;
[23:45:36 CEST] <Chloe> I'm just going to remove it and hope nothing breaks
[23:46:18 CEST] <JEEB> whether it's correct or not, something will most probably result in something different :D
[23:52:57 CEST] <Chloe> jamrial: do you know the new way to check if it has b frames?
[23:54:45 CEST] <jamrial> Chloe: not really, but looking at 15e84ed it apparently just dropped that line
[23:55:27 CEST] <Chloe> I was more thinking about  ffmpeg_opt.c:1032 where it sets dts_heuristic to 1 if it has b frames
[23:59:07 CEST] <JEEB> ooh, ffmpeg.c and all those little IF statements~
[23:59:24 CEST] <JEEB> (and talking more seriously, great that you're tackling that crapola)
[00:00:00 CEST] --- Thu Jul 28 2016