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

[burek]

[01:06:35 CEST] <cone-320> ffmpeg 03Michael Niedermayer 07master:124b7cd48533: Add NOA credits
[01:06:36 CEST] <cone-320> ffmpeg 03hSÇ 07master:a78656a18784: avcodec: loongson delete invalid simple idct put and add optimization
[03:52:49 CEST] <RT|AO> I'm getting this with latest git rev: ./configure: 420: ./configure: tput: not found
[03:52:57 CEST] <RT|AO> ./configure: 588: ./configure: Pipe call failed
[03:53:37 CEST] <RT|AO> ./configure: 6125: eval: Pipe call failed
[03:53:37 CEST] <RT|AO> ./configure: 6219: eval: Pipe call failed
[03:53:51 CEST] <RT|AO> /bin/sh: pipe error: Device or resource busy
[03:55:36 CEST] <c_14> RT|AO: what OS?
[03:55:44 CEST] <RT|AO> win32, MSYS
[03:57:44 CEST] <c_14> According to fate, it should still compile under mingw32. What version?
[03:59:02 CEST] <RT|AO> latest git rev, i.e. a78656a18784e0ef42350b7585f5d9ecf505eb9b
[04:00:15 CEST] <c_14> I meant of mingw32/msys
[04:00:42 CEST] <RT|AO> I can't remember since I installed long time ago
[04:01:00 CEST] <RT|AO> and it used to work
[04:01:22 CEST] <Timothy_Gu> haha i KNEW the tput commit was going to break some platforms
[04:01:38 CEST] <c_14> Probably need to update. that or revert 3e830b6dc844219673b6a036d8a3bd326ac4f9e2 (it just adds colors to warnings)
[04:12:56 CEST] <Timothy_Gu> RT|AO: can you try applying http://sprunge.us/UMbj ?
[05:11:38 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:12e6b64cd47c: Revert "configure: colorize warning messages"
[05:42:39 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:617d53f4c7e4: configure: Reenable colorized warnings and check for tput's existence
[05:45:47 CEST] <Timothy_Gu> RT|AO: patch pushed, although I'm still curious to hear if it works or not
[07:52:30 CEST] <j-b> good moroning!
[07:53:05 CEST] <atomnuker> morning
[07:53:17 CEST] <rcombs> good mourning
[08:09:00 CEST] <TimNich> Yawn, still a bit early for me&.
[08:58:41 CEST] <ubitux> > I just changed an API. As my senior dev told me, I added a @Deprecated annotation to the old public method... And I called the new method NonDeprecated...()
[08:58:43 CEST] <ubitux> #inspiring
[10:17:22 CEST] <cone-380> ffmpeg 03Carl Eugen Hoyos 07master:84c9bf62b42c: lavc/dxv: Silence "Multiple ff_thread_finish_setup() calls" warnings.
[10:18:24 CEST] <nevcairiel> ...
[10:18:32 CEST] <nevcairiel> this is why thigns should go on the ML
[10:18:35 CEST] <nevcairiel> wrong fixes are wrong :p
[10:18:50 CEST] <cone-380> ffmpeg 03Carl Eugen Hoyos 07master:9b2802f0d329: lavc/dxv: Support more real-world old version samples.
[10:44:20 CEST] <durandal_1707> whats wrong?
[10:48:34 CEST] <rcombs> silencing warnings instead of fixing the cause?
[11:07:12 CEST] <nevcairiel> the function clearly doesnt have a update thread context, so adding a check for that is just dumb .. just remove the line
[11:11:16 CEST] <kierank> i feel so sad about your decision to resign, Sir.
[11:11:16 CEST] <kierank> please don't care about the criticism, history will prove everything !
[11:11:16 CEST] <kierank> loongson support you, Sir, and support FFmpeg !
[11:11:24 CEST] <kierank> lol
[11:12:16 CEST] <atomnuker> I'd support loongson too, if they made normal processors
[11:12:40 CEST] <kierank> atomnuker: aac encoder author (who also likes trains) has a loongson
[11:12:50 CEST] <atomnuker> none of those processors which require the most sophisticated compiler in the world to produce good results
[11:13:08 CEST] <atomnuker> no, the rolls-royce, the V8 of processors, the pentium 2
[11:13:34 CEST] <atomnuker> CISC which is really an emulation layer on top of RISC, no sir
[11:14:29 CEST] <atomnuker> a huge chunk of CISC semiconductor slab equipped with an FPU, screaming along at 450 Mhz
[11:15:42 CEST] <atomnuker> you're probably too young to remember but back then when you ordered a processor, you ordered a card which slid onto a long slot in the motherboard
[11:16:09 CEST] <atomnuker> and the card contained a fancy jet black plastic enclosure and a heatsink fused to the processor
[11:17:10 CEST] <atomnuker> it didn't come with a fan because you didn't need one, though there were half-width cooling ribs at the exact width of a fan
[11:17:24 CEST] <atomnuker> so using small wood screws you could hack on a fan
[11:18:23 CEST] <iive> slot1, was it P3 only?
[11:18:49 CEST] <atomnuker> P2 also used a slot, no idea about the original (10 of them) pentium
[11:19:31 CEST] <atomnuker> I miss that +10 kilo PC, its motherboard had a Yamaha-XG FM synthesiser on board
[11:19:47 CEST] <atomnuker> it was an OPL3, so I had the privilege of hearing Doom the way it's meant to be heard
[11:20:26 CEST] <atomnuker> and by a stroke of luck XP could natively address the MIDI synthesiser unlike the SoundBlasters
[12:51:56 CEST] <cone-380> ffmpeg 03Paul B Mahol 07master:b31041adc32f: avfilter: add extrastereo filter
[13:29:09 CEST] <JEEB> did FFmpeg configure follow CC/CXX/CPP environment variables?
[13:29:38 CEST] <JEEB> config.log seems to print out gcc <options> while I was setting CC to gcc-5
[13:30:09 CEST] <nevcairiel> probably not, as we have --cc
[13:30:36 CEST] <JEEB> yeah
[13:30:43 CEST] <JEEB> I just tried that out and it switched it
[13:44:41 CEST] <JEEB> huh, does -g not work with libx265?
[13:49:27 CEST] <JEEB> seems so
[13:49:32 CEST] <JEEB> looking at the libx265 output
[13:49:56 CEST] <JEEB> -g 48 => keyint is still at 250, -x265-params 'keyint=48' => keyint is 48
[14:00:16 CEST] <nevcairiel> JEEB: doesnt appear like its forwarded
[14:00:27 CEST] <nevcairiel> in fact only very little avctx opts are
[14:04:02 CEST] <nevcairiel> which is a shame
[14:16:58 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:5a19bce2ff2b: huffman: use a named identifer for the bits constant
[14:16:59 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:140318c3960d: Merge commit '5a19bce2ff2b61602889392bec747ce81d1e9a1b'
[14:17:16 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:26960aa1cd86: huffman: increase bits constant
[14:17:17 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:b7ce3aefecea: Merge commit '26960aa1cd865e5dc55c67fb2ff9f0629e4d1bda'
[14:18:34 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:741d353ab9cb: huffman: allow specifying nb_bits to ff_huff_build_tree()
[14:18:35 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:ec6b4e21bdfe: Merge commit '741d353ab9cb47fe864e60552bf7b9af7aaa735b'
[14:19:27 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:db9fd1e9af83: fraps: increase vlc nb_bits
[14:19:28 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:94d7060d71b4: Merge commit 'db9fd1e9af83e88bcf2ef40db6a5debf91845c25'
[14:28:02 CEST] <cone-380> ffmpeg 03Luca Barbato 07master:6a6bc43f5f79: dxtory: Factorize slice size checks
[14:28:03 CEST] <cone-380> ffmpeg 03Luca Barbato 07master:a7e6fbd90e62: dxtory: Factorize the buffer loading
[14:28:04 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:696634c5fa58: Merge commit '6a6bc43f5f79587b8936334cc0b3a6616f4807ac'
[14:28:05 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:aa15e233c4cf: Merge commit 'a7e6fbd90e62d3320b1e26d8209fc0f55ee5b0be'
[14:28:58 CEST] <cone-380> ffmpeg 03Vittorio Giovara 07master:599fe93a8403: riff: Add AVj2 fourcc for Avid jpeg2000
[14:28:59 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:80b93f246323: Merge commit '599fe93a840397f551d94db406d0bad42b46b94b'
[14:30:12 CEST] <cone-380> ffmpeg 03Henrik Gramner 07master:3cdda78deb19: checkasm: add unit tests for v210enc
[14:30:13 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:8537e249276b: Merge commit '3cdda78deb19b39dbbf8961ae0aec44dbb19bf6d'
[14:38:50 CEST] <cone-380> ffmpeg 03Luca Barbato 07master:d0f7e4a57fbf: dxtory: Unify and rework the decoding routines
[14:38:51 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:72773203a64a: Merge commit 'd0f7e4a57fbffa0efb204d4274c3dd56fbfff946'
[14:46:14 CEST] <cone-380> ffmpeg 03Martin Storsjö 07master:7cad1bf0759a: mov: Allow more than one keyframe per trun
[14:46:15 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:f4ce8cea7327: Merge commit '7cad1bf0759ada2a1fc3e80bb232a5377dd4fda4'
[14:46:28 CEST] <cone-380> ffmpeg 03Alexandra Hájková 07master:77cf23668991: asfdec: alloc enough space for storing name in asf_read_metadata_obj
[14:46:29 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:8998caf0a4d7: Merge commit '77cf23668991bfd1fb69339f13e1511b4186b7b3'
[14:53:45 CEST] <cone-380> ffmpeg 03wm4 07master:b8b5d8274471: lavu: extend size of the AVPixFmtDescriptor.flags field
[14:53:46 CEST] <cone-380> ffmpeg 03Vittorio Giovara 07master:6b3ef7f08029: lavu: Remove bit packing from AVComponentDescriptor
[14:53:47 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:c734b34b044a: Merge commit 'b8b5d8274471129f122858bc74ad09284dae6ab7'
[14:53:48 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:f53569a93f85: Merge commit '6b3ef7f080293956b2e5212b83135c6b051212e9'
[15:54:59 CEST] <ubitux> so as we user, we can not override the "encoder" format metadata (for muxing)
[15:55:04 CEST] <ubitux> is this on purpose?
[15:55:37 CEST] <ubitux> i see we even explicitely trash it when not bitexact
[15:55:48 CEST] <ubitux> is it because we don't want third party to "own" the name?
[15:56:36 CEST] <ubitux> maybe something like adding " (with Lavf/...)" when encoder meta is set would be OK?
[16:00:40 CEST] <Daemon404> ubitux, oh boy edit lists
[16:01:19 CEST] <ubitux> i didn't push the patchset
[16:01:28 CEST] <Daemon404> i know
[16:01:32 CEST] <Daemon404> but there's a mail about it
[16:01:32 CEST] <JEEB> dun dun dunn
[16:07:36 CEST] <saste> he he talking about "small tasks"
[16:16:44 CEST] <kierank> j-b / Daemon404: http://www.bbc.co.uk/rd/blog/2015/09/vc-2-video-compression-for-production-environmnets
[16:20:08 CEST] <TimNich> Dirac rises
[16:21:53 CEST] <Daemon404> in practicaly, times i will ever have to care about vc-2: none
[16:22:12 CEST] <Daemon404> i see more theora uploaded than dirac, to give you an idea how little it matters
[16:35:52 CEST] <ace040> hello!
[16:35:59 CEST] <ace040> I'm coming from #ffmpeg with a use case about licensing :)
[16:36:30 CEST] <ace040> will copy-paste the stuff from there:
[16:36:46 CEST] <ace040> I am currently developing closed-source/proprietary Windows software that is meant to author video
[16:37:05 CEST] <ace040> files are created and encoded with the help of LGPL-licensed FFmpeg DLLs
[16:37:17 CEST] <ace040> for H.264 support, I need to link a commercially-licensed build of libx264 (also distributed as a DLL) against our FFmpeg build
[16:37:32 CEST] <ace040> so basically I need to build x264 with --disable-gpl and FFmpeg with --enable-libx264 but WITHOUT --enable-gpl (obviously)
[16:37:50 CEST] <Daemon404> i dont think that's legally doable
[16:37:55 CEST] <ace040> the vanilla configure from FFmpeg 2.7.2 does not allow this combination, so what I've done is comment out line 4537 as follows: die_license_disabled gpl libx264 -> #die_license_disabled gpl libx264
[16:37:56 CEST] <Daemon404> you'd need to use the x264 api directly instead
[16:38:03 CEST] <JEEB> well I see jason and BBB agreeing with the LGPL use case
[16:38:06 CEST] <JEEB> in 2010
[16:38:29 CEST] <Daemon404> you cannot link a commercial encoder into an lgpl library legally
[16:39:16 CEST] <JEEB> https://ffmpeg.org/pipermail/ffmpeg-devel/2010-December/083797.html
[16:39:37 CEST] <JEEB> (multiple interpretations löl)
[16:39:54 CEST] <Daemon404> i dont think i agree with that
[16:40:01 CEST] <ace040> ok so I should instead open the stream with libav and feed it to libx264 directly?
[16:40:08 CEST] <JEEB> that's how everyone else so far does it
[16:40:12 CEST] <JEEB> as I noted on #ffmpeg
[16:40:14 CEST] <Daemon404> that would be the least legally-grey, yes
[16:40:22 CEST] <JEEB> I just thought this would be worth another discussion
[16:40:25 CEST] <JEEB> since you brought it up
[16:40:29 CEST] <Daemon404> (waiting for j-b to chime in here with this Strong Opinions)
[16:40:37 CEST] <Daemon404> s/this/his/
[16:40:44 CEST] <JEEB> because it was discussed in 2010 with seemingly positive comments but nothing happened in the end
[16:40:49 CEST] <JEEB> (this was just before the Fork)
[16:40:59 CEST] <Daemon404> JEEB, an opinion doesnt change what a license requries
[16:41:07 CEST] <Daemon404> also IANAL all around
[16:41:07 CEST] <Daemon404> etc
[16:41:09 CEST] <JEEB> yes
[16:41:12 CEST] <JEEB> definitely IANAL
[16:41:28 CEST] <Daemon404> j-b is kind of a lawyer, maybe (pls dont hurt me j-b)
[16:41:31 CEST] Action: Daemon404 hides
[16:41:35 CEST] <j-b> :D
[16:41:41 CEST] <JEEB> I did note that everyone else seems to be doing it a la "like decode with libavcodec, pass to libx264, get stuff from libx264, mux with libavformat"
[16:41:44 CEST] <JEEB> at the moment
[16:42:01 CEST] <JEEB> but I think we need an official decision regarding this since it seems to pop up every now and then with LGPL usage
[16:42:05 CEST] <ace040> sure, I only wanted to know if there was a consensus about this :)
[16:42:05 CEST] <j-b> ace040: you have a x264 license?
[16:42:05 CEST] <cone-380> ffmpeg 03Vittorio Giovara 07master:2268db2cd052: lavu: Drop the {minus,plus}1 suffix from AVComponentDescriptor fields
[16:42:06 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:151aa2ebff51: Merge commit '2268db2cd052674fde55c7d48b7a5098ce89b4ba'
[16:42:45 CEST] <ace040> my company has, yes
[16:43:37 CEST] <j-b> then this is fine.
[16:43:47 CEST] <j-b> Since the libx264.c wrapper is LGPL
[16:44:41 CEST] <ace040> even if we have to patch the configure to feed it --enable-libx264?
[16:44:57 CEST] <j-b> if you only patch the die_license_disabled gpl libx264 line yes
[16:44:59 CEST] <j-b> ONLY that one
[16:45:09 CEST] <j-b> and you compile ffmpeg with --disable-gpl
[16:45:26 CEST] <ace040> yes only line 4537 (in 2.7.2)
[16:45:28 CEST] <j-b> That's as far as FFmpeg is concerned.
[16:45:54 CEST] <j-b> For x264, that's different, though.
[16:46:05 CEST] <dindu> j-b from vlc ?
[16:46:18 CEST] <j-b> ?
[16:46:29 CEST] <dindu> u from vlc forum jb ?
[16:46:42 CEST] <j-b> ace040: if you do that, you do not violate FFmpeg copyright.
[16:46:46 CEST] <j-b> dindu: there is no 2 jb
[16:47:00 CEST] <ace040> --enable-shared --disable-gpl --disable-nonfree --enable-libx264, to be comprehensive
[16:47:17 CEST] <dindu> i see, i got a really interesting Idea,  XDCC streaming to VLC 
[16:47:17 CEST] <Daemon404> j-b, im curious how it is fine to link ffmpeg to a commercial libx264, but not other proprietary libs (e.g. newer msvcrt, your own Special Library, etc.)
[16:47:20 CEST] <dindu> :D
[16:47:34 CEST] <Daemon404> (i dont intend to clog this channel with license discussion,dont worry ;))
[16:47:58 CEST] <j-b> Daemon404: because commercial libx264 is open source.
[16:48:15 CEST] <j-b> Daemon404: the problem with newer msvcrt is different, it's because you need to ship it.
[16:48:27 CEST] <ace040> j-b> maybe I should also bring this up to x264 dev team to be sure
[16:48:36 CEST] <BBB> you are so nice j-b
[16:48:41 CEST] <j-b> ace040: guess who will answer you?
[16:48:46 CEST] <Daemon404> [15:47] <@j-b> Daemon404: because commercial libx264 is open source. <-- only works if the commercial license + source license are OK with lgpl insanity
[16:48:47 CEST] <BBB> without you, the poo guy would need 50 lawyers
[16:49:04 CEST] <j-b> Daemon404: which works in the x264 case.
[16:49:06 CEST] <ace040> ;)
[16:49:07 CEST] <Daemon404> ok
[16:49:10 CEST] <Daemon404> [15:48] <@j-b> Daemon404: the problem with newer msvcrt is different, it's because you need to ship it. <-- why dont you just dl and run teh msvcrt installers, like e.g. games do, during install
[16:49:18 CEST] <Daemon404> most installers grab teh redist
[16:49:20 CEST] <Daemon404> from MS's servers
[16:49:27 CEST] <j-b> Daemon404: because the x264 commercial license is just: "hey, basically, you can consider this as BSD"
[16:49:34 CEST] <Daemon404> ok
[16:49:36 CEST] <BBB> j-b: you should sell your services at a rate of $1000/hour
[16:49:41 CEST] <j-b> Daemon404: it does not matter. You DEPEND on MSVCRT
[16:49:50 CEST] <ace040> BBB> my boss would, I'm just your average programmer ;)
[16:50:01 CEST] <j-b> BBB: I know
[16:50:17 CEST] <BBB> ace040: tell your boss
[16:50:35 CEST] <j-b> Daemon404: if you remove msvcrt90, your program does not work. Therefore your program is a dependency of msvcrt
[16:50:50 CEST] <j-b> Daemon404: however, if you do a Windows 8.1 app, linking to msvcrt120 is 100% ok.
[16:51:01 CEST] <Daemon404> no i get that part.
[16:51:14 CEST] <j-b> Daemon404: compiling with msvc is a different problem than msvcrt, though
[16:51:42 CEST] <j-b> for libfaac and libfdkaac, the issue is that they are not LGPL compatible, while x264-commercial could be.
[16:51:43 CEST] <Daemon404> i dont think any sane person woudl argue you cannot compile with msvcrt.
[16:51:44 CEST] <Daemon404> er
[16:51:47 CEST] <Daemon404> ignore that
[16:51:48 CEST] <Daemon404> reword:
[16:51:49 CEST] <dindu> nobody reads any GLP license or  commercial license , why are you guys fighting when nobody gives a crap about  licenses 
[16:51:51 CEST] <Daemon404> i dont think any sane person woudl argue you cannot compile with msvc.
[16:52:08 CEST] <j-b> Daemon404: sorry, I would argue that in certain case, you cannot.
[16:52:14 CEST] <Daemon404> which case
[16:52:18 CEST] <j-b> And I'm quite sure about it
[16:52:32 CEST] <j-b> Daemon404: let's discuss about that later, because this is off-topic.
[16:52:41 CEST] <Daemon404> "you are not allowed to compile this code with a proprietary compiler" is retarded at best
[16:52:56 CEST] <Daemon404> and literally nobody cares 
[16:53:03 CEST] <Daemon404> feel free to pm the case later :)
[16:53:12 CEST] <j-b> well, it depends on what is brought in by the 'compiler'
[16:53:37 CEST] <iive> there is exception in GPL for system libraries. and you theoretically could use msvcrt from wine.
[16:53:44 CEST] <ace040> actually I forgot to state that I compile both libx264 and FFmpeg with msvc/cl, if that makes a difference
[16:53:48 CEST] <j-b> and in the case of MSVC and MSVC-extensions, it brings code/static-lib you are not allowed to RE, which violates GPL
[16:54:00 CEST] <j-b> iive: see above.
[16:54:23 CEST] <j-b> ace040: you shouldn't, though.
[16:54:40 CEST] <iive> I don't understand what the original problem is.
[16:54:42 CEST] <j-b> ace040: anyway, so now, it depends on YOUR contract with x264 licensing
[16:54:56 CEST] <ace040> j-b> from a legal point-of-view, you mean?
[16:55:00 CEST] <j-b> ace040: yes.
[16:55:48 CEST] <Daemon404> j-b, which static lib which you cannot RE?
[16:56:18 CEST] <j-b> Daemon404: sorry, OffTopic :) and I believe I have an NDA on that.
[16:56:27 CEST] <iive> ffmpeg is LGPL and this allows linking to proprietary code. You just have to provide everything needed to recreate the binary. This includes binary versions of the proprietary code.
[16:56:34 CEST] <Daemon404> j-b, wut?
[16:56:41 CEST] <Daemon404> "it's illegal, trust me" isnt gonna fly
[16:56:49 CEST] <Daemon404> especially on such a ridiculous matter ;)
[16:57:11 CEST] <j-b> Daemon404: let's say for example, C++ amp
[16:57:29 CEST] <j-b> or some resharper tools.
[16:57:42 CEST] <Daemon404> those are very strange subsets
[16:57:48 CEST] <Daemon404> i got the impression you meant *always* with msvc
[16:57:59 CEST] <ace040> iive> that means we have to distribute our msvcrt with the FFmpeg source package?
[16:58:01 CEST] <Daemon404> like e.g. STL, or some C thing
[16:58:29 CEST] <j-b> ace040: ah no, you should not do that
[16:58:37 CEST] <j-b> Daemon404: not always, no.
[16:59:06 CEST] <iive> ace040: msvcrt is system library, it is provided by windows or the compiler.
[16:59:06 CEST] <Daemon404> j-b, i am not surprised then. IIRC, stuff like MFC was very dubious.
[16:59:20 CEST] <Daemon404> iive, that is only true for certain version of msvc, depending on what OS you target
[16:59:26 CEST] <Daemon404> they are not shipped with the OS
[16:59:28 CEST] <j-b> the Windows SDK headers are problematic, though, because of the Oracle/Google thingie
[17:00:02 CEST] <j-b> Daemon404: some versions of MSVC also had quite a bit of code in some headers, and you were not allowed to RE those headers
[17:00:17 CEST] <j-b> which is legalese, but stupid in the real world
[17:00:33 CEST] <j-b> YOU SEE THE CODE, how can you NOT be allowed to RE it?
[17:00:38 CEST] <Daemon404> i'd argue that literallty nobody is going to care if you use a stdlib macro and build with msvc
[17:00:52 CEST] <j-b> I'd argue the same
[17:00:56 CEST] <ace040> j-b> is it okay if, say, we compile a FFmpeg DLL with VS 2012, then provide access to the source package we used along with guidelines that say "we did this and that to compile FFmpeg with VS 2012"?
[17:00:57 CEST] <Daemon404> anywya... im weary of license talk
[17:00:59 CEST] Action: Daemon404 codes
[17:01:17 CEST] <durandal_1707> I'm just going to RE it
[17:01:37 CEST] <j-b> ace040: depends with waht msvcrt do you link to.
[17:02:12 CEST] <ace040> Daemon404> I hate dealing about legal stuff myself, just want to make sure we aren't stealing someone else's work
[17:02:57 CEST] <j-b> ace040: and depends how you link to x264
[17:03:10 CEST] <Daemon404> ace040, then youre better than 99.99% of corporations using ffmpeg and +1 to you
[17:03:41 CEST] <ace040> I speak for myself, not for my company though
[17:03:49 CEST] <durandal_1707> ubitux: when you gona push bool opt?
[17:04:52 CEST] <ubitux> mmh tonight probably
[17:05:01 CEST] <ubitux> i need to test sth raised by nev
[17:05:06 CEST] <ubitux> and i have a bug to fix
[17:05:32 CEST] <ubitux> (you can -opt auto even when it's not in the range)
[17:06:48 CEST] <ace040> j-b> I dunno about my version of msvcrt yet, but as of now I link a dynamic (DLL) build of libx264 against FFmpeg by configure-ing with --enable-libx264 --enable-shared, so basically I have myvideolibrary.dll linked against FFmpeg DLLs, themselves linked against libx264.dll
[17:07:10 CEST] <ace040> I never call libx264 myself (as of now)
[17:08:23 CEST] <BBB> it sounds about right to me
[17:08:36 CEST] <BBB> but I bet you that half of the lawyers in the US would offer to sue you anyway
[17:08:39 CEST] <j-b> ace040: then, if you use the correct msvcrt AND if you don't violate the x264 agreement you have, this is correct.
[17:08:47 CEST] <BBB> (not because youre doing something wrong, but just because they can)
[17:11:33 CEST] <Daemon404> BBB, in the US, half the lawyers would offer to sue you for exisiting at all
[17:11:41 CEST] <Daemon404> litigation is the national passtime
[17:12:09 CEST] <ace040> we're not in the US, but we sell there though
[17:12:11 CEST] <BBB> dude, thats my oxygen that youre breating! I PATENTED IT!!!!
[17:12:33 CEST] <kierank> ace040: the question i have to ask is why you want to use x264 through ffmpeg
[17:12:46 CEST] <ace040> ah yeah, I didn't even talk to the executive team about H.264 patents! :)
[17:13:05 CEST] <BBB> ace040: Im just kidding, I really appreciate that youre trying to do the right thing
[17:13:17 CEST] <BBB> ace040: like daemon404 said, most people dont even bother, they just plain steal
[17:14:10 CEST] <ace040> j-b> could you point me to some details about this msvcrt vs. certain licenses thing?
[17:14:13 CEST] <Daemon404> "a molecule for the inhalation of mammalian beings"
[17:14:16 CEST] <Daemon404> brb patenting
[17:15:16 CEST] <ace040> BBB> sad indeed
[17:15:50 CEST] <j-b> ace040: just link and tell MSVC to compile for XP and don't bring newer msvcrt in.
[17:16:00 CEST] <cone-380> ffmpeg 03Hendrik Leppkes 07master:5d8e836d0ec3: Replace all remaining occurances of step/depth_minus1 and offset_plus1
[17:16:00 CEST] <Daemon404> if youre really lucky, they then try and spread FUD that open source software is all crap, and you should use their awesome proprietary software (which steals ffmpeg)
[17:16:09 CEST] <ace040> kierank> well to be honest I didn't even think twice about it as we need to support several output formats, and FFmpeg is just so damn convenient
[17:16:12 CEST] <Daemon404> j-b, why not vista?
[17:16:13 CEST] <Daemon404> xp is dead.
[17:16:13 CEST] <j-b> Daemon404: like Elemental?
[17:16:18 CEST] <Daemon404> j-b, yes.
[17:16:29 CEST] <j-b> Daemon404: they got bought
[17:16:33 CEST] <Daemon404> (also lol - amazon bought elemental)
[17:16:39 CEST] <j-b> Daemon404: now, we should sue them?
[17:16:47 CEST] <Daemon404> i dont even know what drugs amazon was on
[17:16:52 CEST] <kierank> j-b: they didn't do anything wrong afaik
[17:16:57 CEST] <Daemon404> surely they have more competent people... to know to buy a better company
[17:17:00 CEST] <kierank> their ffmpeg is a bit dubious though
[17:17:10 CEST] <kierank> there's bits of dolby code in there I am sure
[17:17:13 CEST] <Daemon404> kierank, their hevc may be partially ripped off from x264, no?
[17:17:24 CEST] <kierank> some bits of their hevc hrd are similar to what I wrote
[17:17:33 CEST] <kierank> using numbers I plucked out of my arse
[17:18:44 CEST] <j-b> that should be enough to ask 0.01% of their money
[17:18:55 CEST] <ace040> kierank> oh also we need to decode video in a variety of input formats, I keep forgetting that bit! :) so FFmpeg all the way
[17:20:52 CEST] Action: kierank waits for the last IBC parcel
[17:22:25 CEST] <Daemon404> i cant wait for ibc, to learn about all the exciting technologies that will make absolutely no difference in real life.
[17:23:17 CEST] <j-b> kierank: heard about bitcodin, btw?
[17:23:25 CEST] <kierank> what now?
[17:23:35 CEST] <kierank> j-b: help Daemon404 enjoy ibc please
[17:23:49 CEST] <Daemon404> j-b, bitcodin mailed me twice, and followed me on twitter
[17:23:52 CEST] <Daemon404> as did their CEO
[17:24:06 CEST] <nevcairiel> didnt you call them out on their spam
[17:24:23 CEST] <Daemon404> i might have. all the companies who mail me blend together.
[17:24:35 CEST] <kierank> nevcairiel: was me https://twitter.com/obencoder/status/628294591129759744
[17:24:52 CEST] <nevcairiel> ah
[17:25:03 CEST] <Daemon404> also a sign of total legitimacy: changing the name often
[17:25:05 CEST] <kierank> I guess one day I have to make that account "corporate"
[17:25:28 CEST] <ubitux> thx for the feedback!
[17:25:49 CEST] <j-b> 141x realtime wow
[17:26:16 CEST] <j-b> in nothing else than "DASH"
[17:26:31 CEST] <nevcairiel> i forgot what they mailed me about
[17:27:03 CEST] <nevcairiel> apparently i got on their list because i forked the google ExoPlayer project on github, so apparently I must be itnerested in using their DASH services
[17:48:37 CEST] <martijnb> :[ I'm looking forward to ibc, isn't it fine to geek out?
[18:01:13 CEST] <martijnb> as for bitmovin, don't they provide libdash? opensource mpeg dash is nice to have
[18:01:23 CEST] <martijnb> so that's something they contribute at least ;p
[18:03:55 CEST] <cone-380> ffmpeg 03Stefano Sabatini 07master:106cab1152cf: doc/codecs: mention GOP in the g option
[18:03:56 CEST] <cone-380> ffmpeg 03Stefano Sabatini 07master:51c5e924b9e5: doc/codecs: extend documentation for the threads option
[18:03:57 CEST] <cone-380> ffmpeg 03Stefano Sabatini 07master:e25f192d6be8: doc/encoders: add libopenh264 entry
[18:03:58 CEST] <cone-380> ffmpeg 03Stefano Sabatini 07master:ae72b575028d: lavc/libopenh264enc: apply minor consistency fixes to options text
[18:03:59 CEST] <cone-380> ffmpeg 03Stefano Sabatini 07master:309fb6ba2271: lavc/options: extend/fix text for threads and slices options
[18:04:41 CEST] <Daemon404> martijnb, it's just the reference player i think
[18:04:49 CEST] <Daemon404> from DASH-IF
[20:45:54 CEST] <cone-380> ffmpeg 03Paul B Mahol 07master:31c9660b0fab: avfilter/af_ladspa: add special case for 2:2 plugins
[20:51:47 CEST] <cone-380> ffmpeg 03Ganesh Ajjanagadde 07master:c07f493efe23: avfilter/vf_super2xsai: use the name 's' for the pointer to the private context
[21:13:21 CEST] <cone-380> ffmpeg 03Paul B Mahol 07master:84f628470989: avfilter/vf_vectorscope: 9 & 10 bit depth support
[21:43:29 CEST] <andrewrk> so, nodejs and iojs reconciled their forks, and released today
[21:43:35 CEST] <andrewrk> just sayin' ;-)
[22:08:14 CEST] <Daemon404> http://blogs.windows.com/msedgedev/2015/09/08/announcing-vp9-support-coming-to-microsoft-edge/
[22:13:37 CEST] <BBB> I saw that a few days ago
[22:13:38 CEST] <BBB> exciting
[22:13:44 CEST] <BBB> political, also
[22:14:01 CEST] <Daemon404> yes but no support for opus or vorbis
[22:14:02 CEST] <Daemon404> so "webm"
[22:14:07 CEST] <Daemon404> video-only... ?
[22:15:56 CEST] <BBB> it says opus is coming
[22:16:25 CEST] <BBB> http://dev.modern.ie/platform/status/opusaudiocodec/
[22:16:30 CEST] <BBB> Opus Audio Codec
[22:16:30 CEST] <BBB> Under Consideration
[22:16:31 CEST] <BBB> An open codec for audio.
[22:16:32 CEST] <BBB> Roadmap Priority: High  We intend to begin development soon.
[22:16:39 CEST] <BBB> that seems pretty obvious, no?
[22:16:51 CEST] <Daemon404> seems so
[22:17:27 CEST] <BBB> theres also some bla bla on vorbis, but indeed it seems unlikely that that will make it in anytime soon
[22:17:34 CEST] <nevcairiel> libopus isnt too awful either, so its probably not too bad
[22:17:46 CEST] <BBB> which is ok I guess, I mean, opus is supposed to be better and my understanding is that youtube vp9 uses opus
[22:18:20 CEST] <nevcairiel> vorbis is "medium", ogg container is "low"
[22:18:28 CEST] <Daemon404> if it catches on, we get teh pleasure of watchign everyone struggle to make vp9 content
[22:18:31 CEST] <Daemon404> with libvpx
[22:18:36 CEST] <BBB> hahaha
[22:18:39 CEST] <nevcairiel> but if they dont do vp8, then vorbis is pointless as well
[22:18:41 CEST] <BBB> or they just wont use libvpx
[22:18:50 CEST] <nevcairiel> what other encoder is there
[22:19:07 CEST] <BBB> xvp9!!!11123
[22:19:11 CEST] <BBB> :D
[22:20:35 CEST] <Daemon404> i think the more likely thing to happen is people sue libvpx poorly
[22:20:40 CEST] <Daemon404> that is, so it makes worse content than x264
[22:20:44 CEST] <BBB> sue?
[22:20:44 CEST] <Daemon404> (FOR SPEED)
[22:20:46 CEST] <BBB> use?
[22:20:47 CEST] <Daemon404> sue
[22:20:49 CEST] <Daemon404> use
[22:20:51 CEST] <Daemon404> fffff typos
[22:21:03 CEST] <BBB> let me get that picture again
[22:21:11 CEST] <BBB> actually, lets not
[22:21:23 CEST] <BBB> I have some slides on vp9
[22:21:30 CEST] <BBB> they cover that question with actual data
[22:21:45 CEST] <Daemon404> coo
[22:21:45 CEST] <Daemon404> l
[22:21:48 CEST] <BBB> like, real data, not see I can speak words fear my skillz stuff
[22:22:13 CEST] <BBB> I even quote you :)
[22:22:13 CEST] <Daemon404> you would be hard pressed to do a worse job trying to sell me on vp9 than the vp9 team sales person
[22:22:22 CEST] <Daemon404> or whoever kept mailing and calling us
[22:22:39 CEST] <Daemon404> might have been the chrome team.
[22:22:42 CEST] <BBB> maybe it helps that Im technical?
[22:22:50 CEST] <Daemon404> of course.
[22:23:21 CEST] <BBB> anyway, Im obviously still biased, I did participate in the development of vp9, dont forget that
[22:23:37 CEST] <BBB> but I try to be fair, so hopefully it all makes sense
[22:24:36 CEST] <Daemon404> so long as i dont see "twice the quality at half the bitrate!" again
[22:24:57 CEST] <nevcairiel> wasn the claim usually twice the quality or half the bitrate?
[22:24:58 CEST] <BBB> I may have that as claim to prove on my first slide somewhere
[22:25:27 CEST] <BBB> I can remove it if it irritates you :-p
[22:25:30 CEST] <Daemon404> ;p
[22:25:37 CEST] <Daemon404> only if you define quality as purely psnr ;)
[22:25:41 CEST] <BBB> nevcairiel: and, or, its all the same
[22:25:51 CEST] <nevcairiel> its another factor two!
[22:26:04 CEST] <Daemon404> i have also been told that (maybe) vp9's ratecontrol has been improved a lot
[22:26:08 CEST] <BBB> theyre all operators that our technical experts can certainly tell you more about soon[tm]!!12
[22:26:12 CEST] <Daemon404> but i heard that from the daala team, strangely.
[22:26:14 CEST] <jamrial> i think i read it as "same quality at half the bitrate"
[22:26:46 CEST] <Daemon404> j-b, we need someone from v-nova at vdd
[22:26:51 CEST] <Daemon404> purely for troll reasons.
[22:27:22 CEST] <BBB> Daemon404: rate control is a very murky subject, I can go into that a little bit but its a very trollable subject
[22:27:34 CEST] <BBB> vp9s rc is better than vp8s, yes
[22:27:47 CEST] <Daemon404> its hard to be worse than vp8's though
[22:27:52 CEST] <Daemon404> 50% undershoot is not acceptable
[22:27:55 CEST] <Daemon404> (or overshoot)
[22:28:02 CEST] <BBB> wasnt there some bsd licensed h264 encoder patch in ffmpeg one day?
[22:28:07 CEST] <BBB> I bet you it did a worse job
[22:28:19 CEST] <Daemon404> cisco's thing
[22:28:22 CEST] <Daemon404> i dont know how its rc is
[22:28:32 CEST] <BBB> 50% is pretty bad, yes, thats true
[22:28:37 CEST] <BBB> I dont think they fixed that in vp9 per se
[22:28:48 CEST] <BBB> some revisions do a better job at that, but then they suck at the quality aspect of it
[22:28:53 CEST] <BBB> other revisions invert that relationship
[22:28:54 CEST] <Daemon404> weird
[22:28:57 CEST] <BBB> Im not sure which is better
[22:29:06 CEST] <BBB> Id rather have good rate contorl as well as good quality"
[22:29:12 CEST] <Daemon404> i just know i had to use newton's method to compare vpx to other codecs at one point
[22:29:23 CEST] <BBB> I still do that, sadly
[22:29:56 CEST] <llogan> i don't know how to use libvpx
[22:29:58 CEST] <BBB> the problem that Ive seen is that in the revisions with great rate limit adherence (like, within a few %), the quality/bitrate factor goes down by 20% or so
[22:30:03 CEST] <BBB> which is & questionable
[22:30:14 CEST] <Daemon404> BBB, smarter told me all about it once
[22:30:22 CEST] <Daemon404> since he tried to fix it before
[22:30:27 CEST] <BBB> I mean, thats half your gain over x264 gone
[22:30:46 CEST] <BBB> smarter: rly
[22:30:49 CEST] <BBB> smarter: tell me!!!!!
[22:30:59 CEST] <BBB> I would love to understand the actual issue there
[22:31:06 CEST] <Daemon404> not sure if hell remember, this was 1-2 years ago
[22:33:20 CEST] <BBB> so I look at it as a two-way equation, right? a) you have crf encodes, which are optimal for quality comparisons of some sort, but with no factual rate control, and then you have vbr encodes where you try to approximate a rate target limitation in an approximation of a crf
[22:33:27 CEST] <BBB> for 2pass, that shouldnt be hard[tm][r][c]
[22:33:41 CEST] <Daemon404> thats how x264 works, but im not sure linvpx uses that method
[22:33:44 CEST] <BBB> but somehow libvpx struggles enromously with that
[22:33:53 CEST] <BBB> no, I mean, it clearly doesn't
[22:33:55 CEST] <BBB> but it should
[22:34:12 CEST] <Daemon404> i also wonder: does libvpx have any sort of thing like vbv?
[22:34:17 CEST] <Daemon404> or someway to constrain peaks
[22:34:31 CEST] <BBB> yes, theres a few min/max rate % parameters
[22:35:03 CEST] <BBB> --max-intra-rate=<arg>     	Max I-frame bitrate (pct)
[22:35:18 CEST] <BBB> --maxsection-pct=<arg>     	GOP max bitrate (% of target)
[22:35:28 CEST] <BBB> --overshoot-pct=<arg>      	Datarate overshoot (max) target (%)
[22:35:37 CEST] <BBB> thats about it, I think
[22:35:47 CEST] <Daemon404> i like how theyre all percents, but they all use wildly different notations
[22:35:52 CEST] <kierank> Daemon404: http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=106202&PageNum=2
[22:35:55 CEST] <kierank> j-b: ^
[22:36:01 CEST] <kierank> x264 derivative anyone...
[22:37:21 CEST] <kierank> "IQ264 is currently built on top of x264"
[22:38:03 CEST] <BBB> Daemon404: yeah its & a little clunky
[22:38:23 CEST] <Daemon404> kierank, wait... IQ?
[22:38:23 CEST] <Timothy_Gu> kierank: doesn't that mean that it must be gpl?
[22:38:28 CEST] <Daemon404> as in former EuiclidIQ?
[22:38:30 CEST] <Daemon404> and 50 other names?
[22:38:35 CEST] <kierank> yes
[22:38:40 CEST] <Daemon404> for fuck's sake
[22:38:45 CEST] <Daemon404> they changed name AGAIN
[22:38:51 CEST] <Daemon404> right after we rejected them (again)
[22:39:04 CEST] <kierank> EuclidIQ
[22:39:06 CEST] <kierank> still is that
[22:39:07 CEST] <Daemon404> theyre super sketchy, and wont even let us test outselves
[22:39:19 CEST] <Daemon404> they will only send us "Results"
[22:39:36 CEST] <Daemon404> we told them to sod off for a Nth time then.
[22:39:54 CEST] <Daemon404> (to be clear: no time was wasted on them)
[22:56:09 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:9117748cff55: avutil/opt: add AV_OPT_TYPE_BOOL
[22:56:22 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:a6da2fec7c76: avcodec/aacenc: use AV_OPT_TYPE_BOOL
[22:56:38 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:a68d6cf5b472: avdevice/dshow: use AV_OPT_TYPE_BOOL
[22:56:55 CEST] <ubitux> git is so sloooow
[22:57:00 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:ae32c9916d5b: avfilter/kerndeint: use AV_OPT_TYPE_BOOL
[22:57:08 CEST] <ubitux> i'm stall in git push since about two minutes
[22:57:12 CEST] <ubitux> +ed
[22:57:24 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:c97cd1169c55: swscale: use AV_OPT_TYPE_BOOL
[22:57:43 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:266997504dea: avfilter/dynaudnorm: use AV_OPT_TYPE_BOOL
[22:57:52 CEST] <ubitux> are the git hooks parsing the universe?
[22:58:00 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:2f4e2356bc31: avfilter/deband: use AV_OPT_TYPE_BOOL
[22:58:14 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:f790b54d98be: avfilter/interlace: use AV_OPT_TYPE_BOOL
[22:58:38 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:0b93c6d83167: avfilter/interlace: fix opt flags
[22:58:59 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:9571a56009f3: avutil/opt: refactor pixel/sample fmt common case
[23:00:06 CEST] <Daemon404> ubitux, where can i find universe.y
[23:00:37 CEST] <ubitux> git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg
[23:00:39 CEST] <ubitux> here
[23:02:52 CEST] <ubitux> durandal_1707: feel free to add boolz everywhere
[23:04:35 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07release/2.8:1d42df72926c: Add NOA credits
[23:05:07 CEST] <llogan> wot is the story behind the NOA stuff?
[23:05:12 CEST] <cone-380> ffmpeg 03hSÇ 07release/2.8:0752e44b1f0f: avcodec: loongson delete invalid simple idct put and add optimization
[23:05:13 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:2d7726f7ab6c: avfilter/rotate: use AV_OPT_TYPE_BOOL for bilinear option
[23:05:51 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07release/2.8:d86c5f8de865: RELEASE_NOTES based on 2.7
[23:06:18 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07release/2.8:b72c184194b9: avcodec/h264_sei: Remove "Subtitles with data type 0x%02x" sample request
[23:07:37 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:1457610d87a0: avfilter/asetnsamples: use AV_OPT_TYPE_BOOL for pad with zeros option
[23:09:13 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:816cfd00cb61: avfilter/astats: use AV_OPT_TYPE_BOOL for metadata option
[23:12:54 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:fad084186957: avfilter/asyncts: use AV_OPT_TYPE_BOOL for compensate option
[23:14:34 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:6d79aae63c95: avfilter/extrastereo: use AV_OPT_TYPE_BOOL for clipping option
[23:17:14 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:5c64ae64bde8: avfilter/silenceremove: use AV_OPT_TYPE_BOOL for leave_silence option
[23:17:27 CEST] <Daemon404> for a sec i thought NOA = nintendo of america
[23:20:07 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:ed28dd63018b: avfilter/volume: use AV_OPT_TYPE_BOOL for replaygain_noclip option
[23:20:08 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:34201fcf7402: avfilter/volume: fix missing filtering flags for a bunch of options
[23:21:37 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:cb8d71734ca1: avfilter/volume: drop useless trailing comma
[23:22:42 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:b6249d4f5297: avfilter/flite: use AV_OPT_TYPE_BOOL for list_voices option
[23:24:42 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:9f4b3bd96c4d: avfilter/concat: use AV_OPT_TYPE_BOOL for unsafe option
[23:24:58 CEST] <Daemon404> one day the push will finish
[23:25:20 CEST] <ubitux> oh i switched to one at a time :)
[23:25:29 CEST] <ubitux> it's me being slow now ;)
[23:27:10 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:af0945d912a1: avfilter/showcqt: use AV_OPT_TYPE_BOOL for fullhd option
[23:27:22 CEST] <BBB> michaelni: please dont add sponsorship notices to the copyright header
[23:27:29 CEST] <BBB> michaelni: that should be in its own comment block
[23:30:53 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:286d625b43bd: avfilter/showvolume: use AV_OPT_TYPE_BOOL for channel name displaying option (t)
[23:32:27 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:b599d2164251: avfilter/showwaves: use AV_OPT_TYPE_BOOL for split_channels option
[23:35:22 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:e73f46b105d5: avfilter/abuffersink: use AV_OPT_TYPE_BOOL for all_channel_counts option
[23:38:50 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:728eff9e38e5: avfilter/ebur128: use AV_OPT_TYPE_BOOL for metadata option
[23:44:56 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:7a29d10839f0: avfilter/blend: use AV_OPT_TYPE_BOOL for shortest and repeatlast options
[23:47:04 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:fa83b551610d: avfilter/crop: use AV_OPT_TYPE_BOOL for keep_aspect option
[23:49:11 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:96dbc5bdf9f5: avfilter/decimate: use AV_OPT_TYPE_BOOL for ppsrc and chroma options
[23:49:54 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:ee4f0ec0cd33: avfilter/delogo: use AV_OPT_TYPE_BOOL for show option
[23:52:39 CEST] <philipl> https://blogs.windows.com/msedgedev/2015/09/08/announcing-vp9-support-coming-to-microsoft-edge/
[23:52:42 CEST] <philipl> Well, that's huge.
[23:52:45 CEST] <philipl> vp9 in dxva...
[23:56:06 CEST] <jamrial> what gpus currently support hardware decoding of vp9?
[23:58:14 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:97692ef1ba80: avfilter/deshake: use AV_OPT_TYPE_BOOL for opencl option
[23:58:15 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:1cab6a33cd5b: avfilter/drawtext: use AV_OPT_TYPE_BOOL for a few options
[23:59:32 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:e1d24e6c1ec2: avfilter/elbg: use AV_OPT_TYPE_BOOL for pal8 option
[23:59:54 CEST] <philipl> jamrial: nvidia.
[00:00:00 CEST] --- Wed Sep  9 2015