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

[burek]

[01:03:16 CET] <michaelni> jamrial, the only way i can check it is to push it to master and rerun coverity
[01:03:42 CET] <michaelni> well i could run coverity on my private tree but it would confuse everyone i think
[01:04:22 CET] <michaelni> as it would look like ffmpeg master ...
[01:05:02 CET] <jamrial> ah ok
[01:05:13 CET] <jamrial> guess the only way would be to ask him then
[01:05:57 CET] <michaelni> jamrial, actually i have a mail from today from foo86 in my inbox
[01:06:00 CET] <nevcairiel> i had a brief look at the dca things, and they did look mostly like false positives, ie. coverity not recognizing the limitations
[01:06:12 CET] <nevcairiel> .. of variable ranges
[01:06:16 CET] <michaelni> "I took a look at those issues and they seem to be false positives."
[01:06:52 CET] <nevcairiel> i think in particular coverity gets confused when you use get_bits etc, it cant figure out that it can only return a very limited value
[01:07:25 CET] <michaelni> indeed i remember seeing that elsewhere as well
[01:07:28 CET] <nevcairiel> ie. i dont need to check if get_bits(2) is below 3
[01:07:36 CET] <nevcairiel> it never can exceed 3
[01:07:37 CET] <nevcairiel> :d
[01:11:28 CET] <wm4> but what if a bit gets flipped!
[01:19:19 CET] <kierank> durandal_170: ?
[01:27:02 CET] <Timothy_Gu> michaelni: do you have a script for uploading to coverity?
[01:27:22 CET] <Timothy_Gu> also are you the only one doing the upload right now
[01:33:07 CET] <michaelni> Timothy_Gu, if you call a configure line, one line to build it and one to make a tarball .... a script then yes
[01:33:33 CET] <michaelni> AFAIK iam the only one doing the uploading
[01:34:47 CET] <michaelni> but the uploading of the tarball i do by hand 
[01:39:31 CET] <michaelni> if someone wants to help with the upload, first that volunteer has to install as many external libs supported by ffmpeg as possible as coverity only tests whats enabled
[01:39:49 CET] <michaelni> s/upload/build and upload/
[01:41:04 CET] <michaelni> anyway ive started my "script", ill upload it when its done
[01:42:13 CET] <Timothy_Gu> michaelni: ok thx
[01:44:13 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/3.0:eb46065f4a08: doc/utils: fix typo for min() description
[01:44:23 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.8:f9f9f31c6c67: doc/utils: fix typo for min() description
[01:44:35 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.7:4ecb216ad447: doc/utils: fix typo for min() description
[01:44:47 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.6:53128080ebf0: doc/utils: fix typo for min() description
[01:45:10 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.5:c40ee0a107d4: doc/utils: fix typo for min() description
[01:46:03 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.3:49fb1f66f15f: doc/utils: fix typo for min() description
[01:46:50 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.2:c7fe604cf189: doc/utils: fix typo for min() description
[01:47:01 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.1:a9a5f5b388aa: doc/utils: fix typo for min() description
[01:47:13 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.0:72006016ae70: doc/utils: fix typo for min() description
[01:48:00 CET] <cone-276> ffmpeg 03Paul B Mahol 07release/2.4:fcbbe360821d: doc/utils: fix typo for min() description
[01:48:02 CET] <Shiz> ..
[01:52:38 CET] <cone-276> ffmpeg 03Marton Balint 07master:e7dd97b5d8cd: avformat/utils: add a function to standardize creation time
[01:52:39 CET] <cone-276> ffmpeg 03Marton Balint 07master:28fbdece79d2: avformat: use ff_standardize_creation_time for formats writing all format string metadata
[01:52:40 CET] <cone-276> ffmpeg 03Marton Balint 07master:0418b0253aa1: ffmpeg: remove hardcoded 'now' creation_time support
[01:54:32 CET] <michaelni> Timothy_Gu, iam uploading latest ffmpeg build to coverity, but if you want you can do it the next time: my "script"  is here: http://pastebin.com/HMhtHSki
[02:32:22 CET] <Timothy_Gu> michaelni: ok, how often do you do it?
[02:33:03 CET] <michaelni> when i remember, like once every few weeks, which isnt optimal
[02:33:25 CET] <Timothy_Gu> I guess I can set up a cron job doing it every day
[04:02:43 CET] <cone-276> ffmpeg 03Michael Niedermayer 07master:38cd60c921c2: fate: add filter-hls
[04:08:18 CET] <mark4o> hmm is anyone able to compile ffmpeg git master on OS X?
[04:08:51 CET] <mark4o> libavcodec/videotoolboxenc.c:320:23: error: expected ')'
[04:12:31 CET] <c_14> seems like they're all failing since 3af71ac (according to fate)
[04:12:59 CET] <mark4o>     void *CM_NULLABLE ctx,  <- CM_NULLABLE is not defined anywhere, and is taken as an identifier
[04:21:21 CET] <rcombs> that's defined in CMBase.h
[04:21:30 CET] <rcombs> from CoreMedia.framework
[04:22:33 CET] <rcombs> mark4o: what OS X version?
[04:22:48 CET] <mark4o> rcombs: OS X 10.10.5
[04:22:56 CET] <rcombs> maybe it was added in 10.11
[04:23:30 CET] <c_14> rcombs: all darwin fate tests are failing
[04:23:50 CET] <mark4o> maybe; my CMBase.h does not have CM_NULLABLE
[04:24:43 CET] <rcombs> c_14: are there any 10.11 fate tests?
[04:26:43 CET] <c_14> That I don't know. fate doesn't seem to mention the version
[04:26:57 CET] <rcombs> probably as simple as `#ifndef CM_NULLABLE #define CM_NULLABLE #endif`
[04:27:47 CET] <rcombs> mark4o: try sticking ^that after the `#include`s in videotoolboxenc.c and see if it fixes it for you?
[04:28:13 CET] <rcombs> if so, send the patch and I'll signoff
[04:28:35 CET] <rcombs> (I don't have a <10.11 system to test on myself)
[04:31:01 CET] <mark4o> with that it has the same issue with CV_NULLABLE on line 982
[04:33:25 CET] <rcombs> #def that too
[04:39:26 CET] <mark4o> that seems to work, I will send the patch
[04:39:55 CET] <rcombs> thanks for the report and testing :)
[04:40:01 CET] <rcombs> I'll take it there are no warnings, either?
[04:41:03 CET] <mark4o> there are lots of warnings, but not on that file :)
[04:41:41 CET] <rcombs> mark4o: actually, hold on a sec
[04:42:01 CET] <rcombs> mark4o: https://gist.github.com/baffbb647ab6c1a18ac8 this compiles without warnings here; does it do the same for you?
[04:42:26 CET] <rcombs> if the nullable annotations are optional and not particularly useful, we may as well just remove them
[04:43:48 CET] <mark4o> that compiles fine as well
[04:44:01 CET] <rcombs> OK, I'll send that then
[04:44:16 CET] <mark4o> what are CM_NULLABLE and CV_NULLABLE defined to on 10.11?
[04:44:22 CET] <rcombs> `__nullable`
[04:57:00 CET] <cone-276> ffmpeg 03Rodger Combs 07master:ecba35bbe305: lavc/videotoolboxenc: remove *_NULLABLE annotations; fixes pre-10.11 build
[04:57:03 CET] <jamrial> michaelni: posted a fix for the dependency stuff for the filter-hls* test
[04:59:27 CET] <rcombs> mark4o: thanks again
[04:59:46 CET] <mark4o> no problem
[05:00:48 CET] <Akanksha> Hello everyone, I am new here! Please tell me from where should I start knowing more about FFmpeg and setting up a local instance for coding and testing?
[05:01:04 CET] <twid> Just dumb question: what is videotoolbox is used for?
[05:01:37 CET] <twid> start from examlpes given in repo
[05:01:39 CET] <rcombs> twid: hardware video encoding on OSX
[05:01:54 CET] <twid> thx @rcombs
[05:10:51 CET] <jamrial> Akanksha: See http://ffmpeg.org/developer.html#Contributing
[05:11:54 CET] <jamrial> basically, clone the git repo, look what you'd like to work on, then submit any patches you think are worth to the ffmpeg-devel mailing list
[05:14:00 CET] <Akanksha> jamrial: Thanks a lot.  I will do that for sure. :) Thanks again
[07:44:40 CET] <md1001> What do I need to do for project DICOM support?
[08:01:42 CET] <durandal_1707> md1001: ask via email mentor?
[09:28:49 CET] <cone-676> ffmpeg 03Paul B Mahol 07master:dd2ea5cbfb30: avformat/yuv4mpegdec: fix seeking for partial files
[09:44:06 CET] <wm4> remind me, is (int)(uint64)something always ok
[10:14:41 CET] <mrec> hmm.. the deinterlacing using yadif=1 takes 33ms sometimes
[10:21:23 CET] <fritsch> do it separately from the decoding thread
[10:21:26 CET] <fritsch> and buffer some frames
[10:21:29 CET] <fritsch> if you want to do it on the fly
[10:21:39 CET] <fritsch> while watching interlaced content
[10:22:07 CET] <fritsch> that being said, kodi also uses yadif for deinterlacing and 1080i50 works fine even on a Celeron 1008U
[10:22:12 CET] <fritsch> or 1007 don't remember anymore
[10:22:52 CET] <nevcairiel> yadif with slice threading is pretty fast these days
[10:23:14 CET] <mrec> nevcairiel: hmm..
[10:23:41 CET] <mrec> I did not check which deinterlacer xine is using but the quality looks equal and the cpu is 20% lower here
[10:24:21 CET] <mrec> I think there's still some space but I'll try to decode in a separate thread not in the displaying thread
[10:25:04 CET] <durandal_1707> mrec: check xine code
[10:36:09 CET] <wm4> mrec: unless you have a very weak CPU, it should be fine
[10:37:51 CET] <mrec> I see juddering output from time to time .. sometimes it takes 35ms followed by around 8ms no wonder I see that something's not ok
[10:38:01 CET] <mrec> well the decoding/deinterlacing should go into it's own thread..
[10:38:42 CET] <mrec> watching scrolling text gives a headache if you have to focus on it being smooth..
[10:39:04 CET] <mrec> especially since 90% of the time it is smooth
[11:16:49 CET] <cone-676> ffmpeg 03Carl Eugen Hoyos 07master:8653d6e1a668: lavfi/drawutils: Add some missing GBRP pix_fmts.
[11:43:58 CET] <rcombs> on one hand, stripping closed-captions SEIs should be pretty trivial
[11:44:07 CET] <rcombs> on the other hand, I don't really care enough to do it
[11:44:15 CET] <nevcairiel> why would that even matter
[11:44:22 CET] <rcombs> ^
[11:47:49 CET] <kierank> why is that a bug
[11:48:03 CET] <kierank> you break HRD by stripping closed captions
[11:48:47 CET] <nevcairiel> its not a bug, its a feature request
[11:49:04 CET] <nevcairiel> some people dont care about compliance, they just want their things gone =p
[11:49:51 CET] <kierank> what harm is the CC doing?
[11:50:15 CET] <nevcairiel> who knows
[11:50:25 CET] <rcombs> "being a pain to decode and display"
[11:50:34 CET] <nevcairiel> ignoring it is hard?
[11:50:34 CET] <nevcairiel> :D
[11:55:24 CET] <bencoh> l/47
[12:26:54 CET] <cone-676> ffmpeg 03Paul B Mahol 07master:256fa2ab1b28: avfilter: add ciescope filter
[12:36:07 CET] <cone-676> ffmpeg 03foo86 07master:89813487491a: avcodec/dca: fix av_cold placement in declarations
[12:36:08 CET] <cone-676> ffmpeg 03foo86 07master:00e3717b4a21: avcodec/dca: simplify condition
[13:16:40 CET] <basisbit> am currently porting stuff to support ffmpeg 3. seems like the deprecated function avcodec_default_release_buffer is not there any more. any suggestion what should be used instead now? or is there some magic auto-freeing?
[13:23:13 CET] <wm4> basisbit: av_frame_unref
[13:28:33 CET] <cone-676> ffmpeg 03Paul B Mahol 07master:f5f34ee0de8c: avfilter/vf_zscale: unbreak RGB support
[13:30:03 CET] <basisbit> wm4, thx. So you finally dropped avcodec_decode_audio3 :-\ seems like I have to fix my avcodec_decode_audio4 based code XD
[13:31:20 CET] <nevcairiel> of course, its years old
[13:31:39 CET] <wm4> the new API is simpler
[13:32:50 CET] <basisbit> not in all use cases^^
[13:33:26 CET] <wm4> hm true it's not
[13:33:35 CET] <wm4> I was thinking of the encode API I guess
[13:34:06 CET] <nevcairiel> its more logical in any case, providing a pre-allocated buffer of some random size was always rather funky
[13:34:15 CET] <nevcairiel> you never know which size you really need, so you just made it big
[13:35:19 CET] <wm4> the big difference is that the new API requires the caller to deal with planar audio
[13:35:28 CET] <wm4> the old API interleaved the result for a while
[13:36:21 CET] <basisbit> this is especially difficult now when you want to play an audio and a video file and sync them perfectly while playback
[13:36:39 CET] <nevcairiel> how is that related to which API is used
[13:39:18 CET] <basisbit> with ffmpeg 2.8 I was able to get frames and other data from pointer positions which I could calculate from the expected bytes/s for coded bitrate stuff. I have no clue how to do that now with ffmpeg 3 with all these legacy API functions removed.
[13:39:39 CET] <wm4> use samples per second instead
[13:39:44 CET] <wm4> it's easier anyway
[13:41:45 CET] <basisbit> hm... will have to read about the new api functions first. but samples per second sounds promising if they are always static and if you can quickly get the total amount of samples number and samples per second at video opening
[13:46:21 CET] <JEEB_> oh well, RS only sent me my charger by not my rpi3
[13:46:35 CET] <JEEB_> and parcel 1/1
[13:46:58 CET] <wm4> lol
[13:57:16 CET] <JEEB_> e-mailed the person who locally sent me my order confirmation
[13:57:29 CET] <JEEB_> asked if I have to goto Great Britain to complain or what
[14:07:02 CET] <JEEB_> ok, seemed to go rather painlessly - they just responded without asking any further that they will create another order for me with it
[14:07:08 CET] <JEEB_> hopefully the things don't end before that
[14:51:51 CET] <wm4> mateo`: looked at my API yet? I kind of hoped it could get rid of the FIFO business in the mediacodec wrapper
[14:52:46 CET] <mateo`> wm4: no sorry I didn't get the time to look at it yet
[14:57:09 CET] <mateo`> but I will do when I finish debugging the code on a particular device.
[14:59:53 CET] <wm4> I've also thought about adding an async API, but I haven't posted a patch for it on the ML yet
[16:25:03 CET] <GigaRoc> exit
[16:32:55 CET] <cone-291> ffmpeg 03James Almer 07master:0786b28425ee: fate: fix filter-hls tests dependencies
[16:33:46 CET] <mateo`> mmm this Nvidia decoder is giving me a hard time :(
[16:41:57 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:50208a0424fa: avfilter/vf_ciescope: Fix "incompatible pointer type" warnings
[16:41:58 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:ba687ae0bdd1: ffmpeg_vdpau: Free ctx on error path
[17:01:37 CET] <Daemon404> hmmm
[17:01:40 CET] <Daemon404> 8c0ceafb0f25da077ff23e394667119f031574fd is going to suck to merge
[17:01:44 CET] Action: Daemon404 wonders how/what to do
[17:02:37 CET] <nevcairiel> we have our own whitelist, so just dont? its only internal API
[17:03:01 CET] <Daemon404> ec4c48397641dbaf4ae8df36c32aaa5a311a11bf adds a public api
[17:03:10 CET] <ubitux> what are the advantages and drawback of each solution?
[17:03:28 CET] <Daemon404> afaict there pretty much the same
[17:03:31 CET] <Daemon404> jst different
[17:03:37 CET] <nevcairiel> our whitelist has demuxer-specific defaults, which is much smarter
[17:03:59 CET] <Daemon404> theirs is a whitelist and a blacklist...
[17:04:02 CET] <Daemon404> to what end, i do not know
[17:04:14 CET] <nevcairiel> i think ours supports that too
[17:04:41 CET] <nevcairiel> i would just skip the e ntire thing, we have our own solution to that
[17:05:46 CET] <Daemon404> nevcairiel, i was thinking of skipping the internal bits
[17:05:51 CET] <Daemon404> and making the public api match
[17:05:57 CET] <Daemon404> it's the same struct name as ours
[17:06:00 CET] <Daemon404> and also a comma list
[17:06:07 CET] <Daemon404> so it should be not too bad
[17:06:29 CET] <nevcairiel> so, in fact you dont need to do anything, its already compatible?
[17:06:51 CET] <Daemon404> close
[17:06:57 CET] <Daemon404> we dont have a blacklist member of avformatcontext
[17:07:05 CET] <Daemon404> also
[17:07:08 CET] <Daemon404> ours: * - decoding: set by user through AVOptions (NO direct access)
[17:07:09 CET] <nevcairiel> if its not implemented, i would rather not include it at all
[17:07:15 CET] <Daemon404> libav;s is direct access.
[17:07:21 CET] <nevcairiel> their is also avoption
[17:07:26 CET] <Daemon404> ah ok
[17:07:28 CET] <Daemon404> it just isnt listed
[17:07:38 CET] <nevcairiel>  * This field should be set using AVOptions.
[17:07:39 CET] <nevcairiel> ?
[17:07:44 CET] <Daemon404> yeah ok
[17:07:56 CET] <Daemon404> the blacklist member should be trivial to implement
[17:08:04 CET] <Daemon404> i'd rather not break API with libav
[17:08:14 CET] <nevcairiel> its already incompatible in many places
[17:08:22 CET] <Daemon404> is it?
[17:08:28 CET] <Daemon404> where
[17:09:10 CET] <jamrial> a couple functions have same name but different signature afaik
[17:09:36 CET] <Daemon404> thats not as bad as a missing struct member
[17:09:39 CET] <Daemon404> that will just fail to build
[17:09:48 CET] <Daemon404> unless you mean differ in more than type
[17:09:58 CET] <nevcairiel> actual different signatures
[17:10:15 CET] <Daemon404> which funcs
[17:10:17 CET] <Daemon404> im curious now
[17:10:19 CET] <Daemon404> never run into it
[17:10:26 CET] <nevcairiel> should get over this illusion that its a drop-in replacement on an API level
[17:10:38 CET] <nevcairiel> the other direction doesnt work anyway, since we have a long list of extra things
[17:10:44 CET] <Daemon404> sure, but if it is minimal effort to keep it, ill do it
[17:10:48 CET] <Daemon404> i'd rather avoid a clusterfuck
[17:11:00 CET] <jamrial> Daemon404: avcodec_find_best_pix_fmt2() seems to be one
[17:11:08 CET] <nevcairiel> lavfi also has one or two somewhere
[17:11:11 CET] <jamrial> although it's deprecated, so...
[17:11:12 CET] <nevcairiel> i forgot which, since i dont care
[17:12:04 CET] <jamrial> deprecated but without any apparent replacement or FF_API guards
[17:12:52 CET] <jamrial> oh, guess that'd be avcodec_find_best_pix_fmt_of_list()
[17:13:26 CET] <nevcairiel> i think there is one in avutil 
[17:13:40 CET] <nevcairiel> that whole class of functions is rather crazy
[17:25:13 CET] <mateo`> so, the nvidia decoder from the nexus 9, on a h264 baseline 1080p sample, takes 41s to decode 305 frames with sw output and 1,7s with surface output ...
[17:25:40 CET] <mateo`> did they put some calls to sleep on purpose on the sw output path ?
[17:26:18 CET] <nevcairiel> some GPU architectures are just this slow when copying images out of GPU buffers
[17:27:04 CET] <nevcairiel> sometimes you can optimize that due to fancy copy code, no clue about ARM
[17:27:53 CET] <nevcairiel> You should see Intel GPUs on x86, they are also factor 10-20x in speed with an optimized copy vs naive memcpy
[17:28:35 CET] <mateo`> ok
[17:29:08 CET] <mateo`> at least it was not a bug on my side that makes it this slow
[17:29:26 CET] <nevcairiel> well, i would never rule that out
[17:29:36 CET] <nevcairiel> I'm just speculating from experience on x86
[17:30:31 CET] <mateo`> it makes sense and i've compared the FFmpeg code vs some java code that does the same, got the same results in sw output
[17:32:13 CET] <atomnuker> wouldn't surprise me to see nvidia make the sw output path slower
[17:32:27 CET] <atomnuker> after all they do that with cuda too
[17:32:59 CET] <nevcairiel> dunno their cuda decoder on windows is equally fast as pure hardware
[17:33:08 CET] <nevcairiel> with software output, i mean
[17:34:10 CET] <atomnuker> if (not_an_nvidia_awesome_gpu_but_a_processor) sleep();
[17:35:37 CET] <mateo`> well i guess it's time to start working on the mediacodec decoder hwaccel
[17:40:58 CET] <ubitux> http://www.quickmeme.com/img/a3/a3e74e84b75879442f73df18e67c1e0c8cb93e5919a4b3f1baba511bfa3e6cb8.jpg
[17:41:30 CET] <mateo`> :D
[17:51:20 CET] <cone-291> ffmpeg 03Anton Khirnov 07master:8c0ceafb0f25: urlprotocol: receive a list of protocols from the caller
[17:51:21 CET] <cone-291> ffmpeg 03Derek Buitenhuis 07master:510046c228cb: Merge commit '8c0ceafb0f25da077ff23e394667119f031574fd'
[17:53:26 CET] <Daemon404> i implemented blacklist
[17:53:29 CET] <Daemon404> i will send it to the ML
[18:09:56 CET] <Daemon404> weird... FATE occasionally uses a ton of disk i/o while running in parallel
[18:10:03 CET] <Daemon404> (VM disks dont like this)
[18:13:43 CET] <Daemon404> peloverde, is demuxed runnign in 2016?
[18:23:22 CET] <sej> cehoyos there?
[18:24:00 CET] <ubitux> cehoyos not here
[18:24:14 CET] <sej> ya, figured when my tab didnt auto complete :P
[18:24:29 CET] <sej> can anyone give more info on the vdpau filet project?
[18:24:40 CET] <sej> reimar also not available
[18:24:49 CET] <sej> or should i just email them?
[18:24:50 CET] <durandal_1707> ask him via email
[18:25:13 CET] <sej> okay great!
[18:25:16 CET] <durandal_1707> You need hardware with vdpau support
[18:25:24 CET] <sej> yes, i do :D
[18:25:30 CET] <sej> have*
[18:26:12 CET] <sej> have been experimenting with post processing for few weeks last year, was delighted to see it on the projects page
[18:27:46 CET] <peloverde> Daemon404: That's the plan
[18:28:28 CET] <peloverde> They are talking about launching the website for 2016 shortly
[18:29:08 CET] <Daemon404> peloverde, ok
[18:29:09 CET] <peloverde> info at demuxed.com should work now, I can also give you the main organizer's email
[18:29:16 CET] <Daemon404> if i know with enough time in advance
[18:29:21 CET] <Daemon404> i can tack it onto a NYC trip
[18:29:50 CET] <Daemon404> assuming it's late 2016, as it was last year
[18:29:50 CET] <peloverde> okay, I'll ping you when it goes up, they are still finalizing dates with teh venue right now
[18:29:54 CET] <Daemon404> cool
[18:29:58 CET] <peloverde> yeah, same time of year is the plan
[18:30:03 CET] <Daemon404> cool
[18:36:04 CET] <kierank> J_Darnley: have you tried with a 422 source encoding to yuv422p10
[18:36:08 CET] <kierank> just to avoid confusion
[18:39:30 CET] <kierank> peloverde: nab?
[18:40:15 CET] <peloverde> kierank: I'm skipping it this year
[18:40:20 CET] <kierank> :(
[18:40:59 CET] <Daemon404> other people in here might be going
[18:43:00 CET] <wm4> I still don't get why this needs a blacklist
[18:43:06 CET] <wm4> blacklists are still inherently insecure
[18:45:14 CET] <Daemon404> wm4, an option i guess
[18:45:17 CET] <Daemon404> if you want "all but X"
[18:45:22 CET] <atomnuker> J_Darnley: https://0x0.st/8lC.png https://0x0.st/8Ur.png https://0x0.st/8Us.png
[18:45:29 CET] <atomnuker> 420, 422, 444
[18:45:34 CET] <atomnuker> very weird
[18:45:48 CET] <Shiz> atomnuker: is this vapourwave
[18:47:11 CET] <sej> kierank: are you there?
[18:48:38 CET] <kierank> sej: yes
[18:49:04 CET] <atomnuker> Shiz: not vapourwave
[18:49:40 CET] <sej> kierank: i have a doubt on the "fuzzing testsuite" project
[18:49:51 CET] <kierank> Shiz: what's vapourware
[18:49:52 CET] <sej> kierank: can you elaborate on this? Build a web interface able to extract information from each commit and run against an appropriate fuzz corpus. 
[18:50:17 CET] <Shiz> kierank: i did say wave, not ware
[18:50:27 CET] <sej> haha
[18:50:31 CET] <sej> "In the computer industry, vaporware (also spelt vapourware) is a product, typically computer hardware or software, that is announced to the general public but is never actually manufactured nor officially cancelled"
[18:50:34 CET] <kierank> sej: basically the point is that a commit on jpeg shouldn't run fuzzing on h264
[18:50:34 CET] <sej> in any case :P
[18:50:42 CET] <sej> oh
[18:50:54 CET] <sej> okay
[18:51:15 CET] <sej> ya, got it (y)
[18:52:06 CET] <sej> does this higher priority or over other project? coz i'm really interested in vdapu also .... :P
[18:53:18 CET] <wm4> I'm not sure if the vdpau project actually gives much
[18:53:33 CET] <sej> to the people?
[18:53:40 CET] <wm4> it might be too short/easy
[18:53:51 CET] <wm4> no, it'd probably be somewhat useful (maybe)
[18:53:55 CET] <sej> there are 2 of them actually
[18:54:30 CET] <sej> one is harware acceleration (not limited to vdpau) other is post processing
[18:54:51 CET] <sej> which one did you mean?
[18:55:16 CET] <wm4> there is a project that wants to do postprocessing with vdpau, that one
[18:55:33 CET] <sej> ya, vdpau filter .. okay
[18:55:43 CET] <wm4> because vdpau has 1 API call to do this (plus some more to set it up)
[18:56:16 CET] <wm4> but it's there as a project, so you can take it
[18:56:16 CET] <sej> hmm
[18:56:26 CET] <kierank> wm4: if it's a crap project I'm removing it
[18:56:34 CET] <sej> :O
[18:56:37 CET] <sej> :P
[18:56:40 CET] <sej> hmm
[18:56:44 CET] <sej> "all features should be usable to allow comparing the quality and performance of different hardware and hardware vs. software. "
[18:56:56 CET] <sej> this part is also there in thta project
[18:57:17 CET] <kierank> michaelni: why are you copy and pasting projects into outreachy
[18:57:27 CET] <wm4> moreover, vdpau produces RGB output, while other filters usually remain in YUV
[18:57:31 CET] <kierank> when I am the admin
[18:57:43 CET] <sej> oh
[18:57:43 CET] <wm4> that is, the vdpau video mixer (== postprocessor) outputs RGB
[18:58:55 CET] <wm4> kierank: well I have my doubts that it's large enough, that is all
[19:01:11 CET] <kierank> while carl can run gsoc and have it as a total mess outreachy will not be like that
[19:02:13 CET] <kierank> I mean seriously, attracting people into open source by making them work on mxf
[19:02:16 CET] <kierank> or cleaning swscale
[19:03:40 CET] <Daemon404> i personally try and attract people with sweets
[19:03:45 CET] <Daemon404> for some reason that is frowned upon
[19:03:51 CET] <ubitux> how many gsoc/opw participants over the years stayed longer than 3 months in the project? 
[19:04:13 CET] <wm4> kierank: or libpostproc
[19:04:24 CET] <ubitux> i really feel like trying to attract ppl with money is not a good principle anyway
[19:04:44 CET] <ubitux> so since they probably won't stay, maybe better make them work on stuff we don't want to work on
[19:04:45 CET] <kierank> they have mentorship as well
[19:04:47 CET] <Daemon404> yes ive been saying that for years ubitux 
[19:04:48 CET] <ubitux> after all, we're paying them
[19:05:03 CET] <Daemon404> re; money
[19:05:07 CET] <Daemon404> not the other bit
[19:05:10 CET] <kierank> Or actually give them interesting stuff to work on
[19:05:20 CET] <kierank> instead of shit nobody wants to do
[19:05:22 CET] <kierank> they aren't slaves
[19:05:31 CET] <kierank> hint: when you treat people like human beings they respond like that 
[19:05:40 CET] <kierank> irrespective of the sociopathic nature of some in this community
[19:05:59 CET] <ubitux> then my question again, who stayed after having interesting subject?
[19:06:08 CET] <ubitux> but no more money income
[19:06:18 CET] <Daemon404> atomnuker
[19:06:44 CET] <ubitux> ah, the aac was a gsoc thing?
[19:06:48 CET] <Daemon404> i think so
[19:07:00 CET] <ubitux> didn't know that, okay
[19:07:03 CET] <kierank> ubitux: have you had any interesting subjects
[19:07:20 CET] <Daemon404> ubitux is only interested in subtitles, fact
[19:07:26 CET] <ubitux> lol, please
[19:07:34 CET] <ubitux> subtitles are a chore :(
[19:07:45 CET] <ubitux> i hate them, i just do it because no one else wants to
[19:07:50 CET] <sej> :O
[19:08:21 CET] Action: sej asks ppl to kindly ignore his reaction :P
[19:08:36 CET] <ubitux> kierank: i don't remember the gsoc students & subjects we had
[19:09:09 CET] <kierank> it's no secret gsoc has poor leadership
[19:09:14 CET] <kierank> it's why we have a stupid web server
[19:09:14 CET] <ubitux> (my question was geniune, not trying to make a point)
[19:10:45 CET] <kierank> if you want things to improve you have to do something about it
[19:11:41 CET] <Daemon404> not a webserver, kierank 
[19:11:46 CET] <Daemon404> a directory listing api with samba support!
[19:14:19 CET] <J_Darnley> kierank: 422, yes.  10-bit, no.
[19:14:36 CET] <jamrial_> kierank: afaik it's more like someone wanted it in, mentored it for gsoc, then when everyone complained about how out of place it was for ffmpeg he ragequit and left us with the thing commited
[19:15:26 CET] <kierank> gsoc is managed awfully
[19:16:10 CET] <kierank> not to mention that certain people (tm) use it as a point of pride over libav
[19:18:40 CET] <sej> kierank: should i do any qualification tasks to show my knowledge of creating web-interface?
[19:18:49 CET] <sej> for the fuzzing testsuite
[19:18:53 CET] <kierank> sej: you should do the fuzz task if you haven't already
[19:19:09 CET] <sej> yes,i am currently doing that
[19:19:13 CET] <kierank> ok
[19:38:19 CET] <rcombs> Daemon404: I'm also interested in subtitles
[19:38:39 CET] <rcombs> and should probably share more of ubitux's work on them
[19:39:00 CET] <michaelni> kierank, i copy and pasted the projects from gsoc because the outreachy page was totally outdated, listing TBA placeholders for backup mentors and missing many other updates that had been done on the GSoC page
[19:40:46 CET] <rcombs> [12:05:40]  <+kierank>	irrespective of the sociopathic nature of some in this community
[19:40:46 CET] <rcombs> ^ heh, I got some genetic testing done a while back (23andme), and one of the results that came back was a predisposition towards a lack of empathy
[19:49:55 CET] <michaelni> btw if noone wants to mentor the "MXF Demuxer Improvements" project then ill move it to the unmentored projects
[19:50:44 CET] <michaelni> mateo`, durandal_1707, anyone else ^
[19:55:17 CET] <Daemon404> im confused by julian's email
[19:55:30 CET] <Daemon404> is he using some sort of derived revision number, svn-style?
[19:56:35 CET] <c_14> Daemon404: I think he means the 78734 in N-78734-g666e2ed
[19:56:39 CET] <c_14> whatever that's derived from
[19:56:51 CET] <Daemon404> its basically that
[19:56:58 CET] <Daemon404> but usually youd give a hash
[19:57:11 CET] <Daemon404> so you can actually find it
[19:57:57 CET] <c_14> Not everyone knows that the part after the g is the hash.
[19:58:45 CET] <Daemon404> tbh im not sure why we generate a svn-style number at all
[20:13:08 CET] <Daemon404> TIL: OggSpots is a thing
[20:24:34 CET] <kierank> michaelni: don't do it again
[20:24:40 CET] <kierank> The page was fine
[21:00:24 CET] <Daemon404> urg struct order stuff
[21:03:37 CET] <cone-291> ffmpeg 03NagaChaitanya Vellanki 07master:df4b5f076e67: Add test for avpriv_get_trc_function_from_trc function
[21:07:56 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:768734a0ff24: avfilter/vf_vectorscope: add threshold option
[21:07:57 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:5e9f85925c6f: avfilter/vf_vectorscope: improve green graticule visibility
[21:18:17 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:9b0eabdcdfc5: avutil/color_utils: Mark test_data as static const
[21:27:49 CET] <JEEB_> heh, yadif and asm http://csbarn.blogspot.fi/2016/03/yadifmod-for-avisynth26-avisynth.html
[21:28:18 CET] <JEEB_> (did yadif in lavfi have SSE2 and AVX2?)
[21:28:46 CET] <Timothy_Gu> JEEB_: yes
[21:28:53 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:fbfd2601f660: avcodec/utils: Fix 'ISO C90 forbids mixed declarations and code'
[21:28:54 CET] <JEEB_> ok, so he probably ported that over
[21:28:54 CET] <cone-291> ffmpeg 03Michael Niedermayer 07master:966eadeab317: avfilter/vf_ciescope: Fix 'ISO C90 forbids mixed declarations and code'
[21:29:25 CET] <Timothy_Gu> well not sure about AVX2, but we definitely have SSE2
[21:35:12 CET] <durandal_1707> no AVX2
[21:43:08 CET] <durandal_1707> if we have only one outreachy slot why it have gsoc tasks,exp hard ones?
[21:50:44 CET] <BtbN> Daemon404, usualy to have an easy way to tell if some version is more recent. That's not exactly easy with just a hash, without looking at the git log.
[21:51:53 CET] <Timothy_Gu> I don't get why we don't use a more intelligent revision string
[21:52:13 CET] <BtbN> Based on the latest release?
[21:52:14 CET] <Timothy_Gu> like n3.1-dev-10-g5d82370
[21:52:19 CET] <Timothy_Gu> yes
[21:52:23 CET] <Timothy_Gu> not based on N
[21:52:36 CET] <BtbN> Probably because the tags are not in the master branch, so git describe doesn't see them.
[21:52:43 CET] <Timothy_Gu> the -dev ones are
[21:53:10 CET] <Timothy_Gu> in fact if you have a Git master checkout right now git describe will output one based on n3.1
[21:53:13 CET] <Timothy_Gu> -dev
[21:53:37 CET] <BtbN> so the git describe that generates that version string needs to be adjusted, probably somewhere in configure?
[21:54:00 CET] <Timothy_Gu> https://github.com/FFmpeg/FFmpeg/blob/master/version.sh#L8
[21:54:04 CET] <Timothy_Gu> `--match N`
[21:54:16 CET] <Timothy_Gu> also see "Rants" section in http://willus.com/author/ffmpegbmark.shtml
[21:56:46 CET] <BtbN> well, for me that still outputs "n2.9-dev-4001-g966eade" when done with --always
[21:56:52 CET] <BtbN> because I never fetched the new tags
[21:57:26 CET] <Daemon404> BtbN, true
[21:57:30 CET] <Daemon404> im lazy and use dates :P
[21:58:53 CET] <Timothy_Gu> BtbN: how do you not fetch tags?
[21:59:02 CET] <Timothy_Gu> git fetch origin always fetches tags for me
[21:59:09 CET] <BtbN> but git pull does not.
[21:59:12 CET] <Timothy_Gu> oh
[21:59:22 CET] <BtbN> So I only have the tags from when I first clones that repo.
[21:59:25 CET] <BtbN> *d
[21:59:52 CET] <Timothy_Gu> hmmff
[21:59:54 CET] <BtbN> I think a plain "git fetch" also doesn't get them, you need fetch --tags
[22:01:01 CET] <Timothy_Gu> My man page says that by default tags are fetched
[22:01:04 CET] <Timothy_Gu> "By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally."
[22:01:14 CET] <Timothy_Gu> under doc for --no-tags
[22:01:20 CET] <J_Darnley> Simple solution: stop allowing merges and have a linear history
[22:01:36 CET] <Timothy_Gu> but I guess this is an argument for N-<number>
[22:01:56 CET] <BtbN> I'm not a fan ob the N-Thing and would like to see it go.
[22:02:24 CET] <BtbN> maybe adding a silent fetch to the version.sh?
[22:03:29 CET] <BtbN> Or just accept that the revision it's based on might be outdated? 2.9-dev-1234 is still better than N-70000
[22:07:41 CET] <BtbN> hm, adding git fetch in version.sh makes it show an ssh key password prompt for me. Not acceptable.
[22:10:27 CET] <Compn> use web git version link to version.sh ?
[22:10:51 CET] <BtbN> hm?
[22:11:15 CET] <BtbN> you mean explicitly fetching from the anonymous url?
[22:11:33 CET] <BtbN> That might pull in a lot of objects, depending on where the user cloned from
[22:14:58 CET] <BtbN> git fetch --quiet "https://git.videolan.org/git/ffmpeg.git" "refs/tags/*:refs/tags/*"
[22:45:28 CET] <durandal_1707> michaelni: is it doable to add 17 size to avfft?
[22:50:16 CET] <BtbN> Timothy_Gu, sent a patch.
[23:08:49 CET] <darkapex> Any pointers to helpful resources to brush-up dsp used in audio encoders/decoders?
[23:09:53 CET] <atomnuker> not really, learning things as you go is probably the best way to go about it
[23:10:34 CET] <atomnuker> but for lossless audio compression you don't really need to know much
[23:11:53 CET] <darkapex> atomnuker: Yeah, I was still asking if I probably contribute to heavy-dsp codecs later on and I had some free time on hand. For now it's going smooth.
[23:11:57 CET] <darkapex> Thanks :)
[23:12:20 CET] <DHE> Question. If I want to make an API update which affects libav* but would be of no use to the ffmpeg commandline tool, would it still be accepted if I offered it as a patch via the mailing list, etc?
[23:13:04 CET] <wm4> DHE: sure, but depends on the details
[23:13:26 CET] <BtbN> if it doesn't pointlessly break API/ABI
[23:16:41 CET] <nevcairiel> Still needs to be useful in general, bot everything is used by the CLI tools
[23:16:57 CET] <nevcairiel> s/bot/not/
[23:17:57 CET] <DHE> the feature in question is for middle-of-the-stream events. I'm looking at a live streaming application which may have to deal with the source material changing in some way that renders the output file unusable from that point on without explicitly doing something not yet supported.
[23:18:39 CET] <nevcairiel> We have side data to communicate changes midstream already
[23:19:05 CET] <nevcairiel> Could just hook up something there
[23:20:07 CET] <DHE> I'm using the HLS output format. The spec calls for a tag, "EXT-X-DISCONTINUITY" to be inserted at the time of the sequence break but that's not supported right now.
[23:20:22 CET] <DHE> if the side channel is available it might be as simple as adding the feature to just HLS. that would simplify things
[00:00:00 CET] --- Fri Mar  4 2016