[00:04:10 CEST] <nevcairiel> rcombs: just update to fixed mingw instead of doing other crazyness [00:04:28 CEST] <nevcairiel> its fixed in both trunk and latest 4.0 release [01:54:26 CEST] <cone-360> ffmpeg 03Michael Niedermayer 07master:89e939302237: doc/developer.texi: Add a code of conduct [08:15:56 CEST] <Zeranoe> Can someone explain why MFX_EXTBUFF_CODING_OPTION_* are being set? From what I can find they are specific to different usage situations (none of which FFmpeg is doing), and yet FFmpeg is enabling several. [08:36:06 CEST] <Zeranoe> In fact, I'm not even sure why any q->param.ExtParam are being set. [10:37:14 CEST] <BtbN> because that Quick Sync stuff is a giant mess. [10:37:28 CEST] <BtbN> Or am I confusing MFX and MXF again? [10:40:00 CEST] <nevcairiel> the extparams are fine though, there is no other way to set some of these parameters [10:40:58 CEST] <nevcairiel> which is mostly about some SEI info [13:38:45 CEST] <cone-367> ffmpeg 03Paul B Mahol 07master:d93495c95411: avcodec/vble: add frame threading support [14:27:24 CEST] <Zeranoe> nevcairiel: They aren't fine... This bug http://trac.ffmpeg.org/ticket/5324 is a result of them all being enabled without checking if the hardware actually supports it. [14:29:24 CEST] <nevcairiel> saying they are al useless and wrong because some hardware doesnt support one of them is unnecessary hyperbole [14:29:45 CEST] <nevcairiel> but qsv is crap either way, on the driver side already [14:38:20 CEST] <nevcairiel> anyway we wait for your patches [14:50:18 CEST] <jkqxz> Maybe it should be renamed to emphasise that it's not the only way to use the Quick Sync hardware. It's a somewhat dubious external proprietary library with annoying setup, and you may well be better off using other methods (dxva2/d3d11, vaapi, videotoolbox; mf if anyone wanted to write the code for it). [14:54:59 CEST] <andrey_turkin> yes on decoder side. On encoder side vaapi probably should work on Linux but no alternatives on Windows [14:59:21 CEST] <jkqxz> Hence mf, if someone wants to write it. [15:37:36 CEST] <nevcairiel> if mf is media foundation, that just ends up using libmfx/qsv in the backend once again through another layer of abstraction [15:38:05 CEST] <nevcairiel> I've seen all sorts of qsv implementations crap out on various hardware with various drivers [15:38:10 CEST] <nevcairiel> just hanging or crashing [15:42:16 CEST] <BtbN> QSV on Windows is fine [15:42:37 CEST] <BtbN> QSV on Linux is a horrible hack that should be removed from ffmpeg, specialy now as vaapi encoding is supported. [15:43:21 CEST] <BtbN> did 3.0 release with QSV stuff, or did it come after that? [15:50:21 CEST] <jkqxz> I was indeed meaning media foundation. It gains through allowing NVENC and AMDwhatever as well, even if the Quick Sync is the same as libmfx. [15:51:08 CEST] <BtbN> Well, NVENC is natively support already, as well as QSV. [15:51:28 CEST] <BtbN> So why add another layer of indirection that just potentially causes even more trouble? [15:52:18 CEST] <BtbN> Zeranoe, btw., do your builds come with nvenc support? [16:26:08 CEST] <RiCON> BtbN: yes, since last two builds [16:33:59 CEST] <andrey_turkin> that is cool [17:41:34 CEST] <Zeranoe> nevcairiel: They aren't useless, but the way FFmpeg is using QSV makes them useless. Those args are for specific use situations, not to be enabled for every encode. I'm working on a patch. [17:42:27 CEST] <Zeranoe> And I agree with QSV not being ideal, but some people use it and enjoy it and I believe it should work as best it can. [18:36:55 CEST] <cone-367> ffmpeg 03foo86 07master:a0f76b825c81: avcodec/dca: move EXSS sampling frequency arrays to dca.c [19:08:01 CEST] <cone-367> ffmpeg 03Michael Niedermayer 07master:7f5c6ea51102: avformat/utils: Fix use of uninitialized variable [19:39:02 CEST] <Zeranoe> Did something recently happen with VP9? [19:40:27 CEST] <Zeranoe> Not sure why it isn't being included in the newer builds... I don't think anything changed on my end [20:28:06 CEST] <omerjerk> Hi [20:28:19 CEST] <omerjerk> I've some doubts regarding the SoftFloat api in ffmpeg. [20:28:26 CEST] <omerjerk> anyone online ? [20:49:37 CEST] <Compn> omerjerk : wait around for answer :) [20:49:40 CEST] <Compn> not everyone online atm [20:49:42 CEST] <Compn> idleing [20:50:49 CEST] <omerjerk> okay. :) [20:51:13 CEST] <durandal_1707> omerjerk: yes? [20:52:30 CEST] <omerjerk> So carl previously suggested to use SoftFloat api instead of this - https://github.com/omerjerk/FFmpeg/blob/float/libavcodec/alsdec.c#L296 [20:53:10 CEST] <omerjerk> I've a float here - https://github.com/omerjerk/FFmpeg/blob/float/libavcodec/alsdec.c#L1762 [20:53:24 CEST] <omerjerk> I need to convert this normal float value to a SoftFloat object. [20:53:32 CEST] <omerjerk> I'm not getting how to do that. [20:53:53 CEST] <omerjerk> There's no function in the SoftFloat.h file to convert from float to SoftFloat [20:54:06 CEST] <omerjerk> durandal_1707 [21:19:20 CEST] <omerjerk> durandal_1707: Are you there > [21:19:22 CEST] <omerjerk> ? [21:19:39 CEST] <durandal_1707> no [21:22:02 CEST] <durandal_1707> omerjerk: av_int2sf [21:23:12 CEST] <durandal_1707> You must not use float type directly [21:23:46 CEST] <omerjerk> durandal_1707: so I should do av_float2int first to convert the float to int and then pass it to the function you mentioned, right ? [21:24:22 CEST] <ubitux> https://twitter.com/whitequark/status/735882229889409025 [21:24:24 CEST] <durandal_1707> no your code should not have float word [21:26:04 CEST] <durandal_1707> ubitux: great! [21:29:59 CEST] <omerjerk> durandal_1707: Any tip on how do I avoid the float here ? - https://github.com/omerjerk/FFmpeg/blob/float/libavcodec/alsdec.c#L1762 [21:31:01 CEST] <omerjerk> scale = 2^23 [21:34:34 CEST] <durandal_1707> omerjerk: convert scale to softfloat [21:56:10 CEST] <durandal_1707> I don't trust c++ apps [22:12:59 CEST] <andrey_turkin> why not? [22:14:50 CEST] <durandal_1707> have you looked at their binary? [22:16:33 CEST] <andrey_turkin> yeah [23:12:25 CEST] <BBB> jamrial_: Ill try to attend (its noon EST, right?) [23:13:12 CEST] <BBB> if (temp_pcm.f != 0.f || temp_pcm.f != -0.f) { <- isnt that the same as if (1) { ? [23:14:21 CEST] <jamrial_> BBB: 5pm UTC, so i think that's 1pm EST [23:14:51 CEST] <BBB> youre right, tx [23:15:19 CEST] <andrey_turkin> probably should be && [23:31:50 CEST] <drv> doesn't 0.0f == -0.0f anyway by IEEE 754 rules? [23:36:43 CEST] <andrey_turkin> looks that way. Maybe there's something to do with subnormal numbers? [23:37:03 CEST] <andrey_turkin> or just an error [23:51:22 CEST] <kierank> BBB: not sure what you read into my comment on #libav-devel, just giving an example to koda of who would play prores on arm32 [23:51:49 CEST] <BBB> I dont think Im ont hat channel [23:51:58 CEST] <kierank> sorry the ML [23:51:58 CEST] <BBB> oh, the ML? [23:52:38 CEST] <BBB> I dont think we should focus on existential questions like who would play prores on arm32" [23:53:03 CEST] <BBB> I think we should figure out why some part of the bitstream reader (that is apparently more predominant in some decoders than in others) got slower on 32bit [23:53:34 CEST] <kierank> I agree [00:00:00 CEST] --- Fri May 27 2016