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

[burek]

[00:31:01 CET] <jamrial> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69320
[00:34:48 CET] <Compn> jamrial : gcc usually wants small test cases
[00:34:58 CET] <Compn> like  300 lines of c that cause the problem.
[00:35:07 CET] <Compn> not an entire project + fate test
[00:35:12 CET] <jamrial> i know, i provide those when i can
[00:35:16 CET] <Compn> ok :P
[00:35:20 CET] Action: Compn hides
[00:36:29 CET] <Mavrik> Has to be shorter than the maintainers beard.
[00:47:17 CET] <philipl> BtbN: sent you a pull request with the stuff I did today. That's enough frustration for one day.
[00:47:54 CET] <BtbN> Yeah, I kind of put it on hold after i saw that it's not even faster/less CPU intensive than the ffmpeg software decoder.
[01:12:18 CET] <cone-603> ffmpeg 03James Almer 07master:dee579ffcd70: x86/fixed_dsp: add ff_butterflies_fixed_sse2
[02:17:43 CET] <cone-603> ffmpeg 03Michael Niedermayer 07master:7a0361b06f0a: ffmpeg: fix sws_dict leak on error exit
[02:17:44 CET] <cone-603> ffmpeg 03Michael Niedermayer 07master:ad3b6fa7d83d: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_rgb24_wrapper()
[02:17:45 CET] <cone-603> ffmpeg 03Michael Niedermayer 07master:757248ea3cd9: swscale/swscale_unscaled: Fix odd height inputs for bayer_to_yv12_wrapper()
[12:03:21 CET] <cone-897> ffmpeg 03Eddie Hao 07master:a6dc1eb8376c: remove all uses of the deprecated avpicture_get_size() function
[13:18:54 CET] <fritsch> BtbN: seen the last commits to intel's vaapi driver? Something more "in line" to start with ffmpeg hwaccel for hevc 10 bit?
[13:20:06 CET] <wm4> oh how utterly mysterious: http://cgit.freedesktop.org/vaapi/intel-hybrid-driver/
[13:20:32 CET] <fritsch> wrong repo
[13:20:38 CET] <wm4> I know
[13:20:40 CET] <fritsch> :-)
[13:20:49 CET] <fritsch> they should fix the bug I reported first ...
[13:20:51 CET] <wm4> so I see they added 10 bit stuff to libva
[13:20:56 CET] <fritsch> they report vp9 caps on hsw
[13:21:02 CET] <fritsch> and crash directly
[13:21:16 CET] <fritsch> yes, hevc 10 bit is old, but now it seems the drivers was made a bit more compatible
[13:21:31 CET] <fritsch> with "putSurface" you should get the obvious rgba buffer
[13:21:42 CET] <fritsch> for the new EGL buffer sharing I am not yet sure how one can do that correctly
[13:21:51 CET] <fritsch> as src is not NV12
[13:22:01 CET] <wm4> so is that empty hybrid driver repo announcing their intention to implement it?
[13:22:07 CET] <fritsch> nope
[13:22:14 CET] <fritsch> hybrid driver is only for vp9
[13:22:22 CET] <fritsch> all other stuff is in the "real intel" driver
[13:22:27 CET] <wm4> I suppose for 10 bit you'd change from DRM_FORMAT_R8 to DRM_FORMAT_R16?
[13:22:36 CET] <fritsch> yeah
[13:22:48 CET] <fritsch> I don't know what intel's driver uses internally
[13:22:55 CET] <fritsch> e.g. if that's somehow compatible
[13:23:21 CET] <fritsch> i only saw that they can do RGBA32 conversion if you request it
[13:23:32 CET] <fritsch> and then use that given drm format
[13:23:37 CET] <wm4> (but we don't want that)
[13:23:49 CET] <fritsch> yes - we don't
[13:24:34 CET] <fritsch> http://www.intel.com/content/www/us/en/embedded/software/iegd/intel-embedded-graphics-drivers-overview.html <- lol
[13:24:37 CET] <fritsch> did you know that?
[13:24:49 CET] <fritsch> or those vaapi compatible powervr drivers?
[13:25:02 CET] <wm4> no
[13:25:05 CET] <fritsch> and here: http://www.intel.com/content/www/us/en/embedded/software/emgd/embedded-media-and-graphics-drivers-overview.html
[13:25:37 CET] <fritsch> http://cgit.freedesktop.org/vaapi/intel-driver/log/ <- the last commits give more insight of how they handle P010
[13:26:03 CET] <wm4> yeah, looks like what dxva2 does generally
[13:26:14 CET] <wm4> P010 seems to be the same as the windows equivalent
[13:26:48 CET] <fritsch> for P010 there is still the dxva commit missing for ffmpeg
[13:27:09 CET] <fritsch> sws_scale support landed if I see it right
[13:27:47 CET] <wm4> did it?
[13:27:50 CET] <wm4> I don't see it
[13:28:06 CET] <wm4> there's also a fix to the dxva hwaccel missing
[13:28:16 CET] <wm4> nevcairiel had compatibility worries
[13:28:35 CET] <wm4> the problem is that until now the hevc dxva hwaccel allowed 8 bit only
[13:28:47 CET] <wm4> so the question is, would this break API users when it suddenly allows 10 bit?
[13:28:56 CET] <wm4> in theory it could
[13:29:07 CET] <fritsch> there was a straight forward patch for dxva that we picked from his tree
[13:29:08 CET] <fritsch> some time ago
[13:29:13 CET] <fritsch> and adjusted kodi
[13:29:17 CET] <fritsch> it worked (TM)
[13:29:22 CET] <wm4> here too
[13:29:35 CET] <fritsch> for vaapi the changes seem quite non intrusive
[13:29:40 CET] <fritsch> beside the output handling
[13:29:49 CET] <fritsch> concerning the fields
[13:29:51 CET] <fritsch> not much changed
[13:30:32 CET] <wm4> so what hw does actually support this?
[13:30:48 CET] <fritsch> broxton+
[13:30:52 CET] <fritsch> kabilake
[13:30:55 CET] <wm4> oh
[13:31:01 CET] <nevcairiel> skylake has a hybrid 10-bit decoder on windows, but vaapi being vaapi, probably not there
[13:31:07 CET] <fritsch> nope
[13:31:12 CET] <fritsch> and not planned _at all_
[13:31:22 CET] <fritsch> the intel guys said ... marketing bla
[13:31:25 CET] <wm4> so why a vp9 hybrid decoder, but no hevc?
[13:31:35 CET] <fritsch> ask sean van kelley
[13:31:42 CET] <wm4> heh
[13:31:43 CET] <fritsch> the answer is obvious, isn't it?
[13:31:51 CET] <fritsch> let me give you some hints
[13:32:10 CET] <fritsch> chromebox, google, youtube, default codec, whining, fan noise, stutter, default format
[13:32:21 CET] <wm4> lol
[13:32:26 CET] <fritsch> if you are google, you get everything from intel that you want
[13:32:39 CET] <nevcairiel> the hybrid vp9 decoder is pretty slow, not sure it helps anyone =p
[13:32:40 CET] <wm4> very fun
[13:32:51 CET] <fritsch> jep 1080p60 is max
[13:32:53 CET] <fritsch> you get
[13:32:58 CET] <fritsch> it seems to optimized for full hd
[13:33:01 CET] <fritsch> everything beyond that
[13:33:04 CET] <wm4> I wonder what chromium uses for video display with vaapi
[13:33:15 CET] <fritsch> the use egl
[13:33:23 CET] <fritsch> the same as we do
[13:33:33 CET] <wm4> ah, nice
[13:33:33 CET] <fritsch> for surface sharing at least
[13:33:41 CET] <fritsch> there is one of those devs in #intel-gfx channel
[13:33:42 CET] <nevcairiel> i find it rather funny that intel has been pushing vp8/9 hwaccel for so long, and then suddenly nvidia enables full vp9 decoding 4k60+ in their GPUs and intel is once again behind on features :D
[13:33:46 CET] <fritsch> but I don't remember their name anymore
[13:34:08 CET] <fritsch> yeah nevcairiel but on other codecs that intel's hw does ... it seems intel has some very good engineers
[13:34:17 CET] <fritsch> skl's hevc 8 bit decoder is really fast
[13:34:21 CET] <wm4> for dxva they do something strange last I looked (using media foundation to convert surfaces to rgb32...)
[13:34:54 CET] <fritsch> most likely they wanted to implement less code
[13:34:58 CET] <fritsch> therefore did one conversion
[13:35:02 CET] <fritsch> and then used their given chain
[13:35:11 CET] <nevcairiel> intels decoder has been slightly faster than nvidias, but not worth anything for usual use-cases as both are beyond what you really need
[13:35:33 CET] <nevcairiel> nvidia pushes 150fps on 4k hevc10
[13:35:36 CET] <nevcairiel> so.. /shrug
[13:35:43 CET] <JEEB> yup :3
[13:36:28 CET] <fritsch> nevcairiel: kabilake and broxton will do, too :-)
[13:36:29 CET] <fritsch> quite sure
[13:36:39 CET] <nevcairiel> yeah well a year later
[13:36:44 CET] <fritsch> yeah
[13:36:48 CET] <fritsch> with 200W less
[13:37:02 CET] <wm4> so when will we have 10 bit on vdpau
[13:37:03 CET] <fritsch> for 1/4 th the price
[13:37:19 CET] <fritsch> wm4: when the hwaccel on linux also speaks 10 bit
[13:37:20 CET] <fritsch> I think
[13:38:05 CET] <nevcairiel> you could buy a nvidia shield if you want a low power appliance with the same hw decoding features :)
[13:38:11 CET] <fritsch> hahaha
[13:38:15 CET] <fritsch> nope you don't want that
[13:38:22 CET] <fritsch> cause: they have a "color" issue
[13:38:27 CET] <fritsch> let me link you
[13:38:47 CET] <fritsch> http://forum.kodi.tv/showthread.php?tid=256143
[13:38:48 CET] <fritsch> see
[13:39:01 CET] <fritsch> totally broken mediacodec decoding / rendering
[13:39:06 CET] <fritsch> no black, no whites and colors off
[13:39:06 CET] <JEEB> lol
[13:39:37 CET] <fritsch> https://forums.geforce.com/default/topic/895245/shield-android-tv/picture-quality-and-color-space-evaluation/
[13:39:46 CET] <fritsch> quite impressive those pictures _not_
[13:40:18 CET] <fritsch> ah and not a kodi issue - same with internal players
[13:41:12 CET] <nevcairiel> obviously you were supposed to take the hardware and throw off the silly android
[13:41:12 CET] <wm4> what's it with nvidia and limited rang
[13:41:13 CET] <wm4> e
[13:41:52 CET] <JEEB> nevcairiel: win10 IoT edition?
[13:41:54 CET] <wm4> fritsch: so it's just an issue of fixing the lavc hwaccel, and the vdpau API/driver already provides everything needed?
[13:41:56 CET] <JEEB> for ARM
[13:42:11 CET] <JEEB> (wait, does nvidia even have drivers for that?)
[13:42:26 CET] <fritsch> wm4: vaapi does, I don't know about vdpau - but from what I have seens vdpau also has the API for it now - only no driver present for testing
[13:42:49 CET] <nevcairiel> JEEB: linux would be fine
[13:42:50 CET] <fritsch> wm4: that's why I pinged BtbN if he sees "light at the end of the tunnel" to get hevc 10 bit vaapi code already rolling
[13:42:53 CET] <fritsch> nevcairiel: also not
[13:42:55 CET] <fritsch> no hw drivers
[13:43:00 CET] <fritsch> that would support "any" api
[13:43:08 CET] <fritsch> amlogic via linux would work
[13:43:11 CET] <BtbN> fritsch, the 10 bit API is present for a while iirc
[13:43:22 CET] <BtbN> But kinda hard to do anything with it without hardware supporting it
[13:43:23 CET] <fritsch> there were recent changes to the intel driver
[13:43:26 CET] <fritsch> that might change something
[13:43:34 CET] <BtbN> The intel driver can't change the libva API
[13:43:38 CET] <fritsch> nope
[13:43:43 CET] <fritsch> but for us players
[13:43:49 CET] <fritsch> the way we get the decoded surfaces
[13:44:02 CET] <nevcairiel> in any case, I have had my own personal long list of problems with intel gpus, i'm not going to use one any time soon, rather pay a higher power bill =p
[13:44:25 CET] <fritsch> yeah
[13:44:41 CET] <fritsch> i'd say a braswell + hevc 10 bit / vp9 hw would be perfect
[13:44:45 CET] <fritsch> and this will be broxton
[13:44:52 CET] <Compn> nevcairiel : are you nvidia or amd ? curious, after the bitcoin mining thing i dont know what cards are best anymore :P
[13:44:55 CET] <fritsch> broxton has the potential to be a new ION/ION-2
[13:45:03 CET] <fritsch> though also AMD is releasing a new platform with hevc 10 bit support
[13:45:16 CET] <fritsch> as opponent to broxton, but I have forgotten the name
[13:45:26 CET] <fritsch> Compn: haha
[13:45:38 CET] <Compn> you just know after they have stupid 10bit support the anime jerks will go 12/16 bit :P
[13:45:48 CET] <fritsch> Compn: obviously clear ...
[13:46:15 CET] <Compn> nevcairiel : i mean, which do you like better.
[13:46:27 CET] <fritsch> he won'T say AMD I am sure
[13:46:27 CET] <Compn> my sentence muxer is broken today.
[13:46:41 CET] <fritsch> if he is nerved with intel's driver then the worst blob of the world won't make it better
[13:46:54 CET] <nevcairiel> yeah AMD is the worst for video usage
[13:46:58 CET] <fritsch> there was a rent of a valve dev some time ago
[13:47:05 CET] <fritsch> about "who can write drivers"
[13:47:20 CET] <Compn> what card is in the valve box ?
[13:47:22 CET] <fritsch> amd's linux oss team is really good and when you see what one man got going in the last years
[13:47:27 CET] <fritsch> then that's impressive
[13:47:41 CET] <fritsch> vdpau supporting wise
[13:48:06 CET] <fritsch> damn - I need to go "out" ... walking :-)
[13:59:29 CET] <wm4> fritsch: btw. wasn't there something about vaapi mesa support?
[14:19:13 CET] <durandal_1707> ubitux: how is nlmeans going?
[15:01:47 CET] <fritsch> wm4: yes
[15:01:54 CET] <fritsch> wm4: but - you shall not support it!
[15:02:02 CET] <fritsch> wm4: that's what christian told me ...
[15:02:13 CET] <fritsch> as vdpau is far superior on amd cards
[15:02:26 CET] <fritsch> but it works on mpv already as this is what he tested it with
[15:02:28 CET] <fritsch> :p
[15:03:12 CET] <wm4> I don't mind vaapi that much anymore with the EGL interop
[15:03:32 CET] <wm4> and vdpau has this annoying thing of mapping progressive frames as fields with GL interop
[15:04:20 CET] <wm4> hm I also wonder when vdpau will generally support EGL and maybe wayland
[15:04:43 CET] <BtbN> Some headless mode like VAAPI has would also be nice
[15:04:45 CET] <BtbN> vdpau needs X
[15:04:46 CET] <fritsch> i am not sure this gl interop works with amd's mesa implementation
[15:04:51 CET] <fritsch> yes
[15:04:58 CET] <fritsch> it needs X that's the biggest flaw
[15:05:00 CET] <wm4> in theory, vdpau could work over EGL on X, but that doesn't work either
[15:05:38 CET] <wm4> there's only 2 X-specific functions in vdpau, and they're neatly separated out (in a second header file)
[15:05:50 CET] <wm4> (vdpau_x11.h)
[15:05:59 CET] <fritsch> does anybody have AMD hardware and a decent mesa?
[15:06:02 CET] <BtbN> But no non-X11 alternative
[15:06:03 CET] <fritsch> to try vaapi?
[15:06:12 CET] <wm4> not me
[15:06:27 CET] <fritsch> if it's "generic" i could undust my old E350 series gpu
[15:06:37 CET] <fritsch> most likely kodi won't work anyways with it
[15:08:11 CET] <wm4> well, current nvidia still insists on vdpau (and vdpau actually provides more features than vaapi)
[15:08:17 CET] <kierank> J_Darnley: do you think the same code can be used for the v210 unpack?
[15:08:23 CET] <kierank> the same idea I mean
[15:09:16 CET] <fritsch> wm4: which features?
[15:09:47 CET] <fritsch> afaik VPP has most of the things vdpau supports
[15:10:01 CET] <fritsch> weave deinterlacing is not there I think, but that's it
[15:11:44 CET] <wm4> at least properly working deinterlace and ivtc
[15:13:43 CET] <wm4> with vaapi I also have weird problems like non-bob deinterlacing mysteriously not working with non-hw decoded video etc.
[15:16:14 CET] <fritsch> what?
[15:16:22 CET] <fritsch> mmh
[15:16:33 CET] <fritsch> we have no issues with mcdi, madi anymore
[15:16:52 CET] <fritsch> though we never fed sw decoded video into vpp post processing
[15:18:24 CET] <J_Darnley> kierank: I'll look at the decoder but I don't see why not.
[15:18:37 CET] <J_Darnley> Simply put I was just unrolling the loop a little.
[15:20:04 CET] <wm4> fritsch: on nvidia, it's actually advantageous to feed sw-decoded data to the hw postprocessor, because the deinterlacer and the ivtc are pretty good
[15:20:25 CET] <fritsch> i don't get the usecase though
[15:20:41 CET] <fritsch> for VC1 perhaps
[15:20:46 CET] <fritsch> where interlaced is a nightmare
[15:20:55 CET] <fritsch> though that also works in vdpau correctly
[15:26:23 CET] <wm4> maybe if you want to apply additional filtering
[15:26:55 CET] <fritsch> when you already have the data a lot can be achieved with shaders
[15:57:57 CET] <cone-897> ffmpeg 03Michael Niedermayer 07master:c8a9aaab2695: swscale/x86/rgb2rgb_template: Fix planar2x() for short width
[16:18:56 CET] <cone-897> ffmpeg 03James Darnley 07master:61625dcc395f: fate: add 10-bit v210 encoder tests
[16:18:57 CET] <cone-897> ffmpeg 03James Darnley 07master:3836f404a8c0: avcodec/v210: add avx2 version of the 8-bit line encoder
[16:18:58 CET] <cone-897> ffmpeg 03James Darnley 07master:2cba1825f70c: avcodec/v210: add avx2 version of the 10-bit line encoder
[16:18:59 CET] <cone-897> ffmpeg 03James Darnley 07master:4c430738d9cc: avcodec/v210: document the requirement for sample_factor
[16:40:02 CET] <kierank> !!!
[17:14:25 CET] <cone-897> ffmpeg 03Claudio Freire 07master:60a76f8be8f4: AAC encoder: enforce SF delta in PNS and IS SFs
[17:14:26 CET] <cone-897> ffmpeg 03Claudio Freire 07master:df3fa48288d6: AAC encoder: use signed coeffs when measuring IS energy
[17:14:27 CET] <cone-897> ffmpeg 03Claudio Freire 07master:3d0849cc90a7: AAC encoder: TNS fixes on short windows
[17:14:28 CET] <cone-897> ffmpeg 03Claudio Freire 07master:69697be92200: libavcodec/aacenc_tnc.c: remove unused variable w2
[17:23:37 CET] <J_Darnley> Hm.  I might have found a bug in x264asm.
[17:23:42 CET] <J_Darnley> It won't turn "shufps m#, m#, imm8" into "vshufps m#, m#, m#, imm8" causing yasm to report "invalid combination of opcode and operands".
[17:24:01 CET] <J_Darnley> Should x264asm be doing that transformation or not?
[17:29:57 CET] <cone-897> ffmpeg 03Michael Niedermayer 07master:5fbd97fc756a: avcodec/diracdec: Fix qfactor/offset tables
[17:31:20 CET] <kierank> shufps is 3 operand normally
[17:34:50 CET] <J_Darnley> I know.  On further examination the problem might lie with yasm
[17:35:38 CET] <J_Darnley> vshufps xmm1, xmm0, 0x55 is fine
[17:35:46 CET] <J_Darnley> vshufps ymm1, ymm0, 0x55 is not
[18:37:41 CET] <cone-897> ffmpeg 03Carl Eugen Hoyos 07master:1f12a889da2a: configure: The XMA decoders depend on wmapro.
[18:43:15 CET] <philipl> wm4: 10bit hevc is the current project for the nvidia vdpau guy but he's on paternity leave until the end of the month
[18:43:34 CET] <philipl> There will be some significant vdpau changes coming to support the new surface types
[18:43:45 CET] <wm4> aha
[18:43:48 CET] <philipl> We'll need to do a bunch of work in the hwaccel too.
[18:44:37 CET] <philipl> If we're lucky, the other 10bit work going on will at least get us all the necessary surface types and we just have to pass them through
[18:48:30 CET] <nevcairiel> whats with all these crazy people writing vaapi encoders
[18:48:41 CET] <philipl> there's one for everyone!
[18:48:57 CET] <wm4> I guess people really want it?
[18:50:09 CET] <nevcairiel> also avfilter hacks once again
[18:50:43 CET] <wm4> I don't understand the filter patch
[18:50:52 CET] <wm4> where is it getting the context from
[18:50:56 CET] <Daemon404> mmm vaapi.c in avutil?
[18:51:17 CET] <wm4> though there's this in the avutil patch: +static AVVAAPIConnection *av_vaapi_connection_list;
[18:51:21 CET] <wm4> (so, maybe insanity)
[18:52:05 CET] Action: Daemon404 wonders if people ever think they should talk to the devs first before toiling away on massive invasive patches
[18:57:51 CET] <nevcairiel> its always the global state
[18:57:56 CET] <nevcairiel> and no Daemon404, people are insane
[18:58:50 CET] <wm4> +    FT(H264Baseline,            H264Main    ), // (Not quite true.)
[18:58:52 CET] <wm4> hmm
[19:08:16 CET] <durandal_1707> what avfilter hack?
[19:08:44 CET] <wm4> filters for opaque hardware surfaces
[19:09:01 CET] <wm4> there's currently no way to pass through the hw API context
[19:14:54 CET] <durandal_1707> ah, hacklers
[19:25:55 CET] <J_Darnley> kierank: it looks like the decoder doesn't get any faster when using avx2
[19:26:11 CET] <J_Darnley> I've probably got some bug somewhere
[19:32:19 CET] <jamrial> if the output is bitexact then it's not a bug. maybe you're overusing cross-lane instructions and losing any performance gains the 32bytes regs provide
[19:38:27 CET] Action: Daemon404 always thinks about downclocking when he thinks of avx2
[19:40:14 CET] <nevcairiel> Daemon404: thats why the avx2 code has to be a real improvement to be worth it, and not just 5% :d
[19:42:17 CET] <jamrial> do broadwell and skylake also suffer from that?
[20:07:49 CET] <J_Darnley> Thanks for the comments.
[20:08:22 CET] <J_Darnley> It is exact and I'm not running twice as many loops as necesary so I guess its just not faster.
[20:26:09 CET] <J_Darnley> If anyone wants to look at the commit https://gitlab.com/J_Darnley/ffmpeg/commit/0043ade0f4529f9280548f9bb2ce711d2d2d4656
[20:29:59 CET] <durandal_1707> afftfilter is fun as bandpass filter
[20:38:00 CET] <cone-897> ffmpeg 03Michael Niedermayer 07master:033b49e02d57: avcodec/libaacplus: Cleanup in case of init failure
[20:38:01 CET] <cone-897> ffmpeg 03Michael Niedermayer 07master:321e85e1769c: swscale/swscale: Add some sanity checks for srcSlice* parameters
[20:53:39 CET] <BBB> Im wondering if I should add checkasm tests for older codecs like vp8, or if fuller coverage for hevc/h264 is more important
[20:54:08 CET] <nevcairiel> do what is fun for you? :)
[20:59:36 CET] <J_Darnley> Uh oh.  I made some fate clients go red.
[20:59:52 CET] <Daemon404> https://www.youtube.com/watch?v=uACvFAm6JSM
[20:59:54 CET] <nevcairiel> how evil of you
[21:00:00 CET] <J_Darnley> It looks like their yasm doesn't know avx2 instructions.
[21:00:15 CET] <Daemon404> J_Darnley, you need to bump the minimum yasm test then
[21:00:16 CET] <Daemon404> to use avx2
[21:00:31 CET] <Daemon404> or something
[21:00:39 CET] <Daemon404> (not sure if nasm works at all
[21:00:55 CET] <J_Darnley> Other things probably guard using EXTERNAL_AVX2.  I'll probably do that
[21:01:13 CET] <Daemon404> oh ok
[21:01:23 CET] <Daemon404> i thought you had
[21:01:41 CET] <J_Darnley> No :(  I was bad and missed that.
[21:01:54 CET] <nevcairiel> yeah there is a condition for that
[21:02:03 CET] <rcombs> it'd probably be fair to require a newer yasm at this point, though
[21:02:07 CET] <rcombs> it's been years
[21:02:39 CET] <J_Darnley> Why don't I fix my code first then start a bikeshed argument ofer assembler versions.
[21:02:51 CET] <rcombs> fair
[21:04:21 CET] <atomnuker> if you think that's horrifying then just remember that we still have FATE machines regularly running a 13 year old unpatched GCC
[21:06:07 CET] <Daemon404> if you think that's horrifying then just remember that people still have machines regularly running a 13 year old unpatched GCC
[21:06:10 CET] <Daemon404> in production.
[21:06:29 CET] <fritsch> debian woody for the win
[21:07:44 CET] <J_Darnley> Does someone agree that this looks right http://pastebin.com/fZ2tY0qT
[21:11:13 CET] <J_Darnley> Oh wait, there's two of them
[21:14:44 CET] Action: J_Darnley curses the speed of Windows
[21:24:59 CET] <cone-897> ffmpeg 03James Darnley 07master:f59b727e2f98: avcodec/v210: guard new avx2 functions from old assemblers
[21:32:54 CET] <BBB> whooooooooo wants to review patches
[21:34:27 CET] <J_Darnley> I'll have a look after I make some tea
[21:51:54 CET] <jamrial> BBB: emulated_edge_mc_8_sse2 (failed to issue emms)
[21:53:31 CET] <BBB> what is that?
[21:53:38 CET] <BBB> oh emms exclusion list
[21:53:41 CET] <BBB> wheres that again?
[21:54:58 CET] <jamrial> no idea
[21:56:19 CET] <BBB> Gramner: ?
[21:57:15 CET] <jamrial> maybe declare_func_emms instead of declare_func?
[21:57:23 CET] <jamrial> you seem to do that in vp9dsp
[21:59:12 CET] <nevcairiel> its all kinds of backwards
[21:59:30 CET] <nevcairiel> you n eed to use declare_func_emms on functions that are exempt from emms
[21:59:49 CET] <Gramner> yeah, the emms logix is kinda backwards. I blame jannau!
[22:00:01 CET] <Gramner> feel free to change it
[22:10:16 CET] <BBB> jamrial: ok amended locally
[22:10:18 CET] <BBB> anything else?
[22:12:01 CET] <durandal_1707> michaelni: that crop patch I posted is causing crashes in bunch of video encoders
[22:15:08 CET] <J_Darnley> durandal_1707: about that crop patch, since you consume the crop metadata, should you remove it from the frame?
[22:15:52 CET] <durandal_1707> indeed, probably should
[22:16:02 CET] <jamrial> BBB: i'm not sure if calling bench() so many times after a single check_func() is correct
[22:16:20 CET] <jamrial> it for that matter makes checkasm --bench take twice to complete here
[22:16:42 CET] <BBB> I can call it at the end of _size
[22:17:14 CET] <michaelni> durandal_1707, i guess encoders (as well as filters) expect aligned data
[22:17:27 CET] <michaelni> and crop breaks that i guess
[22:17:36 CET] <michaelni> but just guessing
[22:17:49 CET] <BBB> jamrial: ok did that
[22:18:13 CET] <BBB> jamrial: it does make bench fairly random
[22:18:35 CET] <BBB> in that its unclear whether youre benching a representative sampling of calls to emu_edge
[22:19:38 CET] <jamrial> mmh
[22:20:41 CET] <durandal_1707> michaelni: same happens with using 0 CPU flag
[22:21:16 CET] <durandal_1707> so they just don't support frame size change on the fly
[22:22:08 CET] <jamrial> BBB: in that case don't change it. --bench is not used when running fate
[22:22:25 CET] <jamrial> and it's better to get a proper benchmark from it
[22:22:31 CET] <BBB> ok
[22:22:41 CET] <BBB> reverted that again locally
[22:22:59 CET] <BBB> if I come up with a proper way to bench in a statistically meaningful way, Ill change it accordingly
[22:23:13 CET] <BBB> but right now dont really know for sure without changing bench to take variable input
[22:23:19 CET] <jamrial> ok
[22:33:58 CET] <BBB> Gramner: what is the first argument to declare_func_emms?
[22:34:08 CET] <BBB> is that the cpuflags for which we dont want to check for emms usage?
[22:34:18 CET] <BBB> usage being requirement
[22:40:20 CET] <Gramner> I think so, but I feel that a lot of the checkasm emms stuff needs to be changed a bit. some of it seems redundant
[23:02:31 CET] <kierank> are there any simple decoders to look at for examples of how to handle  frame threading
[23:02:57 CET] <atomnuker> theora
[23:04:08 CET] <atomnuker> though it's likely to confuse you even more
[23:04:19 CET] <kierank> I'm having problems with storing data in my struct that's thread-specific
[23:41:29 CET] <BBB> kierank: ask questions, Im happy to answer, MT should be fairly straightforward
[23:41:38 CET] <kierank> jannau seems to have fixed it
[23:41:57 CET] <BBB> \o/ :-p
[00:00:00 CET] --- Mon Jan 18 2016