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

[burek]

[00:50:41 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:52bb493afaa5: avcodec/jpeglsdec: Check ilv for being a supported value
[00:50:42 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:93854b705273: avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line()
[00:50:43 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:56cc35019e4a: avcodec/aacdec_fixed: Fix integer overflow in predict()
[00:50:44 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:52ebd1a0dc2f: avcodec/aacdec_fixed: Fix integer overflow in apply_dependent_coupling_fixed()
[00:50:45 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:a3bb922c4da1: avcodec/xan: Improve overlapping check
[00:50:46 CET] <cone-963> ffmpeg 03Luca Barbato 07release/3.0:66754f0a962e: avformat: Free the internal codec context at the end
[00:50:47 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:4d9321136d7f: avcodec/xan: Check for bitstream end in xan_huffman_decode()
[00:50:48 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:122634a580df: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add()
[00:50:49 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:21ae8b4869e2: avcodec/aacsbr_fixed: Fix division by zero in sbr_gain_calc()
[00:50:50 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:4fbee4272793: avutil/softfloat: Add FLOAT_MIN
[00:50:51 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b45971a95557: avcodec/sbrdsp_fixed: Fix integer overflow in shift in sbr_hf_g_filt_c()
[00:50:52 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b9e9c5cee03f: avcodec/cngdec: Fix integer clipping
[00:50:53 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:f33f13172cfe: avcodec/snowdec: Fix integer overflow in header parsing
[00:50:54 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:f2763b8ba80c: avcodec/mdct_*: Fix integer overflow in addition in RESCALE()
[00:50:55 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:43299eabeabc: avcodec/aacdec_fixed: Fix undefined shift
[00:50:56 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:91aadc6a5b8e: avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c()
[00:50:57 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b8a6b5602762: avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu
[00:50:58 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:2fc1a8ba4984: avcodec/h264dec: Fix potential array overread
[00:50:59 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:4171249d7632: avcodec/vc2enc: Clear coef_buf on allocation
[00:51:00 CET] <cone-963> ffmpeg 03Fredrik Hubinette 07release/3.0:74677deaca81: avformat/mov: Check size of STSC allocation
[00:51:01 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b8a10f10cc5f: avcodec/snowdec: Check intra block dc differences.
[00:51:02 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:12aea29a9596: avcodec/snowdec: Check for remaining bitstream in decode_blocks()
[00:51:03 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:d1421edab7c1: avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb()
[00:51:04 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:bc65abecd31f: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0()
[00:51:05 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:b9b4d34ecfdd: avcodec/zmbv: Check that the buffer is large enough for mvec
[00:51:06 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:a3606385f075: avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output()
[00:51:07 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:bf44f250a223: avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v()
[00:51:08 CET] <cone-963> ffmpeg 03Jacob Trimble 07release/3.0:20e78d53394f: avformat/mov: Propagate errors in mov_switch_root.
[00:51:09 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:712814fb17b6: Use ff_thread_once for fixed, float table init.
[00:51:10 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:c09d587ac54d: Fix undefined shift on assumed 8-bit input.
[00:51:11 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:50b22648100e: Close ogg stream upon error when using AV_EF_EXPLODE.
[00:51:12 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:abff307736fb: avcodec/mpeg4videodec: Check also for negative versions in the validity check
[00:51:13 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:2214afdf408c: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*
[00:51:14 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:71e40180cb1d: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression
[00:51:15 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:78b6e8fb233f: avcodec/mlpdsp: Fix signed integer overflow, 2nd try
[00:51:16 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:a65633aa9d22: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h()
[00:51:17 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:44dc83f0e07a: avcodec/j2kenc: Fix out of array access in encode_cblk()
[00:51:18 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:b01020a0501a: avformat/utils: Prevent undefined shift with wrap_bits > 64.
[00:51:19 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:e6c6bb218e0b: avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead.
[00:51:20 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:532f0d1278c0: Don't manipulate duration when it's AV_NOPTS_VALUE.
[00:51:21 CET] <cone-963> ffmpeg 03Dale Curtis 07release/3.0:06a6f73ad83b: avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u.
[00:51:22 CET] <cone-963> ffmpeg 03Michael Niedermayer 07release/3.0:2bc6b9b2a9c9: Changelog: update
[01:00:17 CET] <atomnuker> durandal_170: you can do the hflipping in-place, you know
[01:00:36 CET] <atomnuker> start at the middle and load up 2 regs at once, shuf them and swap them
[01:02:30 CET] <atomnuker> that ought to speed it up even more
[01:25:01 CET] <ElementalOrange> How are asm/SIMD optimizations normally written? Are they just written by hand with an intimate understanding of ASM and x86?
[01:25:22 CET] <JEEB> how intimate your knowledge is depends, but yes
[01:25:27 CET] <atomnuker> yep
[01:25:39 CET] <JEEB> the basic idea is that you define some function pointers and then implement the function in SIMD
[01:26:03 CET] <ElementalOrange> How does one learn SIMD or how to write decent ASM for it?
[01:27:03 CET] <JEEB> that's a good question since you generally when starting don't really know what's good for what. that said, nobody stops you from making something really basic and then getting reviews on how to improve things
[01:27:21 CET] <JEEB> also intel publishes the instruction set books as PDF as one darn large listing for searching
[01:27:30 CET] <JEEB> (for x86/x86_64)
[01:27:48 CET] <JEEB> then there's NEON for ARMv7+
[01:28:01 CET] <atomnuker> ElementalOrange: just start from one of the existing functions and play around with it to do what you'd like it to do
[01:28:02 CET] <wm4> just don't write them as intrinsics
[01:28:09 CET] <wm4> they have little to none chance of being accepted in ffmpeg
[01:28:17 CET] <Shiz> intrinsics are bad
[01:29:44 CET] <ElementalOrange> Feels very daughting lol
[01:29:55 CET] <jdarnley> There is a half-decent introduction on the VideoLAN wiki that I transcribed and BBB has done a better blog post on the subject.
[01:30:09 CET] <jdarnley> https://wiki.videolan.org/X264_asm_intro/
[01:30:13 CET] <JEEB> https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-using-x86inc-asm/
[01:30:21 CET] <jdarnley> https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-using-x86inc-asm/
[01:30:27 CET] <jdarnley> snap
[01:31:23 CET] <ElementalOrange> What is normally used as function performance analysis?
[01:31:26 CET] <JEEB> ok, the blog is already better than the old wiki because it has "this is what we're trying to do, and here's a SIMD example of defining the same thing"
[01:31:31 CET] <ElementalOrange> s/as/for
[01:31:46 CET] <jdarnley> FFmpeg's timer.h header, perf, checkasm
[01:31:52 CET] <JEEB> ^
[01:32:02 CET] <JEEB> if you look at SIMD patches you will see the functions compared
[01:33:04 CET] <ElementalOrange> Are all these questions answered somewhere on an FFmpeg FAQ?
[01:33:28 CET] <jdarnley> maybe the benchmarking question is
[01:33:44 CET] <JEEB> for the actual writing BBB's blog post that we linked seems darn good
[01:33:57 CET] <ElementalOrange> How about what a "two-loops algorithm" in ASM is
[01:33:58 CET] <atomnuker> ElementalOrange: we usually use libavutil/timer.h:START_TIMER() and STOP_TIMER()
[01:34:10 CET] <JEEB> yea that was the thing :)
[01:34:13 CET] Action: jdarnley has yet to read it to the end
[01:35:20 CET] Action: JEEB hopes someone who knows NEON will notice https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221518.html
[01:35:32 CET] <JEEB> FFmpeg stopped building with ARM clang pretty suddenly :/
[01:38:51 CET] <jdarnley> ElementalOrange: what do you mean by "two-loops algorithm"?
[01:39:24 CET] <jdarnley> I'm sure there are meny examples of nested loops in assembly
[01:39:53 CET] <ElementalOrange> specifically to compute the integral image
[01:39:56 CET] <jamrial> JEEB: also gcc aarch64 it seems
[01:40:19 CET] <jdarnley> What is an integral image?
[01:40:54 CET] <jdarnley> Isthis some specific Computer Science term I am not familiar with?
[01:40:56 CET] <ElementalOrange> https://en.wikipedia.org/wiki/Summed-area_table
[01:41:36 CET] <jdarnley> If we have one of those somewhere then feel free to write assembly for it.
[01:42:07 CET] <ElementalOrange> jdarnley: It's used in NLM
[01:43:04 CET] <cone-963> ffmpeg 03Michael Niedermayer 07n3.0.10:HEAD: avcodec/jpeg2000: Only allocate Jpeg2000Pass for the encoder
[01:47:37 CET] <ElementalOrange> Any ideas what could cause a filter to not be using 100% CPU? I see about 50% usage across 4/8 cores/threads
[02:37:49 CET] <jamrial> wm4: "../video/decode/vd_lavc.c:291:13: error: unknown type name AVCodecHWConfig"
[02:38:52 CET] <wm4> jamrial: wut
[02:39:31 CET] <jamrial> travis for mpv is failing with that and similar errors
[02:40:02 CET] <wm4> oh yeah, I noticed that
[02:40:03 CET] <jamrial> you probably missed adding a header in your recent vd_lavc refactoring
[02:40:07 CET] <jamrial> ah ok
[02:40:22 CET] <wm4> it should get getting the correct ffmpeg version though, and mpv's configure also requires an appropriate libavcodec pkg-config version
[02:40:26 CET] <wm4> so no idea what travis wants
[02:40:46 CET] <jamrial> it's using libav, though
[02:40:46 CET] <wm4> I mean it does include avcodec.h
[02:40:51 CET] <wm4> huh
[02:40:54 CET] <wm4> oh damn
[02:41:03 CET] <wm4> right, I think that was not merged into libav yet
[02:41:05 CET] <wm4> oops
[02:45:25 CET] <jamrial> that explains why appveyor didn't also fail, haha
[03:08:10 CET] <ElementalOrange> Was --enable-gprof replaced by something
[03:08:43 CET] <ElementalOrange> Oh, Oprofile
[04:23:28 CET] <Compn> jkqxz : re amd header , i know that you are against including it, but would you consider it a blocker or veto it? 
[04:23:39 CET] Action: Compn still reading long thread
[04:24:24 CET] <Compn> er maybe i missed the other thread
[04:27:54 CET] <atomnuker> _make_a_separate_repo_
[04:28:00 CET] <atomnuker> how hard can it be?
[04:28:35 CET] <Compn> its not hard
[04:28:40 CET] <Compn> its already on github
[04:29:18 CET] <Compn> oh its a git submodule
[04:29:26 CET] <Compn> atomnuker : would a git submodule be acceptable ?
[04:29:37 CET] <Compn> seperate repo but git auto pulls it in ?
[04:30:12 CET] <atomnuker> yeah, sure
[04:30:14 CET] <Compn> oh git wont pull new submodules down automatically
[04:30:24 CET] <atomnuker> nah, you have to git submodule init
[04:30:29 CET] <Compn> As you know, "git pull" won't update the submodules, and "git submodules update" won't download the latest HEAD of those submodules either.
[04:30:30 CET] <Compn> To update all of your submodules to their latest upstream revision, you can use
[04:30:30 CET] <Compn> git submodule foreach git pull
[04:30:38 CET] Action: Compn stabs self in head
[04:30:42 CET] <atomnuker> but its fine imo as long as its added in the docs somewhere or maybe during the configure scipt
[04:31:24 CET] <atomnuker> "unable to find hwaccel headers, do a git submodule init to pull them and enable amf/cuda/qsv"
[04:31:30 CET] <Compn> ideally, where should this header go? hmm
[04:31:34 CET] <Compn> in xorg ? 
[04:31:49 CET] <atomnuker> headers?
[04:32:01 CET] <atomnuker> go as in where?
[04:32:09 CET] <Compn> i mean, which project should ferry it into a users system
[04:32:17 CET] <Compn> or would it be distro responsibility ?
[04:32:35 CET] <Compn> i mean, shouldnt this amf encoder header come with the binary driver ?
[04:32:36 CET] <atomnuker> this is for build-time use only afaik
[04:32:51 CET] <SortaCore> you guys aren't fragmenting things I hope o.o
[04:33:22 CET] <Compn> SortaCore : amd wants ffmpeg to include a header from its sdk in our codebase
[04:33:48 CET] <atomnuker> so who has access to the videolan git repo to add another one for the headers? j-b?
[04:34:08 CET] <Compn> sure
[04:34:12 CET] <Compn> j-b or thresh
[04:34:15 CET] <SortaCore> ok, so why do you sound like you're making loads of different repo variants?
[04:34:44 CET] <Compn> SortaCore : i'm asking who and where it should be located, if not in our repo...
[04:35:16 CET] <SortaCore> dunno about y'all but git has always been a painful thing to work with
[04:35:34 CET] <Compn> k
[04:35:41 CET] <atomnuker> something like https://git.videolan.org/?p=ffhw_headers.git;a=log;h=HEAD maybe
[04:35:52 CET] <SortaCore> why could you not add it like say, the intel stuff?
[04:36:11 CET] <Compn> SortaCore : theres a large thread on ffmpeg-devel if you wish to read it :)
[04:36:28 CET] <Compn> i'm trying to find a consensus on the next step...
[04:36:39 CET] <SortaCore> it's 3am tho
[04:36:50 CET] <SortaCore> I am like 2 mins from sleeps
[04:36:55 CET] <Compn> good night SortaCore :)
[04:36:58 CET] <SortaCore> is it just license dubiousness?
[04:37:20 CET] <Compn> read the thread sometime when its not so late :)
[04:37:35 CET] <Compn> and no, its now MIT license
[04:37:36 CET] <atomnuker> okay, whatever, what's left is to agree on a name
[04:38:07 CET] <Compn> atomnuker : so we are going to move nv headers there too then? 
[04:38:15 CET] <SortaCore> yes, should it be amd, AMD or aMD camelCase
[04:38:27 CET] <atomnuker> jkqxz, BtbN: does ffhw_headers sound fine for a repo name?
[04:38:40 CET] <Compn> SortaCore : he means the repo name, not amd name heh
[04:38:41 CET] <atomnuker> Compn: yes, lets move everything external we have
[04:38:50 CET] <Compn> atomnuker : ok, good idea :)
[04:39:00 CET] <SortaCore> yea, I was just being sarcastic, y'all keep up the good work
[04:39:12 CET] <Compn> j-b : what do you guys do with your external headers? :)
[04:39:37 CET] <SortaCore> one question tho, when transcoding should it be the same hw_device_ctx in decoder + encoder?
[04:39:46 CET] <SortaCore> or do you initialise two dev ctxs?
[04:40:07 CET] <Compn> atomnuker : i'd say ffheaders , keep it simpler
[04:41:41 CET] <atomnuker> yeah, okay, that's another valid name
[04:42:46 CET] <SortaCore> (does no one know?)
[04:43:01 CET] <Compn> (i am unable to answer your question)
[04:43:17 CET] <SortaCore> (thanks for acknowledgement)
[04:43:19 CET] <philipl> SortaCore: it's the same device.
[04:43:32 CET] <SortaCore> danke vaas
[04:43:58 CET] <SortaCore> this isn't really demoed in any of the examples
[04:44:06 CET] <SortaCore> they do either decode or encode, not both
[04:44:33 CET] <philipl> No one got round to writing a transcode example, but that's how the ffmpeg tools works. Obviously much more complicated
[04:45:40 CET] <philipl> Compn: for what it's worth, I'd have been happy to keep the headers in tree but I actually think a submodule works quite well. The fact that it doesn't automatically follow a branch means we can explicitly set the submodule hash to point to the version of the headers we want at a particular point in time.
[04:45:52 CET] <SortaCore> yea, ffmpeg seems to come with quite a steep learning curve once you pass out of examples/googleables
[04:45:57 CET] <philipl> and the fact that submodules don't checkout automatically can make people happy who don't want the headers automatically...
[04:46:08 CET] <philipl> The things that make submodules horrible to use work in our favour here, arguably :-)
[04:47:22 CET] <SortaCore> why do you want to keep the header out of the full build?
[04:48:15 CET] <philipl> I don't want to keep it out, but I think I don't represent the emerging concensus.
[04:48:36 CET] <SortaCore> ultimately it's about user ease of use, right
[04:48:54 CET] <philipl> That's my priority
[04:49:17 CET] <SortaCore> so my brain's instantly going to big headers, interference with ffmpeg stuff, formats C:\ when intel qsv is in same repo
[04:49:26 CET] <SortaCore> these would be valid concerns
[04:50:00 CET] <SortaCore> if it's just a longer make should be ok
[04:50:14 CET] <Compn> philipl : yes i'm in agreement with you, that including headers is better for users...
[04:52:16 CET] <atomnuker> moderation is the key however lest the repo will become a dumpster for "vendor's first hwdec api"
[04:52:51 CET] <atomnuker> and no, submodules are alright, you just educate users by messages
[04:53:21 CET] <atomnuker> its not the first thing users would learn to know when compiling ffmpeg, its just going to be one of many
[04:53:40 CET] <atomnuker> like "hwaccels are enabled by default, but you still need the distro's dev packages"
[04:58:10 CET] <wm4> just don't set the dumpster on fire
[04:58:14 CET] <wm4> then we don't have to care
[05:07:15 CET] <philipl> wm4: I thought this dumpster was always on fire
[05:08:29 CET] <wm4> probably is
[05:18:54 CET] <Compn> surprised nvidia hasnt fixed their nonsense sdk
[05:19:01 CET] <Compn> so people can download it
[05:19:31 CET] <philipl> I don't know how they expected people to use it.
[05:20:21 CET] <philipl> Even the sdk that you do download is organised like garbage. It doesn't make it clear which headers are actually for development and which are part of the samples
[05:21:51 CET] <atomnuker> spoiler warning: they care exactly 0% about general users
[05:21:57 CET] <atomnuker> absolutely 0%
[05:22:22 CET] <atomnuker> they care about other companies using the sdk to create producs and support for their hardware in their products
[05:27:26 CET] <philipl> Too true.
[05:27:45 CET] <philipl> They care about us using it (see their ffmpeg stuff on the website) but not enough to make it consumable.
[05:30:52 CET] <wm4> lol
[10:34:21 CET] <BtbN> atomnuker, I still think one big repo with all the headers is a horrible idea. It defeats the entire point of not including external headers.
[10:34:40 CET] <BtbN> And with avisynth, it's not even hw
[10:49:50 CET] <durandal_170> atomnuker: i get quite good performance,  and your approach would complicate things even more
[10:58:43 CET] <atomnuker> not really
[10:59:22 CET] <atomnuker> BtbN: fine then, lets have one for each separate header
[11:00:10 CET] <atomnuker> pick a name for the nvidia one and pm thresh to make one, someone with github access can mirror it later
[11:00:18 CET] <BtbN> I don't think we even need one for each header. AMD seems to be maintaining their repository well.
[11:00:43 CET] <atomnuker> alright, then just for the ones we have right now
[11:01:23 CET] <BtbN> And there were people arguing about not really needing it for avisynth anymore as well? But I don't follow that stuff close enough to tell.
[11:02:55 CET] <BtbN> I'm gonna go with ffmpeg-nv-codec-headers. Any objections?
[11:03:03 CET] <atomnuker> I'm pretty absolutely sure no one uses it anymore, I'l lsend a patch to remove it tonight
[11:03:29 CET] <nevcairiel> i'm pretty sure people still use avisynth =p
[11:03:39 CET] <atomnuker> well, I meant that interface
[11:03:46 CET] <atomnuker> with those headers
[11:03:52 CET] <atomnuker> what are the headers for anyway?
[11:04:01 CET] <nevcairiel> to build avisynth support in ffmpeg?
[11:04:02 CET] <nevcairiel> :)
[11:04:21 CET] <atomnuker> so an avisynth filter?
[11:04:36 CET] <nevcairiel> i think its a demuxer that can read .avs scripts
[11:06:46 CET] <atomnuker> apparently there's been a regression since oct 2016 for msvc builds of avisynth or something
[11:07:13 CET] <nevcairiel> doubt many people build msvc outside of using it for development
[11:09:28 CET] <BtbN> contacted thresh. It's either going to be ffmpeg-nv-codec-headers or ffmpeg/nv-codec-headers so it shows up under the + sign, like the vlc language bindings and forks
[11:47:50 CET] <durandal_170> Compn: why you do not share ideas you get via various conferences you visit with rest of community?
[12:32:04 CET] <Compn> durandal_170 : you are assuming i go to any conferences
[12:32:25 CET] <Compn> i do not. vdd is the only media conference i've been to.
[12:42:12 CET] <jkqxz> Compn:  My main problem with including the AMD header is that, as far as I can tell, there are no positive arguments for it while there are definitely arguments against it.
[12:44:26 CET] <jkqxz> The only two points in favour that people have made seem to be "Nvidia has it so AMD should do the same thing" and "AMD users are idiots who can't install headers themselves".  I don't regard either of those as useful positive arguments.
[12:49:57 CET] <jkqxz> If moving the Nvidia headers to a separate repo allows us to get past the first point so that people stop thinking that including the AMD header is somehow not a terrible idea then I am all in favour of it.
[13:11:47 CET] <durandal_170> Compn: then other devs, ping them
[14:49:19 CET] <JEEB> is there maintenance going on with the trac?
[14:49:58 CET] <durandal_170> we do not have admins
[14:50:13 CET] <JEEB> I know, it was a rhetorical question
[15:03:48 CET] <cone-094> ffmpeg 03Paul B Mahol 07master:bbfcb1b7c891: avfilter/vf_threshold: add x86 SIMD
[15:25:26 CET] <iive> is there still problem with trac? seems to work for me.
[15:25:53 CET] <JEEB> responds quickly again
[18:26:26 CET] <cone-886> ffmpeg 03Martin Vignali 07master:b37196adff75: avutil/x86util : add macro for loading a 128 bits constants in an xmm or in each part of an ymm in order to simplify avx2 asm func
[18:26:26 CET] <cone-886> ffmpeg 03Martin Vignali 07master:be6d1f9632e2: avcodec/x86/bswapdsp : use macro for 128 bits constants loading in xmm or ymm
[18:49:01 CET] <daddesio> atomnuker: I sent my patchset to the ML. https://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/221563.html
[18:49:26 CET] <daddesio> For some reason patch 2/4 got submitted twice.
[18:55:54 CET] <sfan5> anyone familiar with the hevc code who could tell me how to check if a frame is used as a reference by other frames?
[19:00:36 CET] <BtbN> look at all the hevc hwaccels
[19:00:42 CET] <BtbN> they all grab that information in some way
[19:15:33 CET] <cone-886> ffmpeg 03Thomas Köppe 07master:53c492640c6b: avutil/mem: Add DECLARE_ASM_ALIGNED macro for DJGPP architecture.
[19:15:34 CET] <cone-886> ffmpeg 03Dale Curtis 07master:09494d098405: avformat/oggdec: Respect AVERROR codes returned by ogg parsers.
[19:15:35 CET] <cone-886> ffmpeg 03John Stebbins 07master:00d454ed2ca3: lavf/movenc: add sdtp (sample dependency) box
[19:20:36 CET] <kurosu> sfan5, you can't know that in advance - as long it's in the dpb, it could be used anytime, until it is actually removed
[19:21:42 CET] <kurosu> if you really want to understand (which I don't), there's in the free specs 8.3.2 "decoding process for reference picture set"
[19:23:01 CET] <sfan5> hm that makes sense
[19:23:22 CET] <kurosu> so, in short, if you hoped to predict that, maybe you can get it right 80% of the time (eg that's the pattern seen, so that frame should be used)
[19:23:41 CET] <kurosu> but you may find streams that don't work that way, and you're toast
[19:23:42 CET] <sfan5> what does the nal->ref_idc == 0 in h264_slice.c do then? since it's used for AVDISCARD_NONREF, which I'm looking to implement for hevc
[19:23:46 CET] <JEEB> yea, future frames can utilize you until you drop out of the reference picture set
[19:24:41 CET] <jkqxz> nal_ref_idc == 0 tells the decoder it will never be referenced by future frames.
[19:24:47 CET] <faLUCE> Hello. My library ( https://github.com/paolo-pr/laav ) uses FFMpeg. I chose the GPL 3.0 license and specified it in EACH file of the project. Please can you help me in checking if is it all ok or I have to add something more?
[19:24:51 CET] <JEEB> sfan5: the best reference for that is http://www.itu.int/rec/T-REC-H.264-201704-I/en
[19:25:10 CET] <JEEB> jkqxz: oh, so there's a flag like that
[19:25:11 CET] <jkqxz> The equivalent for H.265 is an "_N" NAL unit type.
[19:25:22 CET] <JEEB> is this like the leading pictures?
[19:25:26 CET] <sfan5> that sounds like what i wanted to hear
[19:25:48 CET] <jkqxz> Note that an encoder need not ever mark any frames like that, but sensible encoders will.
[19:26:09 CET] <kurosu> ok, so your question was actually: how hevc indicate a frame is dropped from dpb
[19:27:49 CET] <sfan5> so i would need to check for HEVC_NAL_TRAIL_N, HEVC_NAL_TSA_N, ... right?
[19:28:40 CET] <sfan5> JEEB, i've downloaded that spec but it's quite opaque if you're looking at codec internals for the first time >.>
[19:29:23 CET] <JEEB> true
[19:29:24 CET] <jkqxz> kurosu:  When it's dropped is harder, you have to track it through the reference picture sets.  nal_ref_idc or _N are it never being available for reference at all.
[19:29:30 CET] <JEEB> yea
[19:29:38 CET] <JEEB> also usually you only know if it's dropped later
[19:29:48 CET] <JEEB> while if you want to drop it from decoding altogether you have to know before hand
[19:29:52 CET] <JEEB> as in, when you get the packet
[19:29:58 CET] <faLUCE> I also ask if is it possible to link the library in the official FFmpeg page
[19:30:05 CET] <jkqxz> sfan5:  Yes, the _N nal_unit_type values are what you want to look for.
[19:30:15 CET] <sfan5> okay thanks
[19:30:43 CET] <kurosu> jkqxz, probably, I wouldn't know - it's just that the question was more generic
[19:30:45 CET] <JEEB> faLUCE: that would imply some sort of push for your thing which I think is incorrect without people having experience in it and it being something of enough weight that can be recommended without further thoughts
[19:31:25 CET] <faLUCE> JEEB: I did not understand what you meant (forgive my poor english)
[19:31:51 CET] <faLUCE> do you mean that I need more feedback before pushing it in the official page?
[19:32:20 CET] <JEEB> you have to be something generally recommended by a large enough majority to get some sort of official push from the FFmpeg project
[19:33:02 CET] <faLUCE> JEEB: I see. what about the license? Is the procedure I followed correct or do I have to add something more?
[19:33:32 CET] <faLUCE> (all the source is open and I added the GPL 3.0 and later notice in each file of the project)
[19:33:36 CET] <kurosu> sfan5, maybe you can track that through ff_hevc_unref_frame, and check the cases not resulting from an error
[19:34:06 CET] <sfan5> that sounds like it'd be too much work just to implement skip_loop_filter
[19:34:14 CET] <sfan5> as in not worth the effort
[19:35:16 CET] <JEEB> faLUCE: your thing's license can be whatever it is, the stuff is just that you have to follow FFmpeg's license when distributing binaries (which shouldn't be hard for a GPLv3 thing :P)
[19:35:21 CET] <kurosu> in that case you could then have some marker saying "not deblocked", and whenever the frame is actually accessed, you do that
[19:35:36 CET] <kurosu> but you also have SAO after DBF, so...
[19:35:57 CET] <faLUCE> JEEB: I don't have any binary in my library. It is a header only library
[19:36:18 CET] <JEEB> faLUCE: also stop having this darn discussion duplicated, move just onto #ffmpeg
[19:36:51 CET] <kurosu> sounds cumbersome: when DBF/SAO are performed, you can't know if the frame will be reference or not, and postponing these post filters would require storing all the post filter info...
[19:44:08 CET] <kurosu> sfan5, that's for s/w decoding? on what platform?
[19:45:09 CET] <sfan5> just continuing what this patch implemented partially http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176112.html 
[19:49:19 CET] <kurosu> I'd have transformed that code in report_progress + return, because there's still sao done afterwards
[19:52:36 CET] <sfan5> just googled that and it sounds like it should skip that too
[19:53:43 CET] <sfan5> guess i'll do exactly what you suggested
[19:53:57 CET] <kurosu> that's probably occurring on <10% of the pixels, so that's not a big win anyway
[19:54:49 CET] <kurosu> the case where it is partially safe (frame not referenced) is cumbersome imho, so I'd just be content with this, which is probably okish for high enough bitrates
[19:55:47 CET] <sfan5> just relying on the encoder exporting that informating (_N types) sounds fine to me
[19:57:01 CET] <JEEB> yea
[19:57:03 CET] <kurosu> yeah, but that won't help as much - but then I don't know all the settings for skip_loop_filter
[19:57:35 CET] <sfan5> if you want to trade quality for speed you'd set skip_loop_filter=all anyway
[19:57:38 CET] <kurosu> it <AV_DISCARD_ALL, = should be an unconditional return
[19:57:57 CET] <kurosu> yeah
[20:00:02 CET] <kurosu> I have an educated guess that ffmpeg (or libav or any derivative) hevc decoder is 10-20% slower than it could be
[20:00:51 CET] <sfan5> wasn't it based on some external projects code?
[20:01:04 CET] <kurosu> openhevc, but same problem there
[20:01:27 CET] <kurosu> not for lack of simd, just inefficient code all around
[20:01:28 CET] <JEEB> smarter did the original HEVC decoder, not openhevc -- IIRC
[20:01:38 CET] <JEEB> but the lack of SIMD doesn't really help :P
[20:02:03 CET] <kurosu> I don't think there's anything missing nowadays
[20:02:16 CET] <kurosu> except maybe some avx2 for transforms mainly
[20:02:23 CET] <durandal_1707> whats inefficient?
[20:02:26 CET] <JEEB> IIRC there still are some intrinsics that nevcairiel applies
[20:02:40 CET] <JEEB> parts of openhevc that were never finished for upstreaming
[20:02:56 CET] <kurosu> oh, the intra
[20:02:58 CET] <JEEB> (openhevc did work a lot on multiview and scalable coding and intrinsics IIRC)
[20:03:15 CET] <kurosu> I don't think it matters much, probably <1% of profiling
[20:03:35 CET] <kurosu> except if you only have intra frames, obviously
[20:03:46 CET] <JEEB> well it seemed to be enough for some people at some point. haven't seen recent benchmarks
[20:03:55 CET] <JEEB> most recent was by hanna I think
[20:04:03 CET] <kurosu> ok
[20:04:20 CET] <JEEB> also adding a lot of threads tends to help with the instability of the FPS in the decoding
[20:04:32 CET] <JEEB> since you get the buffer of amount of threads
[20:23:11 CET] <kurosu> JEEB, if you have recent benchmarks, I'd like to have a link
[20:27:52 CET] <JEEB> kurosu: the most recent I remember is https://haasn.xyz/posts/2016-11-08-ffmpeg-hevc-decoding-benchmarks.html
[20:29:36 CET] <kurosu> "the intra pred SIMD basically made no difference at all"
[20:31:06 CET] <kurosu> and yeah, cabac is the killer here
[20:31:39 CET] <kurosu> openhevc offers to move it to its own thread
[20:31:53 CET] <JEEB> ah
[20:31:56 CET] <JEEB> kind of makes sense
[20:32:32 CET] <kurosu> yeah, but lots of efforts (need to buffer, add wait/report progress stuff and so on) and I don't know how much you gain
[20:32:49 CET] <kurosu> maybe reasonable on high bitrate + high cpu count systems
[20:32:50 CET] <JEEB> yup
[20:33:08 CET] <JEEB> deffo complexity
[20:34:03 CET] <kurosu> there was the patch series from some arm guy that was a reasonable improvement (3-5% overall?) but he was reluctant to work more on it afaik
[20:34:17 CET] <kurosu> (for inclusion)
[20:54:38 CET] <smarter> JEEB: I did the original HEVC decoder for libav as a gsoc project, at the end of the gsoc I could play I-frames
[20:54:45 CET] <JEEB> yup
[20:54:56 CET] <JEEB> and then rest of that year it was finished up
[20:54:56 CET] <smarter> Then a bunch of people worked on implementing everything else
[20:55:11 CET] <JEEB> plenty of people on the commit message :)
[20:55:20 CET] <JEEB> even me because of random valgrinding :D
[20:55:24 CET] <smarter> haha
[21:10:47 CET] <SortaCore> why does -timeout on rtsp result in bind address error?
[21:11:10 CET] <SortaCore> I saw a ffmpeg ticket with a fix, but apparently it wasn't approved
[21:11:40 CET] <SortaCore> https://trac.ffmpeg.org/ticket/2294
[21:12:41 CET] <wm4> didn't open that link, but we don't accept patches on trac
[21:13:03 CET] <SortaCore> yea, he was told to post to ML, but didn't
[21:13:13 CET] <SortaCore> https://github.com/FFmpeg/FFmpeg/pull/91/commits/61139a7e3ad3827db30d244e5875d9299759eb1a
[21:13:45 CET] <wm4> ...
[21:13:51 CET] <wm4> we don't accept PRs either
[21:13:57 CET] <SortaCore> boi
[21:14:16 CET] <wm4> https://github.com/FFmpeg/FFmpeg/pull/153
[21:14:23 CET] <wm4> though that was after that
[21:15:10 CET] <SortaCore> yea, that bug is ancient apparently
[21:15:27 CET] <SortaCore> I wasn't asking for that fix to be added, I'm just wondering why it's not fixed at all
[21:17:32 CET] <JEEB> SortaCore: nobody hit that same issue and nobody noticed the thing who cared enough
[21:18:04 CET] <SortaCore> rip fam
[21:18:22 CET] <omerjerk> xD
[21:18:32 CET] <SortaCore> I'm gonna make tea and then endure the pain of trying to patch >.>
[21:19:05 CET] <JEEB> but yea, FFmpeg does an awful lot of things and in the small amount of testing I've done with rtsp both at home and at the office this was never hit :P
[21:19:18 CET] <JEEB> so it's completely possible that even within the small circle that has ever utilized RTSP
[21:19:20 CET] <wm4> SortaCore: append .patch to the github commit URL, send as attachment to ffmpeg-devel
[21:19:27 CET] <wm4> it's not hard even if people think that
[21:19:32 CET] <wm4> that said, fuck mailing lists
[21:19:43 CET] <JEEB> yea, esp. if people don't version their patches
[21:19:55 CET] <SortaCore> my issue is with git itself
[21:19:57 CET] <JEEB> I've had to try and make sure I grabbed the latest version of a patch when applying
[21:20:20 CET] <SortaCore> plus in this fact the fix will probably be incompatible with current code
[21:20:33 CET] <JEEB> yea, that's possible. if you actaully want to make it applicable to current HEAD
[21:20:43 CET] <JEEB> depends on how many changes there have been since
[21:20:49 CET] <JEEB> (for those files)
[21:21:02 CET] <SortaCore> I've already modded current head, to make sure QSV only looks for hardware impl
[21:21:22 CET] <SortaCore> there doesn't appear to be an option you can pass
[21:21:41 CET] <SortaCore> so I just changed the enum from "impl any" to "impl any hardware"
[21:22:12 CET] <JEEB> I think some hwaccel already had that as an option
[21:22:31 CET] <JEEB> shouldn't be too hard to add an AVOption and then do an if/else thing
[21:22:48 CET] <JEEB> use_hw_only ? ONE_ENUM : ANOTHER_ENUM
[21:23:55 CET] <SortaCore> this would be good but I treat git like I do extracting snake venom for antidotes
[21:24:24 CET] <SortaCore> I'm normally fixing everything, but git is intimidating
[21:24:35 CET] <JEEB> yea, it can be
[21:24:45 CET] <JEEB> and it definitely has the tools to shoot your own feet off
[21:24:59 CET] <SortaCore> with C++ I could do that and not worry about other people
[21:25:20 CET] <JEEB> well with git unless you force push you don't lose anything :)
[21:25:21 CET] <SortaCore> but I'm a bit concerned I might somehow blow up everything
[21:25:29 CET] <JEEB> I mean, remotely
[21:25:34 CET] <SortaCore> overwrite the master branch with one file somehow
[21:25:40 CET] <JEEB> in the worst case you fsck up your local repo
[21:25:45 CET] <JEEB> and for local repo you have reflog
[21:25:51 CET] <JEEB> which is the log of last N positions
[21:26:11 CET] <SortaCore> no chance of screwing up ffmpeg remote then?
[21:26:23 CET] <JEEB> unless you have push access, no
[21:26:38 CET] <JEEB> (the URL is separate from the public clone one, too)
[21:26:43 CET] <SortaCore> ok, that's reassuring
[21:27:08 CET] <SortaCore> having said that, I'm now looking at the patch the guy submitted, and I can't see how it would fix anything
[21:28:04 CET] <SortaCore> oh, he moved an if
[21:28:23 CET] <JEEB> yea
[21:28:25 CET] <SortaCore> I know how to move ifs!
[21:28:34 CET] <JEEB> he stops setting |= RTSP_FLAG_LISTEN
[21:28:40 CET] <JEEB> when timeout is >0
[21:28:44 CET] <SortaCore> *scuffling* *distant explosion*
[21:28:47 CET] <SortaCore> there we go
[21:47:15 CET] <SortaCore> actually, infinite timeout only makes sense when you're sending, not receiving
[22:11:47 CET] <atomnuker> daddesio: ktnx, on a first look they all lgtm
[22:11:56 CET] <atomnuker> not sure about the downmixing part though
[22:12:11 CET] <atomnuker> does the decoder actually support downmixing?
[22:12:39 CET] <atomnuker> afaik in libopus you can specify what to downmix to but here you can't
[22:13:40 CET] <atomnuker> jamrial: do you think the doing saturation via packed functions (on scalars, so a mov + saturated add + a mov) would be faster than the C version?
[22:13:54 CET] <atomnuker> on x86 that is, because there are no scalar saturation functions here
[22:26:37 CET] <daddesio> atomnuker: My downmixing patch should be correct. Each Opus stream has 1 or 2 channels, so a multichannel OggOpus file contains multiple Opus streams. In FFmpeg, f->channels refers to the # of channels in the CELT frame (which is constrained to 1 or 2).
[22:27:07 CET] <daddesio> actually, you might be right
[22:27:18 CET] <daddesio> hold on
[22:30:16 CET] <daddesio> Libav uses s->coded_channels an s->output_channels in the CeltFrame context.
[22:32:31 CET] <daddesio> Ah yes, I used the wrong variable ! FFmpeg also has an f->decoded_channels.
[22:32:49 CET] <daddesio> Let me verify that it's set to the number of FFmpeg output channels.
[22:34:09 CET] <daddesio> atomnuker: f->decoded_channels is defined here https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/opus_celt.c#L806
[22:36:48 CET] <daddesio> Also, see this: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/opus_celt.c#L865
[22:37:17 CET] <daddesio> The patch should be correct if I change f->channels to f->output_channels.
[22:37:50 CET] <daddesio> As long as output_channels is indeed set correctly.
[22:41:05 CET] <jamrial> atomnuker: if you mean adding such a path in av_clip* functions, i don't know
[22:42:38 CET] <SortaCore> hmm
[22:42:51 CET] <SortaCore> I can't even use the io callback, the formatcontext doesn't exist yet
[23:06:07 CET] <SortaCore> seems like VLC is also failing to open the stream
[23:06:18 CET] <SortaCore> but nonetheless, if an error can occur, it must be detected
[23:12:10 CET] <daddesio> atomnuker: unfortunately it may not be that simple... f->output_channels is still 2 even when I pass -ac 1 to ffmpeg.
[23:14:28 CET] <SortaCore> there's a timeout limit of 1 minute somewhere in rtsp
[23:14:33 CET] <SortaCore> that seems a little high
[23:19:27 CET] <SortaCore> is there a way to pass interrupt_callback to avformat_open_input
[23:19:53 CET] <SortaCore> because the formatcontext isn't valid before, and the open_input seems to be blocking indefinitely
[23:20:14 CET] <SortaCore> the only idea I've come up with is an evil second thread
[23:31:16 CET] <cone-899> ffmpeg 03Paul B Mahol 07master:225341b20de6: avfilter/vf_stack: always copy SAR from first input
[23:31:22 CET] <nevcairiel> you can create a formatcontext before calling open_input
[23:31:38 CET] <nevcairiel> it only creates one for you if you dont pass one in
[23:32:10 CET] <nevcairiel> with avformat_alloc_context
[23:38:57 CET] <SortaCore> ah, danke
[23:54:52 CET] <Compn> jkqxz : ok, no problem. i have no problem with putting the headers in another repo, as long as people are happy :P
[23:54:58 CET] <Compn> jkqxz : thanks for the reply.
[00:00:00 CET] --- Sun Dec  3 2017