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

burek burek021 at gmail.com
Wed Dec 14 03:05:03 EET 2016


[00:02:17 CET] <cone-706> ffmpeg 03Andreas Cadhalpun 07master:3ab8436ff611: opt: reject denominator zero as out of range
[00:07:10 CET] <cone-706> ffmpeg 03Michael Niedermayer 07master:4cf3def805cf: avutil/tests/imgutils: Remove unused variable
[00:17:03 CET] <Compn> another person asking about shipping a copy of samples repo on HD
[00:17:10 CET] <Compn> wonder if llogan wants to do this? :D
[00:39:47 CET] <cone-706> ffmpeg 03Wan-Teh Chang 07master:fed50c4304ee: avutil: fix data race in av_get_cpu_flags()
[09:19:06 CET] <durandal_1707> kierank: -disable-hwaccels ?
[10:02:33 CET] <cone-972> ffmpeg 03Marton Balint 07master:265d45183be1: avfilter/avfilter: fix filtering frames with unknown channel layouts for filters needing writable frames
[12:12:56 CET] <ElAngelo> does anyone know when zeranoe normally builds again?
[12:20:10 CET] <BtbN> every day I think?
[12:20:31 CET] <durandal_1707> maybe when someone stops leeching all stuff repeatedly
[12:21:51 CET] <ElAngelo> nah last build is from 10 december
[12:22:54 CET] <wm4> ElAngelo: wrong channel
[12:25:02 CET] <ElAngelo> yeah i actually realized that after i typed my question :)
[12:25:08 CET] <ElAngelo> sorry for the noise... 
[12:35:35 CET] <kierank> durandal_1707: sure but it's a bug
[13:50:30 CET] <nevcairiel> kierank: just ping BtbN directly about any issues with the cuda/nvenc stuff
[13:50:59 CET] <kierank> BtbN: see trac 6018
[13:51:03 CET] <kierank> 6017 I mean
[13:51:53 CET] <nevcairiel> how come your system passes the dlopen configure check but then doesnt have dlsym anyway?
[13:53:50 CET] <nevcairiel> unless there is a bug th at even bypasses the configure check
[13:54:42 CET] <BtbN> Not doing anything fancy with those, I'd expect other stuff to be affected as well
[14:09:47 CET] <kierank> Why does nvidia stuff get included in the first place
[14:10:03 CET] <kierank> --disable-everything shouldn't require anything more
[14:10:36 CET] <BtbN> I have no idea how that works in the first place. It seems to disable all components, but the component list only contains entires like decoders/demuxers/...
[14:42:44 CET] <Compn> carl usually checks --disable-everything 
[14:42:55 CET] <Compn> at least i remember him fixing it multiple times in the past
[14:52:14 CET] <BBB> kierank: want to help me clickbait something?
[14:52:23 CET] <kierank> yeah why not
[14:53:26 CET] <BBB> https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/
[14:53:59 CET] <BBB> I just posted it on n.ycomb
[14:54:54 CET] <BBB> (https://news.ycombinator.com/item?id=13166720)
[15:16:23 CET] <Shiz> >A video stream consists of frames, and each frame consists of color planes.
[15:16:32 CET] <Shiz> akshually, a stream consists of pictures, which can either be frames or fields :P
[15:17:48 CET] <wm4> vp9 doesn't support interlacing
[15:17:57 CET] <wm4> unless they have a field mode thing?
[15:18:50 CET] <BBB> no interlacing
[15:18:59 CET] <BBB> interlacing=evil
[15:19:13 CET] <BBB> and then theres mbaff
[15:23:01 CET] <JEEB> the HEVC way kind of serves interlacism people well enough, you just have a field/frame flag and that's it
[15:23:41 CET] <nevcairiel> its double terrible though
[15:24:07 CET] <nevcairiel> still the terrible interlacing and not even coding tools to make it more efficient
[15:24:37 CET] <JEEB> lol
[15:24:52 CET] <JEEB> it was still noted that it gives benefits over AVC so (´4@)
[15:25:01 CET] <JEEB> or you just don't give a damn about interlacism, of course
[15:25:04 CET] <nevcairiel> i dont think our decoder ever learned to do that, did it
[15:26:06 CET] <BBB> that sounds worthy of a fate test?
[15:26:07 CET] <nevcairiel> someone was once working on it but I was concerned about his approach because it wouldnt allow hwacceling  it, so he might have given up
[15:26:32 CET] <BBB> the fact that nobody has fixed it yet probably means nobody cares
[15:26:39 CET] <JEEB> :)
[15:26:41 CET] <nevcairiel> (iirc he made it decode both fields into separate frames and then interlaved them manually)
[15:26:46 CET] <JEEB> oh
[15:26:46 CET] <BBB> either because nobody cares about ffmpeg (unlikely), or b/c nobody cares about hevc
[15:26:55 CET] <BBB> so Ill just conclude nobody cares about hevc
[15:26:57 CET] <JEEB> yeah, because our filters expect both fields to be together
[15:27:01 CET] <nevcairiel> more like interlaced hevc
[15:27:03 CET] <BBB> not at all partial or biased ;)
[15:27:14 CET] <wm4> actually it would be cleaner if all decoders just returned fields
[15:27:28 CET] <nevcairiel> still breaks hwaccel =p
[15:27:34 CET] <wm4> all those hacks to recover timestamps with deinterlacing field doubling
[15:27:40 CET] <JEEB> :D
[15:27:55 CET] <JEEB> man I just had forgotten about those
[15:38:53 CET] <BBB> maybe I should blog about how interlacing is dead
[15:40:42 CET] <BBB> although Ive always wanted to write a blog about that one time when one compiler beat my hand-written assembly
[15:40:45 CET] <BBB> I was so pissed
[15:40:58 CET] <nevcairiel> lol
[15:42:17 CET] <nevcairiel> you should be happy to have a competent compiler instead
[15:51:58 CET] <bencoh> 
[15:56:53 CET] <cone-972> ffmpeg 03Michael Niedermayer 07master:30581c51e72a: avformat/options_table: Set the default maximum number of streams to 1000
[15:56:54 CET] <cone-972> ffmpeg 03Michael Niedermayer 07master:f0bdd538712d: avformat/utils: Print verbose error message if stream count exceeds max_streams
[16:11:07 CET] <wm4> so when will we revert this max_streams abomination
[16:13:12 CET] <nevcairiel> everything gets done in the name of security
[16:13:29 CET] <nevcairiel> just register a CVE for whatever problem you have and greenlight any patches!
[16:14:21 CET] <wm4> I'm really not sure why we need to fight so hard for dumb things like this
[16:14:58 CET] <nevcairiel> because security handling is dumb
[16:15:06 CET] <kierank> BBB: upvoted
[16:15:09 CET] <kierank> sorry, was a bit busy
[16:15:17 CET] <nevcairiel> we're open source but we cant take time to discuss patches and share all information, because muh secrets
[16:15:18 CET] <BBB> np, ty
[16:15:28 CET] <kierank> nevcairiel: muh youtube samples
[16:15:32 CET] <wm4> I'm not aware of any secrets
[16:15:35 CET] <BBB> theyre never yt samples
[16:15:48 CET] <BBB> theyre always fate samples or h264 conformance suite samples fuzzed in some way
[16:15:55 CET] <BBB> but security because meh legal
[16:16:03 CET] <BBB> ask lawyers whether & and they say no
[16:16:28 CET] <BBB> Ive learned that in these cases, its best to ask for forgiveness, not permission
[16:16:36 CET] <BBB> use your own judgement ;)
[16:16:36 CET] <nevcairiel> wm4: half the oss projects have hidden/priveledged tickets on their issue tracker in the name of security
[16:16:48 CET] <nevcairiel> i'm surprised we dont have that yet
[16:16:54 CET] <nevcairiel> its apparently all on some non-public ML
[16:18:09 CET] <wm4> we have a security ML
[16:18:22 CET] <wm4> which I don't have access to, so dunno what's there
[16:22:17 CET] <rcombs> standard responsible-disclosure procedure; fix bug, then wait to discuss details publicly until the patch is deployed
[16:22:28 CET] <nevcairiel> this wasnt a bug
[16:22:44 CET] <nevcairiel> you can craft a perfectly valid file with thousands of empty stream
[16:22:46 CET] <nevcairiel> +s
[16:22:48 CET] <nevcairiel> uses a lot of memory
[16:22:50 CET] <nevcairiel> is that a bug?
[16:23:10 CET] <rcombs> so, what is this, supposedly a DoS?
[16:23:18 CET] <nevcairiel> so the CVE claims
[16:23:21 CET] <wm4> it was generated by a fuzzer
[16:23:45 CET] <wm4> and it's essentially a DoS because some malloc fails (and/or causes it get OOM killed)
[16:24:55 CET] <nevcairiel> noone minds quick bug fixes in the name of security, if it goes bad we can always fix it
[16:25:04 CET] <nevcairiel> defining new API and rushing it thorugh for some shady OOM DoS report
[16:25:07 CET] <nevcairiel> its just meh
[16:25:52 CET] <wm4> ffmpeg development, lol
[16:55:24 CET] <wm4> BtbN: are the nvenc presets documented anywhere? i.e. what the heck do they mean
[16:58:59 CET] <BtbN> I'm not aware of any actual definition on what they are
[16:59:01 CET] <nevcairiel> in the nvidia docs, kinda
[16:59:05 CET] <nevcairiel> but not very well
[16:59:32 CET] <BtbN> The pdf docs have some hints and numbers here and there, but no real explanation.
[17:00:15 CET] <nevcairiel> its really not that opaque, tbh
[17:00:25 CET] <nevcairiel> high performance, high quality speak for themself
[17:00:44 CET] <nevcairiel> low latency kinda does as well, probablly primarily for live streaming to their tablets
[17:01:14 CET] <nevcairiel> and dual-pass is just a RC mode
[19:03:00 CET] <cone-972> ffmpeg 03Muhammad Faiz 07master:6a8c0d83572d: swresample/resample: do not allow negative dst_size return value
[19:45:48 CET] <cone-972> ffmpeg 03Alex Converse 07master:bf15981b1262: libvpxenc: Don't spam level errors for VP8 encodes
[00:00:00 CET] --- Wed Dec 14 2016


More information about the Ffmpeg-devel-irc mailing list