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

[burek]

[00:17:54 CET] <Compn> durandal_1707 : i got quicktime off of my mac friend, but the .app mostly consisted of icons, not codec components :\
[00:17:59 CET] <Compn> it installs somewhere else
[00:18:23 CET] <Compn> durandal_1707 : so you can debug mac binaries ok? :P
[00:22:09 CET] <cone-869> ffmpeg 03Philip Langdale 07master:fdb124001e9a: tools/coverity: Add model for av_realloc
[00:22:33 CET] <philipl> Tool is avilable but I won't refresh coverity until we want to use up that scan.
[00:24:27 CET] <philipl> I think we can rerun the scan. The faq specifically says "frequency for build submissions"
[00:24:30 CET] <philipl> This is not a new build
[00:24:48 CET] <philipl> there's already a daily max of 1 that didn't complain just now
[00:25:24 CET] <BtbN> probably, might be a loophole or something
[00:25:31 CET] <BtbN> Even if, it makes sense to fix all those false positives
[00:26:26 CET] <philipl> Done.
[00:26:34 CET] <philipl> I'm sure this isn't what they're limiting.
[00:42:29 CET] <BtbN> but evaluating that is the computational complex stuff
[00:42:35 CET] <philipl> and yet.
[00:42:43 CET] <philipl> You'd think uploads would be the unlimited thing
[00:43:33 CET] <philipl> I can only imagine there's a bunch of work they do to an upload to make it possible to run the analysis
[00:43:34 CET] <BtbN> I'd think the actual analysis would be the limited thing, no matter what triggers it
[00:43:38 CET] <philipl> and that is the work they feel is limited.
[00:44:07 CET] <philipl> anyway. we're down to 81 now
[00:44:47 CET] <philipl> and it did finally silence the cuvid one, funnily enough
[00:45:08 CET] <BtbN> I silenced that.
[00:45:13 CET] <BtbN> By marking it as false positive
[00:45:16 CET] <philipl> ah. well, never mind.
[00:45:49 CET] <philipl> No, I mean the av_mallocz one
[00:45:52 CET] <philipl> It's not in the list anymore.
[00:45:59 CET] <philipl> All this modelling shit did actually help.
[00:46:14 CET] <BtbN> Isn't that what marking it as handled and false positive does?
[00:46:32 CET] <philipl> But in the last analysis, it was there.
[00:46:34 CET] <philipl> This is the same build.
[00:47:01 CET] <philipl> the ffmpeg_cuvid.c one
[00:47:08 CET] <BtbN> yeah, that's the one I marked.
[00:47:09 CET] <philipl> which is what provoked me to do all this in the first place.
[00:47:13 CET] <philipl> Not in my tree.
[00:47:23 CET] <philipl> or you marked it in the web ui?
[00:47:25 CET] <philipl> sorry.
[01:04:30 CET] <cone-869> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:b5c899ab5ec8: ffserver: fix broken HTML on generated status page
[01:15:05 CET] <cone-869> ffmpeg 03Philip Langdale 07master:5512dbe37f83: avcodec/crystalhd: Handle errors from av_image_get_linesize
[01:15:06 CET] <cone-869> ffmpeg 03Philip Langdale 07master:4e6d1c1f4ec8: avcodec/vdpau_hevc: Fix potential out-of-bounds write
[05:32:03 CET] <Timothy_Gu> Compn: the codec components are OS-wide
[06:52:46 CET] <xintox> does anyone know what these "sdk://" urls are in some m3u8 streams I'm seeing?
[06:52:50 CET] <xintox> I can't find anything online about it
[09:54:56 CET] <cone-966> ffmpeg 03Carl Eugen Hoyos 07master:d44af9a38e6b: lavfi: Fix aix compilation.
[10:46:05 CET] <durandal_1707> cbsrobot: could you generate some pixlet videos/samples of bigger video size?
[12:02:18 CET] <cone-966> ffmpeg 03Tobias Rapp 07master:4d57ca51d7af: ffmpeg: assert return value is initialized
[12:54:11 CET] <cone-966> ffmpeg 03;5:A0=4@ !;>1>45=N: 07master:3aa1ff30f3f4: doc/examples/transcode_aac: fix a typo
[18:00:51 CET] <J_Darnley> Gramner: when you have a moment, could you take a look at the patches I just sent?
[18:01:06 CET] <J_Darnley> The last two in particular.
[18:01:39 CET] <J_Darnley> They provide little to no benefit over the C
[18:16:18 CET] <kierank> maybe BBB can help you too
[18:17:13 CET] <BBB> 422 deblock?
[18:20:47 CET] <BBB> is it possible the C function just skips most deblocks?
[18:21:04 CET] <BBB> this happens particularly at very low quantizers (high quality) and is something the simd code typically doesnt implement
[18:21:24 CET] <BBB> (it can be implemented with pmovmksb and mask-conditionals, but I dont think it does)
[18:21:47 CET] <BBB> check tc/tc0 in the C code
[18:24:19 CET] <BBB> pmovmskb apparently
[18:24:20 CET] <BBB> anyway
[18:24:38 CET] <BBB> note that the instruction is very slow so you typically want to not use it
[18:25:56 CET] <J_Darnley> Thanks, I will have a look there.
[18:48:07 CET] <Gramner> J_Darnley: I don't see any point in adding new mmx code where sse2 versions are implemented
[18:50:16 CET] <Gramner> SSE2 is 15 years old, anyone using a cpu older than that obviously doesn't care about performance anyway
[18:54:47 CET] <Gramner> also is the deblock code still using int strides or are the comments simply outdated? while not strictly related to the patches that's something that should be fixed if so because I can spot several bugs in both the new and existing code where the upper half of 32-bit ints are assumed to be zero on 64-bit systems
[19:22:55 CET] <J_Darnley> Yes, int strides
[19:23:22 CET] <J_Darnley> int as argument to the dsp function, int as argument to the calling function.
[19:25:07 CET] <J_Darnley> As for mmx, you have a point regarding its age.
[19:39:28 CET] <ElAngelo> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203661.html
[19:39:34 CET] <ElAngelo> could somebody plz review this?
[19:43:56 CET] <Compn> ElAngelo : sure
[19:48:26 CET] <ElAngelo> much appreciated Compn 
[19:59:23 CET] <Compn> sent
[20:00:05 CET] <Compn> ElAngelo : you have the avid codecs? or just the av1x codec ?
[20:00:21 CET] <Compn> theres a bunch of different ones, i wonder if you could make us samples for each avid codec...
[20:07:38 CET] <ElAngelo> Compn: i only uploaded a sample with av1x
[20:07:44 CET] <ElAngelo> i don't have any others :s
[20:08:02 CET] <ElAngelo> this is not something i created myself btw
[20:08:47 CET] <Compn> ah ok no problem. just thought i would ask :)
[20:09:03 CET] <Compn> sometimes it is difficult for us to install every codec on earth to get samples , so i ask :)
[20:09:22 CET] <ElAngelo> of course
[20:09:37 CET] <wm4> whoever applies this should run fate first
[20:09:40 CET] <ElAngelo> i still don't really the issue i'm seeing actually
[20:10:02 CET] <ElAngelo> what is 'multiple fourcc' ?
[20:10:05 CET] <Compn> im surprised that patch fixes things
[20:10:21 CET] <Compn> well in mov its technically isom :D
[20:10:50 CET] <ElAngelo> i've tested the patch with the original movie i took an extract from and it worked for me
[20:10:53 CET] <Compn> but it means that the encoder writes different or multiple isom (fourcc) track names
[20:10:54 CET] <ElAngelo> ymmv
[20:11:16 CET] <Compn> so it confuses ffmpeg because are we supposed to decode under one fourcc or the other 
[20:11:41 CET] <ElAngelo> aha, that's why i saw a black output only at first?
[20:11:46 CET] <Compn> i think so
[20:44:00 CET] <cone-361> ffmpeg 03Michael Niedermayer 07master:fbdf8f176e0f: ffserver: set format bitexact flag, eliminate warnings about it not being set
[21:43:23 CET] <cone-361> ffmpeg 03Paul B Mahol 07master:6427c9ffee34: swscale: add gbr(a)p16 output support
[21:46:08 CET] <BtbN> Timothy_Gu, philipl, regarding the travis thing, I think the most sensible thing would be creating an FFmpeg/Coverity repository on Github, link it to Travis, and then use this: https://docs.travis-ci.com/user/cron-jobs/
[21:46:18 CET] <BtbN> That way it does not depend on any actual hardware.
[21:47:05 CET] <BtbN> would be set to daily, and then need a bit of logic to only run on certain days a week, but that should be trivial
[21:48:05 CET] <philipl> BtbN: why not link it to the actual repository? because travis isn't actually caring about the ffmpeg source itself
[21:48:33 CET] <BtbN> well, if the coverity travis.yml is ok to be in the ffmpeg repo itself, that works as well
[21:48:56 CET] <philipl> Anyway - it seems fine to use cron to trigger runs.
[21:49:02 CET] <philipl> Then no one has to push to a branch
[21:49:17 CET] <BtbN> Yes, just set the cronjob to build the FFmpeg/FFmpeg github repo daily
[21:49:25 CET] <BtbN> and the rest will be magic in the travis.yml
[21:49:28 CET] <philipl> Daily? four times a week :-)
[21:49:36 CET] <BtbN> It only supports Daily, Weekly or Monthly.
[21:49:48 CET] <BtbN> So Daily it is, and just return early with a day-of-week check
[21:50:31 CET] <philipl> Ok. We could also just say weekly and it would still be a big improvement. and we'd have the other runs for ad-hoc purposes.
[21:50:40 CET] <philipl> but I'm fine starting the way you described.
[21:50:44 CET] <BtbN> Might as well use the 4 builds a week we have
[21:51:05 CET] <BtbN> It's not a lot of work, I'll set up the .travis.yml, and commit it
[21:51:44 CET] <BtbN> http://www.travis.org/ uhm, ok... that's not the page I wanted to end up on, Thank you smart auto complete
[21:53:01 CET] <philipl> Did anyone know this oss-fuzz thing was coming?
[21:53:11 CET] <philipl> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
[21:53:29 CET] <philipl> I mean, we know they've been doing it internally for ages.
[22:13:49 CET] <BtbN> philipl, do you have access to the FFmpeg github org, so you can setup builds for FFmpeg/FFmpeg, turn off builds on pushes and PRs, and then request the ability to use crons on it?
[22:15:03 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/cdc4228288bc4f799e7280681670827489a8041f
[22:20:46 CET] <cone-361> ffmpeg 03Paul B Mahol 07master:6e713841e830: avfilter: add premultiply filter
[22:24:07 CET] <BBB> re: gaps, why not just fill in the missing ones?
[22:24:09 CET] <BBB> seems relatively trivial
[22:24:16 CET] <BBB> (wheres koda)
[22:24:35 CET] Action: durandal_170 agrees
[22:47:02 CET] <nevcairiel> Those missing ones are reserved values
[22:47:26 CET] <nevcairiel> And the other related enums can also have gaps
[23:10:39 CET] <BBB> sooo useful
[23:10:40 CET] <BBB> bleh
[23:11:46 CET] <atomnuker> I think a table to map the values would be better
[23:13:14 CET] <nevcairiel> Following the standard seems fine to me. What's wrong with gaps, anyone that used thr NB element for anything was doing it wrong already anyway
[23:14:45 CET] <wm4> indeed
[23:15:45 CET] <Compn> because we support non-standard stuff too? :P
[23:15:47 CET] <wm4> looking at hevc, it uses 8 bit for the corresponding bitstream fields
[23:16:01 CET] <wm4> maybe it's safe to put non-standard stuff at starting at 256
[23:16:13 CET] <nevcairiel> It never happened in years of multimedia Compn :p
[23:16:16 CET] <Compn> philipl : probably because a lot of bugs /.exploits found have been done with fuzzers. so the only way to fix this is to fuzz it first? 
[23:16:32 CET] <Compn> we have a fuzz gap.
[23:16:52 CET] <wm4> oh lol
[23:16:57 CET] <wm4> the hevc decoder uses the NB fields
[23:17:03 CET] <wm4> to "validate" the values
[23:17:08 CET] <nevcairiel> Many things do
[23:17:18 CET] <wm4> so much for "ABI"
[23:17:31 CET] <wm4> not even ffmpeg itself can follow it
[23:17:35 CET] <nevcairiel> IIRC it used to be in avcodec
[23:17:38 CET] <wm4> yes
[23:17:44 CET] <nevcairiel> When it was moved these became bugs
[23:17:48 CET] <nevcairiel> Before it was fine
[23:17:51 CET] <wm4> but before hevc was merged I think?
[23:17:56 CET] <wm4> (not sure)
[23:18:35 CET] <wm4> I think it was even me who moved it... makes this anti-ABI argument weaker for me to use
[23:20:09 CET] <wm4> no, it was after hevc was merged
[23:20:14 CET] <wm4> blergh.
[23:43:38 CET] <cone-361> ffmpeg 03Gregory J. Wolfe 07master:9c041a3cd506: avformat/tests/fifo_muxer: includes libavformat/network.h to define ETIMEDOUT for fate build.
[23:43:39 CET] <cone-361> ffmpeg 03Michael Niedermayer 07master:89092fafdde8: tests/ffserver.regression.ref: Update ffserver checksums
[00:00:00 CET] --- Fri Dec  2 2016