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

[burek]

[00:51:47 CET] <cone-426> ffmpeg 03Marton Balint 07master:7b8445f03d10: tools: add loudnorm script example to use loudnorm
[00:51:48 CET] <cone-426> ffmpeg 03Marton Balint 07master:005d058f4230: lavfi/loudnorm: add an internal libebur128 library
[01:38:27 CET] <cone-426> ffmpeg 03Andreas Cadhalpun 07master:360bc0d90aa6: smvjpegdec: make sure cur_frame is not negative
[01:38:28 CET] <cone-426> ffmpeg 03Andreas Cadhalpun 07master:484151df7c8f: pnm: limit maxval to UINT16_MAX
[01:38:29 CET] <cone-426> ffmpeg 03Andreas Cadhalpun 07master:cdb5479c9ddc: pnmdec: make sure v is capped by maxval
[01:45:57 CET] <nevcairiel> hours later i finally foudn the reason why cuda just wouldnt link, configure wasnt setup properly =p
[01:46:16 CET] <nevcairiel> no idea how everyone else used it, probably by generating their own new import libraries without wondering why its not working?
[01:51:37 CET] <philipl> BtbN: merge your dynlink changes so nevcairiel doesn't have to suffer :-)
[01:52:33 CET] <nevcairiel> i fixed it
[01:52:37 CET] <nevcairiel> see ml
[02:04:41 CET] <philipl> jolly good
[02:05:12 CET] <nevcairiel> no idea how to make it work with mingw though
[02:15:45 CET] <RiCON> the import libs from the sdk work with 64-bit
[02:15:53 CET] <RiCON> the one time i tried with 32-bit, not so much
[02:16:04 CET] <nevcairiel> should work now with msvc
[02:16:17 CET] <nevcairiel> well "now" with the ml patch
[02:19:53 CET] <nevcairiel> x64 is easier since there is only one calling convention, so it cant mis-match
[03:23:27 CET] <cone-426> ffmpeg 03Michael Niedermayer 07master:04bd1b38ee6b: avcodec/htmlsubtitles: Fix reading one byte beyond the array
[10:16:31 CET] <cone-875> ffmpeg 03Robert Nagy 07master:c0dc9df2cc63: increment initial_prog_date_time when removing old segments
[11:19:26 CET] <BtbN> nevcairiel, that's strange. I tested it with CUDA 8 on MSVC x64 plenty of times, never had any issues
[11:19:35 CET] <nevcairiel> x64 is different
[11:19:44 CET] <nevcairiel> it has no different calling conventions
[11:19:48 CET] <nevcairiel> which is what breaks it here
[11:19:53 CET] <nevcairiel> try x86
[11:25:58 CET] <BtbN> hm, I wonder if dynloading also fails then, or if GetProcAddress is smart enough to resolve the correct symbol. I never tried it on x86
[11:26:20 CET] <nevcairiel> that should be fine, i think
[11:26:35 CET] <nevcairiel> since it uses the dll, and not the import library
[00:00:00 CET] --- Sun Nov 13 2016