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

[burek]

[00:02:04 CEST] <cone-247> ffmpeg 03Kevin Wheatley 07master:bac904826542: avutil/color_utils: Add basic transfer functions for each AVColorTransferCharacteristic
[00:02:05 CEST] <cone-247> ffmpeg 03Kevin Wheatley 07master:7eb3233352f6: avcodec/exr: Add support for applying a transfer characteristic curve to OpenEXR inputs.
[00:02:06 CEST] <cone-247> ffmpeg 03Kevin Wheatley 07master:a1fa5392e63e: avcodec/exr: Mark up the decoded buffer as the appropriate transfer characteristic when applying one
[00:10:58 CEST] <ebail> BBB: on internet, UDP packet reordering happen very often. For the moment jitter buffer is sized to 10. imagine that each time, the queue length is 1. You could never have sorted RTP packets (you could have seq=1,2,5,3,4) If you keep your jitter buffer big enough (as example 5), you would have more accurate sorting (seq=1,2,3,4,5)
[00:11:56 CEST] <ebail> BBB: so I would say yes. Lot of app could need this infos. Probably some of them implement their own JB
[00:16:37 CEST] <Loriker> ebail: from which company are you?
[00:19:00 CEST] <cone-247> ffmpeg 03Lou Logan 07master:98ecee2d3d5e: doc/filters: fix Photoshop curves file extension
[00:19:51 CEST] <ebail> Loriker: not sure to follow you... ?
[00:30:29 CEST] <rcombs> does configure not work on mingw64?
[00:30:34 CEST] <rcombs> (msys2)
[00:30:48 CEST] <nevcairiel> works here
[00:30:55 CEST] <rcombs> getting "Unknown OS 'mingw64_nt-10.0'."
[00:31:27 CEST] <rcombs> fudged configure to handle "mingw64*" the same way as "mingw32*"
[00:31:32 CEST] <nevcairiel> i dont use their dumb batch files
[00:31:39 CEST] <nevcairiel> the way they handle that OS value is fucking stupid
[00:31:56 CEST] <rcombs> who's they
[00:32:08 CEST] <nevcairiel> msys2
[00:32:24 CEST] <rcombs> so what do you do
[00:32:41 CEST] <nevcairiel> i have my own script that just overrides their stupid env variable to the trusted mingw32
[00:33:03 CEST] <nevcairiel> the OS doesnt change just because i click on the batch file for the 64-bit compiler
[00:33:05 CEST] <nevcairiel> its silly
[00:33:26 CEST] <nevcairiel> (incidentally, i also dont use their compilers, but thats unrelated)
[00:33:37 CEST] <rcombs> "libavdevice/gdigrab.c:324:16: warning: format %li expects argument of type long int, but argument 7 has type LONG [-Wformat=]"
[00:33:40 CEST] <rcombs> lovely
[00:34:14 CEST] <rcombs> along with libavdevice/gdigrab.c:336:9: warning: format %li expects argument of type long int, but argument 4 has type DWORD [-Wformat=]
[00:34:25 CEST] <nevcairiel> what does LONG expand to these days then :P
[00:34:39 CEST] <nevcairiel> DWORD is also LONG afaik
[00:34:40 CEST] <Plorkyeran> dword is signed, so that one makes sense at least
[00:34:43 CEST] <Plorkyeran> iirc
[00:34:51 CEST] <nevcairiel> long int is also signed
[00:34:56 CEST] <Plorkyeran> er
[00:34:59 CEST] <Plorkyeran> unsigned
[00:35:06 CEST] <rcombs> `typedef long LONG;`
[00:35:32 CEST] <nevcairiel> dumb gcc is dumb?
[00:35:54 CEST] <rcombs> not sure if it's actually defined that way in the mingw headers
[00:36:05 CEST] <rcombs> (do they even provide their own headers? fuck if I know)
[00:36:16 CEST] <nevcairiel> they do
[00:36:28 CEST] <rcombs> but yeah, configure should probably work with `mingw64`
[00:37:31 CEST] <rcombs> http://puu.sh/k6Vl4/d6a297930b.png well that's not pleasant
[00:38:41 CEST] <rcombs> doing anything at all on Windows continues to be a 0/10 would not recommend experience
[00:39:04 CEST] <nevcairiel> its just the msys2 thing being stupid
[00:39:14 CEST] <nevcairiel> their compiler distribution uses mingw64 trunk
[00:39:20 CEST] <nevcairiel> so you end up with broken things occasionally
[00:39:23 CEST] <nevcairiel> or well, often
[00:39:57 CEST] <rcombs> I also accidentally cloned into "FFmpeg" instead of "ffmpeg" (I prefer lowercase repo dir names), noticed, and ^C'd
[00:40:04 CEST] <rcombs> tried to rm -r the dir
[00:40:15 CEST] <rcombs> nope, something's somehow locked in there
[00:40:30 CEST] <rcombs> close mingw2, reopen, nope, still locked
[00:40:33 CEST] <rcombs> had to reboot
[00:40:50 CEST] <nevcairiel> d3d11va only checks for ID3D11VideoDecoder apparently, so somehow they managed to  include that one but not the context in mingw64, figures
[00:51:43 CEST] <jamrial> rcombs, nevcairiel: that's odd, compiles fine for me here
[00:51:55 CEST] <jamrial> msys2 with their mingw-w64 package based on trunk
[00:54:00 CEST] <jamrial> ID3D11VideoContext not being available would make sense only if you're using mingw-w64 stable
[00:54:33 CEST] <nevcairiel> i use stable, and i never had any troubles
[00:54:41 CEST] <nevcairiel> because videodecoder is also not available
[00:54:45 CEST] <nevcairiel> which configure checks for
[01:05:20 CEST] <jamrial> rcombs: when was the last time you ran pacman and it actually updated stuff?
[01:06:06 CEST] <jamrial> last time i checked their sourceforge mirror was fucked. they moved since then, so you may have not gotten the updated mirrors file
[01:21:57 CEST] <cone-247> ffmpeg 03Michael Niedermayer 07master:77d03b0ebb7b: avutil/version: Bump for avpriv_get_trc_function_from_trc() and AVCOL_PRI/TRC_SMPTEST428_1 and AVCOL_TRC_SMPTEST2084
[01:21:58 CEST] <cone-247> ffmpeg 03Michael Niedermayer 07master:f58e011a1f30: avformat/utils: Increase default max_stream_analyze_duration for flv
[09:38:43 CEST] <satiender> Hi , can we develop single filter , I mean I need only blur filter and if I want to use blur filter , then ffmpeg installation necessary . which takes a lot of memory , but I want write only blur filter 
[09:38:54 CEST] <satiender> Is there any why
[09:39:05 CEST] <satiender> I can write only blur filter
[09:41:34 CEST] <durandal_170> you want to create filter for us?
[10:14:33 CEST] <satiender> durandal_170 : yes , before working on video filters , I worked a lot of thing about video streaming like in our ffmpeg , there have no large output buffer , I create user defined buffer for jitter control and buffering purpose
[10:14:46 CEST] <cone-948> ffmpeg 03Agatha Hu 07master:81071eea7d90: avcodec/nvenc: change flag of cuCtxCreate to avoid CPU spins
[10:15:15 CEST] <satiender> durandal_170 : Now I want work on ffmpeg filters
[10:16:15 CEST] <satiender> durandal_170 : but think something about those users , which want use only single functionality of ffmpeg 
[10:17:10 CEST] <satiender> durandal_170 : So , My idea create a dedicated filters without installation of ffmpeg , that person will be use that filter
[10:17:24 CEST] <satiender> So please give me some idea 
[10:17:32 CEST] <satiender> and some resource 
[10:17:36 CEST] <satiender> about that thing
[10:18:38 CEST] <nevcairiel> if you want to write a video filter independent of ffmpeg, then thats fine, but i dont see what we can do to help you then. we develop ffmpeg here, and any functionality is offered in one package
[10:18:38 CEST] <durandal_170> you can compile only filters, decoders, encoders, etc you want
[10:21:15 CEST] <satiender> nevcairiel : yes your are absolutely right , we are doing development our main platform ffmpeg 
[10:22:16 CEST] <satiender> nevcairiel : but , ffmpeg is very good for x86 and a high performer ARm processor 
[10:23:28 CEST] <satiender> nevcairiel : but thing about those users which want development for video on less costly processors and for mobile application
[10:23:28 CEST] <BtbN> These nvidia patches...
[10:23:51 CEST] <satiender> sorry not thing that is think
[10:24:01 CEST] <nevcairiel> BtbN: lots of fun with corporate-quality code
[10:25:02 CEST] <BtbN> They change the behaviour all over the place
[10:25:14 CEST] <BtbN> Yes, the default is now better. But the twopass automatism is now gone
[10:25:22 CEST] <satiender> durandal_170 : but compile a single filter , I think very time consuming
[10:25:52 CEST] <nevcairiel> BtbN: didnt they add new profile names with the defaults
[10:25:59 CEST] <nevcairiel> i only skimmed over the patch
[10:26:02 CEST] <BtbN> nevcairiel, the guy who actualy did the changes also sent me a patch directly, which they use internaly.
[10:26:07 CEST] <BtbN> nevcairiel, yes, they added 3 new profiles
[10:26:13 CEST] <BtbN> which i have no problem with, i like the idea.
[10:26:24 CEST] <BtbN> But they change the behaviour of the twopass/2pass option
[10:26:37 CEST] <BtbN> removing the automatism, without adjusting the code to respect for that
[10:26:41 CEST] <BtbN> so half of it is broken now
[10:27:13 CEST] <durandal_170> satiender: your English is very bad, I can't understand what you want
[10:27:15 CEST] <ubitux> durandal_170: https://github.com/mpv-player/mpv/issues/1945 isn't this handled by stereo3d?
[10:27:42 CEST] <nevcairiel> ubitux: HDMI frame packing needs to be done at the output stage specifically, nothing you can cheat your way through earlier
[10:28:01 CEST] <ubitux> i'm mostly refering to 'split[a][b]; [a]pad=1920:2205[ap]; [b]crop=1920:1080:0:1080[bc]; [ap][bc]overlay=0:1125'
[10:28:03 CEST] <satiender> durandal_170 : sorry for that 
[10:28:37 CEST] <nevcairiel> (also much faster if you do it in the renderer)
[10:28:44 CEST] <ubitux> sure
[10:28:51 CEST] <satiender> durandal_170 : I said , compilation for a single filter in ffmpeg is vey time consuming task 
[10:28:57 CEST] <ubitux> nevcairiel: btw, i saw you poked them about a "generic solution" for the generic options...
[10:29:01 CEST] <satiender> are agree 
[10:29:04 CEST] <ubitux> (in lavfi)
[10:29:08 CEST] <satiender> are you agree
[10:29:17 CEST] <durandal_170> satiender: not at all
[10:29:56 CEST] <durandal_170> you can build ffmpeg only with drawbox filter
[10:30:30 CEST] <ubitux> > FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
[10:30:32 CEST] <ubitux> what am i reading
[10:30:59 CEST] <ubitux> "I am getting error for unrecognized option '-vf'"
[10:31:01 CEST] <ubitux> no shit
[10:31:03 CEST] <ubitux> :D
[10:31:14 CEST] <satiender> durandal_170 : ok 
[10:31:17 CEST] <BtbN> Is this CentOS 5?
[10:31:39 CEST] <satiender> durandal_170 : I already tell you my problem few days ago
[10:32:07 CEST] <durandal_170> I forgot it sorry
[10:32:20 CEST] <satiender> durandal_170 : I want a blurry video for real time in android phone
[10:33:18 CEST] <nevcairiel> ubitux: i couldnt resist
[10:33:18 CEST] <satiender> means user record video then preview that video 
[10:33:50 CEST] <satiender> durandal_170 : then at preview time swap the screen 
[10:33:54 CEST] <ubitux> nevcairiel: but they're going to NIH it now; you sure you don't want to try to make them pick what we did?
[10:34:19 CEST] <satiender> durandal_170 : then see the blurry video on current position of video
[10:34:26 CEST] <nevcairiel> ubitux: they wouldnt anyway
[10:34:31 CEST] <durandal_170> satiender: than you are on wrong channel, there are already blurring filters in ffmpeg
[10:35:29 CEST] <durandal_170> but I'm not interested in android platform
[10:35:42 CEST] <satiender> durandal_170 : yes bro , I implement that blur filters in android
[10:35:56 CEST] <satiender> but that is not real time like opengl
[10:36:16 CEST] <satiender> please get my idea
[10:36:31 CEST] <satiender> user playing his video 
[10:36:34 CEST] <durandal_170> than do it in opengl
[10:36:48 CEST] <nevcairiel> ubitux: far more likely that they'll just push what they have and claim to fix it better later
[10:37:29 CEST] <satiender> durandal_170 : yes I can do that in opengl but I want do it on ffmpeg
[10:37:43 CEST] <satiender> because ffmpeg have large no of filter
[10:38:13 CEST] <durandal_170> but ffmpeg have no way to use opengl
[10:39:24 CEST] <satiender> no , please remove the opengl currently for understand my problem
[10:39:26 CEST] <satiender> please
[10:39:38 CEST] <satiender> User play his video ok
[10:40:00 CEST] <satiender> at playing time , he swap the screen 
[10:40:29 CEST] <satiender> suppose video half played 
[10:40:55 CEST] <satiender> when he swap the screen , the blur is implemented on video 
[10:41:14 CEST] <satiender> and user see at same time that blurry video 
[10:41:24 CEST] <satiender> on current frame 
[10:41:40 CEST] <satiender> is it possible  in ffmpeg
[10:44:21 CEST] <satiender> because which I already implemented that is not real time
[10:44:54 CEST] <durandal_170> I do not see code
[10:46:04 CEST] <durandal_170> and I dunno if ffmpeg filter is realtime on random android phone, probably not
[10:48:26 CEST] <satiender> durandal_170 : no more question , just one question
[10:48:49 CEST] <satiender> Can that is possible with ffmpeg which I asked ??
[10:59:32 CEST] <BtbN> Great, the patch reverts the coded_frame deprecation...
[10:59:52 CEST] <nevcairiel> tell em to shove it
[11:04:49 CEST] <durandal_170> satiender: yes, its possible to create video halfblurred/halfnormal
[11:08:57 CEST] <satiender> durandal_170 : No , I ask real time is possible
[11:09:34 CEST] <satiender> means user playing video then press button and at same time see the video is blurry
[12:40:46 CEST] <cone-948> ffmpeg 03Carl Eugen Hoyos 07master:85a7ff8c2726: lavc: Fix standalone compilation of the subrip decoder.
[12:58:49 CEST] <cone-948> ffmpeg 03Ganesh Ajjanagadde 07master:07d33439f310: configure: colorize error messages
[13:39:19 CEST] <durandal_170> fine to push ocr?
[13:41:18 CEST] <BtbN> philipl, could you have a quick look at the nvidia patches? I fixed them up a bit and pushed the new version to my github: https://github.com/BtbN/FFmpeg/commits/master
[13:54:38 CEST] <cone-948> ffmpeg 03Michael Niedermayer 07master:055e56e9f76d: avcodec/mjpegdec: Fix decoding RGBA RCT LJPEG
[13:54:39 CEST] <cone-948> ffmpeg 03Michael Niedermayer 07master:8b72f6d50ba8: avcodec/ljpegenc: Fix encoding RGBA LJPEG
[13:58:10 CEST] <ubitux> are we still in the process of abi break?
[13:58:24 CEST] <ubitux> like, can i drop the srt decoder?
[13:59:03 CEST] <nevcairiel> Sure
[14:01:17 CEST] <ubitux> how long do i have?
[14:01:49 CEST] <ubitux> i mean, i suppose we don't have a timescale for that
[14:02:08 CEST] <Daemon404> i mean, who even does releases now?
[14:02:12 CEST] <nevcairiel> Dunno. Until we decide to stop. I would say another week is a good timing, that's two weeks of unstable then
[14:02:21 CEST] <ubitux> Daemon404: michael still does them
[14:02:23 CEST] <nevcairiel> Michael still does releases
[14:02:26 CEST] <Daemon404> oic
[14:02:26 CEST] <Daemon404> k
[14:20:41 CEST] <atomnuker> who really wrote libopus? aliens?
[14:21:22 CEST] <atomnuker> I throw my baddest, meanest samples at it which make everything else fail and it just stubbornly refuses to ever degrade into nastyness
[14:21:43 CEST] <nevcairiel> Haha
[14:21:51 CEST] <nevcairiel> So you're saying it works well
[14:22:12 CEST] <atomnuker> 20kbps, and it still has a decent spectrum
[14:22:55 CEST] <atomnuker> it only barely loses to AAC-HE at 48kbps, at least IMO
[14:23:24 CEST] <Daemon404> atomnuker, derf is some sort of alien, i think, ye
[14:23:24 CEST] <Daemon404> s
[14:23:28 CEST] <Daemon404> sent from the future
[14:23:38 CEST] <atomnuker> but above and below that bitrate it's killing everything
[14:32:59 CEST] <atomnuker> though opus at higher bitrates (128kpbs) overshoots a bit (peaks at 160kbps, average at around 140ish kbps) on some samples
[14:33:30 CEST] <atomnuker> but you know, if you can spare 128kbps you can probably spare some more on top
[15:34:48 CEST] <BBB> we can wait until after vdd
[15:34:55 CEST] <BBB> so we can troll each other about stuff over there
[15:34:57 CEST] <BBB> bribe with beer
[15:44:02 CEST] <RiCON> rcombs: another one with the same issue as the one you had yesterday: https://github.com/jb-alvarado/media-autobuild_suite/pull/155#issuecomment-139540244
[15:44:33 CEST] <rcombs> heh
[15:45:03 CEST] <RiCON> but can't reproduce it myself
[16:04:58 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178731.html <-- not even joking; I have a real 14-channel file here
[16:05:18 CEST] <rcombs> (it's actually 7 stereo mixes)
[16:05:33 CEST] <rcombs> (of songs with the same duration that crossfade together well)
[16:36:32 CEST] <durandal_170> Gonna push ocr
[16:40:48 CEST] <satiender> durandal_170 : how we can configure ffmpeg only for encoding , decoding and filter purpose
[16:40:50 CEST] <satiender> ??
[16:43:12 CEST] <durandal_170> satiender: there is docs and you are on wrong channel
[16:46:36 CEST] <satiender> ok
[16:56:31 CEST] <philipl> BtbN: looking
[16:57:25 CEST] <satiender> durandal_170 : I copy a codec of ffmpeg how I can compile it out side the ffmpeg directory 
[16:57:38 CEST] <satiender> there have multiple undefined errors
[16:57:57 CEST] <satiender> I think I need to link library for that
[16:58:09 CEST] <satiender> like libavcodec but how I can 
[16:58:13 CEST] <satiender> please help 
[16:58:24 CEST] <satiender> give any idea or example
[16:58:26 CEST] <satiender>  ??
[16:58:43 CEST] <BBB> what are you trying to do
[16:58:56 CEST] <BBB> you cant just compile one codec w/o the rest of ffmpeg
[16:58:58 CEST] <durandal_170> seriously this have nothing with ffmpeg development
[16:59:03 CEST] <BBB> true
[17:00:02 CEST] <satiender> durandal_170 : I shared a ffmpeg link here please must see that code
[17:00:16 CEST] <satiender> https://www.ffmpeg.org/doxygen/2.1/doc_2examples_2decoding_encoding_8c-example.html
[17:01:32 CEST] <BBB> satiender: this has nothing to do with ffmpeg development, youre trying to develop with ffmpeg
[17:01:37 CEST] <BBB> satiender: this channel is for ffmpeg development
[17:01:51 CEST] <BBB> satiender: I recommend either #ffmpeg-user, or try something like stackoverflow
[17:02:31 CEST] <c_14> BBB: I think you meant either #ffmpeg or the ffmpeg-user mailing list (or stackoverflow)
[17:02:40 CEST] <BBB> oh right
[17:02:41 CEST] <BBB> ty
[17:04:30 CEST] <philipl> BtbN: Added two small comments. Otherwise looks fine.
[17:14:05 CEST] <satiender> BBB : please give some advice 
[17:14:19 CEST] <ubitux> satiender: advice is "go to #ffmpeg"
[17:15:04 CEST] <BBB> choose between go to #ffmpeg, ask on the ffmpeg-user mailinglist, ask on stackoverflow
[17:15:25 CEST] <BBB> sicne youre already on irc, ask on #ffmpeg seems a logical first try, yes
[17:20:21 CEST] <BtbN> philipl, i wonder if Agatha got mails for them
[17:21:50 CEST] <BtbN> I wondered about that HP/HQ thing as well. "fast" definitely does sound like HP to me.
[17:38:27 CEST] <ubitux> durandal_170: get_scene_score is from select but i think i wrote that one (refering to copyright)
[17:38:33 CEST] <ubitux> not really important though
[17:42:38 CEST] <Zeranoe> Since OpenCL was added to the Windows builds, there have been a few complains that opencl.dll is missing. Would it be possible to have FFmpeg attempt to load the dll only if an opencl feature is being used, and not during initial run?
[17:46:13 CEST] <satiender> BBB : can we use life=s=640x480:mold=10:r=100:ratio=0.1:death_color=blue:life_color=#00ff00,boxblur=2:2 for add effects in my video
[17:46:16 CEST] <satiender> ??
[17:47:12 CEST] <BBB> satiender: still not related to ffmpeg development
[17:48:29 CEST] <cone-948> ffmpeg 03Paul B Mahol 07master:250624415544: avformat/wavenc: use AV_OPT_TYPE_BOOL for write_bext option
[17:48:30 CEST] <cone-948> ffmpeg 03Paul B Mahol 07master:abef6383fb7f: avformat/wavdec: use AV_OPT_TYPE_BOOL for ignore_length
[17:49:05 CEST] <satiender> ok
[17:49:09 CEST] <satiender> Sir sorry
[17:49:14 CEST] <satiender> :(
[17:55:46 CEST] <durandal_170> Zeranoe: maybe, open bug report so its not forgotten
[18:05:49 CEST] <bofh__> yeah, you'd just do a LoadLibrary()/GetProcAddress() at runtime
[18:06:22 CEST] <bofh__> not sure why it's even enabled - is OpenCL really useful for ffmpeg esp. since it only works for a few lavfilter kernels?
[18:06:27 CEST] <Daemon404> it is not
[18:06:32 CEST] <Daemon404> its confined to useless filters
[18:06:35 CEST] <Daemon404> like unsharp mask
[18:06:45 CEST] <Daemon404> which totally need gpu support
[18:07:15 CEST] <Daemon404> furthermore, we do not dlopen any otehr dependencies
[18:08:04 CEST] <bofh__> in that case it may be saner to just turn it off for windows builds IMO
[18:08:20 CEST] <Daemon404> i agree
[18:08:35 CEST] <Daemon404> but people like to build with ALL the deps
[18:08:38 CEST] <Daemon404> no matter how useless
[18:08:41 CEST] <Daemon404> i blame our wiki.
[18:08:46 CEST] <bofh__> which I think is silly
[18:08:52 CEST] <bofh__> see also: fontconfig
[18:09:40 CEST] <durandal_170> Zeranoe: do you build with ladspa?
[18:10:00 CEST] <Daemon404> bofh__, fontconfig is unfortunately a hard dependency of libass
[18:10:05 CEST] <Daemon404> if you want subtitles you need it
[18:10:11 CEST] <nevcairiel> dont think thats still true
[18:10:18 CEST] <nevcairiel> can use directwrite on windows now
[18:10:18 CEST] <Daemon404> there gdi backend was never merged.
[18:10:22 CEST] <Daemon404> oh?
[18:10:24 CEST] <nevcairiel> of course, no xp support then
[18:10:24 CEST] <Daemon404> this is news to me
[18:10:26 CEST] <nevcairiel> so a no go!
[18:10:42 CEST] <Daemon404> so i can finally ditch 20 minutes of REBUILDING FONT CACHE?
[18:11:23 CEST] <nevcairiel> it was merged a couple days ago only
[18:12:08 CEST] <Daemon404> ah.
[18:12:15 CEST] <Daemon404> that is still awesome news.
[18:15:08 CEST] <bofh__> Daemon404: doesn't ffmpeg have a native ass parser/decoder though?
[18:15:32 CEST] <Daemon404> libass is to render.
[18:15:45 CEST] <Daemon404> ffmpeg can only parse
[18:15:58 CEST] <bofh__> (also fontconfig has never been a hard dep of libass - freetype yes, but you have always been able to build w/o fontconfig, though it becomes much more of a pain in the ass to use then)
[18:16:10 CEST] <bofh__> that's amusing, since parsing ass is IMO the hard part
[18:16:29 CEST] <Daemon404> libass was next to useles withotu fontconfig on windows
[18:26:56 CEST] <nevcairiel> Parsing itself is easy, interpret and layout, that's the real deal
[19:46:50 CEST] <RiCON> rcombs: so newest mingw git headers did break d3d11va/dxva
[19:46:56 CEST] <rcombs> whoo!
[19:46:58 CEST] <rcombs> not my fault@
[19:47:05 CEST] <RiCON> they seem to like breaking things constantly
[19:47:23 CEST] <RiCON> so either disable those two or downgrade headers
[19:55:44 CEST] <nevcairiel> (i told you,  trunk mingw is pain to be had)
[19:56:24 CEST] <RiCON> they could have at least stable headers available on msys
[19:56:32 CEST] <nevcairiel> thats another thing
[19:56:45 CEST] <nevcairiel> but stable mingw compiler here http://files.1f0.de/mingw/
[19:56:48 CEST] <nevcairiel> :d
[20:02:07 CEST] <cone-948> ffmpeg 03Rostislav Pehlivanov 07master:8180b113e114: aaccoder: respect cutoff when marking bands as PNS
[20:03:56 CEST] <jamrial> yeah, msys2 shipping up-to-date mingw-w64 trunk is weird
[20:04:02 CEST] <jamrial> changes to trunk tend to break things way too often, and whoever packages it on msys2 apparently doesn't try to rebuild everything again with them
[20:04:33 CEST] <jamrial> otherwise he would have noticed the ffmpeg package would fail to compile, i assume
[20:05:31 CEST] <atomnuker> would someone mind OPing me again?
[20:05:50 CEST] <nevcairiel> if someone gave you access, you can ask chanserv to do it
[20:06:03 CEST] <RiCON> jamrial: they actually build 2.8 just before updating the headers
[20:06:09 CEST] <RiCON> built*
[20:06:27 CEST] <jamrial> heh, no wonder he didn't notice it then
[20:10:00 CEST] <atomnuker> nevcairiel: thanks, apparently ChanServ doesn't allow me to
[20:10:03 CEST] <RiCON> hm, they just removed the patch that added ID3D11VideoContext apparently
[20:13:14 CEST] <jamrial> that's why it broke?
[20:16:18 CEST] <RiCON> they removed https://github.com/Alexpux/MINGW-packages/blob/e629b3add67e2765026380e28a1535eb5af5266f/mingw-w64-headers-git/0006-Add-d3d11-video-decoder.patch
[20:16:37 CEST] <RiCON> maybe because it needed updating so they thought it was fixed upstream?
[20:19:32 CEST] <nevcairiel> i thought upstream already merged that shit?
[20:19:36 CEST] <nevcairiel> man they are so slow
[20:21:55 CEST] <RiCON> latest update to d3d11.h: https://github.com/Alexpux/mingw-w64/commit/dcb758035e39fabf7e2756554d9a4042d90cd5e5
[20:22:11 CEST] <RiCON> maybe ffmpeg itself needs to stuff?
[20:22:18 CEST] <RiCON> update stuff*
[20:22:31 CEST] <jamrial> that's the upstream patch to mingw-w64, right?
[20:23:11 CEST] <jamrial> https://github.com/Alexpux/MINGW-packages/commit/99b58b4130108de4df1eab601d5621d6563dfa0e this is the msys2 package update that removed the dx11 video decoder patch above
[20:23:27 CEST] <jamrial> someone already commented there that it broke ffmpeg
[20:23:35 CEST] <RiCON> me
[20:23:43 CEST] <jamrial> ah
[20:23:48 CEST] <RiCON> but from https://github.com/Alexpux/mingw-w64/commit/dcb758035e39fabf7e2756554d9a4042d90cd5e5 it seems mingw added video decoder stuff already?
[20:24:46 CEST] <jamrial> no matches found for ID3D11VideoContext
[20:24:48 CEST] <jamrial> so no
[20:25:13 CEST] <nevcairiel> for some reason they merged half the things
[20:25:13 CEST] <RiCON> so the patch does need updating
[20:25:30 CEST] <nevcairiel> mingw64 is so slow with supporting new things, even when someone sends patches
[20:27:18 CEST] <BtbN> i wonder if it's possible to build OBS with mingw by now.
[20:27:22 CEST] <jamrial> so all the dx11 stuff never really made it upstream, and all this time it was only applied to the mingw64 package shipped by msys2
[20:32:26 CEST] <nevcairiel> apparently
[20:32:33 CEST] <nevcairiel> should probably add a check to configure for videocontext
[20:33:19 CEST] <jamrial> replacing the one for ID3D11VideoDecoder?
[20:33:29 CEST] <nevcairiel> maybe both for safety
[20:36:03 CEST] <jamrial> sounds good
[20:36:46 CEST] <nevcairiel> although i bet they manage to screw that up, add the videocontext, but dont add the other structs required =p
[20:37:02 CEST] <nevcairiel> effectively, it only works with msvc :p
[20:37:24 CEST] <jamrial> haha
[20:59:05 CEST] <c_14> Does anyone know if Anshul Maheshwari is still around or were they just a student for gsoc/opw and are now gone?
[21:18:40 CEST] <c_14> nvmd, problem is somewhere else
[21:23:30 CEST] <cone-948> ffmpeg 03Michael Niedermayer 07master:0ae40c5a7049: swscale/swscale: Fix "unused variable" warning
[21:37:28 CEST] <cone-948> ffmpeg 03Thierry Foucu 07master:f600381b79ef: libavformat/utils.c: use correct variable for message.
[22:01:47 CEST] <cone-948> ffmpeg 03Alexander S. Drozdov 07master:6a8d58d69309: avformat/tcp: TCP Protocol: fix descriptor leak on listen and interrupt
[22:18:39 CEST] <jamrial> ubitux: what would be the easiest way to add high bitdepth support to pixutils?
[22:19:48 CEST] <jamrial> av_pixelutils_get_sad_fn() can't be extended to support that, so maybe adding a new function with a bitdepth parameter?
[23:24:12 CEST] <cone-948> ffmpeg 03James Almer 07master:b8e4df46ab5a: configure: check for ID3D11VideoContext
[23:29:12 CEST] <RiCON> jamrial: so does that disable dxva2 as well or just d3d11va?
[23:29:23 CEST] <jamrial> just d3d11va
[23:39:38 CEST] <RiCON> yeah, seems to fix it
[00:00:00 CEST] --- Sat Sep 12 2015