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

[burek]

[00:07:55 CEST] <cone-643> ffmpeg 03Michael Niedermayer 07master:aa6c43f3fdec: avcodec/ffv1: seperate slice_count from max_slice_count
[04:18:56 CEST] <rcombs> anyone object to https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179207.html?
[04:21:27 CEST] <philipl> Don't some subtitles have durations?
[04:21:41 CEST] <rcombs> they usually do!
[04:22:11 CEST] <rcombs> but sometimes they're very long, and subtitle "frames" can overlap (unlike video or audio) within a single stream
[04:23:05 CEST] <rcombs> I've got a file here with several events in the first several packets that have a combined duration several times longer than the total duration of the whole file
[04:23:40 CEST] <rcombs> which results in avformat_find_stream_info thinking it's hit its max analyze duration and giving up
[04:41:21 CEST] <philipl> I see. Fair enough.
[04:42:54 CEST] <rcombs> I also considered just skipping subtitles altogether when deciding whether or not to bail out early in find_stream_info
[04:43:24 CEST] <rcombs> I don't really have a strong opinion either way
[04:43:32 CEST] <rcombs> but the current behavior is pretty clearly broken
[04:53:16 CEST] <philipl> That seems the case. I think either approach is reasonable.
[09:17:27 CEST] <cone-723> ffmpeg 03Claudio Freire 07master:9458a62decfc: AAC encoder: tweak PNS usage to be more aggressive
[10:03:20 CEST] <j-b> Daemon404: yes
[11:59:23 CEST] <ubitux> just curious, anyone aside from wm4 & myself willing to work with libav for the m:n async api model? BBB maybe (not here :()?
[11:59:38 CEST] <nevcairiel> i am
[11:59:53 CEST] <ubitux> any suggestion on how to approach this?
[12:00:09 CEST] <ubitux> i mean, from the cooperation aspect, not technical one
[12:00:56 CEST] <wm4> (rcombs also seemed to be interested)
[12:01:16 CEST] <wm4> ubitux: well, we need to decide on a mailing list?
[12:01:25 CEST] <wm4> where the discussion happens, and maybe patches
[12:02:25 CEST] <ubitux> do you think it's possible/overkill to have a temporary 3rd mailing list to avoid butthurts?
[12:02:33 CEST] <nevcairiel> just use theirs and dont think too much about it
[12:02:53 CEST] <ubitux> okay
[12:04:15 CEST] <ubitux> could be nice to send to both though
[12:04:39 CEST] <ubitux> with the fear that it might degenerate fast
[12:05:10 CEST] <nevcairiel> that always ends up silly for people that are not subbed to both, since people often forget to hit reply all
[12:05:14 CEST] <wm4> cross-ML posts are icky
[12:05:19 CEST] <wm4> they get broken really quick
[12:06:30 CEST] <saste> ubitux, or you set up a new common mailing-list, but that might now work
[12:06:44 CEST] <saste> so the safe bet is to use libav-devel
[12:07:26 CEST] <ubitux> yeah, i can deal with it, but it might be nice to keep ffdev up-to-date; maybe some summaries should be sent on a regular schedule
[12:08:04 CEST] <wm4> just send a mail to ffmpeg-devel that the new API is discussed on this and that thread
[12:08:15 CEST] <ubitux> yeah, that was what i had in mind
[12:31:42 CEST] <durandal_1707> 10 minutes of fuzzing nut+ffv1 and there already found hang
[12:56:28 CEST] <haasn`work> nevcairiel: ping, wm4 told me to ask you about YV12->NV12 conversion on the CPU; you said it's as fast as memcpy? Is there a helper somewhere in ffmpeg libs?
[12:57:20 CEST] <haasn`work> And mostly I'm wondering if this would improve rendering performance; currently we do the conversion on the GPU but it's slowing down on some iGPUs that suffer from the extra render pass
[12:57:42 CEST] <haasn`work> So doing it on the CPU might be considerably easier
[13:05:37 CEST] <JEEB> haasn`work: I'm pretty sure he wrote it himself
[13:05:48 CEST] <JEEB> unless the swscale one suddenly got faster
[13:05:54 CEST] <wm4> (haha)
[13:06:05 CEST] <JEEB> check his repo @ http://git.1f0.de/gitweb?p=lavfsplitter.git;a=summary;js=1
[13:14:18 CEST] <durandal_1707> michaelni: found hang in ffv1, interested in sample?
[13:15:39 CEST] <Compn> durandal_1707 : yes he is, just upload it somewheres and give him filename/link
[13:19:45 CEST] <kierank> durandal_1707: open ticket
[13:19:52 CEST] <kierank> durandal_1707: do you want access to the dev machine?
[13:20:50 CEST] <durandal_1707> I'm on somehow already on powerful
[13:21:25 CEST] <durandal_1707> Unless it have 16 cores....
[13:23:39 CEST] <Compn> no build enviro for compn to test bugs :(
[13:29:05 CEST] <BBB> haasn`work: isnt that just nv12enc in ffmpeg?
[13:29:29 CEST] <BBB> haasn`work: and yes perhaps that shouldve been in swscale, but its not
[13:37:32 CEST] <wm4> fritsch: fernet is not on this IRC channel, or is he?
[13:41:58 CEST] <fritsch> wm4: nope - but you reach via email easily
[13:42:20 CEST] <fritsch> wm4: or -  just add your comment to his commits - that's all squash stuff done by him and me
[13:42:35 CEST] <fritsch> wm4: if it is about vaapi / egl
[13:42:57 CEST] <wm4> yes... I got the vaapi egl interop to work yesterday, but to use it by default, I need to detect its presence on loading
[13:43:11 CEST] <wm4> because for vdpau and old Mesa we still need GLX
[13:43:23 CEST] <wm4> but it seems the only way to detect it is to actually try it
[13:44:11 CEST] <fritsch> yes, you are right
[13:44:17 CEST] <fritsch> can't you just check for the extension?
[13:45:19 CEST] <wm4> which one? the closest I know is EXT_image_dma_buf_import, but that is available in Mesa 10
[13:46:35 CEST] <fritsch> https://github.com/FernetMenta/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L2390 <- check for this?
[13:46:48 CEST] <fritsch> which is used for creating the image?
[13:48:02 CEST] <wm4> the code you're pointing to doesn't even check for the extension correctly (unless this is done elsewhere)
[13:48:13 CEST] <fritsch> nope, we know that it will work
[13:48:14 CEST] <fritsch> :-)
[13:48:17 CEST] <wm4> anyway, they are available on Mesa 10 too
[13:48:20 CEST] <fritsch> and no nullptr is returned
[13:48:25 CEST] <fritsch> yeah, it's about the attribs
[13:48:30 CEST] <fritsch> that method gets passed
[13:49:42 CEST] <fritsch> perhaps trying to create an empty elgImageY from a mapped buffer?
[13:49:51 CEST] <fritsch> and see if the resulting thing is an image?
[13:50:09 CEST] <wm4> at this point it's more convenient to just probe it by running the code
[13:50:13 CEST] <wm4> I hoped for a more elegant way
[13:50:20 CEST] <fritsch> yeah - I don't know of any
[13:50:30 CEST] <fritsch> but you could ask: chadv or bwidawski in #intel-gfx
[13:50:45 CEST] <fritsch> they are intel's egl experts and perhaps know
[13:51:22 CEST] <wm4> oh, thanks for the tip
[13:53:14 CEST] <fritsch> yeah, let's wait - they will appear in some hours
[14:46:47 CEST] <cone-019> ffmpeg 03Michael Niedermayer 07master:b2955b6c5aed: avcodec/rangecoder: Check e
[14:50:46 CEST] <michaelni> durandal_1707, should be fixed
[16:09:14 CEST] <saste> I'm getting no mail reply from Lukasz, is he ever online?
[16:11:00 CEST] <Daemon404> no
[16:11:28 CEST] <Daemon404> afaik he quite the communit when his dir listing thing was not well accepted by people
[16:11:31 CEST] <Daemon404> quit*
[16:13:20 CEST] <saste> ok, thanks
[16:13:53 CEST] <wm4> drama
[16:14:27 CEST] <JEEB> oh wow
[16:17:12 CEST] <fritsch> wm4: no reply yet, right?
[16:18:31 CEST] <wm4> fritsch: I didn't send a mail if you mean that
[16:19:41 CEST] <fritsch> wm4: nope on irc
[16:19:51 CEST] <fritsch> just though you got something new
[16:20:05 CEST] <fritsch> btw. our vaapi 10 bit discussion you might have followed lately
[16:20:36 CEST] <fritsch> it was forwarded to the "OTC
[16:20:36 CEST] <fritsch> Media architect and responsible for driver development and features
[16:20:37 CEST] <fritsch> for VAAPI at Intel."
[16:20:44 CEST] <fritsch> guy
[16:21:03 CEST] <fritsch> he then explained us, that hevc is supported on broadwell (!) and braswell
[16:21:13 CEST] <fritsch> which is not right ...
[16:21:27 CEST] <fritsch> but yeah, i kindly asked him to give us a solution for 10 bit content
[16:21:32 CEST] <fritsch> no reply yet
[16:22:24 CEST] <wm4> 10 bit with hevc?
[16:23:04 CEST] <Compn> some devs here are good at telling other devs that their work is terrible 
[16:23:05 CEST] <Compn>  :(
[16:23:25 CEST] <Compn>  vlc 3.0.0 now has dir listing support in http/ftp etc
[16:23:44 CEST] <Compn> or will soon
[16:24:56 CEST] <fritsch> wm4: yes - the gpu assisted work
[16:25:12 CEST] <fritsch> wm4: that there already is on windows or even 8 bit hevc work which is there for broadwell
[16:25:34 CEST] <fritsch> i think you were also online when we talked with __gb__
[16:26:44 CEST] <wm4> ok
[16:26:57 CEST] <wm4> Compn: it still doesn't belong into libavformat, and most agreed with that
[16:27:51 CEST] <Daemon404> Compn, you cant just accept every idea and design as good
[16:33:27 CEST] <kierank> vlc isn't a multimedia library though
[16:33:41 CEST] <Daemon404> that too
[17:10:18 CEST] <nevcairiel> Compn: we never argued its a bad feature as such, and a player might be the right place to have it, but our only argument was that avformat isnt the right place
[17:10:39 CEST] <Daemon404> yep
[17:10:59 CEST] <cone-019> ffmpeg 03Michael Niedermayer 07master:25df7b1c35bf: avcodec/ffv1dec: Fix >8bps error concealment
[17:20:13 CEST] <cone-019> ffmpeg 03Pedro Arthur 07master:a8602dde5e0a: swscale: fix ticket #4877
[17:23:05 CEST] <cone-019> ffmpeg 03Lucas de Andrade 07master:770dd105044d: avformat/hls: Update Cookies response with Setcookie
[17:23:24 CEST] <ubitux> we need one more vote for the voting comittee; michaelni? reynaldo? jamrial?
[17:25:48 CEST] <TimNich> sounds suitably recursive..
[17:27:07 CEST] <Daemon404> can we vote on who votes for the vote
[17:27:19 CEST] <TimNich> now then!
[17:29:57 CEST] <martijnb> before I go duck into the weekend
[17:30:08 CEST] <martijnb> I think you handled Lucas on the mailinglist well, wm4, commendable
[17:31:55 CEST] <wm4> huh
[17:44:12 CEST] <BBB> Compn: I think the broader issue is that its a useful feature for some multimedia applications, but if we put all useful-feature-for-some-multimedia-apps in some lav* library, well soon maintain all of kde _and_ gtk
[17:44:27 CEST] <BBB> Compn: not to mention libxml2, glib, gstreamer, helix, libvpx, x264, etc.
[17:44:44 CEST] <BBB> Compn: we have to put a line in the sand somewhere and say, ok, were not going to do _that_
[17:46:53 CEST] Action: Daemon404 hesitantly points out the proposed charset conversion in libavutil
[17:47:21 CEST] <wm4> (we should still agree on using some xml lib or at least NIH a simple xml parser)
[17:48:04 CEST] <iive> isn't out there a xml lib that is THE xml lib?
[17:48:13 CEST] <Daemon404> no really
[17:48:15 CEST] <Daemon404> not*
[17:48:17 CEST] <nevcairiel> thats libxml2 more or less
[17:48:23 CEST] <Daemon404> nevcairiel, lots use expat
[17:48:28 CEST] <iive> yes... that one.
[17:49:35 CEST] <wm4> and _all_ those libs really suck
[17:49:55 CEST] <Daemon404> parsing xml inherently sucks in C
[17:50:04 CEST] <Daemon404> i dont think youll get around that
[17:51:40 CEST] <BBB> right, what he just said
[17:51:46 CEST] <BBB> xml is & just sucky
[17:52:00 CEST] <BBB> libxml2 is pretty good btw, Ive worked with it a couple of times
[17:52:08 CEST] <BBB> and its more or less a system lib
[17:52:29 CEST] <BBB> as for charset conversion, I really dont understand the issue with using a system lib for that
[17:52:41 CEST] <wm4> BBB: you mean iconv?
[17:53:07 CEST] <BBB> for example
[17:53:13 CEST] <wm4> because the proposed lavu thing is basically aviconv
[17:53:20 CEST] <BBB> of course it is
[17:53:31 CEST] <BBB> at some point michael proposed writing avgcc
[17:53:36 CEST] <BBB> thank god we didnt do that
[17:53:45 CEST] <BBB> so why is aviconv a good idea?
[17:55:02 CEST] <wm4> <BBB> at some point michael proposed writing avgcc
[17:55:04 CEST] <wm4> wat
[17:55:22 CEST] <BBB> we all agree its a terrible idea
[17:55:22 CEST] <BBB> now
[17:55:28 CEST] <BBB> why is aviconv a good idea?
[17:55:44 CEST] <wm4> I guess the idea is avoiding an iconv dependency if the user only needs utf-8 (and maybe latin1/utf-16/something else)
[17:55:55 CEST] <wm4> the end
[17:56:00 CEST] <BBB> (at some point our dear friends at mplayer implemented their own memcpy - also one of those great memories)
[17:56:01 CEST] <wm4> you'll need to ask Nicolas
[17:56:27 CEST] <wm4> these days custom memcpys are needed again
[17:56:32 CEST] <iive> i don't remember avgcc, but it does sound like joke
[17:56:32 CEST] <wm4> because uncacheable GPU memory
[17:56:47 CEST] <iive> oh, and fabrice wrote tiny cc
[18:01:02 CEST] <iive> mplayer does a lot of memcpy of big data. most of the system glibc doesn't use SIMD accelerated memcpy...
[18:01:18 CEST] <Daemon404> uh, maybe 10 years ago
[18:01:57 CEST] <wm4> or 20
[18:02:40 CEST] <BBB> mplayer is from 20 years ago
[18:02:43 CEST] <BBB> ...
[18:02:49 CEST] <iive> glibc have a thing where a version compiled for mmx or sse exists as separate library.
[18:02:49 CEST] <BBB> anyway, all of these are terrible ideas
[18:03:22 CEST] <BBB> if nicolas wants to do aviconv, then well, nothing I can do against it
[18:03:31 CEST] <BBB> but I would personally just use iconv and move on with my life
[18:03:46 CEST] <iive> iconv could be considered a system library.
[18:03:48 CEST] <durandal_170> just vote no
[18:05:14 CEST] <BBB> I thought voting would be reserved for contentious stuff that cannot be judged on technical merits alone?
[18:05:35 CEST] <iive> well, if you have a hammer...
[18:06:28 CEST] <BBB> iive: nah& I dont want to take others fun away
[18:06:41 CEST] <BBB> iive: look, I personally think its a bad idea. but nicolas is smart and its his time
[18:06:49 CEST] <wm4> I tried this: https://github.com/FFmpeg/FFmpeg/pull/153
[18:06:55 CEST] <BBB> iive: Im happy to discuss it with him and lay out my arguments, but Im not going to fight with him over it
[18:06:55 CEST] <wm4> too lazy to write a bot or something
[18:07:48 CEST] <wm4> "As much as I find it gratifying for my ego to see you all welcome us back
[18:07:48 CEST] <wm4> like that, I must say all your votes are both invalid, a"
[18:07:52 CEST] <wm4> this went well
[18:08:25 CEST] <BBB> ?
[18:08:28 CEST] <wm4> "If Margaret Thatcher were to crawl out of her grave and pretend she's a FFmpeg developer, "
[18:08:33 CEST] <wm4> oh well
[18:08:34 CEST] Action: wm4 hides
[18:09:04 CEST] <iive> i think that ffmpeg already have its own utf8 parser. so we already support utf8
[18:09:54 CEST] <BBB> GET_UTF8
[18:09:57 CEST] <BBB> thats true
[18:10:15 CEST] <wm4> do we need an iconv-style API around it?
[18:11:33 CEST] <iive> as for utf16... that's can of worms.
[18:12:46 CEST] <BBB> going back to useful subjects now :-p
[18:12:52 CEST] <BBB> Gramner: have I mentioned how much I love checkasm?
[18:13:06 CEST] <BBB> Gramner: I really dont know how to put it in words, its fantastic
[18:13:33 CEST] <wm4> what does checkasm do?
[18:13:35 CEST] <Gramner> BBB: thanks, that's why I wrote it :)
[18:13:50 CEST] <BBB> wm4: it & uhm & (dont kick me) checks your asm
[18:14:12 CEST] <wm4> we could probably use something like this for libass
[18:14:14 CEST] <BBB> you prepare input in some custom way, then you run a c function, a simd function, and it compares the output to ensure its identical
[18:14:41 CEST] <BBB> most functions use the same generic methods to prepare input, but some are somewhat customized, it depends on what your function does basically
[18:14:42 CEST] <wm4> hm, neat
[18:15:10 CEST] <BBB> and then if it doesnt match, it says (in red! yay! colors) FAILED! and the name of the function that failed
[18:15:21 CEST] <BBB> pretty neat
[18:15:46 CEST] <BBB> its basically a unit test for the dsp behind most codecs
[18:16:14 CEST] <BBB> with the advantage being that its much more precise than a fate test (because it tests one fuction, not a codec), and also much faster
[18:16:31 CEST] <BBB> (you still want fate, absolutely, but having both is neat)
[18:17:12 CEST] <Gramner> it's part of fate as well
[18:17:56 CEST] <BBB> oh right, well, I meant the sample md5 tests in fate
[18:18:08 CEST] <BBB> play first n frames of file m and compare md5s to a ref
[18:19:27 CEST] <BBB> Im wondering if I should play around with avx2 for the vp9 optimizations
[18:19:43 CEST] <BBB> (10-12bpp loopfilter specifically could benefit from it)
[18:20:27 CEST] <BBB> I guess Ill first finish what Im working on now
[18:22:17 CEST] <Gramner> any function where the width of the data being processed is larger than 16 bytes is usally a good target for avx2.
[18:23:08 CEST] <Gramner> you can make avx2 useful for smaller datasets as well, but it's harder and the gain is lower
[18:23:39 CEST] <BBB> loopfilter uses 16 pixels, so for 16bpp thats 32 bytes
[18:24:09 CEST] <michaelni> wm4: neat idea with the pull request, i wonder if that will work though
[18:24:18 CEST] <Gramner> yes, with high-bit depth stuff it's usually easy to make good use of the larger registers
[18:26:28 CEST] Action: BBB looks for victim^dvolunteer to donate a free haswell/skylake MBP
[18:28:45 CEST] <wm4> michaelni: probably not
[18:31:01 CEST] <wm4> saste: didn't you want to add a GPU memcpy to lavu?
[18:32:45 CEST] <saste> wm4, would make sense, to optimize GPU <-> CPU memcpy
[18:33:39 CEST] <saste> also, I measured significant performance improvements with dxva2 when using ASM memcpying instructions
[18:33:50 CEST] <Compn> Daemon404 , nevcairiel , BBB , wm4 : yeah well make noise before it gets to our gsoc page lol :P
[19:17:55 CEST] <BBB> Compn: stuff sometimes slips through ;)
[19:18:11 CEST] <philipl> BBB: you're looking for a donor or a recipient? :-)
[19:18:54 CEST] <BBB> Im the recipient
[19:19:01 CEST] <BBB> so guess what Im looking for :-p
[19:19:06 CEST] <philipl> heh.
[19:44:16 CEST] <durandal_170> is there any simple and good stt engine?
[20:30:25 CEST] <BBB> Compn: its not about excluding people - its about including people that are currently active
[20:30:43 CEST] <BBB> Compn: and the exact criteria where designed in the irc meeting of which full transcripts were posted online
[20:30:48 CEST] <BBB> Compn: so you can see details there
[20:31:03 CEST] <BBB> Compn: to answer your question: no it was not to cut out old devs
[20:42:12 CEST] <atomnuker> man the tiny_psnr tool is sometimes so far off it's ridiculous, but it's good enough to catch bugs & regressions
[20:42:50 CEST] <atomnuker> I wonder if tiny_ssim will be more useful
[20:44:04 CEST] <cone-019> ffmpeg 03Christophe Gisquet 07master:2801a1352dc8: dnxhddec: decode and use interlace mb flag
[20:49:08 CEST] <Compn> BBB : it was literally "lets use this metric" with no discussion
[20:49:12 CEST] <Compn> which is ok
[20:49:16 CEST] <Compn> (yes i went back and re-read it)
[20:49:40 CEST] <Compn> well a lot of discussions on how the committee could be made, 3 person 1 leader, 2 girls 1 cup, whatever.
[20:50:23 CEST] <BBB> I think various people (including me) considered the question of how to improve the metric
[20:50:33 CEST] <BBB> and we decided to go with this as an initial thing because its good enough"
[20:50:36 CEST] <BBB> nobody objected
[20:50:49 CEST] <BBB> do you want us to become philisophers and overthink everything and never get anywhere?
[20:50:56 CEST] <BBB> or do you prefer ffmpeg to go places and rule the world?
[20:58:24 CEST] <Compn> look thats why i asked my question
[20:58:25 CEST] <Compn> the answer is
[20:58:28 CEST] <Compn> "we dont know"
[20:58:34 CEST] <Compn> its not rocket science
[20:58:40 CEST] <Compn> simple question with a simple answer 
[20:58:45 CEST] <Compn> dont be so damn paranoid defensive about it
[20:59:52 CEST] <BBB> your reaction (email) sounded a little tinfoil hat :)
[21:00:07 CEST] <wm4> BBB: it definitely did
[21:00:30 CEST] <Compn> if i was posting with a tinfoil hat i would have asked why only 4 people came up with this idea of who controls the project
[21:00:53 CEST] <Compn> otherwise , i said i dont care. you can read "i dont care" as "tinfoil hat" if you want, but then you are projecting your fears and strawmans
[21:01:59 CEST] <Compn> reynaldo : samsung is coming out with new VR goggles. can we get some goggles to make ffmpeg handle whatever formats they need? :)
[21:02:24 CEST] <Compn> the world needs more 3d goggle vr porn.
[21:04:07 CEST] <reynaldo> Compn: depends
[21:04:35 CEST] <reynaldo> I actually have a vr team sitting nearby here at the office
[21:04:47 CEST] <reynaldo> I just dont really know what they do but I can ask
[21:04:49 CEST] <reynaldo> :)
[21:04:55 CEST] <Compn> ok cool yeah ask, cant hurt :)
[21:04:56 CEST] <Compn> thanks
[21:05:14 CEST] <reynaldo> one thing though
[21:05:37 CEST] <Compn> 3d vr stuff also used for movies, video games, uhhhh .............. yeah movies and video games.
[21:05:38 CEST] <reynaldo> do we have anyone with an actual plan to work on this?
[21:06:10 CEST] <Compn> well i just found out about this like 30 seconds ago, so i'm working on a plan
[21:06:22 CEST] <Compn> maybe durandal_170 who works on filters would be interested in checking the 3d stereo filter works with it
[21:06:22 CEST] <reynaldo> at the corporate side is either they needing something from us or we having an actuall plan leading to something they might be able to benefit from
[21:06:46 CEST] <reynaldo> Compn: give it a round of thought then, email me once you have something so I can FWd it properly
[21:07:28 CEST] <iive> Compn: repeat after me : "Oculus Rift"
[21:07:40 CEST] <Compn> iive : yes i know oculus rift ,what about it ?
[21:07:53 CEST] <reynaldo> the above "corporate" quote refers to situations in which we might be in position to request equipment / money and they actually willing to consider it
[21:08:06 CEST] <iive> Compn: don't bother with anything else, until it's been 2 years after its release.
[21:08:09 CEST] <reynaldo> (from experience at least)
[21:08:34 CEST] <Compn> iive : oculus rift already works with ffmpeg, https://www.reddit.com/comments/2hbee5
[21:09:25 CEST] <Compn> and samsungs' vr goggles are reported to be cheaper than rifts' 
[21:09:35 CEST] <Compn> even though probably not :D
[21:10:41 CEST] <Compn> reynaldo : i understand, but its kind of hard for me to organize a plan with people with no guarentee or funds or anything.  i cant even name a single devel who  likes 3d stuff
[21:11:07 CEST] <Compn> (in fact, i'm pretty sure everyone here hates 3d crap)
[21:12:08 CEST] <iive> i think interlace is more hated.
[21:12:41 CEST] <iive> you can completely ignore 3D stuff, if you encode it e.g. side by side.
[21:22:18 CEST] <cone-019> ffmpeg 03Jeremy James 07master:428424fe7520: dnxhddata: correct weight tables
[21:28:33 CEST] <durandal_170> Compn: I don't hate 3d stuff
[21:31:45 CEST] <cone-019> ffmpeg 03Paul B Mahol 07master:aff3acc54c07: avformat/iff: check for possible overflow in 2nd argument of av_new_packet
[21:36:33 CEST] <durandal_170> Daemon404 searching for sexy elenril on web....
[21:37:13 CEST] <fritsch> durandal_170: http://images5.fanpop.com/image/polls/853000/853139_1318332851689_full.jpg <- that?
[21:40:22 CEST] <durandal_170> why is asf demuxer always build?
[21:42:08 CEST] <crot|2> is it okay to ask about issues getting the latest snapshot to run after fresh ubuntu install/compile or should I keep that in #ffmpeg
[21:43:49 CEST] <wm4> #ffmpeg sounds more appropriate for this
[21:44:30 CEST] <crot|2> fair enough wm4 thanks for the reply 
[21:45:19 CEST] <Compn> reynaldo : ok i thought up a bunch of ideas
[21:45:25 CEST] <Compn> reynaldo : what email should i send to ?
[21:45:33 CEST] <Daemon404> durandal_170, lol
[21:45:36 CEST] <Daemon404> you just watched that sampke?
[21:45:49 CEST] <Daemon404> im particularily proud of adding it to fate
[22:04:39 CEST] <BBB> poor Gramner gets a real michael review :D
[22:10:06 CEST] <wm4> lavu had trees?
[22:10:13 CEST] <Gramner> yes
[22:10:45 CEST] <Gramner> there's probably a web browser hidden there somewhere too
[22:14:04 CEST] <Daemon404> Gramner, no that's in libavformat
[22:14:08 CEST] <Daemon404> i wish i was joking
[22:15:33 CEST] <BBB> sadly thats not even a troll
[22:16:32 CEST] <kurosu> there are far useless stuff in ffmpeg, like that hevc decoder nobody knows about nor use
[22:17:34 CEST] <Daemon404> ^ a proper troll
[22:18:36 CEST] <kurosu> or a self deprecating joke
[22:18:42 CEST] <wm4> what web browser
[22:18:47 CEST] <kurosu> I have moved to more mainstream stuff like dnxhd
[22:18:51 CEST] <Daemon404> oh, i misread wm4
[22:18:59 CEST] <Daemon404> i read web *server*... my bad
[22:19:04 CEST] <wm4> oh, lol
[22:19:25 CEST] <Daemon404> kurosu, it certainly is far more used currently
[22:21:13 CEST] <jamrial> useless libavutil stuff? all the crypto stuff i wrote comes to mind
[22:21:47 CEST] <Daemon404> i thought a lot of that was being used in rt(m)p
[22:21:48 CEST] <Daemon404> and pals
[22:22:11 CEST] <jamrial> not the modules i wrote :p
[22:22:24 CEST] <Daemon404> o olol k
[22:22:43 CEST] <drv> clearly everyone needs IBM CGA fonts
[22:23:13 CEST] <drv> how in the world did that end up in lavu?
[22:23:34 CEST] <jamrial> rtmp uses hmac sha256, support for which i did add, so i guess that's something not-so-useless i did for lavu crytpo
[22:27:00 CEST] <wm4> drv: maybe for rendering text in lavfi or so? dunno
[22:28:10 CEST] <drv> yep, seems so, bit of a shame that it always gets built in now
[22:28:35 CEST] <drv> and not only when you --enable-useless-codecs ;)
[22:29:54 CEST] <durandal_170> new filter in progress: maskedmerge
[22:31:42 CEST] Action: kurosu sheds a tear
[22:32:17 CEST] <kurosu> durandal_170, are you going to implement the whole suite of masktools afterwards?
[22:32:56 CEST] <kurosu> (I'm not sarcastic)
[22:33:08 CEST] <J_Darnley> I think its useful to have all the hash functions available in one library
[22:35:21 CEST] <J_Darnley> I was considering using them for a generic hash program (some thing to replace this DAMN Hash Calc I've been using for years
[22:38:02 CEST] Action: BBB looks for asm review victims
[22:38:24 CEST] <BBB> kurosu: dear sir, hi, can i ask you a question?
[22:39:27 CEST] <durandal_170> kurosu: blend is already there
[22:39:47 CEST] <kurosu> didn't you just ? or what is a ploy to avoid me playing dead ?
[22:40:11 CEST] <durandal_170> if something is useful shuts, why not..
[22:40:22 CEST] <durandal_170> *shure
[22:40:53 CEST] <kurosu> durandal_170, no, it was more about nostalgia
[22:51:28 CEST] <DHE> I have a patch that passes closed captions from MPEG2 to libx264. I've mentioned it before but many months ago. Tested working on set top boxes (a few models from a single vendor) and mobile video players.
[22:53:46 CEST] <iive> DHE: i assume you've sent it to the maillist. you are just asking for someone to review it.
[22:54:47 CEST] <iive> DHE: also, it's ok to bump it (aka reply to your own mail) if so much time have passed.
[22:55:17 CEST] <DHE> I have not actually... need to read up on the procedure...
[22:55:24 CEST] <DHE> right now I just have it thrown up on github
[22:58:32 CEST] <DHE> maybe this should wait until tomorrow then. I'm not firing on all cylinders right now..
[23:05:24 CEST] <iive> :)
[23:07:47 CEST] <BBB> hah, the current vp9 10/12bpp decoder is 35% faster than libvpx
[23:07:51 CEST] <BBB> and itxfm_add is still pure c code
[23:07:53 CEST] <BBB> nice \o/
[23:08:04 CEST] <BBB> directional ipred also, but thats relatively unimportant
[23:13:14 CEST] <iive> BBB: do you profile the code and are you using something else than `perf` ?
[23:13:28 CEST] <BBB> iive: I got exactly that question at my vdd talk :D
[23:13:42 CEST] <BBB> shall I give you a link to the youtube video fragment where I answer that question?
[23:14:04 CEST] <iive> there are videos of VDD talks? I do want link to them.
[23:15:07 CEST] <Gramner> https://goo.gl/Fg1vci VDD talks
[23:15:28 CEST] <BBB> https://www.youtube.com/playlist?list=PLQLpBN3oI7E44HIdTOovThc1MNHLchgHE
[23:15:31 CEST] <BBB> oh crap
[23:16:41 CEST] <iive> that might go into the topic :)
[23:17:08 CEST] <BBB> relevant question at 27:15 of the last talk in that list
[23:17:48 CEST] <kurosu> I use perf or codeXL under windows, but the later requires compiling with msvc which in turn doesn't have critical asm such as cabac
[23:18:16 CEST] <BBB> https://youtu.be/_Q6J2_nvLSI?t=27m12s
[23:18:28 CEST] <kurosu> I think I noticed perf being off by an insn or 2
[23:18:37 CEST] <iive> are you the one with the red shirt?
[23:18:42 CEST] <BBB> yes
[23:19:02 CEST] <iive> kurosu: isn't codexl AMD cpu only?
[23:19:23 CEST] <kurosu> no, but maybe the most useful stuff is AMG gpu only
[23:19:31 CEST] <BBB> so short answer: I use mac instruments, its pretty good at doing per-instruction highlighting although its not perfect
[23:21:25 CEST] <kurosu> there's also an intel tool that instrument your code in object files according to a cpu family of your choice if you surround it with some specific indicators, but it's overkill
[23:21:42 CEST] <kurosu> tells you where the bottleneck is on execution ports etc
[23:21:54 CEST] <iive> i'll watch the whole talk. I'm sure there are more interesting things in there.
[23:29:31 CEST] <BBB> per-block adaptive color transform?
[23:29:32 CEST] <BBB> w
[23:29:33 CEST] <BBB> t
[23:29:34 CEST] <BBB> f
[23:29:38 CEST] <BBB> is that for real?
[23:30:00 CEST] <kurosu> actually the adaptive part is just saying on or off
[23:30:06 CEST] <kurosu> and it's yuv->rgb
[23:30:29 CEST] <BBB> so its to switch between two transform functions?
[23:30:34 CEST] <BBB> a custom and a generic one?
[23:30:48 CEST] <kurosu> no color transform and yuv->rgb
[23:30:59 CEST] <kurosu> I didn't even use the specs name which was confusing to me
[23:31:37 CEST] <kurosu> the only stream I seen using it flags every block
[23:31:57 CEST] <kurosu> akin to saying "hey it's rgb content but in fact it's yuv"
[23:32:11 CEST] <kurosu> *I've seen
[23:32:28 CEST] <BBB> hm& weird
[23:33:12 CEST] <kurosu> well they have 11 bits for quantization scale, of which only 5 are probably useful, so there's room to suddenly find something more useful
[00:00:00 CEST] --- Sat Sep 26 2015