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

[burek]

[00:00:04 CEST] <nevcairiel> that website doesnt work
[00:00:23 CEST] <Justin`> Medium CVE-2015-6761: Memory corruption in FFMpeg
[00:00:38 CEST] <nevcairiel> that thing seems to be filled against chromium
[00:00:46 CEST] <Timothy__Gu> see https://code.google.com/p/chromium/issues/detail?id=447860
[00:00:48 CEST] <nevcairiel> if we dont get reports, we dont fix shit
[00:00:57 CEST] <Timothy__Gu> "global-buffer-overflow at vp56_rac_get_prob_branchy"
[00:01:28 CEST] <Justin`> nevcairiel, it's a FFmpeg CVE
[00:01:32 CEST] <Justin`> Chromium just happen to use ffmpeg
[00:01:51 CEST] <nevcairiel> if chromium gets a report and we dont get it forwarded, we dont fix shit :P
[00:02:05 CEST] <Justin`> That attitude is amazing!
[00:02:08 CEST] <nevcairiel> reading the chromium issue, it doesnt seem to be an actual issue though
[00:02:19 CEST] <nevcairiel> Justin`: you tell me how we're supposed to fix issues noone tells us about
[00:02:30 CEST] <Justin`> You could be checking your own software for CVEs?
[00:02:38 CEST] <Timothy__Gu> how?
[00:02:48 CEST] <Timothy__Gu> mitre never informs us
[00:03:08 CEST] <Justin`> Maybe you could open a dialog with them and get reports forwarded?
[00:03:34 CEST] <nevcairiel> Like I said, this issue was filed against chromium, it would've been up to them to forward it
[00:03:37 CEST] <Timothy__Gu> so basically it's our responsibility to google "ffmpeg vulnerability" 24-7
[00:03:41 CEST] <nevcairiel> but, chromium found it to be a non-issue
[00:04:00 CEST] <Justin`> Timothy__Gu, no.
[00:04:03 CEST] <nevcairiel> apparently asan triggers some mis-compilation
[00:04:35 CEST] <nevcairiel> so in short, there never was a problem
[00:04:47 CEST] <nevcairiel> unless you consider an asan build being broken a problem
[00:05:17 CEST] <Justin`> I'm not sure what an asan is. I just came here to see if you guys had patched ffmpeg to negate the CVE flag.
[00:06:06 CEST] <nevcairiel> asan is a development tool that instruments the binary with extra analysis tools
[00:06:12 CEST] <nevcairiel> in this case, it appears to actually cause bugs
[00:06:32 CEST] <nevcairiel> if the chromium ticket can be believed, normal builds dont exhibit any problems
[00:06:35 CEST] <nevcairiel> hence, no security issue
[00:06:41 CEST] <Justin`> Of chromium.
[00:06:47 CEST] <Justin`> What about builds of other software that uses ffmpeg?
[00:06:58 CEST] <nevcairiel> how would we know, we didnt get told
[00:07:06 CEST] <Justin`> I didn't say you should know.
[00:07:16 CEST] <Justin`> I'm asking if you guys knew and if a patch had been created.
[00:07:17 CEST] <jamrial> Justin`: that nist link says cve not found
[00:07:28 CEST] <nevcairiel> says server error for me
[00:07:38 CEST] <nevcairiel> after like 5 minutes of loading
[00:07:52 CEST] <Justin`> jamrial, here https://security-tracker.debian.org/tracker/CVE-2015-6761
[00:08:12 CEST] <jamrial> on mitre https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6761 it says "reserved"
[00:10:01 CEST] <Justin`> https://cve.circl.lu/cve/CVE-2015-6761
[00:10:04 CEST] <Justin`> https://access.redhat.com/security/cve/CVE-2015-6761
[00:10:12 CEST] <Justin`> A few more links for more info.
[00:10:52 CEST] <kierank> none of them explain how to reproduce the bug
[00:10:55 CEST] <kierank> or have a sample or have anything
[00:11:29 CEST] <jamrial> the circl.lu link at least has a description
[00:11:33 CEST] <Justin`> kierank, I am not sure how else to help. 
[00:11:50 CEST] <Justin`> I am just trying to help out by bringing the CVE to your attention.
[00:12:04 CEST] <nevcairiel> the latest link even has a link to something that presumably is a fix, although it says its not reproducable in ffmpeg
[00:12:04 CEST] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=commit;h=dabea74d0e82ea80cd344f630497cafcb3ef872c
[00:14:21 CEST] <jamrial> that was backported for 2.8.2
[00:15:06 CEST] <Justin`> jamrial, is it possible to release a bugfix release like 2.8.1.1?
[00:15:19 CEST] <iive> Justin`: it is bug in the clang-asan compiler
[00:15:34 CEST] <jamrial> 2.8.1 is a bugfix release for 2.8
[00:15:41 CEST] <jamrial> the next one will be 2.8.2
[00:15:43 CEST] <Justin`> ok
[00:15:51 CEST] <Justin`> any eta on it?
[00:15:55 CEST] <nevcairiel> Justin`: its not a bug that affects any release builds
[00:15:59 CEST] <nevcairiel> so no hurry
[00:16:15 CEST] <Justin`> hmm ok, so is it based on how other apps implement ffmpeg?
[00:17:26 CEST] <jamrial> Justin`: usually a few weeks or a month after the previous point release, depending on how many fixes pile up
[00:17:35 CEST] <Justin`> k
[00:25:11 CEST] Action: durandal_170 added RSD6WADP support
[00:27:51 CEST] <durandal_170> kierank: shouldn't you fuzz with crc disabled?
[00:28:23 CEST] <kierank> probably but I just wanted to decode as a normal user would with a random file
[00:29:40 CEST] <jamrial> i thought crc was disabled by default
[03:36:44 CEST] <cone-635> ffmpeg 03Michael Niedermayer 07master:d6f6e98eb158: avutil/crc: use EINVAL instead of -1 for the return code of av_crc_init()
[04:28:27 CEST] <cone-635> ffmpeg 03Ganesh Ajjanagadde 07master:ef62f573ca5e: swresample/swresample_internal: add av_warn_unused_result
[04:33:44 CEST] <cone-635> ffmpeg 03Ganesh Ajjanagadde 07master:0418541d5d3f: avutil/cast5: update Doxygen for av_cast5_init with return information
[08:22:20 CEST] <ubitux> Timothy_Gu: fate.ffmpeg.org menu doesn't match ffmpeg.org one 
[08:26:32 CEST] <Timothy_Gu> ubitux: fixed. thx for spotting
[08:28:07 CEST] <ubitux> Timothy_Gu: also https:// etc
[08:28:45 CEST] <ubitux> mmh but yeah i guess it's a different site
[08:28:48 CEST] <ubitux> anyway, thx
[09:48:44 CEST] <wm4> so is there really a point in Ganesh adding av_warn_unused_result to fucking everything
[09:49:06 CEST] <nevcairiel> no, but we've always needed a K&R-style person
[09:50:34 CEST] <TimNich> Everyone loves a style guru ;)
[11:18:04 CEST] <mateo`> hey i've bumped my original thread regarding an avfoundation patch (https://ffmpeg.org/pipermail/ffmpeg-devel/2015-August/177845.html) from an email not registered on the ml, would be possible to get it moderated so it can reach the ml a bit faster ?
[11:27:25 CEST] <BtbN> mateo`, you could just subscribe, way faster than asking around for someone to approve it.
[11:34:12 CEST] <mateo`> BtbN: done, i've subscribed with my other email address
[13:56:17 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:5e80a6cd315d: avdevice/alsa: add av_warn_unused_result
[14:11:28 CEST] <durandal_1707> gonna push psx patchset
[14:14:02 CEST] <cone-569> ffmpeg 03Christophe Gisquet 07master:42c1dcde683f: fate: use PROGSSUF
[14:55:46 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:e12908d71e7a: vp9: use AVFrame.buf[0] to check if a frame is valid
[14:55:47 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:97be5d4d2007: w32pthreads: fix mingw build on x86 with -msse2 or higher
[14:58:52 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07release/2.8:e3fcd88f08f4: avcodec/jpeg2000dec: Clear properties in jpeg2000_dec_cleanup() too
[14:58:53 CEST] <cone-569> ffmpeg 03hSÇ 07release/2.8:1a67b0f9ae6c: avcodec: loongson optimize h264dsp idct and loop filter with mmi
[15:26:15 CEST] <BtbN> That OpenCL maintainer dude is realy bad with response-quoting in mails.
[15:26:57 CEST] <BtbN> And some other people have a weird unreadable IN> ... quoting style
[15:27:04 CEST] <nevcairiel> you should try reading those mails from the quicksync guy
[15:27:11 CEST] <nevcairiel> i can barely figure out where his responses start
[15:27:18 CEST] <nevcairiel> yeah that him
[15:27:20 CEST] <nevcairiel> *thats
[15:27:42 CEST] <BtbN> In the latest OpenCL mail the response is hidden in the git version number, which is printed in light gray with a very small font for me.
[15:27:48 CEST] <nevcairiel> hehe
[15:27:54 CEST] <ubitux> can't read those either
[15:28:09 CEST] <ubitux> i just hope he will never talk to me
[15:28:31 CEST] <BtbN> At least he does respond now
[15:28:40 CEST] <BtbN> A few more days and i'd have just pushed
[15:30:52 CEST] <BtbN> It's also realy annoying that we _have_ to top-post at work...
[15:31:05 CEST] <J_Darnley> What?
[15:31:14 CEST] <J_Darnley> How can anyone possibly like that?
[15:31:28 CEST] <BtbN> It's to hard for people to scroll down to read the response, too many missed the response and got confused. So top-responding got a policy.
[15:31:38 CEST] <nevcairiel> I used to do it at work too because the other guys would just get confused and not find my answers
[15:31:44 CEST] Action: J_Darnley rants privately
[15:32:01 CEST] <BtbN> Top-Responding is fine in a normal conversation imo
[15:32:16 CEST] <BtbN> but making it a policy and shouting at people when they don't...
[15:33:14 CEST] <BtbN> It's also encouraged to keep the entire history, so bottom posting would mean you have to skip several thousand lines at some point.
[15:33:15 CEST] <J_Darnley> Perhaps in a conversation between exactly 2 people it might be fine.  Each one of you has read all of the thread.
[15:33:44 CEST] <J_Darnley> And that just makes it worse.
[15:33:48 CEST] Action: J_Darnley runs
[16:10:19 CEST] <Timothy_Gu> ubitux: you mean https://fate.f.o? i dont have the AES keys etc. so you have ask michaelni or baptiste for that
[16:10:44 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:377883c4be7a: avfilter/avfilter: Error out if audio parameters change instead of failing an assert
[16:10:49 CEST] <ubitux> Timothy_Gu: yeah no sorry, forget about it
[16:38:11 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:8b11e4379926: avcodec: add ADPCM PSX decoder
[16:38:12 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:af70117c38b6: avformat: add genh demuxer
[16:38:13 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:c0aeee944342: avformat: add vag demuxer
[16:38:14 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:3919089beb50: avformat: add ads demuxer
[16:38:15 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:3a6389015417: avformat/rsd: add WADP support
[16:38:16 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:8e7571eacda5: avformat: add svag demuxer
[18:37:50 CEST] <cone-569> ffmpeg 03Agatha Hu 07master:2b5dda3f4861: avcodec/nvenc: fix b frame n_quant_offset
[19:24:14 CEST] <durandal_1707> michaelni_: have you looked at ffv1 bugs?
[19:27:54 CEST] <michaelni_> durandal_1707, which ffv1 bugs ?
[19:28:43 CEST] <durandal_1707> michaelni_: on tracker
[19:28:54 CEST] <kierank> I have many more :)
[19:29:01 CEST] <kierank> but three is enough for now
[19:29:55 CEST] <durandal_1707> something about corruption
[19:32:13 CEST] <michaelni_> i see just one feature request with keyword=ffv1
[19:32:36 CEST] <michaelni_> no bugs have keyword=ffv1
[19:33:35 CEST] <kierank> https://trac.ffmpeg.org/ticket/4931
[19:33:36 CEST] <kierank> https://trac.ffmpeg.org/ticket/4932
[19:33:37 CEST] <kierank> https://trac.ffmpeg.org/ticket/4933
[19:33:40 CEST] <kierank> those are the bugs
[20:40:23 CEST] <durandal_1707> michaelni_: added keywords to ffv1 bugs 
[21:13:50 CEST] <cone-569> ffmpeg 03James Almer 07master:8297f560cca2: avformat/rsd: propagate return values of extradata helper functions
[21:17:13 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:4c2d4e8700cd: avcodec/ffv1dec: Clear slice coordinates if they are invalid or slice header decoding fails for other reasons
[21:43:14 CEST] <ubitux> what's the general opinion about "edge emu"? that is, what is generally prefered between border checks in the loop vs memcopying the frame into a larger padded area to skip checks? 
[21:44:01 CEST] <ubitux> having the edge emu looks simpler for the processing function, but i'm wondering if it's worth the trouble given that i'm unsure about the performance impact of doing so
[21:45:45 CEST] <ubitux> context: filters
[21:54:18 CEST] <kurosu> edge emu is useful for codecs where it's actually unusual to go in those areas
[21:54:44 CEST] <kurosu> for filters, it happens every time, so it's less suited
[21:55:07 CEST] <kurosu> on the other hand, you can partially unroll loops to have special case for those borders, too
[21:56:24 CEST] <ubitux> yeah indeed
[21:56:31 CEST] <kurosu> ubitux, besides that, it can be a source of bugs for encoders - see dnxhd which was accessing blocks of 16x16, ie reading 1088 lines out of 1080
[21:56:59 CEST] <kurosu> for those, one can wonder whether always padding to 1088 or let it do the best job out of those 8 lines is useful
[21:58:10 CEST] <ubitux> unrolling sounds fair; i'm unsure where to unroll the left/right borders though
[21:58:21 CEST] <kurosu> in dnxhd case, edge emu is actually worse but for different reasons
[21:58:22 CEST] <ubitux> that is, inside the line processing, or after processing the whole frame
[21:59:06 CEST] <kurosu> I'm not very well versed with filters, but in some cases you can do filtering in place
[21:59:37 CEST] <kurosu> but what do you do with slice processing then? you could consider this is not an edge, except another thread could have modified those pixels already
[21:59:42 CEST] <ubitux> if you need borders cases, you most likely need a squared surrounding area
[21:59:46 CEST] <ubitux> so not inplace
[22:00:14 CEST] <ubitux> consider in and out distinct
[22:00:16 CEST] <kurosu> except if you special case borders, eg convolution filters or equivalent
[22:00:27 CEST] <kurosu> nevemind
[22:00:53 CEST] <kurosu> *nevermind, later lines would access filtered lines, which is not intended
[22:02:03 CEST] <kurosu> looks like a filter property anyway
[22:02:14 CEST] <kurosu> it's up to the filter to decide what's best for it
[22:03:44 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_edgedetect.c;hb=HEAD#l118
[22:03:49 CEST] <ubitux> this is a typical example
[22:04:07 CEST] <ubitux> where the 2 lines on top and bottom are outrolled
[22:04:13 CEST] <ubitux> and column are handled inside the loop
[22:04:38 CEST] <ubitux> in this simple case, it looks fine to handle the special left/right inside the loop
[22:04:52 CEST] <ubitux> but sometimes i wonder if it would make sense to handle the whole column at once to simplify the inner loop
[22:05:02 CEST] <ubitux> but i'm afraid of cache locality issues
[22:07:26 CEST] <kurosu> left and right borders make it unclean simd-wise: basically, you probably need to copy those 2 pixels left and right after processing the line
[22:08:14 CEST] <kurosu> in that case, I'd think it's always better than memcpying a whole image to avoid edge cases
[22:09:54 CEST] <ubitux> yeah that's what i was thinking too
[22:09:56 CEST] <ubitux> ok
[22:09:58 CEST] <ubitux> thanks
[22:10:01 CEST] <kurosu> on the other hand, for that case where the 2 pixels left and right are actually not processed, they could look weird depending on the filter effect
[22:10:23 CEST] <ubitux> yeah, borders are kinda shity with that filter
[22:10:32 CEST] <ubitux> but it could be any special case processing
[22:11:40 CEST] <kurosu> really, it looks like a filter property: if you don't want or can't handle edge case efficiently, request padding, on the other hand, it somewhat free when other filters in the chain are not in-place
[22:11:53 CEST] <durandal_1707> have you saw what vf_neighbor does?
[22:12:21 CEST] <kurosu> you pass an image with larger stride, and invoke padding after the output image has been produced
[22:13:09 CEST] <kurosu> durandal_1707, nope, but to each filter its own
[22:15:27 CEST] <kurosu> use pointers instead of offset, so that multiple pointers refer the same line, without need for padding
[22:41:52 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:5063a18f5635: avcodec/ffv1dec: update progress in case of broken pointer chains
[22:47:08 CEST] <kierank> michaelni_: another deadlock on it's way
[22:52:13 CEST] <kierank> hmm maybve not
[22:53:33 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:e240a28b2068: cmdutils: Add auto to threading capabilities report
[22:53:34 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:0ad43d0f15e3: Merge commit 'e240a28b20680b326a39b0860fda37d7e459bfc0'
[22:55:37 CEST] <kierank> found more
[22:57:51 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:9ef748173a4e: cmdutils: Print general codec capabilities
[22:57:52 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:93ac7a98e022: Merge commit '9ef748173a4e0e58d40afaf38397783cd2537eaa'
[22:59:00 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:2d59159508c5: lavc: AV-prefix a few left out capabilities
[22:59:01 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:53fc900ca0d8: Merge commit '2d59159508c5c1830cc5da907a9454e229077320'
[23:02:43 CEST] <cone-569> ffmpeg 03Vittorio Giovara 07master:1f84b008bf2b: fate: Move screenpresso to the appropriate screen capture file
[23:02:44 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:ba94e985a33d: Merge commit '1f84b008bf2b1eaca473937c48788cb4e4ce1aea'
[23:04:28 CEST] <cone-569> ffmpeg 03Derek Buitenhuis 07master:504e3f75bf73: aac: Make codec init run under ff_thread_once
[23:04:29 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:d307c44bafc6: Merge commit '504e3f75bf73a488d39a80a42962bae2a353dd6b'
[23:04:41 CEST] <cone-569> ffmpeg 03Luca Barbato 07master:49d7fcd774ac: mpeg12: Unbreak building stale code
[23:04:42 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:eebea62671b6: Merge commit '49d7fcd774ac31f242818ad9d45d9c013f3bb3db'
[23:05:13 CEST] <cone-569> ffmpeg 03Luca Barbato 07master:b52307933b57: wrapped_avframe: Drop a now-unused variable
[23:05:14 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:af065bf11b61: Merge commit 'b52307933b576eba741c80108c3dad09eb48ba12'
[23:05:25 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:68e00ad66d13: w32pthreads: fix mingw build on x86 with -msse2 or higher
[23:05:26 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:02daf2b36025: Merge commit '68e00ad66d13c57d9eb3a3862b44ab3fb030e19f'
[23:17:38 CEST] <kierank> michaelni_: https://trac.ffmpeg.org/ticket/4939
[23:17:49 CEST] <ubitux> nevcairiel: can you elaborate on 53fc900?
[23:19:05 CEST] <nevcairiel> the only hunk ffmpeg didnt have from that commit is the one that got reverted in  49d7fcd
[23:19:16 CEST] <nevcairiel> no point in introducing breakage for a few commits if i know about it
[23:20:49 CEST] <ubitux> i'm confused at git grep '[^_]CODEC_CAP_HWACCEL'
[23:20:51 CEST] <ubitux> but ok
[23:20:53 CEST] <ubitux> thx
[23:24:20 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:cd8a0a9a9a9e: swscale/swscale: add av_warn_unused_result to sws_init_context
[23:26:02 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:31ed189d5c05: avutil/internal: add av_warn_unused_result to avpriv_open
[23:27:26 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:a0b079ac25fe: avutil/file: add av_warn_unused_result to av_file_map
[23:27:47 CEST] <nevcairiel> wonder if my braswell already arrives tomorrow, then I could hopefully get the vp9  hwaccel done
[23:30:18 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:6d0c8cb79ac0: avdevice/internal: add av_warn_unused_result
[23:56:06 CEST] <rcombs> heh, I've always wondered why libx264rgb existed
[00:00:00 CEST] --- Sat Oct 17 2015