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

[burek]

[00:41:41 CEST] <BBB> oh my goodness this guy is a senior staff engineer
[00:42:05 CEST] <beastd> this guy?
[00:42:13 CEST] <nevcairiel> corporate code, this is how it looks
[00:44:14 CEST] <BBB> beastd: Sailaja Mahendrakar <smahendrakar at rgbnetworks.com>
[00:44:44 CEST] <BBB> you know, in google, a senior staff engineer is sometimes an indication of a really clueful engineer
[00:45:14 CEST] <nevcairiel> in some companies its a corporate puppet
[00:45:54 CEST] <kierank> it's a broadcast company
[00:45:57 CEST] <kierank> what do you expect
[00:47:56 CEST] <gnafu> Hehe.
[01:20:09 CEST] <philipl> #if 1 my friends.
[01:26:29 CEST] <kierank> I sent him an email
[03:57:34 CEST] <cone-344> ffmpeg 03Mariusz SzczepaDczyk 07master:c84d208c275d: examples/avio_list_dir: add move and delete methods
[04:36:04 CEST] <cone-344> ffmpeg 03Niklesh 07master:a604289b8570: movtextdec: Add support for automatic text wrapping
[12:26:46 CEST] <durandal_1707> I want to split histogram filter into 3 filters: histogram, waveform and vectorscope
[13:35:46 CEST] <Compn> BBB : did you see rxt's post on mplayer-dev-eng about deprecated api?
[13:36:03 CEST] <Compn> very in depth review of api :)
[13:39:41 CEST] <BtbN> That's an... interesting patch oO
[13:47:45 CEST] <wm4> who?
[13:50:21 CEST] <Compn> the thumbnail one probably
[13:51:21 CEST] <BtbN> yes
[13:55:37 CEST] <ubitux> durandal_1707: mostly only black slider logic remaining
[13:55:51 CEST] <ubitux> https://github.com/ubitux/FFmpeg/compare/selectivecolor
[13:55:58 CEST] <ubitux> i even added the photoshop preset import
[13:56:14 CEST] <ubitux> but without the black slider it's pointless
[14:11:08 CEST] <wm4> michaelni: what's the goal of the gsoc swscale refactor?
[14:12:31 CEST] <BBB> Compn: no
[14:12:58 CEST] <BBB> Im probably the only person in the world not subscribed to mplayer-dev-eng :-p
[14:15:14 CEST] <BBB> rtogni isnt here, is he?
[14:15:48 CEST] <ubitux> he was here the other day
[14:15:51 CEST] <Compn> hes not on irc at the moment
[14:15:54 CEST] <Compn> afaict
[14:16:00 CEST] <BBB> Compn: so, re his point on get_buffer, most users of lav* support threading and refcounting, so they use refcounted buffers. the new api is meant to support that
[14:16:21 CEST] <Compn> BBB : can you reply to his mail using google groups ?
[14:16:25 CEST] <Compn> er gmail interface
[14:16:31 CEST] <BBB> dont think so...
[14:16:43 CEST] <Compn> gmane*
[14:16:45 CEST] <BBB> or, I guess, I dont know how
[14:16:59 CEST] <Compn> http://blog.gmane.org/gmane.comp.video.mplayer.devel
[14:17:05 CEST] <Compn> you should be able to
[14:17:14 CEST] <wm4> mplayer has absolutely horrible horror code for get_buffer
[14:17:15 CEST] <Compn> i might have to manually allow all mails from you, but then thats it
[14:17:26 CEST] <wm4> it's so horrible that nobody ever got it to work well
[14:17:35 CEST] <wm4> I still see fixes by reimar every once in a while
[14:17:41 CEST] <wm4> have fun fixing this crap
[14:17:59 CEST] <wm4> it may as well be the most horrible mplayer code that involves libav* API
[14:21:20 CEST] <michaelni> wm4, the goal would be to turn the mess of custom hardcoded stages into a single generic API into which  the stages plug cleanly allowing other stages to be inserted, or allowing for example input colorspace convert / hscale or vscale/color convert to be split for rare formats or many other things
[14:22:17 CEST] <wm4> michaelni: so if I understand this right, the gsoc guy managed to separate scaling and conversion, but it became 3% slower
[14:22:22 CEST] <wm4> so he put them back together?
[14:26:00 CEST] <michaelni> we first should get the API in without speedloss then split things cleanly but leave the merged pathes for the common cases. all the stages&converters should in te end be in seprate files so the merges stages would be more like filters used through a common API
[14:26:55 CEST] <wm4> s then split things cleanly but leave the merged pathes for the common cases <- but that means code duiplication again?
[14:28:18 CEST] <michaelni> i dont really know if there would be duplicated code. i would hope that can be avoided
[14:29:19 CEST] <michaelni> ATM the API and using the existing code within the API need to be gotten into shape and pass review
[15:14:30 CEST] <cone-570> ffmpeg 03Michael Niedermayer 07master:88fe45e0fe37: avcodec/svq1enc: Check dimensions
[15:34:26 CEST] <cone-570> ffmpeg 03Michael Niedermayer 07master:b1f59bb66067: avcodec/flashsvenc: Correct max dimension in error message
[17:18:35 CEST] <durandal_1707> ubitux: what's so hard about black slider?
[17:19:02 CEST] <ubitux> i don't understand how it affects the adjustments
[17:19:52 CEST] <ubitux> i thought it was a simple c+k m+k y+k
[17:19:59 CEST] <ubitux> but actually not
[17:22:25 CEST] <ubitux> it might be clamped/rescaled to the max(c,m,y)-min(c,m,y) of the adjustments, or to the adjustment range of the pixel, but can't figure out how exactly
[17:22:37 CEST] <ubitux> it's probably something stupid, but well..
[17:59:35 CEST] <BtbN> This is some next level bug oO
[17:59:39 CEST] <BtbN> https://sourceware.org/bugzilla/show_bug.cgi?id=15199
[18:00:00 CEST] <BtbN> In my case it's triggered by mesa dlopening libudev, which the application also links against.
[18:03:19 CEST] <wm4> is dlopening in a static ctor even allowed?
[18:03:58 CEST] <BtbN> No idea, but aparently it's a realy bad idea
[18:08:00 CEST] <BtbN> Ok, managed to "fix" it by building mesa without support for gallium, which is where stuff gets loaded
[19:22:50 CEST] <ubitux> kierank: can you test if http://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177225.html works as expected when you have a moment?
[19:29:27 CEST] <ubitux> michaelni: can you rm sub/SAMI_ass_capability_tester.smi? it was never in use (and never will)
[19:29:47 CEST] <ubitux> it keeps poping up when rsyncing
[19:35:35 CEST] <Compn> ubitux : you cant git rm it ?
[19:35:47 CEST] <ubitux> it's not in git
[19:35:49 CEST] <Compn> ah
[19:35:51 CEST] Action: Compn afk
[19:50:15 CEST] <jamrial> BBB: could you bench this whenever you have time? http://pastebin.com/VkFYKEZA
[19:50:21 CEST] <jamrial> i don't have an ssse3 machine at hand right now so i can't do it
[19:51:07 CEST] <jamrial> assuming palignr is as fast as intel claims it to be it should be faster, if anything for going from 8 unaligned loads to only 2
[20:00:37 CEST] <BBB> jamrial: hm& so, I tested that back long ago
[20:00:45 CEST] <BBB> jamrial: and palignr is not fast at all on my machine
[20:00:55 CEST] <BBB> sadly :(
[20:01:34 CEST] <BBB> I can test again if you want...
[20:13:16 CEST] <jamrial> ah. well up to you
[20:14:43 CEST] <jamrial> in any case i may be able to test it later, especially if you add support to checkasm, so don't worry
[20:21:13 CEST] <jamrial> mmh, it supposedly is pretty fast on sandy bridge and ivy bridge, where it can do up to two per cycle. it's a tad slower on nehalem and haswell (one per cycle), and considerably slow on core2 merom
[20:22:20 CEST] <jamrial> if your cpu is the latter (core 2 without sse4.1) then that would explain it
[20:24:09 CEST] <jamrial> if we can confirm it's faster on recent cpus we could keep both versions and check for specific flags to run one or another
[20:24:34 CEST] <BtbN> It's slower on haswell?
[20:24:54 CEST] <jamrial> yeah, i don't know why
[20:25:01 CEST] <jamrial> same happened with other instructions
[20:26:12 CEST] <jamrial> check http://www.agner.org/optimize/instruction_tables.pdf or http://software.intel.com/sites/landingpage/IntrinsicsGuide/
[20:34:04 CEST] <kierank> ubitux: I'm not 100% sure how (possibly showinfo?) but I can try
[20:34:29 CEST] <ubitux> well, you said you needed that pattern
[20:34:41 CEST] <ubitux> i assumed you had a check if it wasn't following it
[20:34:45 CEST] <ubitux> (like, not working or something)
[20:35:52 CEST] <ubitux> -af ashowinfo will give you the nb_samples yes
[20:37:08 CEST] <kierank> well I implemented it myself because I couldn't get it to work
[21:03:00 CEST] <durandal_1707> kierank: what sws flags you used for smptebars? 
[21:03:27 CEST] <kierank> smptebars=s=720x576,format=yuv422p
[21:03:33 CEST] <kierank> that goes through an unscaled path
[21:03:56 CEST] <kierank> bizzarely if you use uyvy422 which is the native hardware format it goes through a scaled path
[21:19:26 CEST] <BBB> kierank: theres no native uyvy conversion then
[21:19:32 CEST] <BBB> kierank: which is not at all unsurprising
[21:20:00 CEST] <BBB> kierank: you could convert to yuv422 or yuv422p and then use a fast yuv422p to uyvy converter (Im not sure thats faster, but its likely what youre looking for in this particular case)
[21:20:28 CEST] <kierank> I was more concerned about colour accuracy
[21:20:38 CEST] <kierank> because the point was to verify the smptebars implementation
[21:21:10 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/pkPaJG3G/irccloudcapture177591402.jpg
[21:21:14 CEST] <kierank> it's right now
[21:21:23 CEST] <kierank> but with the scaled path there were lots of faint lines everywhere
[22:11:34 CEST] <kierank> Daemon404: when are you in town?
[22:11:44 CEST] <Daemon404> 20->22
[22:11:50 CEST] <Daemon404> 21 is conference dya
[22:11:51 CEST] <Daemon404> day*
[22:12:12 CEST] <Daemon404> im also in London on 10 Sep
[22:12:17 CEST] <kierank> could maybe go for a drink with atomnuker 
[22:12:54 CEST] <Daemon404> which day
[22:13:11 CEST] <kierank> dunno
[22:13:20 CEST] <kierank> 20/21 easiest
[22:13:25 CEST] <kierank> 22 i am hopefully moving into new place
[22:13:33 CEST] <Daemon404> 21 will be full, and 22 i am on a train at 11
[22:13:44 CEST] <Daemon404> so 20 aud or 10 sep work best for me
[22:14:08 CEST] <kierank> 10 sep is ibc for me
[22:14:16 CEST] <Daemon404> ah right
[22:14:38 CEST] <atomnuker> any day/time's fine with me
[22:14:42 CEST] <kierank> 20th probably best
[22:14:52 CEST] <Daemon404> all righty. i dont get into london until like 9pmish
[22:14:56 CEST] <Daemon404> at paddington
[22:15:00 CEST] <kierank> k
[22:15:15 CEST] <atomnuker> well, the 20th it is then
[22:15:35 CEST] <Daemon404> all right-y
[22:18:50 CEST] <Daemon404> wait wtf am i smoking
[22:18:55 CEST] <Daemon404> i get in at 3pm on the 20th
[22:19:04 CEST] <Daemon404> i was only 6 hours off...
[22:22:34 CEST] <Daemon404> so any time is good on teh 20th.
[22:25:16 CEST] <atomnuker> yeah, we need to agree on that and on a pub
[22:32:13 CEST] <Daemon404> my hotel is in the City, so it's not hard for me to get home, likely
[22:35:47 CEST] <kierank> have you been to the cheshire cheese?
[22:36:05 CEST] <Daemon404> nope
[00:00:00 CEST] --- Sun Aug 16 2015