[00:10:03 CEST] <kierank> there are options not available on the cli [00:19:46 CEST] <kierank> BBB: http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=1180... [00:19:47 CEST] <kierank> congrats [00:22:11 CEST] <jamrial> whoa, neat [00:27:09 CEST] <BBB> sweet [00:27:19 CEST] <BBB> why is everyone still doing hevc? [00:27:39 CEST] <BBB> I guess 10bit support in hevc is better developed than it is for vp9, particularly in terms of client support [00:27:42 CEST] <BBB> (tvs etc.) [00:28:20 CEST] <nevcairiel> vp9 also lacks any kind of in-band metadata like SEI for HDR or whatnot, using the container is a bit awkward, wonder if they have that for av1 [00:28:45 CEST] <BBB> I think the reason is that for internet streaming this stuff is unlikely to change within a stream [00:28:56 CEST] <BBB> and for stream switching you can use container-level stuff like HLS or whatever [00:29:17 CEST] <BBB> I dont think av1 is doing this stuff differently ATM [00:29:25 CEST] <BBB> (but I dont know all av1 details) [00:29:32 CEST] <nevcairiel> i would still prefer all video relevant things to come from the bitstream [00:29:44 CEST] <nevcairiel> piecing it together from different sources is always awkward [00:30:01 CEST] <BBB> thats true [00:30:22 CEST] <BBB> brb, dinner [00:30:25 CEST] <nevcairiel> there is also problems with "who is right" which noone ever specifies [00:30:42 CEST] <nevcairiel> like vp9 has some color matrix flags, but the container has more [00:30:48 CEST] <nevcairiel> what if they disagree [00:30:51 CEST] <BBB> I certainly agree vui-style signaling in vp9 could be improved [00:31:05 CEST] <BBB> I think the container level takes priority becuse it was added since the codec level stuff was incomplete/suboptimal [00:31:13 CEST] <BBB> but youre right, who knows, right? :) [00:31:15 CEST] <BBB> brb [00:33:37 CEST] <Compn> 8%!!!!!!! [00:34:46 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:a234b5ade3ca: avcodec/mdec: Fix signed integer overflow: 28835400 * 83 cannot be represented in type 'int' [00:34:47 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:a8ad83b793e8: avcodec/aacsbr_template: Do not leave bs_num_env invalid [00:34:48 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:12dea8a5a153: avcodec/ivi: Free custom blk_vlc [00:34:49 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:35f3df0d76e2: avutil/softfloat: Fix multiple runtime error: left shift of negative value -8 [00:36:33 CEST] <TD-Linux> nevcairiel, https://aomedia-review.googlesource.com/#/c/8738/ [00:37:30 CEST] <nevcairiel> man gerrits ui is so terrible [00:37:45 CEST] <TD-Linux> ?polygerrit=0 makes it tolerable [00:37:58 CEST] <nevcairiel> thats better [00:39:16 CEST] <nevcairiel> those fields added there are the very least tehy should have, still no arbitrary metadata for eg. HDR [00:39:49 CEST] <TD-Linux> yes, the HDR level information isn't there yet [00:40:31 CEST] <nevcairiel> one problem with HDR is that the tech is still evolving, so without some extensible syntax elements like SEI it will be very limited very fast [00:40:51 CEST] <nevcairiel> HEVC is adding a bunch new HDR signaling SEIs in the next spec update [00:41:23 CEST] <TD-Linux> yes, extension points for metadata are quite desired so I expect them to get in at some point [00:42:10 CEST] <nevcairiel> wasnt the bitstream supposed to freeze soon [00:43:59 CEST] <TD-Linux> BBB, also nice [00:44:49 CEST] <nevcairiel> everyone said vpxenc rate-control was garbage, but they never fixed it, so good for BBB :) [00:45:02 CEST] <TD-Linux> atomnuker is fixing it t oo [00:59:50 CEST] <jamrial> nevcairiel: pushed until the end of this year it seems [01:10:49 CEST] <cone-036> ffmpeg 03James Almer 07master:214f4133c4cb: avcodec/hevc_parser: move hevc_find_frame_end() down in the file [01:10:50 CEST] <cone-036> ffmpeg 03James Almer 07master:859cc5c8e662: avcodec/hevc_parser: cosmetics [02:12:38 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:523205ce1ed9: avcodec/snowdec: Check qbias [02:56:58 CEST] <james999> endrift: it said you closed a thread about mGBA link from 2015 a bit back [02:57:20 CEST] <james999> was wondering if that's because the issue was fixed or you decided to drop it [04:27:26 CEST] <wm4> Subject: [libav-devel] [PATCH 0-9/200] Introduction to a new channel layout API [04:27:29 CEST] <wm4> what a good start [04:37:16 CEST] <kierank> wm4: not actually that many changes [04:37:22 CEST] <kierank> but it's done as a 200 patchset [04:38:05 CEST] <wm4> probably 1 per decoder/encoder/filter [04:42:01 CEST] <jamrial> yeah, same as codecpar and such [04:54:24 CEST] <philipl> It's a great way to catch up on being 1000 changes behind :-) [04:57:34 CEST] <wm4> I expect most of those patches to be quite trivial (just converting between channel mask and the new struct) [04:58:04 CEST] <jamrial> in some cases they squash it all into one as well [04:58:06 CEST] <wm4> though the fact that ffmpeg for some reason kept a separate channel count complicates this [04:58:10 CEST] <jamrial> codecpar was squashed, bitstream reader wasn't [05:18:04 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:e813df4fa345: avcodec: Avoid splitting side data repeatedly [06:38:37 CEST] <alevinsn> jkqxz: you there> [06:38:38 CEST] <alevinsn> ? [06:39:14 CEST] <alevinsn> jkqxz: Before I submit the qsv patches to the ML, I wanted to confirm with you that the way I represented you and Luca are okay [06:39:27 CEST] <alevinsn> in the patches on your Web site, you had signed-off-by for both you and Luca [06:39:48 CEST] <alevinsn> I changed that to Reviewed-by, which I've seen James Almer do in his patches [06:39:51 CEST] <alevinsn> is that okay? [06:41:20 CEST] <atomnuker> (those things are mostly pointless and some people omit them, don't take them seriously) [06:42:00 CEST] <atomnuker> signed-off means you "sign-off" to the policies of the project, whatever that means, but you already do by submitting so its pointless [06:46:37 CEST] <Compn> doesnt hurt to ask [06:59:36 CEST] <alevinsn> I think it is nice to give proper credit [07:00:05 CEST] <alevinsn> but signed-off-by seems to be associated with the author of the patch [07:07:14 CEST] <wm4> that's how I interpret it [11:39:32 CEST] <jkqxz> alevinsn: To my mind, signed-off-by is the set of people who signed off on something for it to be committed. Therefore, I would add it to things which I commit as maintainer of the relevant thing. [11:40:01 CEST] <jkqxz> If the author is committing it themselves to code they maintain, then maybe only they appear. (Or not at all, since that is implicit.) [11:40:08 CEST] <jkqxz> People are pretty inconsistent about using it, though. [11:40:11 CEST] <nevcairiel> the SOB header means all sorts of different things to different people, the original usage the linux kernel uses is usually only used there =p [11:40:25 CEST] <jkqxz> True. [12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:c535436cbeea: avcodec/mlpdec: Fix runtime error: left shift of negative value -22 [12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:b20c71409b24: avcodec/fic: Fix multiple left shift of negative value -15 [12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:c0ffcb34c7e9: avcodec/clearvideo: Fix multiple runtime error: left shift of negative value -1024 [13:17:03 CEST] <ubitux> nevcairiel: how do you deal with align for cropping? [13:17:22 CEST] <ubitux> realloc when left cropping? [13:18:26 CEST] <ubitux> same question with sample skipping [13:19:15 CEST] <nevcairiel> probably [13:19:37 CEST] <BtbN> wm4, feel free to push that cuvid patch btw. [13:20:06 CEST] <wm4> already did [13:20:07 CEST] <ubitux> nevcairiel: it could be much faster if the dsp was handling the unaligned part with C [13:20:13 CEST] <ubitux> or something along these lines [13:20:26 CEST] <BtbN> ah, missed that. [13:20:44 CEST] <nevcairiel> ubitux: in most cases you would have to handle the entire thing in C then, which I doubt is going to be any faster then [13:20:58 CEST] <nevcairiel> and it seems like a questionable optimization with a lot of complexity [13:22:08 CEST] <ubitux> malloc+memcpy isn't great either when all you want is trimming 3 pixels on the left [13:22:38 CEST] <ubitux> but i don't know, it's hard to have a general rule for that [13:24:05 CEST] <BtbN> Why not just add an offset to the beginning, and reduce the width? [13:24:20 CEST] <BtbN> Because of alignment of the initial pointer? [13:24:49 CEST] <ubitux> yes [13:25:08 CEST] <nevcairiel> alignment is two fold, you need to first pixel to be aligned properly of course, and the stride needs to be aligned so that further lines are also aligned [13:25:54 CEST] <BtbN> yeah, probably not possible without either a memcpy, or a cropping parameter at the frame [13:26:02 CEST] <ubitux> which reminds me that i never got done with png dsp on aarch64 because of the alignment requierement [13:26:11 CEST] <ubitux> afaik the x86 dsp is handling it manually [13:26:19 CEST] <ubitux> to support DR or whatever it was [13:26:40 CEST] <ubitux> (or was it pngdec?) [13:30:10 CEST] <ubitux> ah it wasn't about alignment but about padding [13:30:25 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189617.html [13:31:05 CEST] <wm4> libav adds a cropping rect to AVFrame, so in theory you can crop by pixel [13:31:30 CEST] <BtbN> But doesn't that mean that every single encoder/filter/.. needs to be aware of it? [13:31:31 CEST] <wm4> of course that might be unusable in general [13:31:35 CEST] <wm4> that too [13:31:52 CEST] <ubitux> "if a user app returns pointers to some memory for direct rendering from get_buffer then it might be all kinds of stuff" [13:31:56 CEST] <BtbN> filters probably not as much, as long as they pass it through untouched [13:32:03 CEST] <ubitux> "for example it might be aligned but there might be data to the right like window decorations/border" [13:32:10 CEST] <nevcairiel> get_buffer specifically documents alignment requirements [13:33:12 CEST] <ubitux> shouldn't we have an alignment requirement check in avcodec encode side doing a realloc if needed? [13:33:29 CEST] <nevcairiel> perhaps [13:33:37 CEST] <ubitux> or we want it at frame level such that even lavfi could always assume alignment between filters? [13:33:53 CEST] <nevcairiel> I also said as much in my reply to nicolas, but I dont think per-codec alignment info is a practical thing [14:44:14 CEST] <BBB> nevcairiel: I partially disagree with what you wrote [14:44:23 CEST] <BBB> nevcairiel: I think a per-codec-*instance* is crazy [14:44:28 CEST] <BBB> nevcairiel: but per-codec certainly makes sense [14:44:37 CEST] <BBB> not all codecs have avx2 [14:44:48 CEST] <BBB> and updating that per-codec isnt so hard, you could even integrate that into the dsp_init functions [14:45:27 CEST] <BBB> unsigned ff_h264dsp_init(H264DSPContext *ctx); <- return value is max_alignment [14:45:33 CEST] <BBB> and then up that value for each arg dsp init [14:45:39 CEST] <BBB> (or pointer; whatever) [14:45:51 CEST] <BBB> however& I think it should be per-codec, not per-codec-instance [14:46:02 CEST] <BBB> since its unlikely that one h264 needs 16 and another 32 [14:46:07 CEST] <BBB> they likely both need 32 [14:49:53 CEST] <nevcairiel> per codec makes determining that even harder though, since you cant call the dsp function to figure it out [14:58:09 CEST] <BBB> maybe [14:58:41 CEST] <BBB> or you declare it in the dsp header file, and then you can [14:58:57 CEST] <BBB> we already have a substandard system (configure) to define which dec/* depends on which dsp [14:59:09 CEST] <BBB> so why not use that and automatically generate alignment contraints from that? [14:59:14 CEST] <BBB> this shouldnt be super-hard [14:59:30 CEST] <BBB> per-codec enable/disable is also configure-generated [15:24:59 CEST] <nevcairiel> I'm mostly worried about even more subtle bugs [15:25:08 CEST] <nevcairiel> because our typical test cases of memory are always fully aligned [15:25:15 CEST] <nevcairiel> so partial alignment will basically not be tested much [15:33:25 CEST] <ubitux> pixelutils tests do test alignment :3 [15:35:17 CEST] <wm4> alignment of what? [15:35:23 CEST] <ubitux> buffer [15:35:28 CEST] <ubitux> :/ [15:35:40 CEST] <ubitux> the pointer passed to the dsp func [15:35:54 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:4654baff125d: avcodec/opus_silk: Fix integer overflow and out of array read [15:35:55 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:d58fe0177453: tools/target_dec_fuzzer: Do not use codec_id to look up decoder, but use selected decoder directly [15:35:56 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:38e79d9d9c94: tools/target_dec_fuzzer: Do not attempt to fuzz VDPAU, its not supported [15:35:57 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:fc2c420b8293: avcodec/mimic: Fix runtime error: left shift of negative value -1 [15:35:59 CEST] <ubitux> it misalign it before testing function that are supposed to support misaligned data [16:10:13 CEST] <iive> nevcairiel: what is the issue here? [16:10:28 CEST] <iive> also isn't avx a lot more relax about alignment? [16:37:59 CEST] <BBB> nevcairiel: well [16:38:06 CEST] <BBB> nevcairiel: I believe most affected code is simd, right? [16:38:12 CEST] <BBB> nevcairiel: if we make it a goal to get 100% checkasm coverage [16:38:19 CEST] <BBB> nevcairiel: we can test it effectively as part of checkasm [16:38:22 CEST] <BBB> nevcairiel: which is part of fate [16:38:27 CEST] <BBB> nevcairiel: wouldnt that be enough? [16:57:32 CEST] <wm4> it's funny how I noticed problems with unaligned audio data and certain encoders years ago [16:57:58 CEST] <wm4> I was all like "ok this is libavcodec bullshit" and simply changed my internal audio code to work like avframe [16:59:45 CEST] <JEEB> sounds like a valid way of handling it [17:12:32 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:4ace2d22192f: avcodec/g723_1: Fix multiple runtime error: left shift of negative value [17:12:33 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:12936a4585bc: avcodec/dfa: Fix signed integer overflow: -2147483648 - 1 cannot be represented in type 'int' [17:12:34 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:9bf4523e4014: avcodec/webp: Fix null pointer dereference [17:15:27 CEST] <durandal_1707> ubitux: how is fft handled with avfft in lavc? [17:16:21 CEST] <durandal_1707> first element and last one is 0 for img part [17:34:22 CEST] <BBB> durandal_1707: the first elements img is the last elements real [17:34:51 CEST] <BBB> durandal_1707: so that it doesnt require (2^n)+1 elements where the first/last img are 0, but instead just 2^n elements, thus making memory management slightly easier [17:34:53 CEST] <BBB> (all this IIRC) [20:53:23 CEST] <jamrial> michaelni: when were you planning on tagging 3.3.1? [20:53:49 CEST] <jamrial> even if only a few fixes are backported, at least one of them is a very important CLI one [21:04:15 CEST] <michaelni> jamrial, i wanted to fix and backport a few more issues, ossfuzz found quite a few new issues in the last days [21:04:31 CEST] <jamrial> michaelni: ah ok [21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:0884b1c5ffe0: avcodec/golomb: Assert that k is valid in get_ur_golomb_jpegls() [21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:7b6a51f59c46: avcodec/shorten: Check k in get_uint() [21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:2ef0f3927114: avcodec/mss3: Change types in rac_get_model_sym() to match the types they are initialized from [21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:1283c4244767: avcodec/hq_hqa: Fix runtime error: left shift of negative value -207 [21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:df8575584dca: avcodec/shorten: Check residual size [21:29:27 CEST] <ubitux> michaelni: "unsupportd" typo in df8575584dcacde187d92ee3142800373fd34882 [22:24:44 CEST] <cone-671> ffmpeg 03Aaron Levinson 07master:b9d2005ea5d6: avformat/utils: free AVStream.codec properly in free_stream() [22:53:49 CEST] <cone-671> ffmpeg 03James Almer 07release/3.3:4f19268eee12: avcodec/options: factorize avcodec_copy_context() cleanup code [22:53:50 CEST] <cone-671> ffmpeg 03James Almer 07release/3.3:8119efdbec1f: avcodec/options: do a more thorough clean up in avcodec_copy_context() [22:53:51 CEST] <cone-671> ffmpeg 03Aaron Levinson 07release/3.3:329176adc52c: avformat/utils: free AVStream.codec properly in free_stream() [23:25:19 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:277e397eb596: avutil/softfloat: Fix overflow in av_div_sf() [23:25:20 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:e1b60aad77c2: avcodec/cdxl: Check format parameter [23:25:21 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:8a8335de030a: avcodec/dds: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [00:00:00 CEST] --- Sun May 7 2017