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

[burek]

[00:01:19 CET] <JEEB> http://up-cat.net/p/faf7bc9c
[00:01:24 CET] <JEEB> does this mean what I think it means?
[00:01:48 CET] <JEEB> (AVFrames get untouched)
[00:01:54 CET] <iive> a welcome party?
[02:53:18 CET] <alevinsn> wm4, jkqxz:  would be helpful to get the patch that fixes the D3D11 memory leak committed
[03:01:46 CET] <cone-296> ffmpeg 03Greg Wessels 07master:2c2f25eb8920: avutil/hwcontext_d3d11va: Fix leak when wrapping texture in AVD3D11FrameDescriptor
[03:02:15 CET] <jamrial> alevinsn: done
[03:02:47 CET] <alevinsn> thanks
[03:02:59 CET] <jamrial> jkqxz: feel free to bark at me if the patch wasn't good :p
[03:21:41 CET] <cone-296> ffmpeg 03James Almer 07master:cd1ff3e45d45: avformat: move priv_pts from AVStream to an internal struct
[04:21:17 CET] <atomnuker> J_Darnley: did you get somewhere in removing the deinterleave crap from vc2enc's dwt?
[09:41:38 CET] <cone-074> ffmpeg 03Carl Eugen Hoyos 07master:ba79a101a2f9: lavc/dnxhddata: Do not print frame rates with supported profiles.
[10:45:40 CET] <nevcairiel> JEEB: there is code in decode.c which copies avctx stuff to the frame thats being allocated
[10:48:07 CET] <JEEB> ah
[10:48:23 CET] <JEEB> ok, then that makes sense
[10:50:57 CET] <J_Darnley> atomnuker: no, I didn't start on it at all
[11:12:56 CET] <stevenliu> Hi guys, there have a contributor want add the company copyright into the hlsenc.c, i cannot sure should i add the patch into ffmpeg?
[11:13:37 CET] <BtbN> I don't think the copyright lines in the GPL header have any real meaning anyway?
[11:13:46 CET] <BtbN> It's (L)GPL after all
[11:15:21 CET] <stevenliu> That mean whatever, i can commit it into ffmpeg, right. if yes, i will test fate , if test passed, i will merge the patchset.
[11:16:52 CET] <stevenliu> or mean, no people care that, because ffmpeg under LGPL :D   do i misunderstand it?
[11:18:55 CET] <BtbN> I think the only reason for it existing is to attribute the code below it to someone.
[11:19:09 CET] <BtbN> So if they did meaningful contributions to it, why not?
[11:19:27 CET] <stevenliu> ok, i get it, Thanks
[11:22:56 CET] <BtbN> I'm a bit confused about that "legal team" thing he mentioned.
[11:23:20 CET] <BtbN> Not an expert on this, but I don't think that line has any legal effect?
[11:28:17 CET] <durandal_1707> stevenliu: have link to the patch?
[11:30:03 CET] <BtbN> I don't think our patchwork properly picks up patches as attachments
[12:19:11 CET] <stevenliu> durandal_1707:  just in maillist
[12:20:30 CET] <stevenliu> title is : [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance 
[12:22:34 CET] <durandal_1707> stevenliu: yes, adding just one line on top of file is ok
[12:22:55 CET] <stevenliu> ok, thanks :D
[14:55:21 CET] <J_Darnley> Oh my.  The table of possible exceptions has become much more complicated with avx512
[14:57:26 CET] <J_Darnley> Okay... VMOVDQA32 is in exception class E1
[14:57:36 CET] <J_Darnley> *Type E1
[14:58:52 CET] <J_Darnley> Type E1 is "Vector Moves/Load/Stores"
[14:59:10 CET] <J_Darnley> Its mem arg is "Explicitly aligned, w/ fault suppression"
[15:01:26 CET] <J_Darnley> So that means location should be 64-byte aligned
[15:01:29 CET] <J_Darnley> but the fault will be suppressed
[15:01:36 CET] <J_Darnley> so execution will just continue?
[15:09:09 CET] <J_Darnley> or not?
[15:09:34 CET] <J_Darnley> Well obviously not.  This address is only 32-byte aligned and has caused a segfault
[15:13:22 CET] <iive> yes it has to be 64 byte aligned.
[15:15:52 CET] <iive> it loads the whole register, and the mask is used to zeroe some 32 bit parts
[16:15:26 CET] <J_Darnley> Sigh.  How is the alignment of s->block and/or s->blocksq
[16:17:10 CET] <kierank> J_Darnley: DECLARE_ALIGNED in mpegvideo.h
[16:17:11 CET] <kierank> iirc
[16:17:44 CET] <J_Darnley> oops, I guess I pressed enter in the wrong window
[16:18:43 CET] <kierank> ?
[16:19:25 CET] <J_Darnley> You managed to interpret correctly so nevermind
[16:20:01 CET] <J_Darnley> There isn't a DECLARE_ALIGNED in that header
[16:22:03 CET] <J_Darnley> I must have overlooked a change somewhere
[16:23:26 CET] <durandal_1707> kierank: have guy interested in improving cineform decoder contacted you again?
[16:25:53 CET] <jamrial> J_Darnley: that macro is lavu mem stuff
[16:27:00 CET] <J_Darnley> Yeah, I know that.  I've already added a _64 version and used it in a few places but I can't see where s->block and/or s->blocks get aligned.
[16:27:37 CET] <J_Darnley> See cbbec68847 for what I am basingmy change on
[16:34:01 CET] <kierank> durandal_1707: no guy contacted me
[16:36:13 CET] <J_Darnley> Perhaps I should double check what "int16_t (*block)[64]" declares.  That is 1 pointer, right?
[16:42:16 CET] <BBB> yes
[16:42:34 CET] <BBB> e.g. block[6][64], (*block2)[64] = block
[16:43:06 CET] <BBB> its one pointer to a 2d (but single-memory-block) array
[16:59:50 CET] <J_Darnley> Ah hah!  See libavutil/mem.c:64
[17:03:54 CET] <jamrial> J_Darnley: yes, and you also need to change STRIDE_ALIGN in libavcodec/internal.h
[17:04:18 CET] <J_Darnley> Yeah, I found that already or was pointed to it.
[17:04:59 CET] <jamrial> because av_cpu_max_align() can't be used for this as there's nothing stopping the user from changing cpu flags on the fly with av_force_cpu_flags()
[17:06:34 CET] <nevcairiel> we should just let users crash if they do that, you gotta learn somehow not to touch the open flame, etc
[17:07:27 CET] <J_Darnley> "force"?  Will that allow them to SIGILL?
[17:07:58 CET] <nevcairiel> probably, its a dumb as fuck function
[17:08:37 CET] <J_Darnley> Then I agree with you.  Let them also crash on misalignment.
[17:09:12 CET] <iive> jamrial: if they force the flags, won't this mean that e.g. avx512 assembly won't be used
[17:09:39 CET] <nevcairiel> the idea is that they force it lower, allocate a bunch of things, and then force it back up
[17:09:42 CET] <jamrial> function pointers are set during init
[17:09:44 CET] <nevcairiel> its some t heoretical nonsense
[17:09:59 CET] <nevcairiel> or that
[17:10:02 CET] <nevcairiel> call init before changing it
[17:10:12 CET] <nevcairiel> so that a dsp context is already set for another cpu flags
[17:10:36 CET] <nevcairiel> that function will never do anything useful beyond calling it the very first thing
[17:14:20 CET] <jamrial> av_force_cpu_flags() is in any case a developer function. nobody but asm devs ever call ffmpeg with -cpuflags
[17:15:01 CET] <jamrial> maybe we could just add a notice to its doxy function saying "reinit your shit after forcing flags with this function" and call it a day
[17:18:32 CET] <kierank> durandal_1707: you can fix broken cineform samples from new code if you want
[17:18:45 CET] <kierank> and the author is nice guy, he will answer your questions
[17:22:20 CET] <durandal_1707> well, if other guy does not show up...
[17:22:58 CET] <kierank> i don't remember other guy tbh
[17:23:53 CET] <durandal_1707> the loudnorm contributor iirc
[17:26:22 CET] <kierank> probably some guys will pay you to add the film scanning support
[17:26:27 CET] <kierank> forgot the name of the format it uses
[17:31:29 CET] <durandal_1707> dpx?
[17:38:35 CET] <kierank> bayer
[17:40:17 CET] <durandal_1707> hmm, that needs swscale changes
[17:40:42 CET] <cone-410> ffmpeg 03Vittorio Giovara 07master:ce1a99d870c0: hevc: Make sure to update the current frame transfer characteristic
[17:40:43 CET] <cone-410> ffmpeg 03Anton Khirnov 07master:48a5c35346ae: caf: add an Opus tag
[17:40:44 CET] <cone-410> ffmpeg 03wm4 07master:9b9285bbf18e: dxva: DXVA2_ModeHEVC_VLD_Main10 does not support Main
[17:40:45 CET] <cone-410> ffmpeg 03wm4 07master:2b1324bd1675: lavf: allow avformat_close_input() with NULL
[17:40:46 CET] <cone-410> ffmpeg 03James Almer 07master:51f977c2c4b3: Merge commit '2b1324bd167553f49736e4eaa94f96da9982925e'
[17:49:01 CET] <cone-410> ffmpeg 03Huang, Zhengxu 07master:2fd6e7d077f5: libavcodec/mjpeg_qsv: Add QSV MJPEG encoder
[17:49:02 CET] <cone-410> ffmpeg 03Huang, Zhengxu 07master:550cb6a85d0f: lavf/vf_deinterlace_qsv: Enable the qsv deinterlace vpp
[17:49:03 CET] <cone-410> ffmpeg 03James Almer 07master:1926f13a206b: Merge commit '2fd6e7d077f590e4d7195356f9baeb271f8b9ae2'
[17:49:04 CET] <cone-410> ffmpeg 03James Almer 07master:975db5dcc2ed: Merge commit '550cb6a85d0f7211289f7a789527d48cb29460ff'
[17:55:46 CET] <cone-410> ffmpeg 03Sean McGovern 07master:80e919b17435: rmdec: add missing brackets to compound statement
[17:55:47 CET] <cone-410> ffmpeg 03wm4 07master:47399ccdfd93: lavc, lavu: move frame cropping to a convenience function
[17:55:48 CET] <cone-410> ffmpeg 03wm4 07master:45df7adc1d9b: imgutils: add function to clear an image to black
[17:55:49 CET] <cone-410> ffmpeg 03James Almer 07master:5fd6fa0ca7f3: Merge commit '45df7adc1d9b7e8fbae5af9328baa6ab3562002b'
[18:02:17 CET] <Gramner> J_Darnley: the evex exception classes is due to masking. elements that are masked out will not cause exceptions. e.g. you wont segfault from reading past the end of an array if the bits in the opmask register corresponding to the elements past the end are 0
[18:03:15 CET] <atomnuker> durandal_1707: not really, you could probably build support for it in vf_colorspace
[18:03:33 CET] <atomnuker> though you'll need to figure out how to convert it to xyz
[18:03:35 CET] <Gramner> if all elements are masked away you can even do vmulps zmm0 {k1}, [0] if you want to and it will run fine
[18:08:53 CET] <atomnuker> BBB: can vf_colorspace become swscale now?
[18:09:28 CET] <BBB> no
[18:10:16 CET] <durandal_1707> nobody wants to fix old stuff for free
[18:10:30 CET] <Compn> we should intentionally break everything and then wait to be paid to fix it 
[18:10:31 CET] <BBB> its not for-free, I just dont want to get into new trollwars about it
[18:10:55 CET] <BBB> swscale exists, it does something and works for some things, let people use it as they want
[18:11:10 CET] <BBB> vf_colorspace exists, it does something and works for some things, let people use it as they want
[18:11:14 CET] <Compn> my idea : we make swscale one of many colorspace converters that the user can select...
[18:11:22 CET] <BBB> it prevents pointless trollwars and keeps my mind sane and allows me to work on fun things
[18:11:33 CET] <Compn> then we put gimp and other pix transforms in ffmpeg :)
[18:11:41 CET] <Compn> imagemagick has one
[18:11:42 CET] <BBB> zscale?
[18:12:26 CET] <iive> Gramner: strange, the documentation doesn't mention anything like that.
[18:12:34 CET] <BBB> I assure you that if I announced today that I was working on revamping swscale or rewriting it or something like that, Id be trolled to death and would never have motivation to work again on anything whatsoever
[18:12:40 CET] <Compn> BBB : you are still holding on to your sanity? :) 
[18:12:42 CET] <Gramner> it does, just not very clearly
[18:12:54 CET] <BBB> Compn: Im ok, sure, yes
[18:12:59 CET] <BBB> why?
[18:13:19 CET] <Compn> i did not mean to imply anything, just that open source tends to make people go insane 
[18:13:31 CET] <BBB> turn off tv/radio, dont read too much news, pay attention to irc on a diet, and life is quite ok :)
[18:13:38 CET] <Compn> good good
[18:13:49 CET] <Compn> im off to bike ride 3 miles, later 
[18:13:58 CET] <jamrial> i don't think anyone likes swscale, so who would troll anyone that publicly says they intendo to revamp/rewrite it?
[18:13:58 CET] <BBB> netflix is fantastic, it allows me to watch movies yet no troll-ads for medication for arthritis etc.
[18:14:11 CET] <BBB> Compn: have fun!
[18:14:28 CET] <Compn> i mean, they have troll movies now
[18:14:36 CET] <Compn> yes, give adam sandler more money...
[18:16:34 CET] <atomnuker> BBB: ok can swscale become vf_colorspace now?
[18:17:42 CET] <kierank> it can become /dev/null hopefully
[18:17:56 CET] <BBB> atomnuker: no
[18:17:57 CET] <nevcairiel> do you have a replacement? =p
[18:18:09 CET] <iive> Gramner: can you give me a quote/link/pointer, because the one I'm reading is quite clearly states otherwise.
[18:18:23 CET] <atomnuker> BBB: ok can vf_colorspace become vf_colorspace now?
[18:18:59 CET] <BBB> I think so
[18:19:03 CET] <BBB> brb
[18:19:05 CET] <atomnuker> right, identity operation verified, its halfway to being a group now
[18:20:04 CET] <durandal_1707> atomnuker: what are you doing?
[18:20:50 CET] <Gramner> iive: "The instructions operation is not performed for an element if the corresponding opmask bit is not set. This implies that no exception or violation can be caused by an operation on a masked-off element."
[18:21:23 CET] <atomnuker> science
[18:22:27 CET] <Gramner> that quote is from Intel® Architecture Instruction Set Extensions Programming Reference, October 2017
[18:22:39 CET] <Gramner> 2016*
[18:23:07 CET] <Gramner> just the version I had around, it's likely the same in every version
[18:23:38 CET] <iive> ". When the source or destination operand is a memory operand, the operand must be aligned on a 16 (EVEX.128)/32(EVEX.256)/64(EVEX.512)-byte boundary or a general-protection exception (#GP) will be generated. To move integer data to and from unaligned memory locations, use the VMOVDQU instruction."
[18:25:52 CET] <ubitux> atomnuker: there are a few for (int ...) to fix in the patch
[18:25:58 CET] Action: ubitux too lazy to comment...
[18:26:36 CET] <Gramner> alignment requirement and validity of memory is unrelated concepts
[18:28:24 CET] <iive> "For some instructions with a memory operand, memory faults are suppressed for elements with a mask bit of 0."
[18:28:39 CET] <atomnuker> ubitux: can't fix unless you comment
[18:29:08 CET] <ubitux> ah michael just commented it
[18:29:13 CET] <ubitux> saved me a mail
[18:29:21 CET] <durandal_1707> lol, just fix it and apply
[18:31:46 CET] <iive> Gramner: J_Darnley's problem was alignment. I took your comment as reasoning that if you have the unaligned data parts masked out, it will not trigger exception.
[18:32:21 CET] <cone-410> ffmpeg 03Anton Khirnov 07master:45c4bf3df03e: h264dec: track the last seen value of x264_build
[18:32:23 CET] <cone-410> ffmpeg 03Yogender Kumar Gupta 07master:79c6477c2abd: h264dec: fix Lossless Decoding (Profile 244) for 8x8 Intra Prediction
[18:32:23 CET] <cone-410> ffmpeg 03Anton Mitrofanov 07master:18d3f36d3c4d: h264_cabac: Fix CABAC+8x8dct in 4:4:4
[18:32:24 CET] <cone-410> ffmpeg 03Anton Mitrofanov 07master:70946e605924: h264dec: Fix mix of lossless and lossy MBs decoding
[18:32:25 CET] <cone-410> ffmpeg 03James Almer 07master:bc987cf91dd9: Merge commit '45c4bf3df03ef53ae61fa1473424d4ae024f22e4'
[18:32:26 CET] <cone-410> ffmpeg 03James Almer 07master:d49ca877d0e4: Merge commit '70946e605924e2108c39f96faa369c220177f301'
[18:32:43 CET] <durandal_1707> ubitux: why webvtt demuxer/decoder doesnt handle positioning?
[18:32:53 CET] <BtbN> Can someone take a look at CID #1419523? It looks like a false positive to me. new_device is not lost, it's in the devices dynarray
[18:32:54 CET] <Gramner> iive: ah, my comment was in relation to "(+J_Darnley) Oh my. The table of possible exceptions has become much more complicated with avx512"
[18:33:05 CET] <iive> Gramner: the documentation says this might be the case for some instructions, but I am not sure vmovdqa32 is one of them.
[18:33:40 CET] <ubitux> durandal_1707: how does it look like?
[18:33:49 CET] <Gramner> I don't think alignment checking is classified as a memory fault so that will probably always trigger, yes
[18:34:59 CET] <jamrial> alright, just reached the hwaccel set
[18:36:01 CET] <durandal_1707> o/
[18:36:06 CET] <jamrial> michaelni: what is it going to be? if you insist on not using opaque_ref, then what will be done? BtbN seems to prefer private_ref as nevcairiel suggested
[18:36:42 CET] <durandal_1707> ubitux: positioning is ignored
[18:36:52 CET] <BtbN> I don't have a strong oppinion on the variable name
[18:37:12 CET] <ubitux> durandal_1707: i mean, do you have a sample?
[18:37:24 CET] <BtbN> private_ref which is documented to only ever being used internally in a single library, not for cross-library stuff
[18:37:32 CET] <ubitux> (like, how is it stored)
[18:37:58 CET] <michaelni> jamrial, ill change it to what people prefer unless someone else is faster (i still have a few things todo before ill update the patch)
[18:39:06 CET] <jamrial> BtbN: ah. single library use is what michaelni did for his patch. nevcairiel suggestion was cross library afaik
[18:39:20 CET] <BtbN> Wasn't it the other way around?
[18:39:43 CET] <durandal_1707> ubitux: :) from spec only
[18:40:11 CET] <ubitux> durandal_1707: well then& :)
[18:40:28 CET] <jamrial> BtbN: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219166.html is the patch, and http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219168.html is nevcairiel's suggestion
[18:40:28 CET] <ubitux> you can look at how srt/subrip handles it
[18:40:35 CET] <ubitux> if you care about it
[18:41:27 CET] <BtbN> jamrial, ah, it was avcodec-only to any-library-only
[18:43:59 CET] <jamrial> yeah, basically, even if for now it will be lavc only, the suggestion was one field that may be used internally by all libraries to avoid adding a new field for lavfi or whatever needs to handle frames in the future
[18:44:44 CET] <jamrial> it is in any case not really important for now, since it will be used by lavc only for the foreseeable future
[18:48:44 CET] <BBB> atomnuker: sorry, was on a call, couldnt respond more verbosely
[18:49:00 CET] <BBB> atomnuker: so uh, I dont think swscale vs. vf_colorspace should be on the top of our list
[18:49:08 CET] <BBB> theres various people interested in this subject matter
[18:49:22 CET] <BBB> and I think if we try to fix it now before addressing some other issues, well just make things worse
[18:49:31 CET] <BBB> e.g. lu_zero also wants to write a avscale
[18:49:43 CET] <BBB> if we start, well just trigger them into doing the same thing and double the problem size
[18:54:32 CET] <cone-410> ffmpeg 03James Almer 07master:4cfb46f94f1d: checkasm/llviddsp: fix warnings about mixed declaration and code
[18:55:18 CET] <atomnuker> BBB: if we start we'd be likely to finish it though
[18:55:35 CET] <atomnuker> I don't see other issues though, I think swscale just needs another api
[18:55:45 CET] <atomnuker> some bugfixes and a little polish and it'll be fine
[18:59:25 CET] <cone-410> ffmpeg 03James Almer 07master:9d3eb75cf637: avcodec/qsvenc_jpeg: fix copyright header
[20:59:33 CET] <cone-410> ffmpeg 03Kaustubh Raste 07master:4878854eefe6: avcodec/mips: Improve hevc bi wgt 4 tap hv mc msa functions
[20:59:34 CET] <cone-410> ffmpeg 03Kaustubh Raste 07master:350721e9fd6b: avcodec/mips: Improve hevc uni 4 tap hv mc msa functions
[20:59:35 CET] <cone-410> ffmpeg 03Kaustubh Raste 07master:4fba8728e82f: avcodec/mips: Improve hevc uni weighted 4 tap vt mc msa functions
[20:59:36 CET] <cone-410> ffmpeg 03Kaustubh Raste 07master:372a4dda3356: avcodec/mips: Improve hevc non-uni hv mc msa functions
[21:05:02 CET] <cone-410> ffmpeg 03James Almer 07master:349e9a878767: avformat/ty: fix format specifiers in debug log messages
[21:35:02 CET] <jamrial> why does everyone seem to hate the side data API?
[21:35:20 CET] <nevcairiel> nicolas hates everything these days, and rarely if ever provides solutions
[21:35:40 CET] <durandal_1707> everyone is not Nicolas
[21:35:59 CET] <jamrial> it's not just him, wm4 also said he hated it, and was hoping ubitux could come up with a replacement or such
[21:36:44 CET] <durandal_1707> i do not thinks so, wm4 loves libav
[21:36:50 CET] <jamrial> i mean, i know having frame/pkt/stream side data with slightly different API each is a tad annoying, but for things that are used by one codec or feature there's no reason to pollute the avframe or avpacket structs
[21:36:55 CET] <nevcairiel> wm4 just hatest that there is no generic sidedata list structure with a single api, instead everything that uses them has a different api
[21:37:27 CET] <jamrial> efforts have been made to remove lots of single codec fields from avcodeccontext. why go the other way with avframe/avpacket?
[21:37:51 CET] <nevcairiel> not like thats actually going to happen
[21:47:57 CET] <TD-Linux> BBB, btw what happens if I try to put RGB24 into vf_colorspace? does it go through swscale first?
[21:48:18 CET] <BBB> I believe vittorio did something with that at some point, didnt he?
[21:48:24 CET] <BBB> it obviously only accepts GBRP (planar RGB)
[21:48:44 CET] <nevcairiel> avfilter will convert it for you
[21:48:46 CET] <BBB> the conversion of RGB24 to GBRP does go through swscale, but I believe it doesnt touch your pixels
[21:48:54 CET] <BBB> it just reorders them
[21:49:00 CET] <nevcairiel> assuming sws is actually sane
[21:49:01 CET] <BBB> all of this IIRC, I dont recall 100%
[21:49:02 CET] <nevcairiel> :)
[21:49:10 CET] <jkqxz> How does this gamma thing interact with color_trc?
[21:49:15 CET] <nevcairiel> it doesnt
[21:49:35 CET] <BBB> vf_colorspace only uses color_trc, it completely ignores the gamma property
[21:49:41 CET] <BBB> IIRC
[21:49:50 CET] <BBB> but support for gamma wouldnt be hard to add
[21:49:51 CET] <nevcairiel> of course it does, the gamma property doesnt exist yet =p
[21:49:55 CET] <TD-Linux> BBB, okay. I ask because it is touching pixels from testsrc with a 1:1 input to output so trying to figure out where it's coming from
[21:49:56 CET] <BBB> oh
[21:49:58 CET] <BBB> :-p
[21:50:08 CET] <jkqxz> I mean, in general.  If both are set what should happen?
[21:50:30 CET] <jkqxz> (Or am I not quite understanding what it means...)
[21:50:36 CET] <atomnuker> jkqxz: that gamma thing on the ML? its only useful for png images where non-gamma aware scalers scale things differently (so you get 2 different images depending on scaling)
[21:50:39 CET] <BBB> jkqxz: I dont know exactly what gamma means so I guess ¯\_(Ä)_/¯
[21:50:59 CET] <BBB> (means being how it is defined in the API as taking precedence etc.)
[21:53:35 CET] <jamrial> durandal_1707: can you try to not make things any more complex than they already are?
[21:53:50 CET] <jkqxz> Should setting AV_FRAME_DATA_GAMMA == 11/5 have identical behaviour to setting color_trc to AVCOL_TRC_GAMMA22, assuming everyone does the right thing with both fields?
[21:54:21 CET] <jamrial> it's a stupid side data patch for png. don't turn it into a project policy war
[22:02:20 CET] <jamrial> some of the shortest fuses i've ever seen these past months
[22:05:21 CET] <Compn> people are on fire
[22:08:55 CET] <alevinsn> jamrial:  it looks like you've made most of the recent non-merge changes to configure, many after the fine-grained link-time dependency settings merge
[22:09:26 CET] <alevinsn> I submitted to patches, one of which was to fix an issue related to that merge with the libmfx build on Windows
[22:09:36 CET] <alevinsn> two patches I mean
[22:10:26 CET] <alevinsn> I looked in the MAINTAINERS file to see who "maintains" configure and related stuff
[22:10:37 CET] <alevinsn> but no one is listed there--I had thought it was nevcairiel in the past
[22:11:32 CET] <Compn> it was diego , so long ago
[22:11:51 CET] <Compn> possibly mans before that 
[22:11:55 CET] <Compn> the in tree builds and such
[22:12:10 CET] <Compn> out of tree builds*
[22:12:12 CET] <Compn> whichever tree
[22:12:20 CET] Action: Compn slumps away
[22:12:26 CET] <alevinsn> well, at this point, it is mostly altered through merges and anyone who has modification writes
[22:12:33 CET] <alevinsn> rights
[22:12:37 CET] <alevinsn> spelling terrible today
[22:12:49 CET] <Compn> alevinsn : so what is your question ?
[22:13:05 CET] <Compn> you want to get a patch OK'd ?
[22:13:11 CET] <alevinsn> yes....
[22:13:25 CET] <Compn> and you were trying to ping jamrial to OK it...
[22:13:27 CET] <alevinsn> nevcairiel responded to the first
[22:13:27 CET] <Compn> :)
[22:13:37 CET] <alevinsn> on the list, and I responded back, and that was it
[22:13:49 CET] <Compn> yeah, send a ping then
[22:13:53 CET] <Compn> or ping them here
[22:13:58 CET] <alevinsn> I'll do whatever is needed to get the patches approved so I can stop maintaining and babysitting them :-)
[22:14:27 CET] <Compn> sometimes its more fun just to get commit rights and commit it yourself :D
[22:15:23 CET] <alevinsn> I had suggested it some months ago here on IRC, but no one was interested in it
[22:15:26 CET] <alevinsn> at the time at least
[22:15:32 CET] <Compn> ah
[22:15:40 CET] <Compn> hence my suggestion to get commit rights :)
[22:17:00 CET] <alevinsn> With commit rights comes some responsibility, right?  At a minimum, doing more frequent code reviews, right?
[22:17:20 CET] <Compn> no
[22:17:23 CET] <Compn> nothing like that
[22:17:42 CET] <Compn> it just means you commit something that works and takes the responsibility of committing it away from other devs
[22:17:45 CET] <alevinsn> I mean, that would be fine--it does seem to me that anyone with commit rights perhaps ought to be more involved in doing code reviews
[22:17:47 CET] <durandal_1707> now aptX is blocked because of stupid int in for loop
[22:18:46 CET] <alevinsn> so, is the best way to get commit rights simply to submit a patch adding myself to the maintainers list?
[22:18:54 CET] <durandal_1707> atomnuker: if you not gonna "fix" it i will push it "fixed"
[22:19:05 CET] <atomnuker> durandal_1707: fix what?
[22:19:39 CET] <atomnuker> I can't push it because the muxer patch fails and I want both in at the same time
[22:19:51 CET] <durandal_1707> alevinsn: no, you must send bunch of patches first to prove yourself worthy
[22:20:07 CET] <atomnuker> so I'm waiting for the muxer patch to get updated before I push it, not the for stuff
[22:20:08 CET] <alevinsn> A number of my patches have been committed over the last several months
[22:20:17 CET] <Compn> alevinsn : i dont think you have to officially maintain either, but you should probably send your key to michaelni , assuming you have been around a while, and agree with the dev rules...
[22:20:25 CET] <Compn> and ask him for commit rights
[22:20:53 CET] <alevinsn> some have been rejected as well
[22:21:24 CET] <durandal_1707> atomnuker: isnt it just doc part that breaks, fix it manually
[22:23:24 CET] <durandal_1707> alevinsn: what kind of patches? quality and quantity matters
[22:23:29 CET] <iive> alevinsn: so, your patches are not pushed, so you want to get commit rights in order to push them, but in order to get these rights, you must have a bunch of approved and committed patches ...
[22:24:07 CET] <Compn> alevinsn : welcome to kafka :D
[22:24:16 CET] <Compn> and or brazil.
[22:24:18 CET] <durandal_1707> just ping patches
[22:24:45 CET] <alevinsn> durandal_1707, iive:  mostly relatively small patches, some fixing build issues, some QSV bug fixes, one bug fix due to incorrect memory free in Direct3D HW context or something like that
[22:25:23 CET] <atomnuker> durandal_1707: git am completely refuses to let me fix it and I don't want to mess with recreating the patch down to the time and author info
[22:26:10 CET] <durandal_1707> just edit patch and remove doc hunk
[22:26:24 CET] <Compn> manually?
[22:26:28 CET] <Compn> hehehe
[22:26:38 CET] <atomnuker> then iive will complain about me amending someone else's patch
[22:27:04 CET] <alevinsn> There's a file, I think, with a list of commits that are included in a particular release
[22:27:14 CET] <alevinsn> but I forget where that can be found--anyone here recall?
[22:27:15 CET] <durandal_1707> ah, yes, should talk in private next time
[22:28:15 CET] <iive> git formatted patches won't apply if the checksum is wrong, and it would be wrong if the patch has been manually edited.
[22:32:15 CET] <durandal_1707> i did it numerous times, im wicked
[22:41:12 CET] <alevinsn> ok, a total of 9 patches committed pertaining to qsvenc, decklink, Windows build issues, hwcontext_dxva2, and one memory leak
[22:41:21 CET] <durandal_1707> alevinsn: its git command and releases have some sort of it in Changelog iirc
[22:42:08 CET] <alevinsn> perhaps 5-6 patches additional either rejected, ignored, or abandoned
[22:42:29 CET] <durandal_1707> about what?
[22:44:29 CET] <alevinsn> first set of patches had to do with fixing interlaced video decoding in ffmpeg--michaelni eventually discovered that the change introduced a timing issue
[22:44:38 CET] <alevinsn> that broke one of his test cases
[22:44:56 CET] <alevinsn> originally was one patch, but was broken into two--both abandoned
[22:45:32 CET] <alevinsn> one was a bad idea of mine in configure
[22:45:46 CET] <alevinsn> I submitted a documentation patch that no one was interested in
[22:46:02 CET] <durandal_1707> about what?
[22:46:09 CET] <alevinsn> fate.texi
[22:46:23 CET] <alevinsn> there was discussion on it, but then nothing, and it wasn't all that important in the end
[22:46:31 CET] <alevinsn> https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=302
[22:47:13 CET] <alevinsn> I think I have gotten better at working in the ffmpeg code base and writing patch descriptions that adhere to FFmpeg check-in conventions since I started
[22:47:45 CET] <alevinsn> Sorry:  this one is better:  https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=302&state=%2A&archive=both
[22:50:34 CET] <cone-410> ffmpeg 03Carl Eugen Hoyos 07master:da99b3f0c90a: lavfi/scale2ref: Set output frame rate to main input frame rate.
[22:51:01 CET] <Compn> alevinsn : you will have to learn to ignore comments of an unrelated nature, especially when you do not need to adress them :)
[22:51:03 CET] <Compn> hhehe
[22:51:04 CET] Action: Compn runs
[23:33:35 CET] <cone-410> ffmpeg 03James Almer 07master:69218b419808: configure: add missing avutil deps for hwcontext modules
[00:00:00 CET] --- Thu Nov  9 2017