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

[burek]

[00:28:07 CET] Action: Daemon404 will merge some more tomorrow; today was a holiday
[00:47:09 CET] <cone-932> ffmpeg 03Timothy Gu 07n3.1-dev:HEAD: RELEASE: Update to 3.0.git
[00:55:42 CET] <cone-932> ffmpeg 03Rostislav Pehlivanov 07master:3b1d1437a0f3: vc2enc: print the average quantization index at the end
[02:00:12 CET] <Timothy_Gu> FYI, GitStats for FFmpeg since ubitux's is down https://timothygu.me/gitstats/ffmpeg/
[02:48:08 CET] <Timothy_Gu> In case anyone's interested: Added VideoToolbox H.264 encoder. https://github.com/FFmpeg/FFmpeg/pull/177
[03:51:53 CET] <rcombs> Timothy_Gu: ooh, interesting
[05:02:13 CET] <Timothy_Gu> proud host of the only x86 Linux GCC release branch FATE box
[05:06:18 CET] <Timothy_Gu> also michaelni, do you plan on reenabling the Loongson FATE station?
[05:54:39 CET] <Timothy_Gu> ubitux: for some reason ffmpeg.org is being rrreally slow
[05:55:09 CET] <Timothy_Gu> the homepage takes 12s to load here (without encryption), but even fatebeta.ffmpeg.org takes 2s
[08:20:38 CET] <wm4> Timothy_Gu: there were patches for this before
[08:20:47 CET] <wm4> somehow got lost
[08:21:23 CET] <wm4> ah it's the same author
[09:17:55 CET] <cone-521> ffmpeg 03Carl Eugen Hoyos 07master:d0962160e076: lavfi/elbg: Make the pal8 output opaque.
[10:52:17 CET] <michaelni> Timothy_Gu, about loongson, yes, i already thought about it yesterday but then didnt have enough time
[11:43:47 CET] <ubitux> http://b.pkh.me/howto-aarch64-qemu-ffmpeg-neon-debug
[11:44:12 CET] <ubitux> (since it's always a pain to get such shit working, just sharing a quick bootstrap)
[11:45:04 CET] <ubitux> note: i didn't use linaro builds because gdb wasn't working (linked against libncurses5 while local system only has libncurses6) 
[11:47:31 CET] <ubitux> Timothy_Gu: i'm not responsible for ffmpeg.org admin
[11:47:53 CET] <ubitux> Timothy_Gu: and my gitstats isn't down, i just don't update it on a regular basis
[11:48:05 CET] <ubitux> i need to add an instance juste like coverage
[11:48:56 CET] <michaelni> Timothy_Gu, http://ffmpeg.org/ loads instantaneously here locally
[11:50:59 CET] <ubitux> it was probably stressed yesterday because of HN 
[11:51:42 CET] <michaelni> quite possibly
[11:56:53 CET] <michaelni> also we still have a 2nd server that is unused and should instead contain a duplicate of ffmpeg.org, it likely is more powerfull but ENO_VOLUNTEERS
[12:06:44 CET] <BtbN> Well, the 3.0 version number certainly brought more media attention than a 2.9 would have.
[12:09:11 CET] <ubitux> oh ffs "nexti" and related are all interpreted as a "continue" in gdb
[12:09:18 CET] <ubitux> what in the fucking hell is this shit
[12:11:05 CET] <wm4> lol gdb
[12:11:32 CET] <wm4> maybe there's a technical reason, like nit knowing whether single step will work, and if it doesn't, program execution is forcibly continued beyond?
[12:12:15 CET] <ubitux> there is obviously a (braindead) technical reason
[12:12:27 CET] <ubitux> i'd like to know it though
[12:42:38 CET] <durandal1707> michaelni: could you please look at my drawutils patch, fate test mess up terminal and I dunno how to fix it
[13:33:59 CET] <michaelni> durandal1707, against term messup this (from nicolas) may help if you use bash at least: bash_tty_mode=$(stty -g)
[13:33:59 CET] <michaelni> PROMPT_COMMAND='stty $bash_tty_mode'
[13:37:37 CET] <michaelni> the term messup is due to segfaults i think
[13:38:02 CET] <michaelni> fate-filter-pixfmts-pad test for yuva422p16le segfaults for example
[13:39:25 CET] <michaelni> more precissely this segfaults: ffmpeg -nostdin -nostats -cpuflags all -threads 1 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -f image2 -vcodec pgmyuv -hwaccel none -threads 1 -thread_type frame+slice -i tests/vsynth1/%02d.pgm -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -threads 1 -idct simple -dct fastint -vf format=yuva422p16le,pad=500:400:20:20 -vcodec rawvid
[13:39:25 CET] <michaelni> eo -frames:v 5 -pix_fmt yuva422p16le -frames:v 1 -f nut md5:
[13:40:48 CET] <BBB> kierank: I couldnt get it to crash with 2 threads with your patch, FWIW, and valgrind was happy
[13:56:07 CET] <durandal1707> michaelni: thanks
[14:05:17 CET] <durandal1707> michaelni: looks like bug in vf_pad
[14:30:21 CET] Action: Daemon404 doesn't know how michaelni has the patience for Mats
[14:31:18 CET] <durandal1707> i marked him as spam and now all his mails is happily in spam
[14:32:47 CET] <Daemon404> lol
[14:40:47 CET] <durandal1707> michaelni: actually everything points in output.asm bug in swscale
[14:43:01 CET] <durandal1707> is there way to force valgrind to print exact instruction that caused crash?
[14:43:59 CET] <iive> durandal1707: you can attach gdb on valgrind issue
[14:52:04 CET] <mateo`> wm4: forgot to reply to one of your question, content uris support is not mandatory for mediacodec (it's not even related except from the fact that it comes from android)
[14:55:20 CET] <wm4> ok
[14:55:32 CET] <wm4> still confused about the jni thing
[14:56:27 CET] <mateo`> which part ?
[14:57:08 CET] <wm4> it sounds like we can just use JNI_GetCreatedJavaVMs()?
[14:58:07 CET] <mateo`> In theory we could, we just need to check that jni_invocation_ != NULL, get the symbol of this function and call it
[14:58:25 CET] <mateo`> gst is doing that actually
[15:00:10 CET] <wm4> well if it crashes just blame google or the API user?
[15:00:12 CET] <mateo`> the only reason why i didn't do that is that i don't want to call private c++ code dlopen/dlsym etc
[15:01:18 CET] <mateo`> and don't really want to deal with those potential crashes ...
[15:01:23 CET] <mateo`> but this is something i can change
[15:02:29 CET] <wm4> is the jni_invocation symbol maybe exported? I noticed it's not static
[15:03:16 CET] <mateo`> yes it's exported
[15:03:25 CET] <cone-348> ffmpeg 03Mats Peterson 07master:b86ba37096dd: lavc/rawdec: Retrieve nut palette from packets
[15:04:22 CET] <mateo`> it's possible to dlsym all this mess :p
[15:06:14 CET] <wm4> mateo`: if it's exported, it's easy to check... the symbol is a pointer to a C++ class, but on all ABIs we deal with it it can be treated like a void* and checked for NULL
[15:08:51 CET] <mateo`> should i really go that way then ? :s
[15:09:46 CET] <wm4> IMHO yes, don't know about others
[15:17:00 CET] <mateo`> wm4: your idea behind is to not export any public api related to jni / android (so no application context either) and confine the jni utils to lavc ?
[15:19:12 CET] <durandal2707> michaelni: why it crashes only in asm in swscale?
[15:19:13 CET] <wm4> mateo`: kind of
[15:19:55 CET] <wm4> mateo`: if we really want this lavf content thing, we could probably do echo '#include "libavcodec/jni.c"' > libavformat/jni.c
[15:20:09 CET] <wm4> a dirty trick, but it's already used somewhere else
[15:20:23 CET] <ubitux> what am i reading
[15:21:09 CET] Action: JEEB closes ubitux's eyes with his hands
[15:21:53 CET] <mateo`> android, jni, dlsym c++ symbols, including .c
[15:22:10 CET] <mateo`> my life is really full of shit :D
[15:22:28 CET] <wm4> welcome to multimedia
[15:23:18 CET] <ubitux> http://z0r.de/3564
[15:23:32 CET] <mateo`> and now flash ...
[15:23:34 CET] <mateo`> thanks man
[15:24:25 CET] <ubitux> ffplay "http://z0r.de/L/z0r-de_3564.swf"
[15:24:27 CET] <ubitux> ;)
[15:25:47 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:15d9645fb4ce: swscale/slice: Actually use the buffers' strides
[15:27:20 CET] <kierank> eugh probing for dvb teletext
[15:30:43 CET] <J_Darnley> I'm tempted to shout at these android guys and tell them to get a proper OS with an actual file system
[15:31:33 CET] <Mavrik> Well it does have a file system.
[15:31:38 CET] <Mavrik> It's just fun to use!
[15:32:06 CET] <J_Darnley> Is this the future that the idiots who say "file are dead" actually want?
[15:32:27 CET] <durandal2707> andrey_utkin: ping
[15:32:45 CET] <Mavrik> (Not sure how filesystem is related to the crappy API that's MediaCodec)
[15:33:07 CET] <mateo`> it's not related
[15:33:33 CET] <J_Darnley> Sure it is.  Look at that horrible nonsense in the guy's latest mail.
[15:33:48 CET] <ubitux> note: please never remove --disable-pthreads in the future
[15:33:49 CET] <mateo`> it's me
[15:34:04 CET] <J_Darnley> Oh I can shout at you here can I?
[15:34:08 CET] <mateo`> you can
[15:34:36 CET] <J_Darnley> GET A PROPER OPERATING SYSTEM WITH AN ACTUAL FILE SYSTEM
[15:34:52 CET] <Mavrik> mateo`, btw, any worries about people who'll try to use MediaCodec from binaries that don't have a JVM instantiated?
[15:36:47 CET] <mateo`> Mavrik: i'm not familiar with this configuration, i don't know in details the implications of not having a jvm instantiated.
[15:37:10 CET] <Mavrik> Ok, so for example in one of the applications we abuse ffmpeg by using Runtime.getRuntime().exec()
[15:37:19 CET] <Mavrik> Which just runs ffmpeg compiled as a normal Linux binary for Android.
[15:37:31 CET] <Mavrik> Of course as a silly developer I'd like ffmpeg to use MediaCodec APIs
[15:37:38 CET] <Mavrik> But that binary won't have a JVM available :)
[15:37:58 CET] <Mavrik> Since it's just a binary and there's no JNI environment.
[15:38:33 CET] <mateo`> The c++ jni wrapper of google is supposed to be able to spawn a vm but i have no idea if it's actually working
[15:39:28 CET] <Mavrik> Well if you need testing :)
[15:39:33 CET] Action: Mavrik looks at pile of devices on his table.
[15:40:12 CET] <andrey_utkin> durandal2707: hi?
[15:42:29 CET] <durandal2707> andrey_utkin: there is drawbox/drawgrid patch on ml
[15:42:31 CET] <mateo`> Mavrik: I have also a bunch of devices. Do you need something special on the device to exec the binary ?
[15:42:43 CET] <Mavrik> nop, just build the binary with NDK standalone toolchain
[15:42:54 CET] <andrey_utkin> durandal2707: thanks, I will take a look.
[15:42:55 CET] <Mavrik> push it to /data/tmp
[15:42:56 CET] <Mavrik> and run it
[15:42:59 CET] <mateo`> ok
[15:43:12 CET] <Mavrik> Or the use case we did was to unpack it from assets to app files dir and run it from there via Java
[15:44:04 CET] <andrey_utkin> durandal2707: "avfilter/vf_drawbox: add alpha support" ?
[15:44:09 CET] <mateo`> Mavrik: then i'll try to do something for this particular case, but it won't be my priority at first.
[15:44:13 CET] <michaelni> also if anyone can help fill in awnsers for the GSoC questions in "0127 22:03 To FFmpeg devel (3.7K) [FFmpeg-devel] GSoC 2016" please do, and especially the "How many potential mentors have agreed to mentor this year?" i need, need to leave now, will read log
[15:44:34 CET] <Mavrik> mateo`, yp, personally I think just not supporting that is a valid option as well
[15:44:49 CET] <Mavrik> Just wanted to warn about that possibility since that's the "easiest" way of using ffmpeg from an Android app.
[15:46:55 CET] <durandal2707> andrey_utkin: yes
[15:48:04 CET] <mateo`> J_Darnley: there is a proper filesystem behind it, which uses fuse, which ... well ... :D
[15:48:32 CET] Action: J_Darnley resists further arguing/trolling
[15:50:02 CET] <andrey_utkin> sorry for being not an active part of ffmpeg, now I've got new job and it is strongly ffmpeg-related :) I hope I'll get more active, also a tricky transcoding tool (main feature is time interval based transcoding with filtering or remuxing) will get developed and released under GPL
[15:50:57 CET] <wm4> <ubitux> note: please never remove --disable-pthreads in the future <- ?
[15:51:50 CET] <wm4> andrey_utkin: awesome
[15:52:14 CET] <durandal2707> andrey_utkin: no need to be sorry, you do what you want..
[15:52:50 CET] <ubitux> wm4: i need it for qemu+gdb to work
[15:52:57 CET] <ubitux> with pthreads, it's unusable
[15:54:28 CET] <mateo`> wm4: i'm wondering about the ability to open a fd from lavf, would that mean a fd protocol (which will have big security concerns) ?
[15:54:58 CET] <wm4> you always have to be careful about what to pass to lavf
[15:55:07 CET] <wm4> also I wonder if we already have a fd protocol somewhere
[15:55:11 CET] <wm4> I just didn't find it
[15:59:41 CET] <andrey_utkin> wm4: there's underdeveloped "fd" protocol named "pipe", it handles only STDIN and STDOUT currently.
[16:24:45 CET] <Daemon404> hmm.
[16:24:52 CET] <Daemon404> we have 0 hls coverage.
[16:25:01 CET] <nevcairiel> network things are usually not covered
[16:25:06 CET] <Daemon404> i guess i can only pray my hls merge is correct aside from testing manually
[16:25:12 CET] <Daemon404> nevcairiel, hls can have file://
[16:25:15 CET] <Daemon404> for fate
[16:25:28 CET] <nevcairiel> i would argue that no, hls can not have file, it has http in the name
[16:25:29 CET] <nevcairiel> =p
[16:25:37 CET] <Daemon404> :P
[16:28:30 CET] <cone-348> ffmpeg 03Paul B Mahol 07master:a588c7ac13bc: avfilter: add fieldhint filter
[16:28:39 CET] <wm4> well this ability of the hls demuxer caused the recent security issue
[16:28:48 CET] <wm4> might as well use it for good and add it to fate?
[16:33:28 CET] <Daemon404> perhaps yes
[16:34:18 CET] <rcombs> have we limited it to only allow mpegts for the underlying demuxer?
[16:34:35 CET] <rcombs> and uh I think maybe mp3 is also allowed
[16:34:39 CET] <nevcairiel> its not limited to that though, it allows raw audio things
[16:34:44 CET] <nevcairiel> adts and mp3 at least
[16:34:48 CET] <nevcairiel> also some subtitle formats i think
[16:35:09 CET] <nevcairiel> anyway the  thing that got limited is the protocol support
[16:40:37 CET] <ubitux> yay, nv12 to bgra on aarch64 working
[16:40:48 CET] <Daemon404> ur
[16:40:50 CET] <Daemon404> urg
[16:40:59 CET] <Daemon404> for merging 81306fd4bdeb5c17d4db771e4fec684773b5790f
[16:41:01 CET] <Daemon404> im unsure what to do
[16:41:09 CET] <Daemon404> we use (abuse?) urlcontext stuff
[16:41:21 CET] <Daemon404> cookies, user-agent, http-proxy
[16:41:21 CET] <Daemon404> etc
[16:41:47 CET] <Daemon404> im dont know what to do here
[16:42:50 CET] <Daemon404> wm4, you may have an opinion?
[16:42:56 CET] <durandal1707> ubitux: aarch64 is alive?
[16:43:31 CET] <durandal1707> ubitux: stop working on obsolete stuf, do nlmeans ;)
[16:43:32 CET] <ubitux> awakening
[16:43:40 CET] <ubitux> it's not obsolete
[16:43:45 CET] <ubitux> it's the name for arm64
[16:43:46 CET] <rcombs> aarch64 is the hot new thing
[16:43:46 CET] <wm4> Daemon404: let me see
[16:44:06 CET] <Daemon404> wm4, libav ripped out the use of ffurl_* and make it use ctx->io_open
[16:44:14 CET] <Daemon404> i.e. the new callbacks for sub-file i/o
[16:44:26 CET] <Daemon404> but we use a bunch of options in the ffurl stuff (ss\ee above)
[16:44:36 CET] <wm4> user-agent needs to be passed down, cookies need to be preserved (sub-requests can change them)
[16:44:53 CET] <Daemon404> yeah but this is all specific to ffurl
[16:44:56 CET] <Daemon404> which is my problem.
[16:45:11 CET] <wm4> which specific parts cause problems?
[16:45:27 CET] <Daemon404> because where the hell do i set the options then
[16:45:31 CET] <Daemon404> ffurl use is *gone*
[16:45:32 CET] <wm4> it seems hls.c mainly uses avoption to communicate this stuff
[16:46:23 CET] <Daemon404> e.g. see hls_read_header
[16:46:26 CET] <Daemon404> i dont know wtf to do with this
[16:47:47 CET] <wm4> man...
[16:48:00 CET] <durandal1707> relax
[16:48:27 CET] <wm4> accessing another URLContext->priv_data_class and then using avoptions on it
[16:49:08 CET] <wm4> Daemon404: replace URLContext->priv_data_class with AVIOContext->opque, maybe
[16:49:09 CET] <Daemon404> i cleaned up the merge itself, but this bit is left, and it's over my head atm
[16:49:23 CET] <Daemon404> wm4, i though about that but i was not sure.
[16:49:33 CET] <Daemon404> technically that is wrong
[16:49:38 CET] <Daemon404> especially for custom i/o
[16:49:44 CET] <wm4> it was wrong before
[16:49:53 CET] <Daemon404> lol
[16:50:17 CET] <Daemon404> i guess ill add a similar check to the custom i/o check
[16:50:23 CET] <Daemon404> itll just mean custom i/o = no cookeis n shit
[16:50:42 CET] <wm4> I wonder if you want just call av_opt_get on AVIOContext directly
[16:50:50 CET] <nevcairiel> custom io for hls sounds like a dangerous path anyway
[16:50:59 CET] <nevcairiel> so much shit you can screw up =p
[16:51:08 CET] <Daemon404> nevcairiel, i used it once :P
[16:51:09 CET] <Daemon404> for fun
[16:51:09 CET] <wm4> with search flags = AV_OPT_SEARCH_CHILDREN
[16:51:19 CET] <wm4> strange definition of fun
[16:51:21 CET] <Daemon404> libcurl-implemented avio callbacks
[16:51:28 CET] <Daemon404> i did not use this in a rwal scenario though
[16:51:31 CET] <Daemon404> real*
[16:52:28 CET] <Daemon404> wm4, i notice our hls.c is orders of magnitude more complex ;p
[16:52:35 CET] <Daemon404> (and cookies with hls... wtf why?)
[16:52:57 CET] <wm4> some servees require it
[16:52:59 CET] <wm4> *servers
[16:53:08 CET] <Daemon404> but why
[16:53:14 CET] <Daemon404> cant you use params or a rest-like api
[16:53:19 CET] <Daemon404> params as in GET
[16:53:26 CET] <wm4> because mixing of multimedia and web devs
[16:53:32 CET] <Daemon404> ;-;
[16:54:02 CET] <Daemon404> the hls segmenter i wrote uses a rest-liek api with signing
[16:54:12 CET] <Daemon404> i cant fathom why cookies would be needed
[16:54:41 CET] <rcombs> idiocy
[16:56:52 CET] <ubitux> anyone friendly with as ?
[16:57:02 CET] <ubitux> i'd like to do additions in preproc
[16:57:27 CET] <ubitux> but for identifying a register typically
[16:57:55 CET] <Daemon404> rcombs, that makes me really sad
[16:59:08 CET] <Daemon404> wm4, seems to work
[16:59:18 CET] <wm4> good enough
[16:59:18 CET] <Daemon404> but i dont have any cookie-needing hls urls to test
[16:59:25 CET] <Daemon404> so uh... :|
[16:59:28 CET] <wm4> neither have I
[16:59:36 CET] <Daemon404> but it doesnt segfault, and it plays vimeo's hls streams from ym segmenter
[16:59:39 CET] <wm4> though it was added recently
[16:59:39 CET] <Daemon404> ... lol
[17:00:02 CET] <Daemon404> wm4, feel liek doign a quick once-over on teh diff?
[17:00:06 CET] <Daemon404> just on irc
[17:00:19 CET] <wm4> sure
[17:01:42 CET] <Daemon404> wm4, http://chromashift.org/diff.txt
[17:03:08 CET] <nevcairiel> i assume avio handles the whitelist which was previously handled manually?
[17:03:30 CET] <Daemon404> nevcairiel, only with non-custom i/o
[17:03:36 CET] <nevcairiel> of course
[17:03:46 CET] <Daemon404> when i merged io_open i made sure to keep whitelisting
[17:03:49 CET] <Daemon404> in teh default handler
[17:05:01 CET] <wm4> I like how this whitelist shit goes out of the window
[17:05:17 CET] <Daemon404> it does; it's still there
[17:05:24 CET] <Daemon404> just in a different layer
[17:05:31 CET] <wm4> -/* Intercept and handle ID3 tags between URLContext and AVIOContext */
[17:05:33 CET] <wm4> stray change?
[17:05:55 CET] <Daemon404> well it doesnt intercept considering there's no URLContext
[17:06:00 CET] <Daemon404> i wasnt sure what to change it to though
[17:08:07 CET] <ubitux> we need to decide something for the precision in sws convert :(
[17:08:21 CET] <ubitux> i'm porting the 32-bit code but since it's unused...
[17:08:45 CET] <wm4> Daemon404: I can make a short test, does the patch apply on git master? or alternatively, hand me a git url
[17:09:10 CET] <Daemon404> git master yes
[17:09:17 CET] <Daemon404> git apply or patch -p1
[17:09:48 CET] <Daemon404> it worked on a playlist with subplaylists over https for me
[17:10:00 CET] <Daemon404> need someone else to test
[17:10:34 CET] <wm4> not sure if I can contribute to this, but I'll test anyway
[17:10:48 CET] Action: Daemon404 could always push and wait for people to send him death threats
[17:24:39 CET] <wm4> Daemon404: I don't know, seems to work for me
[17:25:01 CET] <Daemon404> ok
[17:27:36 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:81306fd4bdeb: hls: eliminate ffurl_* usage
[17:27:37 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:d0fc5de3a643: Merge commit '81306fd4bdeb5c17d4db771e4fec684773b5790f'
[17:33:05 CET] <Timothy_Gu> ubitux: thanks for the info
[17:36:02 CET] <Daemon404> do we have a policy on how to merge avplay stuff into ffplay?
[17:36:05 CET] <Daemon404> do it? dont do it?
[17:36:09 CET] <wm4> don't
[17:36:15 CET] <wm4> they're probably far too different
[17:36:17 CET] <wm4> same for avconv
[17:36:43 CET] <Daemon404> i see
[17:36:44 CET] <Timothy_Gu> michaelni: loads fine now
[17:36:45 CET] <nevcairiel> i usually just looked at the affected areas
[17:36:53 CET] <nevcairiel> and if its similar and easily merged, i did it
[17:36:55 CET] <nevcairiel> if not, then not
[17:37:07 CET] <Daemon404> nevcairiel, ok, i wasnt sure how martin balint felt.
[17:37:17 CET] <Daemon404> it's a shame git is too dumb to understand renames during merges
[17:37:22 CET] <nevcairiel> since w hen do merges care about the individual maintainers =p
[17:37:38 CET] <Daemon404> lo,.
[17:37:39 CET] <Daemon404> lol*
[17:50:08 CET] <cone-348> ffmpeg 03Luca Barbato 07master:f22f90059432: avplay: Move the stream setup in the main thread
[17:50:09 CET] <cone-348> ffmpeg 03Luca Barbato 07master:fdd464cb7045: avplay: Allocate the refresh thread next to the decode thread
[17:50:10 CET] <cone-348> ffmpeg 03Luca Barbato 07master:21bbc345ccb6: avplay: Rename VideoState to PlayerState
[17:50:11 CET] <cone-348> ffmpeg 03Luca Barbato 07master:611ba89b896a: avplay: Rename cur_stream to player
[17:50:12 CET] <cone-348> ffmpeg 03Luca Barbato 07master:6fa464f8d29b: avplay: Statically allocate the player state
[17:50:13 CET] <cone-348> ffmpeg 03Luca Barbato 07master:eef9f0650835: avplay: Allow to override the codec
[17:50:14 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:32766877b4e1: Merge commit 'eef9f06508354d1c7d5624c1c18997e7974288f1'
[17:52:24 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:9cac1b4b4f15: qsvenc: Add private option to replace coder_type
[17:52:25 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:c63da6e91630: Merge commit '9cac1b4b4f1532fb2aeef54799285360656be5eb'
[17:53:51 CET] <ubitux> nothing to take from the avplay patches?
[17:54:25 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:1546a41adae8: pixdesc: Drop unneeded deprecation warning guards
[17:54:26 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:3f462fcf76bb: Merge commit '1546a41adae818b340acdd9b5dacd6d0a92b6507'
[17:54:47 CET] <Daemon404> ubitux, out stuff seems to be vastly different / incompatible
[17:55:00 CET] <ubitux> ok
[17:55:02 CET] <Daemon404> and has some of it already
[17:56:04 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:6695f178a592: pixdesc: Use AV_CEIL_RSHIFT in documentation
[17:56:05 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:73bd20c4d238: Merge commit '6695f178a5929eab91d3da7e9023999f1774bd0e'
[17:57:51 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:e80307140f73: yuv4mpegenc: Use AV_CEIL_RSHIFT where needed
[17:57:52 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:56475e885ba7: Merge commit 'e80307140f736f593ee643affa015333d7c5e27f'
[18:01:03 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:4709f72115e4: lavfi: Use AV_CEIL_RSHIFT where needed
[18:01:04 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:4401f07f4daa: Merge commit '4709f72115e4028a1cb43e916925678bfceef870'
[18:03:08 CET] <cone-348> ffmpeg 03Luca Barbato 07master:eafb05fcf37c: v210: x86: Add the correct guards around the asm code
[18:03:09 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:8f8381bf0364: Merge commit 'eafb05fcf37cd19a910ca3b17824384f9006bc0a'
[18:04:08 CET] <cone-348> ffmpeg 03James Almer 07master:b624f0660b66: x86: Add ymm_reg struct
[18:04:09 CET] <cone-348> ffmpeg 03James Almer 07master:77a44f577b64: configure: add missing avx2 support check
[18:04:10 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:2f78be00194b: Merge commit '77a44f577b644a328dcf90cde11d2ecae69eda05'
[18:07:09 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:60f0fde3092d: libx264: Make sure to preserve default option values
[18:07:10 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:113c25653320: Merge commit '60f0fde3092d18d4d36555962c192af8691a099c'
[18:12:32 CET] <ubitux> yay, vulkan out
[18:12:41 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:1ba1fede9dfe: flacenc: Restore defaults and range for {min, max}_prediction_order
[18:12:42 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:dc22269b2325: Merge commit '1ba1fede9dfe03dc48862e5e0530cca7192f5038'
[18:15:55 CET] <durandal2707> ubitux: what is vulkan?
[18:16:26 CET] <ubitux> http://www.phoronix.com/scan.php?page=article&item=vulkan-10&num=1
[18:16:54 CET] <ubitux> "successor" / alt opengl
[18:17:11 CET] <nevcairiel> its extremely low level, so its not going to replace anything
[18:17:17 CET] <jamrial> both amd and nvidia released drivers with support, at least on windows
[18:17:24 CET] <Daemon404> J_Darnley, ping
[18:17:32 CET] <J_Darnley> pong
[18:18:52 CET] <Daemon404> J_Darnley, can i skip these two from Libav: v210: Add avx2 version of the 8-bit line encoder, v210: Add avx2 version of the 10-bit line encoder
[18:19:01 CET] <Daemon404> they seem to be weirdly different from ours
[18:19:03 CET] <Daemon404> and im not sure why
[18:19:13 CET] <J_Darnley> ...
[18:19:17 CET] <J_Darnley> Let me look
[18:19:39 CET] <J_Darnley> I did send the patches there at kierank's request and got infrequent replies from them.
[18:19:50 CET] <J_Darnley> They seem to hate keeping me in Cc
[18:19:52 CET] <Daemon404> i guess they fiddled with them
[18:20:05 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=d29237e5578a187c5a8d91338cd70ce0fd6f6003
[18:20:08 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=15ec7aa4170ed05ad1b17000ef1e3940d0a0c5e7
[18:23:04 CET] <wm4> so how long is this fork bullshit supposed to carry on
[18:23:20 CET] <J_Darnley> Hm, no cextern from them
[18:26:03 CET] <J_Darnley> Okay, the 8 bit has a few changes in asm constants and AVX2 guards.  Otherwise I think its the same from a cursory glance.
[18:26:25 CET] <durandal2707> wm4: until you stop talking with evil nicks
[18:26:53 CET] <Daemon404> J_Darnley, should i skip then, or are those constraints important
[18:26:57 CET] <mateo`> wm4: news from android bs land, i got the hack using the c++ private api to retreive the vm, no need to have av_jni_set_java_vm anymore (in theory)
[18:27:14 CET] <J_Darnley> I thought someone had already merged in the AVX2 guards
[18:27:19 CET] <wm4> mateo`: sounds good
[18:27:36 CET] <J_Darnley> I'm still looking at thw 10 bit
[18:27:39 CET] <Daemon404> ok
[18:27:49 CET] <Daemon404> J_Darnley, also see: https://git.libav.org/?p=libav.git;a=commitdiff;h=15ec7aa4170ed05ad1b17000ef1e3940d0a0c5e7;hp=d29237e5578a187c5a8d91338cd70ce0fd6f6003
[18:27:54 CET] <Daemon404> it comes directly after your commit
[18:28:00 CET] <Daemon404> just wanna make sure it wont make anything explode
[18:28:52 CET] <J_Darnley> Similar differences for the 10 bit
[18:29:20 CET] <J_Darnley> I think you gave me a wrong link just now
[18:29:29 CET] <J_Darnley> that's the 10bit patch
[18:29:34 CET] <Daemon404> uh.. yeah
[18:29:43 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commitdiff;h=e280fe13291e9c712a5f4aa13b5263f3e8afed45
[18:29:55 CET] <Daemon404> im not sure how the asm consumes that struct member
[18:29:59 CET] <Daemon404> so i thought i'd aks.
[18:30:01 CET] <Daemon404> ask even
[18:30:44 CET] <J_Darnley> The asm doesn't use it. The C does when deciding how many samples the DSP functions processes
[18:30:57 CET] <Daemon404> ok
[18:31:19 CET] <cone-348> ffmpeg 03James Darnley 07master:d29237e5578a: v210: Add avx2 version of the 8-bit line encoder
[18:31:20 CET] <J_Darnley> It is a better solution than 1 value controlling 2 separate code paths
[18:31:20 CET] <cone-348> ffmpeg 03James Darnley 07master:15ec7aa4170e: v210: Add avx2 version of the 10-bit line encoder
[18:31:21 CET] <cone-348> ffmpeg 03Luca Barbato 07master:e280fe13291e: v210: Use separate sample_factors
[18:31:22 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:6bff2b5f6a3d: Merge commit '15ec7aa4170ed05ad1b17000ef1e3940d0a0c5e7'
[18:31:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:04e4166536d3: Merge commit 'e280fe13291e9c712a5f4aa13b5263f3e8afed45'
[18:32:52 CET] <J_Darnley> P.S.  How can I make git show what gets changed in a merge commit?
[18:33:24 CET] <durandal2707> no that's secret, it hides backdoors
[18:33:49 CET] <jamrial> J_Darnley: click "diff1" on each listed file
[18:34:08 CET] <durandal2707> that's why i hate merges
[18:34:11 CET] <J_Darnley> Click?  My terminal has nothing to click on
[18:34:22 CET] <durandal2707> buy windows
[18:34:31 CET] <jamrial> then use the web interface
[18:34:59 CET] <cone-348> ffmpeg 03Luca Barbato 07master:a38a4f44b5c7: configure: Support MSYS2 mingw-w64 64bit
[18:35:00 CET] <cone-348> ffmpeg 03Vicente Jimenez Aguilar 07master:f428893c1725: doc: Improve the channelsplit example
[18:35:01 CET] <J_Darnley> I will not buy Windows when I can pirate. :)
[18:35:01 CET] <cone-348> ffmpeg 03Henrik Gramner 07master:389b79842c67: msvc: Fix libx264 linking
[18:35:02 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:e7b8ec8b6fd8: Merge commit '389b79842c67b1f5730215a752a5f89cb1b8d9a3'
[18:35:20 CET] <durandal2707> J_Darnley: this channel is public
[18:35:26 CET] <Daemon404> J_Darnley, git diff <mergehash>^..<mergehash>
[18:35:29 CET] <Daemon404> is how i check
[18:35:35 CET] <J_Darnley> I know.
[18:35:51 CET] <J_Darnley> Daemon404: thanks
[18:35:52 CET] <Daemon404> i dont think cgit has a real way to look on the webui
[18:35:54 CET] <Daemon404> it's pretty bad.
[18:36:28 CET] <J_Darnley> durandal_1707: I know.  What is MS going to do?  Sue me for my life savings of ~¬200
[18:38:07 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:a32dbf2aed3b: asfdec: break if EOF is reached after asf_read_packet_header
[18:38:08 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:e4d1621c6e51: asfdec: check avio_skip in asf_read_simple_index
[18:38:09 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:bf50607ab761: asfdec: check for too small size in asf_read_unknown
[18:38:10 CET] <cone-348> ffmpeg 03Andreas Cadhalpun 07master:2e6ba1993ef4: asfdec: make sure packet_size is non-zero before seeking
[18:38:11 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:5781bfae0cf4: flacenc: Load default prediction_order parameters if none is selected
[18:38:12 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:8bbca8de3944: Merge commit '5781bfae0cf4271278a8bea176d615cb5c222335'
[18:40:13 CET] <wm4> did you know that configure checks for certain shell bugs, and tries other shells if they are detected?
[18:40:35 CET] <durandal2707> omg, that is insane
[18:40:43 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:dd53af4b37c7: avplay: drop support for building without lavfi
[18:40:44 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:a236e4e8b840: Merge commit 'dd53af4b37c7790ce26065b36d5655c1af38b295'
[18:40:52 CET] <wm4> it tries bash, ksh, and /usr/xpg4/bin/sh 
[18:40:57 CET] <ubitux> yep
[18:41:26 CET] <durandal2707> from who originated such an idea?
[18:41:44 CET] Action: J_Darnley suggests it was autotools
[18:42:12 CET] <wm4> mans, 2006
[18:42:24 CET] <ubitux> it actually predates this commit
[18:42:26 CET] <wm4> for Solaris
[18:42:50 CET] <J_Darnley> Daemon404: your merge looks good to me, sorry for the trouble.
[18:43:04 CET] <ubitux> ah still mans in 2006 actually 
[18:46:00 CET] <cone-348> ffmpeg 03Diego Biurrun 07master:34c9eba982c7: configure: Refactor toolchain flag setting
[18:46:01 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:1c417bad613d: Merge commit '34c9eba982c75196392a3b0b245dd34297c4511d'
[18:46:10 CET] <Daemon404> J_Darnley, not your doing, dont worry
[18:46:18 CET] <Compn> its not insane
[18:46:25 CET] <Compn> its insane that there are so many shell bugs to work around
[18:46:29 CET] <Compn> at least 10 years ago :P
[18:46:31 CET] Action: Compn runs
[18:48:58 CET] <cone-348> ffmpeg 03Luca Barbato 07master:99214d42a902: dnxhd: Make the encoder message friendlier
[18:48:59 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:55cada301049: Merge commit '99214d42a902c8392d7887c08fdc5dc1fc2475ae'
[18:50:13 CET] <durandal2707> there is no filter that insert silence/black inside vfr gaps?
[18:51:09 CET] <Daemon404> .. gaps?
[18:51:13 CET] <Daemon404> there are no gaps to fill
[18:51:32 CET] <Daemon404> vfr has no gaps. the two are urnelated
[18:52:07 CET] <durandal2707> say last frame you get at 6 hours and next frame you get at 7th hour..
[18:52:45 CET] <Daemon404> yes>
[18:52:51 CET] <Daemon404> that frame is static for that full hour then
[18:52:54 CET] <Daemon404> there is no gap.
[18:53:22 CET] <durandal2707> what if there is gap, and last frame have duration
[18:53:37 CET] <Daemon404> how can there be a gap?
[18:53:51 CET] <Daemon404> with lavf/lavc there cant be
[18:54:03 CET] <Daemon404> the only possible way there could be a gap is mismatched frame durations and timestamps
[18:54:11 CET] <Daemon404> in which case it's not a vfr problem at all
[19:03:28 CET] <durandal2707> Daemon404: there is possible to have non-monotonic pts
[19:04:30 CET] <cone-348> ffmpeg 03Lou Logan 07master:ddc9a587f929: doc/filters: remove redundant example
[19:08:39 CET] <omerjerk> can someone explain this .comp field ? - https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L481
[19:09:06 CET] <wm4> omerjerk: see pixdesc.h
[19:09:27 CET] <omerjerk> okay, Thanks. 
[19:09:31 CET] <wm4> it's not easy to figure out (because these descriptors are complex), but all information is there
[19:10:54 CET] <omerjerk> okay.
[19:11:22 CET] <cone-348> ffmpeg 03Thomas Lee 07master:7a00653be6b1: tiny_psnr: Support large files
[19:11:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:ea1f47757b2d: Merge commit '7a00653be6b13131ce1b2cdeca696429f57caaf8'
[19:17:31 CET] <durandal2707> llogan: there was no need to remove example
[19:19:29 CET] <cone-348> ffmpeg 03Paul B Mahol 07master:c4ed21367559: avfilter/f_streamselect: check if map is available
[19:35:17 CET] <llogan> durandal2707: it wasn't good
[19:47:51 CET] <tmm1> ubitux: any other comments on the ccaption encoding patch?
[19:59:07 CET] <ubitux> tmm1: i will test and apply soon
[20:02:13 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:cdbaa436042b: mpeg12dec: Always close reader on error
[20:02:14 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:2ec66ff83d00: Merge commit 'cdbaa436042ba59c3b2bd7e9652e9a14136fd604'
[20:03:21 CET] <JEEB> -win21
[20:06:28 CET] <cone-348> ffmpeg 03Diego Biurrun 07master:249827f736db: mpeg12dec: Refactor mpeg1_decode_block_intra()
[20:06:29 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:8e2105297dae: Merge commit '249827f736db4c94dfcb24a3883aa4c04f9b119b'
[20:33:02 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:7c25ffe070c2: mpeg1: Make intra-block decoding independent of MpegEncContext
[20:33:03 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:58dd885f9ae7: Merge commit '7c25ffe070c286874a8c3513f7504b90e1626b0c'
[20:46:45 CET] <cone-348> ffmpeg 03Vittorio Giovara 07master:f7d77b9a5dd4: eatqi: Remove MpegEncContext dependency
[20:46:46 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:c82d31808bdc: Merge commit 'f7d77b9a5dd42bf0f5dffecf590466b4c4239437'
[20:49:01 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:fb25d99b0a5e: buffersrc: do not discard the error from ff_filter_frame()
[20:49:02 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:9a9f3f151fa2: Merge commit 'fb25d99b0a5e21fb8cc184c7a9d3736387778266'
[20:50:20 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:28259c13db78: nvenc: factor out the pixel format list
[20:50:21 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:118beda35507: nvenc: merge input and output surface structs
[20:50:22 CET] <cone-348> ffmpeg 03Anton Khirnov 07master:d005ccc630e4: nvenc: rename a misnamed function
[20:50:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:fab8d9717c9c: Merge commit 'd005ccc630e42daab8ec2afecf972d1551a9401a'
[20:52:00 CET] <cone-348> ffmpeg 03Luca Barbato 07master:e579d8b29cdb: lavf: Dump the cpb side data information
[20:52:01 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:0479cf8530d0: Merge commit 'e579d8b29cdb9b42c50a0fde277dfb047c1466ad'
[20:52:43 CET] <cone-348> ffmpeg 03Hendrik Leppkes 07master:8c399bd5cefd: dxva2_hevc: properly signal the num_delta_pocs from the SPS RPS
[20:52:44 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:df61e4c24150: Merge commit '8c399bd5cefd572eceb448981fcb6d4dbca35d27'
[20:54:04 CET] <cone-348> ffmpeg 03Philip Langdale 07master:8958c5c64d05: hevc: Track long and short term RPS size for VDPAU
[20:54:05 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:146637905920: Merge commit '8958c5c64d05453204642b55a7b8b44c93023b17'
[21:06:00 CET] <cone-348> ffmpeg 03Philip Langdale 07master:8d34a2f803c9: vdpau: Support for VDPAU accelerated HEVC decoding
[21:06:01 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:cbe3f28d0ac7: Merge commit '8d34a2f803c9ca9433b5a51bacbbe352e8d327e2'
[21:07:22 CET] <cone-348> ffmpeg 03Luca Barbato 07master:5eb562831b3a: mov: Use the correct type for size
[21:07:23 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:4e3185d20866: Merge commit '5eb562831b3a9bea8026c413ef1338e06450d005'
[21:07:30 CET] <Daemon404> oh FUCK
[21:08:10 CET] <Daemon404> fixing
[21:10:18 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:00bd23749988: mov: Fix leftover merge conflict cruft
[21:10:27 CET] <Daemon404> maybe thats enough for today.
[21:12:34 CET] <Daemon404> nevcairiel / wm4 - whats up with the hwaccel/cuda stuff anton pushed recently
[21:12:38 CET] <Daemon404> re: merge
[21:15:45 CET] <wm4> git.libav.org (web) is timing out
[21:15:48 CET] <wm4> so, no idea
[21:15:54 CET] <wm4> did he push the hwcontext stuff?
[21:16:10 CET] <jkqxz> Yes.
[21:16:15 CET] <nevcairiel> yes yesterday already
[21:16:57 CET] <Daemon404> janne is updating libav.org services
[21:17:00 CET] <Daemon404> its a planned downtime
[21:17:04 CET] <Daemon404> itll be back
[21:17:11 CET] <Daemon404> get the github mirror 
[21:17:14 CET] <Daemon404> check*
[21:17:55 CET] <durandal_1707> its finnally down!
[21:20:32 CET] <wm4> github, I'd rather use the terminal
[21:21:20 CET] <Daemon404> looks like its back up anywya
[21:21:37 CET] <wm4> ok the hwcontext stuff was merged
[21:21:46 CET] <wm4> what about it? we kind of want it
[21:21:52 CET] <wm4> (I think...)
[21:22:03 CET] <Daemon404> i dunno, i dont live in hardware land
[21:22:22 CET] Action: Daemon404 is no player person
[21:23:20 CET] <jkqxz> Yes.  It's not clear that it's actually in final form yet.  I don't know how your merging works, though.
[21:24:42 CET] <Daemon404> i type /<<< in vim and then hit dd a lot
[21:24:46 CET] <Daemon404> and then cy
[21:25:57 CET] <durandal_1707> learn regexp
[21:26:21 CET] <Daemon404> / in vim is a regexp
[21:27:01 CET] <durandal_1707> advanced stuff
[21:27:27 CET] <Daemon404> i dont think there is a regexp advanced enough to gain sentient intelligence and handle merge conflicts
[21:27:35 CET] <xyz> mateo`: hey, are the newest mediacodec changes not on your github yet? here https://github.com/mbouron/FFmpeg/commits/stupeflix-devel it still uses av_jni_register_java_vm
[21:28:00 CET] <J_Darnley> Daemon404: at that point you might as well let it write the program for you.
[21:28:08 CET] <Daemon404> indeed
[21:36:05 CET] <durandal_1707> michaelni: are you back?
[21:38:36 CET] <michaelni> durandal_1707, iam here, yes
[21:40:12 CET] <durandal_1707> michaelni: know why pad crashes only with asm and only with x bigger than 0
[21:40:40 CET] <durandal_1707> with my drawutils patch
[21:40:54 CET] <michaelni> didnt look yet, but is it SSE asm and misaligned access maybe ?
[21:46:52 CET] <durandal_1707> it uses mov instruction
[21:47:33 CET] <durandal_1707> for reading, for writing I can't remember
[21:48:45 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:58f21b6c9354: avformat/hls: fix potential integer overflow
[21:48:46 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:5c02c95f2c2a: avcodec/mpeg12: Fix error return
[21:48:47 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:2e8ad2d65af5: avcodec/mpeg12: Remove duplicate block_last_index setting code
[22:18:16 CET] <durandal_1707> michaelni: it seems to crash when x is not multiple of 8
[22:18:25 CET] <michaelni> durandal_1707,  crash is due to misalgned access
[22:24:36 CET] <durandal_1707> michaelni: so what should get fixed ? pad?
[22:30:52 CET] <michaelni> if pad could produce aligned data that would be better/faster. Either way the code shouldnt crash 
[22:31:11 CET] <durandal2707> michaelni: shouldnt same happen with crop filter?
[22:31:29 CET] <michaelni> yes, quite possible
[22:32:17 CET] <durandal2707> but it doesnt
[22:32:34 CET] <durandal2707> and why 8bit path is not affected?
[22:36:36 CET] <wm4> so why can't we have a crop rectangle in AVFrame, instead of intentionally misnaligning image data
[22:37:07 CET] <nevcairiel> why do you keep caring about top/left cropping, i have never even seen a sample that used it outside of fate =p
[22:37:18 CET] <durandal2707> its planned to do in evil(tm) plan
[22:39:01 CET] <wm4> nevcairiel: it does become a minor issue surprisingly often (not necessarily left/right, but width/height too... like non-mod-2 4:2:0)
[22:40:49 CET] <nevcairiel> my stuff can deal with such conditions
[22:41:50 CET] <wm4> mine too, by rounding up in all situations
[22:46:54 CET] <ubitux> durandal2707: sometimes a new buffer is allocated
[22:47:01 CET] <ubitux> durandal2707: that's what happens with w3dif 
[22:47:09 CET] <ubitux> iirc
[22:48:35 CET] <durandal2707> w3fdif uses movu instructions
[22:49:00 CET] <nevcairiel> it also reads half-vector sized data, so it needs to
[22:50:00 CET] <durandal2707> actually w3fdif doesnt access buffers directly
[22:52:42 CET] <d-fens_> hi, i couldn't find it in docs anywhere: is it possible to a time-based expression to any filter or does each filter have to support expressions  individually? like using unsharp=luma_amount=sin(%t) for example? 
[22:52:50 CET] <d-fens_> *use
[22:54:16 CET] <durandal2707> d-fens_: individually, if its mentioned in filter docs
[22:54:51 CET] <d-fens_> durandal2707: thanks, thats a pity though
[22:55:52 CET] <durandal2707> d-fens_: there is luascript filter in works
[22:56:29 CET] <d-fens_> durandal2707: ok i gotta read up on this
[22:58:05 CET] <d-fens_> durandal2707: what will thes filter allow me to do?
[22:58:34 CET] <durandal2707> to change filter options each frame
[22:58:54 CET] <durandal2707> for filters that do 1 in 1 out frame
[22:59:33 CET] <ubitux> durandal2707: there are many mova in w3fdif
[22:59:45 CET] <d-fens_> ah i see
[23:00:15 CET] <d-fens_> durandal2707: anything to try out yet?
[23:00:32 CET] <ubitux> durandal2707: and the reason it works is only because of av_frame_clone() afaict
[23:00:47 CET] <ubitux> so something similar might happen in vfscale/pad
[23:01:15 CET] <ubitux> BBB: find has a -delete option :p
[23:01:23 CET] <BBB> on mac?
[23:01:34 CET] <ubitux> good question
[23:01:35 CET] <BBB> oh it does!
[23:01:39 CET] <BBB> ++
[23:01:45 CET] <BBB> you awesome
[23:02:05 CET] <durandal2707> ubitux: wtf you are talking about?
[23:02:08 CET] <ubitux> on mac it has the annoying limitation of requiring the current dir
[23:02:16 CET] <ubitux> (so you have to explicit the .)
[23:02:24 CET] <ubitux> that's the only difference i know
[23:02:46 CET] <ubitux> durandal2707: w3fdif clones the frame, so it gets a new aligned buffer, so the x86 asm using mova can work
[23:03:04 CET] <ubitux> if it wasn't doing so, sth like crop=x=1,w3fdif would crash
[23:03:08 CET] <durandal2707> ubitux: w3fdif doesnt use frame directly
[23:03:17 CET] <durandal2707> and when it does it uses movh
[23:03:43 CET] <ubitux> ok
[23:04:28 CET] <durandal2707> not ok, you are repeating this w3fdif story over and over again
[23:04:45 CET] <ubitux> because i probably didn't understand the first time
[23:04:53 CET] <ubitux> so this is the 2nd time and now i get it :)
[23:14:50 CET] <durandal2707> d-fens_: not yet
[23:23:57 CET] <michaelni> Daemon404, are you available as GSoC mentor ? (we need to know approximately for "How many potential mentors have agreed to mentor this year?"), same question for others
[23:25:08 CET] <michaelni> atomnuker,nevcairiel, durandal2707 , are you potentially available as mentor for GSoC ?
[23:28:17 CET] <durandal2707> mentor for what?
[23:29:18 CET] <michaelni> whatever you like
[23:29:40 CET] <nevcairiel> I'll happily answer questions on IRC and assist in any way I can, but I'm not really guaranteed to be available, so i'm not available for any official roles
[23:30:46 CET] <michaelni> iam asking because we need to give google some number of "potential mentors" and that likely will affect how many slots we get. would be crazy for google to give us more slots than we have mentors
[23:31:38 CET] <michaelni> so if few people say "yes" now and later many have a great idea and student then we will be short on slots likely
[23:38:04 CET] <durandal2707> what about motion interpolation for lavfi?
[23:38:26 CET] <michaelni> durandal2707, yes perfect idea
[23:39:09 CET] <michaelni> also please add it to the ideas page (https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016)
[23:40:59 CET] <michaelni> also i would interpret "potential mentor" as "assuming theres a student who is well qualified for the project you wish to mentor, would you mentor him"
[00:00:00 CET] --- Wed Feb 17 2016