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

[burek]

[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