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

[burek]

[00:13:49 CET] <philipl> BtbN: No. I don't. It's possible only michaelni has admin on github
[00:19:57 CET] <J_Darnley> What's the usual way to configure ffmpeg to build as 32-bit on a 64-bit linux?  Pass -m32 or something to --extra-cflags?
[00:21:59 CET] <BtbN> Setting CC to gcc -m32 also works
[00:22:19 CET] <BtbN> no idea what's the right place though
[00:23:14 CET] <michaelni> philipl, Timothy_Gu and lou should also have admin access to github but if its something simple i can do it too ?
[00:26:22 CET] <Shiz> setting CC is the 'correct' approach
[00:26:29 CET] <Shiz> because it's a fundamental option that changes the compiler's nature
[00:26:41 CET] <Shiz> the proper solution is to have a 32-bit cross-compiler though because multilib is broken
[00:26:51 CET] <J_Darnley> Okay, thanks for the imput.
[00:27:27 CET] <J_Darnley> On windows I'd just set the right compiler so I guess I'll do the same here.
[00:30:02 CET] <J_Darnley> Ah.  I can't use the byte-sized register there.
[00:35:38 CET] <philipl> michaelni: good to know. BtbN needs to do some stuff for travis.
[00:40:26 CET] <michaelni> BtbN, ive added you to the travis admins group on ffmpeg github, well rather invited it seems
[00:47:07 CET] <cone-361> ffmpeg 03Michael Niedermayer 07release/2.8:046cc06f5a23: avformat/idroqdec: Check chunk_size for being too large
[00:47:08 CET] <cone-361> ffmpeg 03Michael Niedermayer 07release/2.8:46edc6d5ef24: avcodec/flac_parser: Update nb_headers_buffered
[01:23:01 CET] <atomnuker> BtbN: google is offering continuous project fuzzing here: https://github.com/google/oss-fuzz#accepting-new-projects
[01:26:23 CET] <atomnuker> oh wait, they already have us in
[01:34:40 CET] <atomnuker> michaelni, ubitux, Timothy_Gu, philipl, BBB, nevcairiel and whoever else wants in: okay if I add your email in the CCs for ^^^
[01:35:05 CET] <BBB> sure
[01:40:47 CET] <kierank> atomnuker: ffmpeg is already in, what is there to do
[01:45:38 CET] <BBB> omg you have to specify the codecs to fuzz
[01:45:42 CET] <BBB> like, it doesnt fuzz vp9
[01:45:56 CET] <BBB> hevc is also missing
[01:48:25 CET] <atomnuker> kierank: no contacts or anyone to send alerts to
[01:48:44 CET] <kierank> well michaelni is in the bug reports themselves but ok
[01:51:10 CET] <atomnuker> BBB: it fuzzes indeo2 though, a major player in the world of video compression
[01:52:53 CET] <atomnuker> kierank: I thought the system only sent emails to anyone listed in https://github.com/google/oss-fuzz/blob/master/projects/ffmpeg/project.yaml
[01:53:14 CET] <wm4> obscure codecs are your trump card in the finding exploitable bugs game
[01:53:36 CET] <BBB> new code is your trump card in exploiting anything
[01:54:04 CET] <BBB> you can always disable game codecs in your corporate build
[01:54:11 CET] <BBB> disabling vp9 seems questionable
[01:54:23 CET] Action: kierank disables vp9
[01:54:24 CET] <kierank> :)
[01:54:38 CET] <kierank> vp9 fuzzing was slooooow
[01:54:39 CET] Action: BBB finds a metal pipe
[01:54:50 CET] <kierank> can't remember if I found bugs or not
[01:55:12 CET] <BBB> but yes its slow, its a complex decoder
[01:55:16 CET] <BBB> I bet hevc took a while also
[01:55:26 CET] <kierank> atomnuker: how can I upload our corpus to it?
[01:55:29 CET] <philipl> If we disable all codecs, it'll be way faster and less bug exposure. Seems like a win-win all round.
[01:55:40 CET] <atomnuker> kierank: you submit a pull request
[01:55:51 CET] <kierank> really, but these are binaries?
[01:55:59 CET] <kierank> large binary files
[01:56:04 CET] <atomnuker> wait, corpus? as in sample?
[01:56:10 CET] <atomnuker> *s
[01:56:11 CET] <kierank> yeah samples
[01:56:33 CET] <michaelni> atomnuker, i should be in the list of people who get alerts with anyone else who is on ffmpeg-security at ffmpeg, i did receive mails from that thing aready
[01:56:56 CET] <michaelni> where can you see the list of people who are getting the reports ?
[01:57:22 CET] <atomnuker> michaelni: I guess they have us in already, didn't know that
[01:57:48 CET] <atomnuker> kierank: I guess you modify the Dockerfile to download the samples
[01:58:11 CET] <kierank> https://github.com/google/oss-fuzz/blob/master/projects/ffmpeg/Dockerfile
[01:58:17 CET] <kierank> nothing that suggests any location here
[01:59:35 CET] <atomnuker> or maybe modify the build.sh script to do it since it does the compilation
[01:59:44 CET] <atomnuker> and the fuzzing
[01:59:58 CET] <kierank> https://oss-fuzz-build-logs.storage.googleapis.com/build_logs/ffmpeg/latest.txt
[02:00:28 CET] <kierank> ah
[02:00:29 CET] <kierank> https://github.com/google/oss-fuzz/blob/879120437d81de928879a93b1c9796d630aa767e/projects/ffmpeg/build.sh
[02:00:54 CET] <kierank> found it
[02:05:35 CET] <kierank> good to see that this goes in without review:
[02:05:35 CET] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c06d9234101646d4bf3d239e4fba629a3e4e981f
[02:05:49 CET] <kierank> when my one that tests more codepaths was submitted ages ago
[02:06:11 CET] <kierank> good job michaelni!
[02:08:36 CET] <kierank> I guess google doesn't care about sliced threads
[02:13:38 CET] <michaelni> kierank, the patch was long on the ML and anyone could have commented
[02:13:43 CET] <kierank> was it?
[02:13:46 CET] <kierank> i can't find it
[02:14:14 CET] <michaelni> this here i think: [FFmpeg-devel] [PATCH] doc/examples: add fuzz target for individual ffmpeg APIs for in-process fuzzing with libFuzzer, AFL, and similar fuzzing engines.
[02:15:00 CET] <kierank> ok, sorry I guess. 
[02:15:48 CET] <michaelni> np
[04:40:10 CET] <Timothy_Gu> BtbN: the cron jobs plan sounds good to me
[04:49:52 CET] <Timothy_Gu> durandal_170: vf_zscale currently doesn't compile with the latest release
[04:50:24 CET] <Timothy_Gu> your b96a6e2024fa2b52d6a2473a7cf16ee20a8ab5c8 only checks for >= 2.3, but ZIMG_TRANSFER_IEC_61966_2_1 support is added after 2.3
[04:50:46 CET] <Timothy_Gu> see https://github.com/sekrit-twc/zimg/commit/c3eb60933b1080ca09adfd3d3b7d1b2812c0501d#diff-fa1a382834fd45d827544a52d955320eR279
[11:19:33 CET] <superware> can someone please have a look at https://trac.ffmpeg.org/ticket/5615 ?
[12:26:40 CET] <BtbN> hm, where should the coverity build notifications be sent to?
[12:36:27 CET] <BtbN> michaelni, can you import this repository into the FFmpeg org: https://github.com/BtbN/FFmpeg-Coverity
[12:37:03 CET] <BtbN> No idea what an apropiate name would be. Should just not have Docker in its name, Docker dislikes that...
[12:43:34 CET] <michaelni> BtbN, https://github.com/FFmpeg/FFmpeg-Coverity
[12:44:11 CET] <BtbN> nice, thanks
[12:44:33 CET] <BtbN> now to delete and re-create the docker image, because changing the repo is not possible...
[13:42:59 CET] <BBB> http://techblog.netflix.com/2016/12/more-efficient-mobile-encodes-for.html < netflix goes vp9
[13:46:21 CET] <kierank> and high profile h264!!!!!oneone
[13:46:58 CET] <BBB> thats so 2005
[13:47:27 CET] <BBB> I know, broadcast still lives in 2005
[13:47:55 CET] <BBB> as opposed to in 2005, when they were actually alive
[13:52:45 CET] <BtbN> With VP9 hardware decoding still missing in basically all browsers, that's kind of annoying.
[13:54:19 CET] <wm4> you can still use better playback solutions
[13:59:06 CET] <BBB> BtbN: its for mobile, most modern android phones have vp9 decoding hardware
[13:59:15 CET] <BBB> BtbN: and they obviously use h264-high profile as fallback
[13:59:43 CET] <BBB> BtbN: Im guessing here that mobile means the netflix app on android/iphone (where iphone has no vp9)
[13:59:49 CET] <wm4> so do they use your encoder yet?
[14:00:59 CET] <BBB> I dont think the blog says anything about what encoder they use :-p
[14:05:27 CET] <kierank> is that a polticians answer?
[14:05:45 CET] <kierank> BBB: also did you see ittiam wrote their own vp9 encoder?
[14:07:09 CET] <BBB> I believe their encoder is based on libvpx, but I could well be wrong here
[14:20:25 CET] <cone-073> ffmpeg 03Rainer Hochecker 07master:7a9db61da39f: matroskadec: partly revert "demux relevant subtitle packets after a seek"
[19:37:01 CET] <Timothy_Gu> BtbN: I gleaned from philipl's script some more dependencies (https://github.com/FFmpeg/FFmpeg-Coverity/commit/33194033b79cde3931a69ad50bb07af36910b9e2)
[19:37:36 CET] <Timothy_Gu> I can't test right now but I think they should allow us to add some more dependencies like ladspa, zmq, opencl, etc.
[19:38:13 CET] <BtbN> I enabled Travis-Builds to test it for now
[19:38:20 CET] <BtbN> without uploading the results though
[19:40:27 CET] <Timothy_Gu> now that the dockerfile and the travis script are in the same place, can we not just build the image in travis instead of resorting to Docker Hub?
[19:40:54 CET] <BtbN> that would take forever
[19:42:08 CET] <cone-073> ffmpeg 03Michael Niedermayer 07master:7d1b1b660bb8: avfilter/vf_premultiply: remove redundant semicolons
[19:42:09 CET] <cone-073> ffmpeg 03Michael Niedermayer 07master:b7d94c19cd0e: avformat/ffmenc: Replace some st->codec use by codecpar
[19:42:10 CET] <cone-073> ffmpeg 03Michael Niedermayer 07master:c06d4f2cedb7: avformat/ffmenc: Drop ffm_write_header_codec_private_ctx()
[19:42:11 CET] <cone-073> ffmpeg 03Michael Niedermayer 07master:e8215b77ff46: avformat/ffmenc: set bitexact mode for old API without accessing the encoder
[19:42:12 CET] <cone-073> ffmpeg 03Michael Niedermayer 07master:78519a002973: avformat/ffmenc: Make ffm_write_header_codec_ctx() use codecpar
[19:42:13 CET] <cone-073> ffmpeg 03Michael Niedermayer 07master:4059cd395205: avformat/ffmenc: Remove the last use of st->codec
[19:42:30 CET] <BtbN> Having the finished image on DockerHub saves quite a bit of time and work
[19:42:46 CET] <Timothy_Gu> okay I'll take your word for it
[19:43:05 CET] <BtbN> Building the image takes ~30 minutes
[19:43:30 CET] <BtbN> Downloading it takes around one minute
[19:46:23 CET] <Timothy_Gu> The wget progress bar seems to take up most of the log space (~8000 lines)
[19:47:34 CET] <BtbN> Yeah, it could use a -q
[20:48:15 CET] <cone-073> ffmpeg 03Anton Khirnov 07master:3359eede8fc5: Add a compat stdatomic.h implementation based on GCC atomics
[20:48:16 CET] <cone-073> ffmpeg 03Anton Khirnov 07master:c91e72ed52f2: Add a compat stdatomic.h implementation based on windows atomics
[20:48:17 CET] <cone-073> ffmpeg 03Anton Khirnov 07master:70faadc82687: Add a compat stdatomic.h implementation based on suncc atomics
[20:48:18 CET] <cone-073> ffmpeg 03Anton Khirnov 07master:74b5f1086237: Add a compat stdatomic.h implementation based on pthreads
[20:48:19 CET] <cone-073> ffmpeg 03Anton Khirnov 07master:41e891e89ed7: Add a compat dummy stdatomic.h used when threading is disabled
[21:13:44 CET] <cone-073> ffmpeg 03Vittorio Giovara 07master:059a786c2020: fate/mov: Rename a couple of entries to respect the file naming scheme
[21:13:45 CET] <cone-073> ffmpeg 03Vittorio Giovara 07master:46fae40d2537: hevc: Allow parsing external extradata buffers
[21:13:46 CET] <cone-073> ffmpeg 03Vittorio Giovara 07master:25fcbf7a84a4: hevc: Support extradata changes
[21:31:23 CET] <philipl> coverity ran!
[21:32:20 CET] <BtbN> yeah, it's basically working now. Just have to wait for them to enable cronjobs.
[21:32:28 CET] <philipl> excellent.
[21:35:20 CET] <BtbN> "Thanks so much for your email! I've just enabled Cron Jobs for your organization: FFmpeg. "
[21:35:26 CET] <BtbN> well, that went quicker than expected
[21:37:13 CET] <BtbN> ok, coverity is up and running with that now.
[21:37:29 CET] <BtbN> running monday, wednesday, friday and sunday
[21:37:38 CET] <BtbN> no idea when on those days though
[21:41:42 CET] <philipl> We'll find out eventually.
[21:42:31 CET] <BtbN> ah, they run the moment I add them
[21:42:34 CET] <BtbN> and from then on every 24h
[21:42:47 CET] <BtbN> Canceled the build, as it's redundant to run it immediately again
[21:42:58 CET] <BtbN> tomorrow it will exit out early, so next build on sunday
[22:05:35 CET] <BtbN> Would be way easier to do 4 builds per week if there was one more day
[22:08:18 CET] <philipl> heh
[22:19:50 CET] <Compn> https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20video%20and%20slides/DEF%20CON%2024%20Conference%20-%20Ang%20Cui%20-%20A%20Monitor%20Darkly%20-%20Reversing%20and%20Exploiting%20Ubiquitous%20-%20Video%20and%20Slides.srt
[22:20:14 CET] <Compn> does ffmpeg sub parser fail because of lack of spaces between --> arrow ?
[22:20:59 CET] <nevcairiel> probably
[22:21:03 CET] <nevcairiel> its just not valid srt that way
[22:22:31 CET] <Compn> bleh, zeranoe's builds crash on my vista box
[22:22:43 CET] <Compn> and xp box
[22:22:56 CET] <nevcairiel> xp is probably expected =p
[22:23:13 CET] <Compn> i should start building on my xp box
[22:23:25 CET] <Compn> assuming you guys havent totally broken xp by now
[22:45:44 CET] <J_Darnley> A random question but I see things relevant...
[22:45:48 CET] <J_Darnley> How many people use --enable-small in a serious manner on x86 or x86_64?
[22:46:11 CET] <nevcairiel> its not really a mode anyone cares about on desktop chips like those
[22:46:15 CET] <FishPencil> Which zimg does FFmpeg use? https://github.com/sekrit-twc/zimg or https://github.com/buaazp/zimg
[22:46:21 CET] <nevcairiel> the first
[22:47:10 CET] <FishPencil> Thank god, because the 2nd is horrible to build
[22:47:32 CET] <nevcairiel> the second also does something quite different =p
[22:48:33 CET] <FishPencil> The description looked right?
[22:50:07 CET] <J_Darnley> nevcairiel: I didn't think many people would but working on this assembly I see much repeated code.
[22:50:23 CET] <J_Darnley> Code that in the ancient mmx is in a small "private" function.
[22:50:37 CET] <nevcairiel> i dont think we generally consider "bloat-y" code to be a candidate for --enable-small
[22:50:40 CET] <J_Darnley> That gets called often.
[22:52:37 CET] <nevcairiel> if you can re-use the s ame code block without duplicating it thats always nice, sometimes you can just jump into it as a tail-call or call it without the overhead of parameter passing, but othertimes you just macro it and include it in every function ;)
[22:53:06 CET] <J_Darnley> That is exactly what I am looking at.
[22:54:14 CET] <J_Darnley> It is just a little, strange, to see the difference in style.
[22:54:28 CET] <nevcairiel> the original h264 mmx code is just so old
[22:54:31 CET] <nevcairiel> styles shift
[23:55:43 CET] <ubitux> https://www.youtube.com/watch?v=ZaTuFB5QXHo #vectorscope ?
[23:55:48 CET] <ubitux> durandal_170 ^
[23:55:59 CET] <ubitux> (for inspiration)
[00:00:00 CET] --- Sat Dec  3 2016